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

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.

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.

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

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.

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:

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

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:

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

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.

I'm glad to see progress on this. I can't wait to see some examples of programs running

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.