binary compatibility ABI (was: Re: [boehm-gc] Import 6.3 alpha 1)

Thu Aug 14 22:40:00 GMT 2003

On Friday, Aug 15, 2003, at 05:21 Pacific/Auckland, Jeff Sturm wrote:
> On 2003年8月14日, Andrew Haley wrote:
>>> static int a, b;
>>> ...
>>> return a + b;
>>>>>> Does this require 2, 3 or 4 memory loads?
>>>>>> (I believe 2 is the answer for non-PIC, 4 for PIC. If we take 
>>> advantage
>>> of the fact that static fields are at a fixed offset from the class
>>> record, it can be done in three, while preserving position 
>>> independence.)
>>>> Unless a and b are in the exact same class as the 'return a + b'
>> statment, the positions of a and b relative to the class record may
>> change.

Yeah. With full binary compatibility, and assuming 'a' and 'b' are in 
another class, its 5 loads:
load offset of a
load offset of b
load class pointer
load a
load b
However the compiler should have a better chance to optimize this than 
it does for PIC loads. eg the class pointer will most likely already be 
loaded, because it is needed for the class initialization check anyway, 
and it should be able to schedule the loads effectively. I doubt it 
will be any slower in most cases than what we have now for PIC. It 
might even be faster due to better scheduling & locality.
If a and b are in the same class, we can always skip the loading of 
offsets as they are known at compile time, assuming the size of 
non-user fields in the class object is fixed by the ABI. If a and b are 
in another class but the same binary, we can skip the offsets only if 
we do not allow runtime class replacement. Thats probably a reasonable 
thing to do by default for user code, but perhaps not for libgcj.
Non-static field loads are much the same, in that offsets are known at 
compile time for fields in the same class and maybe the same 
compilation unit. The catch is that in classes that don't extend 
directly from Object, we don't know the size of our superclasses - in 
this case there would be just one offset to load for all fields in the 
class, which is added to the object pointer to get the base offset. For 
classes that extend directly from Object (or, perhaps, have 
superclasses that are all in the same binary unit) we can skip that too.
Regards
Bryce.