www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - abi specs, multiple linkages, binary symbol information

reply Jakob Praher <jpraher yahoo.de> writes:
hi all,

I like the D language. Since I also play with gcj (the static gcc java 
compiler), which has a new ABI (additional to the c++ linkage), I was 
wondering about the default D ABI:

* how classes/modules/functions/methods are mangled
* which type codes exist
* is there a way to describe any type using a type code (which is 
probably needed for method overloading )

* is there a way to specifiy versioning in the ABI
* since D has its own linkage (opposed to C++ linkage) I would 
appreciate a less is more approach and a more stable ABI like that of C++


Yes I looked at DMD but I thought, it would be pleased to know there is 
a written spec (the language reference is quite quiet about that).

What would be interesting is to support many different types of 
ABIs/Linkages.
This could be done by "helping" the compiler to understand the ABI that 
one is using.

And: As the language is specified today, is there a way to do a load 
time linking?

I would be interested to link GCJ shared objects against D in a very 
native form, so that one could use for instance the many java libs 
already developed.

for instance

 gcj import org.apache.xalan...TransformerImpl;
 gcj import java.lang.String;

int main( char[][] args ) {
	TransformerImpl impl = new TransformerImpl( );
	....

}
....


Plus: In order for instance to export a D class to be linked with GCJ, 
one clearly needs more meta information exposed in the object file, or 
distilled from the D sources.

For me I'd favor the first approach, which would be interesting, since 
one could link against a D object file without the need of the 
corresponding D source code.

The metadata approach used by GCJ is very straigt forward:

* There is an UTF8 table
* There is a Method table for each method of a class
* There are some other tables for Class Descriptors ...
* The method table contains also all the referenced methods (not only 
the ones defined)
* There is a Class table for each class (which contains links to the 
other tables)

	- vtable  (the class's methods)
these tables are used for the java binary compatiblity stuff:
	- otable  (offset table for referenced objects by an offset)
	- atable  (address table for referenced objects via address)
	- itable  (interface table)


Surely the simplicity of the java type system allows for a simple 
implementation of that. D would need some more meta information 
(modules, functions, custom types. .... )

But it would be an interesting task, since then binary compatiblity in D 
would be more stable. And the interoperabilty between the gcj project 
and D could also be interesting.

looking forward to some discussions

-- Jakob
Oct 10 2004
next sibling parent "Thomas Kuehne" <eisvogel users.sourceforge.net> writes:
Jakob Praher schrieb:

 I like the D language. Since I also play with gcj (the static gcc java
 compiler), which has a new ABI (additional to the c++ linkage), I was
 wondering about the default D ABI:

 * how classes/modules/functions/methods are mangled
 * which type codes exist
 * is there a way to describe any type using a type code (which is
 probably needed for method overloading )

 * is there a way to specifiy versioning in the ABI
 * since D has its own linkage (opposed to C++ linkage) I would
 appreciate a less is more approach and a more stable ABI like that of C++


 Yes I looked at DMD but I thought, it would be pleased to know there is
 a written spec (the language reference is quite quiet about that).

 What would be interesting is to support many different types of
 ABIs/Linkages.
 This could be done by "helping" the compiler to understand the ABI that
 one is using.

 And: As the language is specified today, is there a way to do a load
 time linking?

 I would be interested to link GCJ shared objects against D in a very
 native form, so that one could use for instance the many java libs
 already developed.


The cross linking between D and Java libs via gcd/gcc/gcj would be realy
interesting.

I'm not sure how GCJ handles Java's VM.

The potential huge probelms I see is be that D is a garbage colleted but Java
normaly uses a
full blown VM to enable runtime reflections and runtime loading of additional
libs.

Currently the D language documentation  requires a maior overhaul to transform
it in to a
specification/standard. Until then - I guess - there won't be any progress on
the cross
linking front.

Thomas
Oct 17 2004
prev sibling parent "Ben Hinkle" <bhinkle mathworks.com> writes:
"Jakob Praher" <jpraher yahoo.de> wrote in message
news:ckc8t2$312l$1 digitaldaemon.com...

 hi all,

 I like the D language. Since I also play with gcj (the static gcc java
 compiler), which has a new ABI (additional to the c++ linkage), I was
 wondering about the default D ABI:

 * how classes/modules/functions/methods are mangled
 * which type codes exist
 * is there a way to describe any type using a type code (which is
 probably needed for method overloading )

 * is there a way to specifiy versioning in the ABI
 * since D has its own linkage (opposed to C++ linkage) I would
 appreciate a less is more approach and a more stable ABI like that of C++


 Yes I looked at DMD but I thought, it would be pleased to know there is
 a written spec (the language reference is quite quiet about that).

 What would be interesting is to support many different types of
 ABIs/Linkages.
 This could be done by "helping" the compiler to understand the ABI that
 one is using.

 And: As the language is specified today, is there a way to do a load
 time linking?

 I would be interested to link GCJ shared objects against D in a very
 native form, so that one could use for instance the many java libs
 already developed.

 for instance

  gcj import org.apache.xalan...TransformerImpl;
  gcj import java.lang.String;

 int main( char[][] args ) {
 TransformerImpl impl = new TransformerImpl( );
 ....

 }
 ....


I was looking forward to something like that, too. The D ABI might be too
different from g++/gcj to make this work, though. Try posting to the d.gnu
newsgroup or try pinging David Friedman. Interoperability (more than through
C) with Java/C++ would be very cool. Maybe the D.NET effort could also shed
some light on the task. Walter has said that once D settles down the ABI
could be documented and frozen but I think he's reluctant to document all
the mangling and such now.


 Plus: In order for instance to export a D class to be linked with GCJ,
 one clearly needs more meta information exposed in the object file, or
 distilled from the D sources.

 For me I'd favor the first approach, which would be interesting, since
 one could link against a D object file without the need of the
 corresponding D source code.

 The metadata approach used by GCJ is very straigt forward:

 * There is an UTF8 table
 * There is a Method table for each method of a class
 * There are some other tables for Class Descriptors ...
 * The method table contains also all the referenced methods (not only
 the ones defined)
 * There is a Class table for each class (which contains links to the
 other tables)

 - vtable  (the class's methods)
 these tables are used for the java binary compatiblity stuff:
 - otable  (offset table for referenced objects by an offset)
 - atable  (address table for referenced objects via address)
 - itable  (interface table)


 Surely the simplicity of the java type system allows for a simple
 implementation of that. D would need some more meta information
 (modules, functions, custom types. .... )

 But it would be an interesting task, since then binary compatiblity in D
 would be more stable. And the interoperabilty between the gcj project
 and D could also be interesting.

 looking forward to some discussions

 -- Jakob


You seem to know quite a bit about the gcj and I'm guessing the probably you
and David (and Walter on the D side)are the most expert (the only experts?)
about this kind of thing. I'll be very interesting in testing or debugging
whatever you come up with.

-Ben
Oct 18 2004