Closed titzer closed 1 year ago
Aren't you doing to have to lookup the memory refereed to by memindx
anyway when doing a load or store? e.g to look up its bounds?
Not for memory 0; the interpreter caches its base in a register and uses the same virtual memory protections for OOB access as JIT-compiled code does.
Could you encode the is64 in the low bit of the base register?
Oh, indeed, could be a nice idea. I'll think on that a bit.
This does mean an additional subtract (of 1
) in the interpreter, while JIT code will be specialized to the 64-bittitude of the memory and the offset immediate, allowing the -1
to be folded in.
@titzer, given there is a way to make it work by tagging the base register are you ok with close this out or mark as post-mvp?
If you still want to pursue it perhaps we can discuss in the meeting this week. I'd be curious to hear what folks think about how much we should be tuning specifically for interpreters.
Let's chat about it in the meeting.
We decided not to require a flag bit.
For in-place interpreters (i.e. ones that use the original Wasm bytes), an issue with memory64 is how to determine whether the index operand is a 32-bit or 64-bit value. As proposed, this information is statically-determined from the memory declaration. Right now, the in-place interpreter design in Wizard doesn't need to access per-module information for memory instructions (which would be an additional indirection from
instance->module->memory[memindx].is64
). Currently, Wizard skips the flags byte of memory loads and stores. Thus supporting memory64 would have a performance cost.However, we could (at no cost to other tiers) require that memory instructions that refer to a 64-bit memory have an additional 'is64' flag set. That flag is easy to check in an interpreter. It would be statically required to set the flag bit to
1
for 64-bit memories and0
32-bit memories. All other execution tiers could ignore this; i.e. it is a validation-time only check.Thoughts?