Binary format bikeshed: where the `typeidx` immediate is located
还没有人认领这个 Issue。
评估
- 难度
- 4/5
- 预计耗时
- 3-5 天
- 新手友好度
- 45/100
- Issue 类型
- 功能
- 描述清晰度
- 基本清楚
- 活跃度
- 活跃
- 技术栈
- wasm
- 领域
- compilers
调研方向
The issue discusses the binary format of the memarg immediate in WebAssembly proposals. Review the spec for multibyte-array-access and acquire-release-atomics to understand the current layout. Examine the parser code that handles these flags and immediates. The goal is to propose a consistent ordering of immediates based on flag bits, ensuring the change is compatible with existing and related proposals.
由索引模型根据 Issue 内容生成。
描述
Currently this proposal specifies memarg ::= flags:u32 offset:u32 typeidx:u32 when flags has bit 5 set, but subjectively I find this a bit inconsistent with other immediates-specified-by-flags. For example bit 6, implying a memory index immediate, looks like memarg ::= flags:u32 memidx:u32 offset:u32. For the acquire-release-atomics proposal bit 4 implies memarg ::= flags:u32 ordering:u8 offset:u32 (at least I'm pretty sure given my current reading of the explainer and parser).
I opened a somewhat related issue at WebAssembly/acquire-release-atomics#28 but I think it'd be a bit nicer if the flags bits had payloads present after the flags leb in increasing order of the bits. Specifically I'd propose:
;; already specified in core wasm
memarg ::= flags:u32 offset:u32 if (flags >> 4) == 0b000
| flags:u32 memidx:u32 offset:u32 if (flags >> 4) == 0b100
;; added by acquire-release-atomics
memarg ::= ...
| flags:u32 ordering:u8 offset:u32 if (flags >> 4) == 0b001
| flags:u32 ordering:u8 memidx:u32 offset:u32 if (flags >> 4) == 0b101
;; added by multibyte-array-access
memarg ::= ...
| flags:u32 typeidx:u32 offset:u32 if (flags >> 4) == 0b010
;; added by both
memarg ::= ...
| flags:u32 ordering:u8 typeidx:u32 offset:u32 if (flags >> 4) == 0b011
where 0b110 and 0b111 are both parse errors with this proposal (memory index + type index). The 0b011 case might be invalid for now though while this proposal isn't extended to atomics, though.
Basically though I wanted to ask: what would others think about moving the typeidx immediate to before offset:u32?
EDIT: sorry forgot to finish writing the issue title before I hit submit so the notifications sent out have a pretty bad issue title :(
- 主要语言
- WebAssembly
- 星标
- 4
- 派生
- 1
- 平均合并
- 16 小时 35 分钟
- 30 天内合并 PR
- 1
环境准备
- 没有 Dockerfile 或 Docker Compose 文件
- 没有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
WebAssembly/multibyte-array-access 的其他 Issue
-
难度 3/5 1-2 天 新手友好度 50/100
WebAssembly/multibyte-array-access#8 · 1 条评论 ·
-
难度 5/5 一周以上 新手友好度 35/100
WebAssembly/multibyte-array-access#5 · 11 条评论 · 1 个 reaction ·
-
难度 5/5 一周以上 新手友好度 25/100
WebAssembly/multibyte-array-access#4 · 4 条评论 ·
-
难度 5/5 一周以上 新手友好度 35/100
WebAssembly/multibyte-array-access#3 · 5 条评论 ·
-
难度 5/5 一周以上 新手友好度 25/100
查看 WebAssembly/multibyte-array-access 的全部 Issue
相似的 Issue
-
难度 2/5 1-3 小时 新手友好度 72/100
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 78/100
JakeChampion/lang#10539 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 78/100
paritytech/revive#633 ·
维护者通常 2 天内回复
-
难度 1/5 1 小时以内 新手友好度 92/100
vlang/v#29099 · 1 个 reaction ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 84/100
维护者通常 1 天内回复