Michel Fortin wrote:
On 2009-04-13 09:43:53 -0400, Frits van Bommel
<[email protected]> said:
(How does this combine with the "D ABI" anyway? I know binary
compatibility between the different compilers is a bit of a pipe dream
at the moment, but the only way that could work would be to
standardize any and all shuffling of class fields...)
Interesting observation.
But you don't necessarily need to standardize the shuffling algorithm.
If the offsets for fields in a class could be resolved at link time (the
compiler could dump the offsets in the object file), then the linker
could arange the final executable for any layout. The same could be done
for virtual functions too, giving us a true non-fragile ABI capable of
supporting changes in the order of member fields and functions.
Some problems I see with this:
* Good luck implementing that for all of OMF (DMD/win), COFF (GDC/win),
ELF(anything *nix).
* Same for LLVM bitcode, for LDC and any other future compilers based on LLVM.
Especially because this is a *typed* IR, and optimizations usually work best if
you don't work around types with pointer<-->int conversions.
* Implementing this without reducing the quality of generated code; some
architectures allow better instructions if you know the offset is below a
certain limit, which must then be known at compile-time (except for something
like LLVM, where link-time is early enough for this if you're generating IR
instead of native code at first).
* If you do this, you don't know how big a class body is at compile-time
(because padding is unknown). So the compiler doesn't know what size to allocate
in the stack frame for 'scope c = new C;"
So yeah, in theory this might be possible, but I don't know of any object format
that supports all these without it pessimizing the generated code. I just don't
think it's worth it at the moment.
Though if you feel like extending LLVM to support this... (it's IR object format
is probably closest to efficiently supporting something like this due to
arbitrarily-complex constant expression support in IR and inter-module
optimizations. You might be able to get it to work, as long as the offsets and
sizes are known by the time the assembler gets involved)
It would certainly allow support for some other cool stuff, like adding fields
and (virtual) methods to classes from other object files (aka modules).
