www.digitalmars.com         C & C++   DMDScript  

D - D ABI?

reply Hauke Duden <H.NS.Duden gmx.net> writes:
I realize that it may be a little early for this, but are there plans to 
standardize the D ABI once the language is finalized and the compiler 
complete?

I think that the missing C++ ABI is the number one thing that has kept 
pure old C alive over all these years. Not being able to use C++ over 
compiled object boundaries pretty much prevents it from being used for 
precompiled libraries (i.e. almost all commercial ones).

Are there any plans to create a standard ABI for D?

Hauke
Sep 23 2003
next sibling parent Mark T <Mark_member pathlink.com> writes:
In article <bkp285$2hc9$1 digitaldaemon.com>, Hauke Duden says...
Are there any plans to create a standard ABI for D?
At least a standard name mangling method could be defined.
Sep 23 2003
prev sibling next sibling parent "Walter" <walter digitalmars.com> writes:
"Hauke Duden" <H.NS.Duden gmx.net> wrote in message
news:bkp285$2hc9$1 digitaldaemon.com...
 I realize that it may be a little early for this, but are there plans to
 standardize the D ABI once the language is finalized and the compiler
 complete?
I hadn't thought about it.
 I think that the missing C++ ABI is the number one thing that has kept
 pure old C alive over all these years. Not being able to use C++ over
 compiled object boundaries pretty much prevents it from being used for
 precompiled libraries (i.e. almost all commercial ones).
Actually, DMC++ can call functions in VC++ DLL's, because they use the same ABI.
 Are there any plans to create a standard ABI for D?
I don't see a problem with doing that.
Sep 23 2003
prev sibling next sibling parent reply Olaf Rogalsky <olaf.rogalsky theorie1.physik.uni-erlangen.de> writes:
Hauke Duden wrote:
 I think that the missing C++ ABI is the number one thing that has kept
 pure old C alive over all these years. Not being able to use C++ over
 compiled object boundaries pretty much prevents it from being used for
 precompiled libraries (i.e. almost all commercial ones).
A single ABI standard? For which platform? There is more than windows and i386! Different platforms/cpus have different needs, nevertheless, an unified name mangeling scheme is desirable. -- +----------------------------------------------------------------------+ I Dr. Olaf Rogalsky Institut f. Theo. Physik I I I Tel.: 09131 8528440 Univ. Erlangen-Nuernberg I I Fax.: 09131 8528444 Staudtstrasse 7 B3 I I rogalsky theorie1.physik.uni-erlangen.de D-91058 Erlangen I +----------------------------------------------------------------------+
Sep 24 2003
parent reply Hauke Duden <H.NS.Duden gmx.net> writes:
Olaf Rogalsky wrote:
 A single ABI standard? For which platform? There is more than windows 
 and i386!
 
 Different platforms/cpus have different needs, nevertheless, an unified
 name mangeling scheme is desirable.
There are things that can be defined independent of the platform. For example, the way exceptions are handled, parameters are parsed or the frame pointer is updated in function calls. C is the proof for this: the C ABI is standardized and thus all compiled objects can interact with each other, no matter which compiler produced them. The important thing is not that binaries produced for different platforms do everything the same way, but that binaries for the SAME platform can work together. I guess for D there are some things that can be platform independent: The memory management interface (garbage collector), generic vtable layout, exception handling and the function/delegate calling conventions. Struct/class member layout and stuff like that is something that will probably have to be platform specific, of course. But I still think there should at least be a defined standard for the most common platforms (e.g. IA32). Hauke
Sep 24 2003
next sibling parent "Walter" <walter digitalmars.com> writes:
"Hauke Duden" <H.NS.Duden gmx.net> wrote in message
news:bks4j7$mmb$1 digitaldaemon.com...
 There are things that can be defined independent of the platform. For
 example, the way exceptions are handled, parameters are parsed or the
 frame pointer is updated in function calls.
That turns out to be not as practical as it should be. For example, exceptions are handled totally different on linux than on Win32, because Win32 has an operating system defined way of doing it, and linux does not. Function call/return sequences are set by compatibility with the local C compiler, and those differ from OS to OS even on the same CPU.
 C is the proof for this: the C ABI is standardized and thus all compiled
 objects can interact with each other, no matter which compiler produced
 them.
C doesn't do exception handling :-( but it is of major importance for D to match the C ABI well enough to interact with C binaries.
 The important thing is not that binaries produced for different
 platforms do everything the same way, but that binaries for the SAME
 platform can work together.
I agree with you there.
 I guess for D there are some things that can be platform independent:
 The memory management interface (garbage collector), generic vtable
 layout, exception handling and the function/delegate calling conventions.

 Struct/class member layout and stuff like that is something that will
 probably have to be platform specific, of course. But I still think
 there should at least be a defined standard for the most common
 platforms (e.g. IA32).

 Hauke
Sep 24 2003
prev sibling parent Olaf Rogalsky <olaf.rogalsky theorie1.physik.uni-erlangen.de> writes:
Hauke Duden wrote: 
 There are things that can be defined independent of the platform. For
 example, the way exceptions are handled, parameters are parsed or the
 frame pointer is updated in function calls.
E.g., the Power ABI (which is used by IBM's own UNIX and in a variant by Apple) uses registers for argument passing in most cases. This is possible, because the Power PC has lots of registers, but you can't do it on a CISC processor. It is therefore impossible to standardise it.
 C is the proof for this: the C ABI is standardized and thus all compiled
 objects can interact with each other, no matter which compiler produced
 them.
Yes, but every vendor has invented his own ABI, and we most be able to interface with it, because D has support for calling C objects.
 The important thing is not that binaries produced for different 
 platforms do everything the same way, but that binaries for the SAME 
 platform can work together.
I agree. But the latest ABI change in the gcc showed, that binary compability even on different versions of the same compiler is not for safe.
 Struct/class member layout and stuff like that is something that will 
 probably have to be platform specific, of course. But I still think 
 there should at least be a defined standard for the most common 
 platforms (e.g. IA32).
^------in my terminology a platform is a compound of processor and OS Sorry, I don't beleive in binary compability across different OS's or processors. Gruesse, Olaf -- +----------------------------------------------------------------------+ I Dr. Olaf Rogalsky Institut f. Theo. Physik I I I Tel.: 09131 8528440 Univ. Erlangen-Nuernberg I I Fax.: 09131 8528444 Staudtstrasse 7 B3 I I rogalsky theorie1.physik.uni-erlangen.de D-91058 Erlangen I +----------------------------------------------------------------------+
Sep 25 2003
prev sibling parent Mike Capp <aphelion clara.co.uk> writes:
Hauke Duden wrote:

 I realize that it may be a little early for this, but are there plans to 
 standardize the D ABI once the language is finalized and the compiler 
 complete?
Amen, brother. I don't think it need wait until the language is finalized though; a draft ABI could evolve alongside everything else and would signal that D is not going to repeat C++'s mistake. I agree with you that C++'s lack of an ABI has been the prime reason for the miserable failure of component-based development in that language. I'm a newbie here and am still working through the spec (accumulating copious notes en route), but this is *hugely* important. Cheers, Mike
Sep 30 2003