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

[Sylvain Pasche]

On Friday Jul 19  19:13, Rhys Weatherley wrote:
 > 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.

Yes, I have tested it before, the tool is quite impressive. In fact,
it differs from what I do because it translates IL -> Java
language. The advantage in doing so is that they can more easily use
java language to simulate complex instructions not available as bytecode.
One drawback is that it puts some restriction on the
translation, for example they can not translate code using gotos.

One other thing useful with their product is that they have a complete
implementation of corlib in java (as a single jar). It will simplifiy
development testing, waiting eventually for a free java mscorlib
library. 

 > 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.

There will certainly be several restriction on the
translation. However, it is possible, as demonstrated with stryon
product to translate by ref arguments and other.
It will need some java utility classes, and the output will be much
more difficult to produce than with the simple opcode translation. I
let it for later.

 > 
 > 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.
 > 

In fact, wanted to use the "to be written" pnet java
assembler. As pnet is able to produce java bytecode from C#, I think a
java assembler would be useful for both the translator and the
compiler. Here I can help Gopal who is writing one.

And for the pinvoke problem, one solution might be to create a kind of
"native proxy". I put this on my "low priority" todo list, if realisable.


Sylvain