Re: Class layout accross multiple architectures.

[mrs at wrs dot com (Mike Stump)]

> Date: Sat, 15 Aug 1998 13:08:09 -0400
> From: Ben Scherrey <scherrey@gte.net>
> To: egcs@cygnus.com

> My desire is to take this one step further.

Do it.  The benefit of supporting egcs is that the costs will be much
smaller than the others and the incremental cost is greatly reduced.

> Just how large a difference is there between the object layouts of
> various hardware/OS implementations of egcs?

Fairly Small.

Well, I assume you already know about the layout differences with C
and vendor C++ across all your platforms and their implementation
costs.  Say this is 100.  The incremental egcs differences across all
of them and implementation cost is around 30.  The number would be
lower, much lower, but you don't support enough platforms yet.

Now, I know the 30 sounds kinda high, it is, but, the benefit is the
next hardhard/OS platform's cost is down at around 4 (or lower),
instead of around 20 I might guess.

> I guess the first platforms we'd like to support are probably
> Linux/Intel, Solaris/SPARC, and HP/Ux on
> whatever-processor-is-in-the-9000. I suspect that some areas should
> be pretty consistent but that others will be entirely platform
> dependent.

Pretty consistent.  The biggest variance, is something like
-fvtable-thunks.  It is the default on some platforms like Linux, and
not on others.  From there, are we dealing with 64 bit pointers or 32
bit pointers?  That's about it.

If you autoconf for such things, then the incremental cost should be
down to near zero for new platforms.  Try that with any other
solutions!

You'll spend more maintenance time on existing platforms than new
ports I suspect.  Though this is controllable as it will be lock
stepped with new compiler releases.  Most of the velocity is in the
past, but up coming velocities will be things like:

  * An _experimental_ new ABI for g++ can be turned on with -fnew-abi.
    The current features of this are more efficient allocation of base
    classes (including the empty base optimization), and more compact
    mangling of C++ symbol names (which can be turned on separately
    with -fsquangle).  This ABI is subject to change without notice,
    so don't use it for anything that you don't want to rebuild with
    every release of the compiler.

Also, we may rearrange vbases some, but that's about it for my radar
screen.  Most of the aggressive improvements I can forsee in g++ arise
from things like type tracking for virtual dispatching and type info,
and smarter inlining, which involve code generation, but not abi
issues.  One that I can forsee that affects the abi is massive global
rearrangement of code from runtime or link time feedback.  You don't
have to worry about this one for 4 years though.

> Is it possible to effectively abstract out these layouts?

Of course.  It is even easier than the previous work your have done
(if you abstracted it).