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