Stream: git-wasmtime

Topic: wasmtime / issue #8674 Implement the table64 extension to...

Wasmtime GitHub notifications bot (May 21 2024 at 18:53):

alexcrichton added the wasm-proposal:memory64 label to Issue #8674.

Wasmtime GitHub notifications bot (May 21 2024 at 18:53):

alexcrichton opened issue #8674:

The memory64 proposal was recently updated to include 64-bit tables in addition to 64-bit memories. Support for this extension has been implemented in wasm-tools and the main branch of Wasmtime is now using this version of wasm-tools. Wasmtime, however, does not yet implement the table64 extension and this is intended to track that.

Support for the table64 extension should be relatively simple in Wasmtime but it'll require a number of refactorings to switch indexing types and such. An (incomplete) list of implementation items to handle for this will be:

• Wasmtime's representation of table types should be updated with 64-bit limits and a table64 flag
• Methods taking indices in Wasmtime, such as this, should switch to u64 instead of u32.
• Libcalls involving tables, like this, should switch to u64 values.
• Translation of invoking libcalls should switch to using 64-bit values instead of 32-bit values. 32-bit tables will zero-extend indices to 64-bit values.
• Embedder API methods, like Table::get, should switch to u64.

More-or-less what I'm thinking is that a few key locations need to switch to u64 and then whack-a-mole is played with rustc to figure out where else needs to be switched to a u64. One point of note I'll say is that in general it's best to avoid as casts in this refactoring. Casting with as loses information in top bits if casting to a smaller size and that can accidentally cover up cases that should be out of bounds or trap. Instead u32::try_from or usize::try_from should be used where possible with appropriate handling of the error (e.g. bubbling it up or unwrapping with a comment as to why the unwrap is ok)

Wasmtime GitHub notifications bot (Jun 05 2024 at 01:32):

ssnover commented on issue #8674:

I'm up for a game of whack-a-mole if you could assign me.

Wasmtime GitHub notifications bot (Jun 05 2024 at 01:49):

alexcrichton assigned ssnover to issue #8674.

Wasmtime GitHub notifications bot (Jun 17 2024 at 20:15):

alexcrichton commented on issue #8674:

If you're interested @ssnover some "getting started" tests can be enabled by commenting out this block now that the spec test suite has the table64 tests inside of it. Note though that those are not exhaustive tests so you'll likely want to write a test or two of your own as well.

Wasmtime GitHub notifications bot (Jun 30 2024 at 14:54):

ssnover commented on issue #8674:

Hi @alexcrichton , sorry to go quiet on this issue after picking it up. I have a branch with most of the changes made, but I'm left with interactions around the i31ref type. Is there any equivalent being introduced by memory64 for an i63ref that is superseding or living alongside i31ref?

Wasmtime GitHub notifications bot (Jul 01 2024 at 20:30):

fitzgen commented on issue #8674:

There is not an i63ref, so no need to worry about it.

Wasmtime GitHub notifications bot (Sep 04 2024 at 18:10):

lwshang commented on issue #8674:

@ssnover Are you still working on it? If you’ve moved on to other things, I’d be happy to take it over and help move it forward.

Actually, the project I’m working on is blocked due to the lack of table64 support in Wasmtime. So, I’ll start implementing it anyway.

Last updated: Dec 23 2024 at 12:05 UTC