This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: binary compatibility ABI (was: Re: [boehm-gc] Import 6.3 alpha 1)
- From: Andrew Haley <aph at redhat dot com>
- To: Tom Tromey <tromey at redhat dot com>
- Cc: Bryce McKinlay <bryce at mckinlay dot net dot nz>, Jeff Sturm <jsturm at one-point dot com>, Ranjit Mathew <rmathew at hotmail dot com>, <java at gcc dot gnu dot org>
- Date: Thu, 21 Aug 2003 12:11:48 +0100
- Subject: Re: binary compatibility ABI (was: Re: [boehm-gc] Import 6.3 alpha 1)
- References: <839A9B20-CEA8-11D7-AD15-003065F97F7C@mckinlay.net.nz><87llto46dk.fsf@fleche.redhat.com>
Tom Tromey writes:
> >>>>> "Bryce" == Bryce McKinlay <bryce@mckinlay.net.nz> writes:
>
> >>>> static int a, b;
> >>>> ...
> >>>> return a + b;
>
> Bryce> Yeah. With full binary compatibility, and assuming 'a' and 'b' are in
> Bryce> another class, its 5 loads:
>
> Bryce> load offset of a
> Bryce> load offset of b
> Bryce> load class pointer
> Bryce> load a
> Bryce> load b
>
> Isn't there a missing `load otable pointer' in here?
> And to get the otable, don't we have to dig through the vtable first?
> I must still be missing something.
You seem to be assuming a specific model for handling binary
compatibility of static members.
> It could be fewer loads, if we put `location of a' and `location of b'
> into the current class's otable:
That's what I was thinking of doing. But as this isn't externally
visible it's an implementation decision, not an ABI issue.
But yes, it seems to me that this scheme is just as good as the scheme
used by C for PIC.
Andrew.