• Wolfgang Draxinger (36/36) Jul 15 2006 I just came back to http://www.digitalmars.com/d/abi.html and

Wolfgang Draxinger <wdraxinger darkstargames.de> writes:

I just came back to http://www.digitalmars.com/d/abi.html and
saw, that there have been no recent changes. I wonder, if this
is the current state or if there has been further development on
the topic.

If not I'd like to make a few suggestions

Describe memory offsets in multiples of the plattforms native
pointer size (i.e. sizeof(ptrsize_t)). Currently the ABI is
limited to 32 bit. (One might double the sizes implicitly for 64
bit plattforms).

Separate the ABI in Compile Level and Link Level.
The Compile Level operates on the alignment of data within memory
and the data transfer methods within a compilation object.
The Link Level however should be coupled to the output format
(COFF, ELF, $whatever). IMHO it makes sense so describe Link
Level ABI for different object formats.
E.g. the component system I've developed for my engine, called
ECS, similair to DDL, stores the properties of code objects in a
hierachical, EMBF like (EMBF a binary XML counterpart) structure
without elude to name mangling and other tricks. Since ECS
provides a sound set of the runtime code that would otherwise
call statical constructors (and module inits) it also conflicts
a bit with parts of any ABI that would force strict rules on
that topic. Since static constructor calling and module
initialization is part of the Link Level, logically put it
there. Link systems that differ from the usual ELF/PE/COFF will
not by inflicted that way.

Currently declaring a class $xxx implicitly instanciates a
Class$xxx, StaticClass$xxx and an instance that names
Static$xxx. I wonder if there could be a less namespace
polluting solution to that. Maybe somee new properties on the
modulespace?

I'm nearly done converting all the C++ source code of my 3D
engine to D. Where converting means: "puting nearly 20% of the
code to /dev/null". I just love D!!!

-- 
Wolfgang Draxinger