D - D ABI?
- Hauke Duden (9/9) Sep 23 2003 I realize that it may be a little early for this, but are there plans to...
- Mark T (2/3) Sep 23 2003 At least a standard name mangling method could be defined.
- Walter (6/14) Sep 23 2003 I hadn't thought about it.
- Olaf Rogalsky (12/16) Sep 24 2003 A single ABI standard? For which platform? There is more than windows
- Hauke Duden (18/23) Sep 24 2003 There are things that can be defined independent of the platform. For
- Walter (10/27) Sep 24 2003 That turns out to be not as practical as it should be. For example,
- Olaf Rogalsky (20/33) Sep 25 2003 E.g., the Power ABI (which is used by IBM's own UNIX and in a variant by
- Mike Capp (10/13) Sep 30 2003 Amen, brother. I don't think it need wait until the language is
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
Mark T <Mark_member pathlink.com> 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
"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
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
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
"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
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
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