There's been a bit of discussion lately about getting Java on the Prizm. The JVM has even been ported to the processor before, but only to the Windows CE API. This means that while the processor can handle the language, it probably needs a dedicated Prizm port.

z80man from omnimaga has taken the initiative in starting a project to port Java to the Prizm, but I decided to take a look at the JVM myself as well. I managed to write a bit of code to parse the header of the .class files, which is the first step in making a JVM. It still has a few bugs that I'm looking at, though, so feel free to point out any if you see them.


Code:

Very cool! Nice work so far. What do you envision as your next step?

Writing the code that will perform each of the JVM instructions is probably the next step.

Have you found documentation for the instruction set you'll have to implement?

An excellent question. I'm curious what the footprint of the JVM is like in terms of memory and CPU cycles. I'm hoping it's relatively low, considering that Java is supposedly runnable on phone and such, but I don't have high expectations given my usual perception of Java as big, slow, and bloated.

Would it be possible for a larger game like Minecraft (which runs on Java) to be theoretically run on the calculator? (even running at an extremely low framerate/utilizing the flash memory as "virtual memory"?) I doubt it, but it would be awesome if actually possible.

EDIT: Not being on a "normal" operating system might be a problem, I would think.

Even if the memory requirements were met, recreating the Java standard libraries would be a pain in the butt.

http://www.daimi.au.dk/dOvs/jvmspec/ref-Java.html

I believe that's the full instruction set for the standard JVM. If it's not, then it's still more than complete enough for me

The libraries wouldn't be fun to recreate. However, since they're basically collections of classes (correct me if I'm mistaken in this), then they could probably be run natively.

Indeed, I think once you have the VM working, most of the other stuff falls neatly into place.

Pretty much all CPUs can handle the language - even the Z80, that is never the problem. The problem is whether it is fast enough and has enough RAM to actually be useful, and whether or not someone actually takes the time to do it.

That said, writing a VM from scratch will take you months if not years assuming a *very* high level of skill. You would be *much* better off trying to port an existing VM - such as Android's Dalvik.

I'm curious as to why you think it would take years if the JVM is fundamentally just an interpreter.

Also, porting an existing VM is essentially the same thing as re-writing it. The Prizm API does not look like the API of say, Android.

"just an interpreter"? An interpreter is a huge amount of work. You can't just map 1 JVM instruction to 1 or more assembly instructions - it doesn't work like that. There is also significantly more than just handling the JVM instructions. The GC alone is going to be a massive undertaking.



Noooooooo, it is not. *FAR* from it. If you port a VM, you already have an architecture to work with, things like a working GC, memory management, JNI, runtime typing, reflection, etc... You have clear spots where you need to make prizm specific stuff, and the bulk of the work (all the hard stuff) is already done. Not to mention there will already have been a significant amount of debugging and optimizations done.

You are grossly underestimating how much work a VM needs. Dalvik's VM, for example, is about 180,000 lines of code (that is just the vm folder, by the way, dalvik as a whole tips the scales at close to 500,000 LOC in C, 150,000 LOC of assmebly, and another 150,000 LOC in Java - that includes things like debugging tools).



We're talking about the VM here - there is no API.

Not sure how a virtual machine of any kind exists without interfacing with the native API, but okay. I guess I'll find out as we get farther along in this project

Well, yes, the VM does need to access to some native API (you mentioned Android, though, which isn't a native API). A malloc and free are obviously needed, as is some way of reading files. You'll also need some way of loading and executing shared libraries (Java without JNI is pretty useless)

At this point, the interpreter is seeming to be the easiest part of the whole thing, probably because I'm not trying to use a JIT, which reduces it to essentially a fancy lookup table. The interface stuff like JNI is where all of my work is going in.

the Prizm uses a SuperH 3, how much different is the SH3 when compared to a SuperH 4 ?

Because the Dreamcast uses a SH4 as its CPU and many of its browsers (planetweb as a example) used a form of JVM.

The Prizm uses a custom SH4A core that has had a few things removed and/or modified. For example, it has no FPU, which the Dreamcast SH4 almost certainly has. However, instruction set wise, the the SH3 and the SH4 are so similar that we managed to get Assembly code running on the Prizm without even being sure of what processor it was using.

I would think that bodes extremely well for Java on the Prizm running inside the JVM, then!

The advantage of writing a new JVM by hand is that for one thing, it can natively support the various file formats on the Prizm and that it can work around memory constraints much better. Plus, I can't possibly maintain C code, so ASM is the only way I could do the project

Yeah, but the downside of writing a new JVM by hand is that it's really, really hard, as Kllrnohj pointed out. And why can't you maintain C code? We can easily teach you C if you'd like; it's quite straightforward.