32bit support?

[vados-cosmonic]

Hey there, thanks for building this project -- it's one of the most promising JS engines I've seen so far.

I'd love to be able to build this engine in WebAssembly + WASI and use it in the "modern" Wasm ecosystem, but right now the only WASI target present for Rust is wasm32-wasip1/wasm32-wasip2 (and at some point wasm32-wasip3 will exist)... Unfortunately, Nova doesn't support 32bit but it'd be great if it did, so the build could work. I did some early experimentation and the requirement for 64bit is obviously quite fundamental (helpfully there's an assert that made that clear!).

I'm happy to help with doing the work to make this possible but wanted to check if 32bit support was an explicit non-goal of the project, which is reasonable. wasm64-unknown-unknown is present, but wasm64-wasi{p1,2,3,} are probably not going to be out soon, so would love to hear your thoughts!

[aapoalas]

Hello! Thank you for the interest and the kind words <3

32-bit support is not an explicit non-goal; I've been toying with the idea basically from the start. The big sticking point that I have with it is the "reference representation". If you take a look into value.rs and search for eg. Object(OrdinaryObject<'a>) you'll find the definition of what an ordinary object (like one created with an object literal {}) looks like when it is in the Value enum. Inside is effectively a 32-bit (non-zero) integer wrapped in some pretty paper. With the tag of the Value enum the representation comes out to effectively be a (u8, MaybeUninit<[u8; 3]>, NonZeroU32). This is obviously then aimed at fitting into a single register on a 64-bit machine (and I should strongly consider adding an align(8) requirement to make that even clearer).

But on a 32-bit architecture it's less clear that that's useful / reasonable. For wasm specifically... well, it may actually still be the proper choice since the machines running wasm are still likely 64-bit machines and we do fit into a register there. But if we're talking actual, honest-to-god 32-bit machines then it would perhaps make more sense to slim the Value down to just 4 bytes, (u8, NonZeroU24) kind of way. At that point we run into a lot of trouble:

1. There's unfortunately a fair bit of code in the engine assuming that SmallString has 7 bytes of payload capacity. In a 4-byte Value it would only have 3.
2. Basically every piece of integer-related code in the engine assumes that all safe integers fit into a SmallInteger; in a 4-byte Value this is not the case and we're in for a world of hurt.
3. All object reference types are built using 32-bit (non-zero) integers at their core; in a 4-byte Value we'd still want their "strongly-typed" form to be a 32-bit integer but when placed in a Value we'd want to chop the top byte off to make room for the variant. The basic idea here isn't too hard, just make all object reference creation check that the integer value doesn't overflow a 24-bit unsigned integer, but getting the Value, Object, Function, WeakKey, and possible other enums to understand this will require a whole new set of types that are based on [u8; 3] instead :(

If you want to try out a wasm build, I'd think the best choice would be to skip trying to go down to 4-byte Values (the memory savings would be cool, but the loss of power of on-stack integers and strings would be significant as well) and just loosen the restriction on usize. There's sure to be a lot of places where we run into issues with usize not being equal in size to u64 but it shouldn't be uncountably many :)

[vados-cosmonic]

Thanks for the break down on possible directions -- excited that there is a possible path forward here!

If you want to try out a wasm build, I'd think the best choice would be to skip trying to go down to 4-byte Values (the memory savings would be cool, but the loss of power of on-stack integers and strings would be significant as well) and just loosen the restriction on usize. There's sure to be a lot of places where we run into issues with usize not being equal in size to u64 but it shouldn't be uncountably many :)

I think I understand this suggestion! Do you have any places that would be good to start/files to pay close attention to? It feels like I'd need to basically remove the assert and pore through the code to try to find anywhere where the relationship needs to hold. value.rs is the obvious place to start, but any other pointers would be appreciated!

[aapoalas]

I think I understand this suggestion! Do you have any places that would be good to start/files to pay close attention to? It feels like I'd need to basically remove the assert and pore through the code to try to find anywhere where the relationship needs to hold. value.rs is the obvious place to start, but any other pointers would be appreciated!

This'll match a lot of places, but searching for as usize, as u64, and as i64 will give you likely places of mistaken assumptions.

[vados-cosmonic]

Appreciate it, thank you! 🙇

[aapoalas]

Oh, also usize::try_from might match a bit.