Re: [Jilc-dev] Current Status

[Gopal.V]

If memory serves me right, Gaurav Vaish wrote:
>    * I did some hacking today with Gopal's jdasm. Basically, going through the
> minutest details. Found that few properties are not implemented - like
> processing byte code for Method, Class and in case of BigConstant. I still 
> have methods to look into closely.
        No way !. It resolves the Method, Field , Class & BigConstant correctly.
Well didn't U see the java/io/PrintStream/println(Ljava/lang/String;)V  
where System.out.println() was called ?. See code below.
<snip from="jdasm.c>
CODE:>           case FIELD:
CODE:>           case METHOD:
CODE:>           case CLASS:
CODE:>           case BIGCONSTANT:
CODE:>               PRINT_OPCODE_NAME(found_code);
CODE:>               print_string_cp(cp,code[start+1]<<8|code[start+2]);
CODE:>               start=start+3;
CODE:>               break;
</snip>
        The types I missed (messed) are ATYPE,MARRAY and INTERFACE which 
should not take much time once I get down to it.
>     Some issues to be handled -
>     * I think lot of work will be needed to handle "lock" / "synchronized"
> thing. In IL, "lock" causes and System.Monitor object to be created and then
> uses try-catch funda to deal with it. I am not quite sure of what exactly
> happens in Java. May be Gopal can throw more light on this.
> 
        I would suggest that we first get HelloWorld to work on Version 0
and then talk about complex stuff like Threading. Our work will be full
of Opcode maps, Class maps, Method maps.....
        
        JVM_IADD => IL_ADD 
        JVM_FADD => IL_ADD 
...........
        java.lang.Object => System.Object
...........
        java.io.PrintStream.println(String) => System.Console.WriteLine(String)

        The real issue is the large hashtable/map(s) needed. So what book would
you suggest for reading up on the IL bytecode.
(no ECMA specs please)
>   * There are several opcodes (encapsulated in 2-bytes, ie, unsigned short) in
> IL while in java there are less than 256 (1-byte, ie, unsigned char)
        Thunk, Was that a code offset that dropped ?. We'll have to watch the 
code offset stuff really closely. That's why I suggested that we use ILAssembly
code as our output for the first stage. (debugging bytecode is really hell!).
I should know that , my 5th sem mini-project was a Java assembler. ( Had fun
debugging the indexes/offsets using Hexview -- that's why I wrote class loader
and later made it into a disassembler :)

Gopal.V
-- 
<Gopal> 
    |                        //===<=>===\\
    +---name gopal.v        || GNU RULEZ ||
    |                        \\===<=>===//
    `---nick t3rmin4t0r