we're trying to figure out if it's possible to retrieve the size of a data segment or if we need to use hacks. it appears that we need to use hacks?
can't believe there isn't a data.length opcode
if you're looking for wasm memory, there is memory.size
this is the problem:
(data $HelloWorld "Hello, World!\n")
(global $HelloWorld-len i32 (i32.const 14))
anyway, there's probably a reason nobody uses wat
wat is meant to be a 1-to-1 representation of the wasm binary format, and the general idea with the binary format is that (like other binary formats for code) it should be efficient and possible to emit from a tool, not necessarily flexible or easy to write in a way that human-targeting PLs are. (It's still nicer than many bytecodes but that's not the primary purpose)
Said another way: the producer of a Wasm module can know how long its data segments are, because it emits them; so the binary format doesn't need an operator for this, and it would be unnecessary complexity for the VM to implement.
the VM already needs to know how long data segments are, due to memory.init instruction. it's just not currently exposed (in an useful way - trapping isn't useful) to the wasm guest for some reason.
Sure -- there's plenty that the VM knows about the guest that it could, in theory, expose to the guest. The question with a virtual-machine design is "why" rather than "why not" -- again, Wasm is designed to be a universal portable bytecode, not a convenient and friendly programming language for humans to write.
I'm offering a descriptive reason for why things are how they are, in my understanding; not trying to have a discussion on the merits; for the latter I'd encourage you to file issues on the Wasm design repo and drive an instruction-set extension (and receive much more feedback in the CG) if you're so inclined. The best we can offer here is "an interpretation of upstream".
Last updated: Jan 24 2025 at 00:11 UTC