If memory serves me right, Piers Cawley wrote:
/me is a newcomer from DotGNU ... and has missed the mails quoted,
hence here's what I have ..
> Regarding JVM - Parrot Compatibility
> Newcomer Karthik Kumar is interested in writing a tool to convert java
> ".class" files to parrot ".pbc" files and asked for information on what
> had been done in this area.
I had a run-in with JILC (http://savannah.gnu.org/projects/jilc/), in which
the entire JVM loading and disassembly was hijacked from my curriculum project
work.... The ILC part is still lacking (the reasons for /me giving up is
simple, those people started jilc.sf.net :-)
But KK should be able to make use of the code atleast partially ...
> it's very easy to get the basics working because of the low
> number of JVM bytecodes.
Don't fall into that trap .... /me has made that mistake once ...
In JVM a localvariable can contain any data type , viz ints,floats,
or objects.. It takes a lot of flow analysis to figure out what
type is in a particular localvar..
iconst_0
istore_0
goto jmp1
fconst_0
fstore_0
goto jmp2
jmp1:
iload_0
pop // or maybe a toString() which clears the stack ?
jmp2:
fload_0
pop // or a println();
is a valid bytecode formation ... viz, I need to split
this into 2 localvars and track with type information for IL ...
(no, it's not an undecidability problem , but still it's difficult
which is yet another reason why JILC got left in the wayside)
I'm assuming that parrot will need a similar mapping to store
to the 'I' and 'F' type registers ?
Gopal
--
The difference between insanity and genius is measured by success
