On 2011-03-04, at 10:47 PM, chevalma@iro.umontreal.ca wrote:
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.
Code allocation will need to be treated specially in any case, in particular because it has to be in an area of memory where the execute bit is on (or at least we need to organize the system so this is an option). There is also a need (on most architectures) to flush the data caches when code objects are created, so that the instruction cache sees the new code. We can arrange things so that the Tachyon code is in an area that doesn't span more than 2 GB. The foreign code (C) can be anywhere if we use a trampoline in the Tachyon code area, in other words a 32 bit relative jump to a 64 bit jump.
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.
It will be interesting to measure the speed difference, but as I say there is no strong reason to avoid the faster (and more compact) 32 bit relative jumps.
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.
Unfortunately, in terms of code space it is just as inefficient, and it will be less efficient in terms of speed due to the additional padding (either noops or short relative jumps). But I'm curious to know by how much.
Marc