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:
If R0 holds pointer to 4 bytes before the start of the .class file

      STC.L SR,@–R15               // Store value to RET to.
      MOV.L @R0+,R1
      MOV.L (Magic),R2
      XOR R1,R2                  // If both values are the same, 0->R2
      TST R2,R2
      BT/S Parse
      NOP
      RET
   (Magic) 0xCAFEBABE
   
   ParseVer:
      XOR R4,R4
      MOV.L @R0+,R1
      MOV.L (Min Major_Minor),R2
      MOV.L (Max Major_Minor),R3
      CMP/HS R2,R1               // If min version>version
      ROTL R4
      CMP/HS R1,R3               // If version>max version
      ROTL R4
      TST R4,R4                  // If both false, 1->T
      BT/S ParseConst
      NOP
   (Min Major_Minor) 0x** ** ** **      // Upper two bytes are major version, lower two bytes are minor
   (Max Major_Minor) 0x** ** ** **      // Same as before
   
   ParseConst:
      MOV.L R0,@R15-               // Store pointer to Constant pool
      MOV.W @R0+,R1
      MOV.L R1,R8
      ROTL R1
      ADD R1,R0                  // Skip over Constant pool
   
   ParseFlags:
      XOR R12,R12                  //Clear flag register
      MOV.W @R0+,R1
      ROTL R1
      CLRT
      ROTR R1
   <Other flag checking?>
      OR R1,R12                  // Add Access flags to lower 16 bits of flag register
   
   ParseClasses:
      XOR R2,R2
      XOR R4,R4      
      MOV.L @R0-,R1
      MOV.B 0x10,R3
      CLRT
   Loop1:
      ADD 0xFF,R3
      ROTR R3
      TST R3,R3
      BF/S Loop1
      ROTL R2                     // Move super_class index into R2
      
      CMP/HS R1,R8
      ROTL R4
      CMP/HS R2,R8
      ROTL R4
      TST R4,R4
      BT/S GetIndices1
      NOP
      RET
      
   GetIndices1:
      MOV.L @R15+,R7
      MOV.L R7,@R15-
      ADD R7,R1
      MOV.W @R1,R1
      <Handle this_class>
      ADD R7,R2
      MOV.W @R2,R2
      <Handle super_class>

   Parsefurther:
      MOV.L R0,@15-
      MOV.W @R0+,R1
      MOV.W R1,R4
      XOR R2.R2
   Loop2:
      ADD 0xFF,R1
      MOV.W @R0+,R3
      CMP/HS R3,R8      // R8 must be carried from the previous sections!
      TST R1,R1
      BF/S Loop1
      ADD 0x01,R2
      ADD 0xFF,R2
      CMP/EQ R2,R4
      BT/S FieldsMethods
      NOP
      RET
   FieldsMethods:
      MOV 0x01,R3
   Loop3:
      MOV.L R0,@R15-
      MOV.W @R0+,R1
      MOV 0x04,R2
      MULU.W R1,R2
      STS MACL,R1
      ADD R1,R0
      TST R3
      BF/S Loop3
      ADD 0xFF,R3
      
   Parseattribs:
      MOV.W @R0+,R1
      MOV 0x07,R2
      MULU.W R1,R2
      STS MACL,R2
      MOV.L R0,@R15-
      ADD R2,R0
   ParseInstruct:
      Etc...
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?
elfprince13 wrote:
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. Graphing Calculator

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.
elfprince13 wrote:
Have you found documentation for the instruction set you'll have to implement?


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 Razz

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. Smile
Qwerty.55 wrote:
This means that while the processor can handle the language, it probably needs a dedicated Prizm port.


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.
Qwerty.55 wrote:
I'm curious as to why you think it would take years if the JVM is fundamentally just an interpreter.


"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.

Quote:
Also, porting an existing VM is essentially the same thing as re-writing it.


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).

Quote:
The Prizm API does not look like the API of say, Android.


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 Smile
Qwerty.55 wrote:
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 Smile


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.
Qwerty.55 wrote:
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 Razz
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.
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
Page 1 of 4
» All times are UTC - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement