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

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

"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