### Author Topic: Khavi: Java on the Prizm  (Read 54133 times)

0 Members and 1 Guest are viewing this topic.

#### AngelFish

• Is this my custom title?
• LV12 Extreme Poster (Next: 5000)
• Posts: 3242
• Rating: +270/-27
• I'm a Fishbot
##### Re: Java on the Prizm
« Reply #30 on: April 21, 2011, 03:47:48 pm »
No, for the moment it uses just naive interpretation to interpret the instructions. The process you're referring to is called Just In Time compilation (JIT) and it's how the normal JVM works. The problem is that it's more difficult to write and debug than regular interpretation and uses the same framework, so I'm going to get the instruction by instruction parsing working, THEN change it to handle JIT parsing.
∂²Ψ    -(2m(V(x)-E)Ψ
---  = -------------
∂x²        ℏ²Ψ

#### Snake X

• Ancient Veteran
• Posts: 810
• Rating: +33/-8
##### Re: Java on the Prizm
« Reply #31 on: April 21, 2011, 07:12:10 pm »
So does this mean MINECRAFT?! Omg minecraft on a calc

edit: also is this going to include all the features of java? Like will it be a cut down java for the sake of space like TI-lua or the real thing?

edit 2: can the java be compiled on-calc or on the computer? it would be awesome to cheat on my java exam
« Last Edit: April 21, 2011, 08:28:42 pm by Snake X »
Loved this place, still the best producers of power metal, and sparked my dreams of coding.

#### jnesselr

• King Graphmastur
• LV11 Super Veteran (Next: 3000)
• Posts: 2270
• Rating: +81/-20
• TAO == epic
##### Re: Java on the Prizm
« Reply #32 on: April 21, 2011, 10:05:02 pm »
This would be pretty interesting, but I don't know if Java is going to be enough to get me to get a prizm with ubercalc coming out.  We shall see.  Anyway, nice to see some good progress!

• Guest
##### Re: Java on the Prizm
« Reply #33 on: April 21, 2011, 10:44:11 pm »
I'm just wondering, but I realize now that there is little point of making a Java VM for one platform -- the garbage collecting and other things just take away space and speed -- why not have the Java compile on comp, then have some sort of a transfer program to simplify it before sending?  Because I feel as if the extra stuff just really isn't needed.  To tell the truth, I think it would be better to just make a Java-like language from scratch that has everything in Java-syntax and OOP but has direct control over objects like C++.

If you are porting Java though anyways, I do hope you're porting something like Java ME . It still has all that inflated crap in the header and GC, but at least it's meant for smaller size constraints.
« Last Edit: April 21, 2011, 10:50:53 pm by Ashbad »

#### z80man

• Casio Traitor
• Posts: 977
• Rating: +85/-3
##### Re: Java on the Prizm
« Reply #34 on: April 21, 2011, 11:05:54 pm »
Well the problem with making Java a compiled language is that it wouldn't work with pre-compiled .class files. Also one of the big pluses about Java is all of the pre-included libraries that are so powerful. If Java was compiled into machine code that would be one extremely difficult as it is almost the same thing as making a C++ compiler and two would probably not get much use because Java without the libraries and garbage collecting is just C++ in which there is already a compiler.

List of stuff I need to do before September:
1. Finish the Emulator of the Casio Prizm (in active development)
2. Finish the the SH3 asm IDE/assembler/linker program (in active development)
3. Create a partial Java virtual machine  for the Prizm (not started)
4. Create Axe for the Prizm with an Axe legacy mode (in planning phase)
5. Develop a large set of C and asm libraries for the Prizm (some progress)
6. Create an emulator of the 83+ for the Prizm (not started)
7. Create a well polished game that showcases the ability of the Casio Prizm (not started)

#### AngelFish

• Is this my custom title?
• LV12 Extreme Poster (Next: 5000)
• Posts: 3242
• Rating: +270/-27
• I'm a Fishbot
##### Re: Java on the Prizm
« Reply #35 on: April 21, 2011, 11:17:22 pm »
I'll respond to each of the points individually.

I'm just wondering, but I realize now that there is little point of making a Java VM for one platform -- the garbage collecting and other things just take away space and speed -- why not have the Java compile on comp, then have some sort of a transfer program to simplify it before sending?

For one thing, I don't know any computer languages well enough to write such a program. Secondly, it'd be very wasteful in terms of memory usage. Thirdly, Java isn't a very good compiled language. The language was designed to be interpreted, not compiled. Compilers don't necessarily have enough information to make efficient compilations.

Quote
Because I feel as if the extra stuff just really isn't needed.  To tell the truth, I think it would be better to just make a Java-like language from scratch that has everything in Java-syntax and OOP but has direct control over objects like C++.

All I'm doing is writing an interpreter for Java bytecode, which doesn't require the slightest knowledge of Java (I seriously can't write a Hello World program in Java).

Quote
If you are porting Java though anyways, I do hope you're porting something like Java ME . It still has all that inflated crap in the header and GC, but at least it's meant for smaller size constraints.

I'm not porting Java ME. I'm writing a JVM from scratch according to the Java Virtual Machine Specifications. That's a very different order and it allows me to make a lot of machine specific optimizations.

Quote
edit: also is this going to include all the features of java? Like will it be a cut down java for the sake of space like TI-lua or the real thing?

edit 2: can the java be compiled on-calc or on the computer? it would be awesome to cheat on my java exam

All the features?

Heck no. I don't have the next three years of my life to dedicate to this one program
Java has really developed quite a massive infrastructure to support the JVM. All that I am doing is writing the JVM and a bit of extra software in order to make the VM interface smoothly with the rest of the Prizm's software. This also means that there will be no compilation on-calc. You will have to compile your code to .class files with the Java SDK or some other compiler.

Anyway, I think it should be made clear that this is not my project alone. z80man is writing the front-end stuff like the shell that this will run under and some of the routines while I'm writing the core engine and interpreter.

EDIT: Dang it z80man, you ninja'd me and I lost The Game

EDIT EDIT: I kind of forgot, but here's the source for the class loader, initialization code, and .sh3 file loader:

Code: [Select]
General Parser form: // Detect filetype and jump to proper parsing algorithm STC.L SR,@–R15 // Store value to return to after termination of program MOV $d,R9 // Offsets MOV$e,R10 ADD R8,R9 ADD R8,R10 MOV $04,R13 // Number of entries in algorithm address tables Loop: MOV.L @R9+,R11 MOV.L @R10+,R12 CMP/EQ R11,R1 BT/S Jump ADD 0xFF,R13 TST R13,R13 BT/S Return NOP BRA Loop NOP (Algorithm method table) 2e 73 68 33 // .sh3 parsing 2e 63 6c 61 // .class parsing 2e 6a 61 72 // .jar parsing (hopefully) 2e 65 6c 66 // .elf parsing (hopefully) (Algorithm Jump table) Undecided // Offset of .sh3 parsing Undecided // Offset of .class parsing Undecided // Offset of .jar parsing (hopefully) Undecided // Offset of .elf parsing (hopefully) Return: RTS // File type not recognized Jump: ADD R8,R12 JMP @R12.sh3 parsing ADD$03,R0 // Skip over ".sh3" at the beginning of the file XOR R6,R6 XOR R5,R5 MOV.L (sh3 table offset),R9 HeaderLoop: MOV.W @R0+,R1 MOV (final packet),R3 CMP/EQ R1,R3 BT/S Endparse NOP BSR GetPacket MOV $04,R2 BRA HeaderLoop NOP (final packet) 0xFF FF EndParse MOV$02,R2 CMP/EQ R2,R6 BT/S FinParse // Check for file name and file type packets NOP <Handle error> RTS // File did not have file type and/or File name packets (NOP?) FinParse RTS // File is loaded and R0 points to the executable machine code NOP (sh3 table offset) Unknown // Offset of header packets table GetPacket: MULU.W R1,R2 // Table is a collection of offset pointers to routines to handle packet headers. ADD R8,R9 STS MACL,R3 ADD R9,R3 MOV.L @R3,R4 ADD R8,R4 JMP @R4 NOP Offset table (0x00 00) Unknown (0x00 01) Unknown (0x00 02) Unknown (0x00 03) Unknown (0x00 10) Unknown (0x00 11) Unknown (0x00 12) Unknown (0x00 13) Unknown (0x01 00) Unknown (0x01 01) Unknown (0x01 02) Unknown (0x01 03) Unknown (0x01 04) Unknown (0x01 05) Unknown (0xFF FF) Unknown Table routines 0x00 00  (Parent program) RTS MOV.L ADD $0D,R0 // We don't care about the parent program, so it's skipped 0x00 01 (File type) ADD$01,R6 ADD $02,R0 MOV.W (filetype),R2 CMP/EQ R1,R2 BT/S SH3file NOP <Handle non-executable file> RTS (NOP?) (filetype) 0x00 01 SH3file: RTS // File is executable NOP 0x00 02 (FileName) ADD$01,R6 RTS ADD $09,R0 0x00 03 (Version compatibility) MOV.W @R0+,R1 ADD$01,R5 // Mark bit 1 of R5 that the version compatibility packet was detected RTS // There's only one format version at the time of writing, so it's kind of redundant :p ADD R1,R0 0x00 10 (Header packet) RTS MOV.W @R0+,R1 0x00 11 (Language) RTS ADD $04,R0 0x00 12 (Checksum) RTS ADD$05,R0 0x00 13 (TimeStamp packet) RTS MOV.W \$0F,R0 0x01 00 (HeaderEnd) RTS MOV.W @R0+,R1 0x01 01 (Icon Packet) MOV.W @R0+,R1 RTS ADD R1,R0 0x01 02 (File size) MOV.W @R0+,R1 RTS ADD R1,R0 0x01 03 (Clock speed packet) MOV.W @R0+,R1 RTS ADD R1,R0 0x01 04 (MMUCR) MOV.W @R0+,R1 RTS ADD R1,R0 0x01 05 (File Load) MOV.W @R0+,R1 RTS ADD R1,R0 0xFF FF (Main()) .class parsing 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 <handle error> RTS // File not .class file (NOP?) (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 <handle error> RTS // Version not supported (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?> ADD 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 <Handle error> RTS // super_class and/or this_class are not indices into the constant_pool table (NOP?) 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 Loop2 ADD 0x01,R2 ADD 0xFF,R2 CMP/EQ R2,R4 BT/S FieldsMethods NOP <Handle error> RTS // Something in the interfaces array isn't a valid index into the constant_pool (NOP?) 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 InterpreterStart: ...
« Last Edit: April 21, 2011, 11:26:15 pm by Qwerty.55 »
∂²Ψ    -(2m(V(x)-E)Ψ
---  = -------------
∂x²        ℏ²Ψ

#### turiqwalrus

• Posts: 840
• Rating: +51/-2
• Wheeeeeee~!
##### Re: Java on the Prizm
« Reply #36 on: April 22, 2011, 09:06:54 am »
this is looking nice, qwerty55
I'll be happy when I can program in a language that I'm familiar with

#### AngelFish

• Is this my custom title?
• LV12 Extreme Poster (Next: 5000)
• Posts: 3242
• Rating: +270/-27
• I'm a Fishbot
##### Re: Java on the Prizm
« Reply #37 on: April 26, 2011, 05:26:39 am »
Okay, after quite a bit of work converting it to Gnu AS syntax, Khavi (Java for Prizm) is finally assembling without any errors in the main code. I've attached the source for the initialization code and classloader below. To build it on a Windows machine, cd to a directory containing the source [and the assembler] and copy/paste this in:

Quote
sh3eb-elf-as.exe --small -aln Kahvi_source.txt -o Kahvi.o >Khavi_Errors.txt

It's time to start doing serious work on the JVM itself and decide whether or not to thread the interpreter
« Last Edit: April 27, 2011, 08:57:22 pm by Qwerty.55 »
∂²Ψ    -(2m(V(x)-E)Ψ
---  = -------------
∂x²        ℏ²Ψ

#### z80man

• Casio Traitor
• Posts: 977
• Rating: +85/-3
##### Re: Java on the Prizm
« Reply #38 on: April 26, 2011, 11:38:17 am »
Don't worry about threading the interpreter now. The most important thing is to get the basic runtime up and to ensure that it works. Then we can add the more complex features such as garbage collecting, threading, and Just in Time Compilation. Also unless you already have it working don't bother with the floats right now because we have some more important work to do.

List of stuff I need to do before September:
1. Finish the Emulator of the Casio Prizm (in active development)
2. Finish the the SH3 asm IDE/assembler/linker program (in active development)
3. Create a partial Java virtual machine  for the Prizm (not started)
4. Create Axe for the Prizm with an Axe legacy mode (in planning phase)
5. Develop a large set of C and asm libraries for the Prizm (some progress)
6. Create an emulator of the 83+ for the Prizm (not started)
7. Create a well polished game that showcases the ability of the Casio Prizm (not started)

#### AngelFish

• Is this my custom title?
• LV12 Extreme Poster (Next: 5000)
• Posts: 3242
• Rating: +270/-27
• I'm a Fishbot
##### Re: Java on the Prizm
« Reply #39 on: April 26, 2011, 03:52:35 pm »
Threading shouldn't be terribly difficult (famous last words  ), since it's just a matter of setting and resetting the WDT register after you properly initialize the interrupt table to handle the threads.

EDIT: Screwed up the build with some misaligned data that the instruction table was masking. Took a few minutes to fix.
« Last Edit: April 26, 2011, 07:29:56 pm by Qwerty.55 »
∂²Ψ    -(2m(V(x)-E)Ψ
---  = -------------
∂x²        ℏ²Ψ

#### AngelFish

• Is this my custom title?
• LV12 Extreme Poster (Next: 5000)
• Posts: 3242
• Rating: +270/-27
• I'm a Fishbot
##### Re: Java on the Prizm
« Reply #40 on: April 27, 2011, 08:59:46 pm »
Okay, I finally got a moment to fix the build errors. The good source has been reuploaded to my previous post in case anyone wants to look it over for whatever reason. *Now* I can write the interpreter...
∂²Ψ    -(2m(V(x)-E)Ψ
---  = -------------
∂x²        ℏ²Ψ

#### DJ Omnimaga

• Clacualters are teh gr33t
• CoT Emeritus
• LV15 Omnimagician (Next: --)
• Posts: 55936
• Rating: +3153/-232
• CodeWalrus founder & retired Omnimaga founder
##### Re: Java on the Prizm
« Reply #41 on: April 27, 2011, 09:03:41 pm »
I'm glad to see progress on this. I can't wait to see some examples of programs running

#### AngelFish

• Is this my custom title?
• LV12 Extreme Poster (Next: 5000)
• Posts: 3242
• Rating: +270/-27
• I'm a Fishbot
##### Re: Java on the Prizm
« Reply #42 on: April 30, 2011, 12:40:13 am »
It's amazing what no school, no homework, and no Internet will do for your productivity. The binaries are about 4kb now from 1kb two days ago. It's really starting to hit just how massive this project is. There's pretty much no way a JVM is ever going to fit on an 84+ without an app. Anyway, specs:

During development, programs will be limited to a 2KB operating buffer per thread. This is because I want to avoid as much interaction with the system as possible until other things are finished. I've also come up with a potential cache management system to use with the eventual JIT compiler, but I think I'm going to have to seriously abuse the cache to get it to work.

It's starting to look like an actual interpreter
∂²Ψ    -(2m(V(x)-E)Ψ
---  = -------------
∂x²        ℏ²Ψ

#### z80man

• Casio Traitor
• Posts: 977
• Rating: +85/-3
##### Re: Java on the Prizm
« Reply #43 on: April 30, 2011, 03:35:07 am »
Great to see that you've had much time to work on this. I'e been very limited lately and will be this weekend because I have an AP exam on Tuesday, but after that I will be practically homework free for the rest of the school year.

And because you are planning to use JIT compilation later on, one thing that I found that can increase speed there is when writing the routines into the runtime ram, you write them in at a fixed length that way jump statements don't require intervention on the work of the interpreter. What I'm setting up for the 84+ emulator is that originally each routine when written to ram would be extended to 64 bytes, but this proved to be too short so I'm increasing it to 128 bytes unless I size optimize the routines at the cost of speed. This would then allow execution to then jump around quickly if for example a for loop was written in the runtime ram. This would be especially useful for java because there is no worry about SMC unlike the 84+ and a less complex memory manager would be required.

List of stuff I need to do before September:
1. Finish the Emulator of the Casio Prizm (in active development)
2. Finish the the SH3 asm IDE/assembler/linker program (in active development)
3. Create a partial Java virtual machine  for the Prizm (not started)
4. Create Axe for the Prizm with an Axe legacy mode (in planning phase)
5. Develop a large set of C and asm libraries for the Prizm (some progress)
6. Create an emulator of the 83+ for the Prizm (not started)
7. Create a well polished game that showcases the ability of the Casio Prizm (not started)

#### AngelFish

• Is this my custom title?
• LV12 Extreme Poster (Next: 5000)
• Posts: 3242
• Rating: +270/-27
• I'm a Fishbot
##### Re: Java on the Prizm
« Reply #44 on: May 08, 2011, 02:44:42 am »
I've decided that a slight change of name is in order. The project is now officially the Khavi Virtual Machine Framework.

This name change is prompted by the fact that I have now added support for the instruction set of the Lua virtual machine. This will be included in the default release and will allow the framework to emulate both stack based and register based virtual machines.

On an unrelated note, I'll also be rewriting a large portion of the program to adhere to something more resembling a real virtual machine rather than a naive interpreter. This will result in some slowing of the program, but it will likely save kilobytes of space and code in the long run as well as permit the program to execute threads running different languages simultaneously without interference*. The only thing that I have to completely rewrite because of this is the thread manager/context switcher, although that's by far the most complicated and evil part of this whole insane program.

Overall, progress!

*The current way would allow Lua to do some very bad things to Java threads if the interpreter freaked out.
∂²Ψ    -(2m(V(x)-E)Ψ
---  = -------------
∂x²        ℏ²Ψ