I don't see a problem here. 32 bit relative addresses are sufficient. We can assume programs will never have more than 2 GB of code.
I think that's a little restrictive. It requires a separate allocation method for code blocks than for regular data, as well as special handling in the GC, because we do want code to be garbage collected in the end. We also can't guarantee that C code is within that offset limit.
If speed is a concern, I would advise that we benchmark the speed difference of both methods. Considering all the overhead function calls incur, including the spills, I wonder if the difference in speed would be very visible. My instinct is that it might matter in fibonacci, but it probably won't be an issue in practice.
There's also the possibility that we could use both mechanisms at once. Relative calls for all calls that happen to fall within that 32-bit limit, absolute calls for the rest. We would just have to pad the shorter opcode sequence with noops so they both take the same space.
- We assumed sizeof(int) == sizeof(void *) in the d8 extensions we
wrote and in the Tachyon C proxy generation. We will need to change it to adequately support 64 bits.
That should be easy to fix.
I modified the v8 code to use intptr_t in places where that was assumed. It's an integer type guaranteed to be able to hold a pointer value. It could technically be bigger than a pointer, but likely never ever will be in practice.
Do the 64 bit port first. I don't think it will be more than a day of work, and the changes needed will be fairly permanent (i.e. not just a quick workaround).
I'll be at the lab on Monday to help with the FFI issues and debugging.
- Maxime