dotgnu-general
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [DotGNU]Developing a IL -> jvm translator


From: Rhys Weatherley
Subject: Re: [DotGNU]Developing a IL -> jvm translator
Date: Fri, 19 Jul 2002 19:13:17 +1000

Sylvain Pasche wrote:

> I'm actually working on a translator of IL to java bytecode.
> I make this anouncement now to avoid duplicating efforts in case
> someone else had the same idea (in case, please contact me).

You may want to check out iNET from Stryon (formerly
HalcyonSoft):

http://www.stryon.com/

It's a commercial product that purports to provide this kind
of functionality.  (I haven't used it myself).  Having a Free
converter would definitely be nice.

> I think about using the coder architecture developed in pnet. That is,
> to write a coder objet that will output java bytecode during the
> method verification process.

Seems like a good approach.  You can reuse the pnet code
to do most of the hard work of pulling the IL program apart
and analysing the structure of the method code.  I'd suggest
starting with the "ilverify" program rather than "ildasm".
The "ilverify" program contains a dummy coder - replace it
with your JVM coder.

You will have some problems though.  IL has instructions for
manipulating call-by-reference parameters and for constructing
delegates.  There are no equivalents of these in the JVM.
IL can also manipulate unsigned types, although that isn't
quite as hard to handle during translation.

> I see two way of implementing this translator:
> 
> 1) The translator outputs opcodes in textual form (printf). ...
> 2) The translator make a copy of the IL image in memory ...
>
> I would be glad to hear if someone thinks one solution is better than
> the other..

Both would have the same order of difficulty to implement,
in my opinion.  The first (output assembly code) will require
a JVM assembler.  The "jasmin" program may work for this.
The second shifts the assembler burden into the converter,
but because you already have most of the information hanging
around, it isn't as bad as writing a full assembler.

Cheers,

Rhys.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]