Implement 32-bit Support
bigfootjon opened this issue · comments
I have an use case (for a personal project) to deploy a starlark-parsing binary to a Raspberry Pi 3, which is a 32-bit ARM platform (Rust target armv7-unknown-linux-gnueabihf).
However, when I try and compile for armv7 (or any 32 bit platform, for example i586-unknown-linux-gnu) I get compile time errors in a few places:
https://github.com/facebookexperimental/starlark-rust/blob/main/starlark/src/values/layout/pointer.rs#L73-L78
https://github.com/facebookexperimental/starlark-rust/blob/main/starlark/src/syntax/ast.rs#L81-L83
https://github.com/facebookexperimental/starlark-rust/blob/main/starlark/src/values/layout/pointer_i32.rs#L38 (this constant value is simply too large)
That seems to be all of them at compile time, but due to an unrelated problem I don't have a cross-linker on the device I'm writing this from. I assume due to the first link above that there are runtime problems. So I'm wondering, are there any plans to support 32-bit? (I'm aware I'm asking to roll back the clock and that no one should use 32-bit any more, but it is what it is)
CC @stepancheg who might have a better idea how feasible it is. There are two things that immediately spring to mind:
- We use pointer tagging to represent various data - in particular we have 3 bits, 1 for if the value is frozen, 1 for if it's an int, and 1 for if it's a string. Given we can't have frozen int, I imagine we could compress that to 2 bits, which would meet the alignment guarantees of 32 bit. I think we could probably arrange the pointers to also be added to 8 bytes given they all come from our heap as an alternative.
- We encode the int's in the pointer. Currently we have 64 bit pointers, 3 bits of tags (although could be 2) and then put 32 bits of int in the remaining 61 bits. We could have a conditional feature where on 32 bit we only stored 30 bits of int, and made it a runtime error if you produced an int out of that range. In #6 we are discussing having a BigInt fallback, which might mean that we could just say you always use the fallback on 32bit platforms or something.
The size of the AST is of no concern, and that conditional can be made 64bit only - it's just a debug check.
In fact, with point 1, I'm wrong - we use the 3 tag bits to represent 5 fundamental states (frozen, unfrozen, frozen-str, unfrozen-str, int) - so can't compress those to 2 bits. I think the best path to 32bit support would be to add bigint as per #6, then on 32bit not have pointer-tagged int at all, making the pointer tag 2 bits and the int packed into a pointer not a thing at all.
I'm interested in it on 32bit as well. I was playing around trying to get it running in web assembly, but I hit issues with 32-bit compatibility since wasm is only 32-bit.
I was trying to experiment with 32 bit rust.
And I stumbled upon an interesting problem: I have nowhere to test it: both mac and linux are 64 bit, and setting up qemu is too much trouble. Especially in CI (both our internal and external on github).
I also tried webassembly, and the problem was, both interepreter I tried (don't remember which exactly) were very poor at providing diagnostics. Like if there's panic, you can only guess where it comes from.
Do you have any good advice how to work with 32-bit code?
32 bit starlark works (at least on wasm32-wasi) since commit e0c1d81.