[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [DotGNU]Morphing java code to IL
From: |
Gopal V |
Subject: |
Re: [DotGNU]Morphing java code to IL |
Date: |
Sun, 23 Sep 2001 16:12:30 +0530 |
User-agent: |
Mutt/1.0.1i |
Hi,
> You don't want to do this. Trust me. JVM bytecode
> is very different in structure to IL, even though it looks
> similar. Local variables are the hardest. IL explicitly
> tags locals with their types. JVM doesn't - the type
> is determined by looking for the first place in the
> method where the variable is assigned.
I had prepared a comparison of the JVM opcodes and IL opcodes
and come to the conculsion that they were comparable. JVM
opcodes have an equivalent or similar opcode in IL. So I
thought that JVM => IL was possible. Frankly the idea of
local variables creating problems did not cross my mind.
> However, do not attempt to convert the bytecodes into
> IL. Instead, just return the raw code to the caller. It is
> the responsibility of the caller, such as the disassembler,
> to interpret the bytecodes appropriately. I've been
> planning for some time to add Java method bodies to
> ilasm and ildasm. I actually want it to work this way,
> to support the C# compiler's JVM mode.
I think this makes more sense why I should not convert during
loading.
> If you really want to build a JVM->IL converter, then
> do it as a separate program. It would call the function
> ILMethodGetCode to get the Java method body, and
> then would perform dynamic flow analysis to figure out
> the local variables prior to conversion. But be warned:
> it is a _lot_ harder than it looks.
>
With the problem of typed local variables , I would have to do a
reshuffling of local variables to get the correct type onto the
correct local var. But can I change type flag of a local variable
using some opcode (is there any such thing ?).
Gopal