JavaL: Java bytecode interpreter

Basically, sort of like that n00b programming language ComputerCraftFan11 is writing, except instead of parsing Java source code (which would be a pain in the a**), it parses either Java bytecode (directly), or disassembled (through `javap -c`) code.

That way, instead of relying on people to program according to a strict standard supported by the interpreter (durr, you must put one statement on each line and you have to have braces on the same line and no extra whitespace), the interpreter only needs to rely on the (inherently strict) bytecode produced by the Java compiler (or, if you're really desperate, yourself).

That's what I'm working on right now, using Wikipedia and the Java VM Specs as reference.

Feedback?

Screenies!

Spoiler

–Current Version–
v0.1b2: Disassembled/interpreted Java bytecode. Halfway there!

v0.1b2: Reading all the constants, interfaces, fields, etc.

–Older Versions–
v0.1b1: Reading the constants from the .class file

Maybe I misunderstood, but since when can you run java code directly through computercraft?

Dlcruz129, on 01 January 2013 - 03:54 PM said:

Maybe I misunderstood, but since when can you run java code directly through computercraft?

Maybe I wasn't clear. I was actually talking about writing a Java VM in Lua (which, of course, CC can run).

On an unrelated note, here's a screenshot of it!

pokepal101, on 01 January 2013 - 05:58 PM said:

Dlcruz129, on 01 January 2013 - 03:54 PM said:

Maybe I misunderstood, but since when can you run java code directly through computercraft?

Maybe I wasn't clear. I was actually talking about writing a Java VM in Lua (which, of course, CC can run).

On an unrelated note, here's a screenshot of it!

o_O it's done already?

Dlcruz129, on 01 January 2013 - 06:16 PM said:

pokepal101, on 01 January 2013 - 05:58 PM said:

* snip *

o_O it's done already?

He's just listing up all constants in the binary, which is only one step towards an actual JVM.

Orwell, on 02 January 2013 - 12:24 AM said:

Dlcruz129, on 01 January 2013 - 06:16 PM said:

pokepal101, on 01 January 2013 - 05:58 PM said:

* snip *

o_O it's done already?

He's just listing up all constants in the binary, which is only one step towards an actual JVM.

Yes, I've got quite a fair bit to go. (Actually, not that much towards a Hello World compatible JVM) Although, flicking through the JVM specifications, it doesn't look like too big a job. Mainly just keeping everything readable (without having access to OOP) and implementing all those 200 opcodes………

pokepal101, on 02 January 2013 - 02:05 AM said:

Orwell, on 02 January 2013 - 12:24 AM said:

Dlcruz129, on 01 January 2013 - 06:16 PM said:

pokepal101, on 01 January 2013 - 05:58 PM said:

* snip *

o_O it's done already?

He's just listing up all constants in the binary, which is only one step towards an actual JVM.

Yes, I've got quite a fair bit to go. (Actually, not that much towards a Hello World compatible JVM) Although, flicking through the JVM specifications, it doesn't look like too big a job. Mainly just keeping everything readable (without having access to OOP) and implementing all those 200 opcodes………

I happen to be in the middle of creating an emulator myself (for the 6502 cpu), and the biggest issue for you will be efficiency, not readability. :P/> At least if you want it to run at a bearable speed…

Orwell, on 02 January 2013 - 02:10 AM said:

I happen to be in the middle of creating an emulator myself (for the 6502 cpu), and the biggest issue for you will be efficiency, not readability. :P/> At least if you want it to run at a bearable speed…

For Redpower 2?! Java emulator! :o/>

tiin57, on 02 January 2013 - 06:18 AM said:

Orwell, on 02 January 2013 - 02:10 AM said:

I happen to be in the middle of creating an emulator myself (for the 6502 cpu), and the biggest issue for you will be efficiency, not readability. :P/> At least if you want it to run at a bearable speed…

For Redpower 2?! Java emulator! :o/>

Not a Java emulator :P/> A 65EL02 bytecode emulator written in Lua. There will also be a compiler and a way to flash the 65EL02 from CC using bundled cables. :)/> I could try and port an existing open source Java emulator to the 65EL02.. would be challenging with those specs though.

Orwell, on 02 January 2013 - 02:10 AM said:

I happen to be in the middle of creating an emulator myself (for the 6502 cpu), and the biggest issue for you will be efficiency, not readability. :P/> At least if you want it to run at a bearable speed…

I'm not that worried about efficiency :D/>. It it runs at 1 FLOPS, deal with it. But if I can't find my way around the growing labyrinth of code…

pokepal101, on 02 January 2013 - 03:28 PM said:

Orwell, on 02 January 2013 - 02:10 AM said:

I happen to be in the middle of creating an emulator myself (for the 6502 cpu), and the biggest issue for you will be efficiency, not readability. :P/> At least if you want it to run at a bearable speed…

I'm not that worried about efficiency :D/>. It it runs at 1 FLOPS, deal with it. But if I can't find my way around the growing labyrinth of code…

Fair point. :)/>

Orwell, on 02 January 2013 - 12:24 AM said:

He's just listing up all constants in the binary, which is only one step towards an actual JVM.

Here's another step! JavaL can now print the disassembled bytecode of a Java program! Almost there!!!

Spoiler

This is exciting..! :D/> I think that you'll have more work than you expect though. :P/> I know that I have for my own.

Orwell, on 03 January 2013 - 12:42 AM said:

This is exciting..! :D/>/> I think that you'll have more work than you expect though. :P/>/> I know that I have for my own.

http://en.wikipedia.org/wiki/Java_bytecode_instruction_listings
Push to stack… Pop from stack… Look-up from constant pool… Numerical local variables…
Doesn't look too difficult from here on in.
The lack of OOP in Lua might become a problem later down the track though…

The problems lie more in stuff like unsigned bytes and big endian and other stuff that's non-trivial in Lua… But you'll be ok. Java is designed to be emulated anyway, so that's an advantage. :)/>

Orwell, on 03 January 2013 - 01:44 AM said:

The problems lie more in stuff like unsigned bytes and big endian and other stuff that's non-trivial in Lua… But you'll be ok. Java is designed to be emulated anyway, so that's an advantage. :)/>/>

Unsigned bytes? Just… read a number……. Lua doesn't care.
Big endian? The majority of numbers in class files are 2-bytes long. I couldn't have gotten this far without implementing that!

function readu2()    --Read unsigned 2-byte integer
    bit.blshift(byte1, 8) + byte2
end

I know, those were just examples. About signedness, Lua doesn't care, but the simulated machine does, I'm not sure about the JVM, but I had to implement both explicitly. Well, you can keep on proving how simple it is, I believe you anyway. :)/> My experience just says that you will hit at least one wall somewhere, but we'll see. :P/>

I must say, I can see your doing a good job at this. :)/> And I notice that you have a good understanding of computer systems and architecture. :)/> I'm rather curious!

Orwell, on 03 January 2013 - 02:02 AM said:

I notice that you have a good understanding of computer systems and architecture. :)/>

Really? I honestly don't. I still don't get the difference between 32-bit and 64-bit computers :)/> I'm just a unix-head who uses C when he has to.

pokepal101, on 03 January 2013 - 02:08 AM said:

Orwell, on 03 January 2013 - 02:02 AM said:

I notice that you have a good understanding of computer systems and architecture. :)/>

Really? I honestly don't. I still don't get the difference between 32-bit and 64-bit computers :)/> I'm just a unix-head who uses C when he has to.

In that case, I'm even more curious. :P/> Addressing width might even be something you need to take in consideration (not sure, I'm not that knowledgeable about the JVM).

Btw, I just checked and the JVM is quite chill about signedness. :)/> Basically it uses unsigned bytes or signed shorts.

Edit: Also, most emulators are written using the procedural paradigm instead of object oriented. It would be quite hard to implement OOP into the design (I have the cpu and ram as the only types, the rest are all helper functions that take the cpu as argument). I'm sure you could do better, though often OOP is traded for efficiency.

If you plan on being able to just run an arbitrary Java program, you then need the entire Java part of the jvm library, which then relies on native libraries that I'm unsure how easily you'll be able to achieve if at all loading of jni native libs.

tomass1996, on 03 January 2013 - 12:17 PM said:

If you plan on being able to just run an arbitrary Java program, you then need the entire Java part of the jvm library, which then relies on native libraries that I'm unsure how easily you'll be able to achieve if at all loading of jni native libs.

I was planning on re-implementing some of the core classes of the Java libraries. For example, javal.lang.System might be defined as abstract and it's functionality is provided directly by the JVM.

Orwell, on 03 January 2013 - 02:14 AM said:

Addressing width might even be something you need to take in consideration

See, I had to Google that one! Hmm… It looks like something to do with locations in memory - Java doesn't really care about memory. It just cares about the stack.