Comment by whizzter
16 days ago
I've built some prototypes and is there any particular reason you didn't go for NaN-tagged indexes instead unless it's for 32bit? Numeric cases would've had less loads since it's a number directly and indexes in the mantissa should be enough for at least about 48bit of ref space.
I did consider a similar system ages ages ago for more easily embedding a JS engine into a C/C++ codebase, type-shapes would be allocated on a per page-basis so the runtime/GC wouldn't need any V-table pointers,etc on top of regular plain C object shapes to locate the type info but instead rely on an indirection per-page for those types shared with the C world. Ultimately felt a bit too complicated for something meant for embedding.
I didn't really consider NaN tagged indexes: Rust made using an enum basically a given. That being said, I probably wouldn't change even if could now. A NaN tagging scheme blocks out at least 11 bits out of your from your useful payload, leaving you with at most 46 bits to split between your discriminant and payload, while giving you freedom to express arbitrary doubles on the stack.
A tagged index gives you 7 bytes to use for payload: This for instance gives us the possibility of representing all but the most decimal heavy doubles on the stack (we drop the bottom byte from a double if it is all zeroes, and save the remaining data on the stack), but also allowing up to 7 byte strings on the stack! And all safe integers! And up to 56 bits worth of Bigints!
So, a tagged enum is pretty powerful :)
Some pros definetly, my target was mainly games so coherent and/or low cost handling of primitive values (numbers) was a priority. With NaN tagging you can do all operations sans addition with the regular floating point instructions and if the CPU has a canonical NaN representaation that doesn't collide with the chosen tag pattern then there is basically no cost for the dynamic typing when it comes to numeric operations.