Omnimaga
Omnimaga => Discontinued => Our Projects => Khavi => Topic started by: z80man on April 04, 2011, 12:34:23 am
-
Many of you here have requested a java virtual machine for the Prizm. (most notably Ashbad ;)) Well I have been studying my java bytecode and I believe that this is quite possible. If you did not know, java bytecode is a stack oriented language in which the Prizm excels at. Now I did not find any of the jazelle extensions that the arm has, but it doesn't mean that java is impossible. What can be done is code the proper functions for each of the instructions, some of which would only take 1 SH3 instruction. The other thing to do is remove all of those fancy, but unnecessary features of the JVM. Stuff like malicious code testing and maybe partial garbage collecting. So right now I'm kind of busy with about 4 other Prizm projects that I'm working on, but during the summer or maybe after the AP exams, I will have time to get started on this.
EDIT: Changed topic title to include the project name
-
It sounds interesting, but do you not need a VM to maintain the state of all the objects and run threads?
-
Many of you here have requested a java virtual machine for the Prizm. (most notably Ashbad ;)) Well I have been studying my java bytecode and I believe that this is quite possible. If you did not know, java bytecode is a stack oriented language in which the Prizm excels at. Now I did not find any of the jazelle extensions that the arm has, but it doesn't mean that java is impossible. What can be done is code the proper functions for each of the instructions, some of which would only take 1 SH3 instruction. The other thing to do is remove all of those fancy, but unnecessary features of the JVM. Stuff like malicious code testing and maybe partial garbage collecting. So right now I'm kind of busy with about 4 other Prizm projects that I'm working on, but during the summer or maybe after the AP exams, I will have time to get started on this.
This looks like a great idea. There was once a topic about Java on the NSpire, so I hope this turns out right for the PRIZM :D
-
:)
-
Java would be nice, assuming it's feasible. A bunch of people in the community already knows Java and maybe Builderboy could port some of his games to the Prizm. :P
-
Java would be nice, assuming it's feasible. A bunch of people in the community already knows Java and maybe Builderboy could port some of his games to the Prizm. :P
The Silencer on the PRIZM? :crazy:
-
Java would be nice, assuming it's feasible. A bunch of people in the community already knows Java and maybe Builderboy could port some of his games to the Prizm. :P
We could have multi platform games!
-
Okay, I took the liberty of spending a few days exploring the JVM and how it works. It's surprisingly simple. I see absolutely no reason why would we couldn't get a JVM running on the Prizm.
I spent an hour tonight and wrote a routine to parse/validate about half of the .class file format (the rest should be fairly easy to parse). It could probably be used as initialization code for such a JVM.
General Parser form:
If R0 holds a pointer to the first byte 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
RET
(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
ROTL R1
CLRT
ROTR R1
MOV.L R1,R8
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:
CLRT
XOR R2,R2
XOR R4,R4
MOV.L @R0-,R1
MOV.B 0x10,R3
Loop1:
ADD 0xFF,R3
ROTR 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 R8,R1
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:
Etc...
Also, I have a full instruction list of the JVM, along with a few SH3 ASM routines I wrote that happen to perform those operations.
During runtime, the following are assumed:
R12 is a 32 bit flag register.
R13 holds PC.
R14 points to the operand stack.
R15 is a stack for interpreter use.
aaload
0x32
aastore
0x53
aconst_null
0x01
aload
0x19
Also supports Wide format, which means the opcode is preceded by 0xC4
aload_<n>
aload_0 opcode = 0x2A
aload_1 opcode = 0x2B
aload_2 opcode = 0x2C
aload_3 opcode = 0x2D
anewarray
0xBD
areturn
0xB0
arraylength
0xBE
astore
0x3A
Also supports Wide format, which means the opcode is preceded by 0xC4
astore_<n>
astore_0 opcode = 0x4B
astore_1 opcode = 0x4C
astore_2 opcode = 0x4D
astore_3 opcode = 0x4E
athrow
0xBF
baload
0x33
bastore
0x54
bipush
0x10
breakpoint
0xCA
Reserved opcode. Should not appear in any .class file.
caload
0x34
castore
0x55
checkcast
d2f
d2i
d2l
dadd
daload
dastore
dcmpg
dcmpl
dconst_<d>
ddiv
dload
dload_<n>
dmul
dneg
drem
dreturn
dstore
dstore_<n>
dsub
dup
dup2
dup2_x1
dup2_x2
dup_x1
dup_x2
f2d
f2i
f2l
fadd
0x62
faload
fastore
fcmpg
fcmpl
fconst_<f>
fconst_0 opcode = 0x0B (11)
fconst_1 opcode = 0x0C (12)
fconst_2 opcode = 0x0D
fdiv
0x6E
fload
fload_<n>
fmul
0x6A
fneg
0x6A
frem
freturn
fstore
fstore_<n>
fsub
getfield
getstatic
goto
goto_w
i2b
i2c
i2d
i2f
i2l
i2s
iadd
0x60
iaload
iand
0x7E
iastore
iconst_<n>
iconst_m1
idiv
0x6C
if_acmpeq
if_acmpne
if_icmpeq
if_icmpge
if_icmpgt
if_icmple
if_icmplt
if_icmpne
ifeq
ifge
ifgt
ifle
iflt
ifne
ifnonnull
ifnull
iinc
iload
iload_<n>
impdep1
impdep2
imul
ineg
instanceof
invokeinterface
invokespecial
invokestatic
invokevirtual
ior
0x80
MOV.L @R14+,R1
MOV.L @R14+,R2
OR R2,R1
MOV.L R1
irem
0x70
MOV.L @R14+,R0
MOV.L @R14+,R2
MOV R2,R3
SUB R0,R3
MOV $20,R4
DIV0U R0,R1
Startdiv:
ADD $FF,R4
DIV1 R0,R1
TST R4,R4
BT/S Startdiv
ROTCL R2
DMULU.L R2,R3
STS MACL,R2
MOV.L R2,@-R14
ireturn
ishl
ishr
istore
istore_<n>
isub
iushr
ixor
0x82
MOV.L @R14+,R1
MOV.L @R14+,R2
XOR R2,R1
MOV.L R1
jsr
0xA8
jsr_w
0xC9
l2d
l2f
l2i
ladd
0x61
laload
land
lastore
lcmp
lconst_<l>
ldc
ldc_w
ldc2_w
ldiv
lload
lload_<n>
lmul
lneg
lookupswitch
lor
lrem
lreturn
lshl
lshr
lstore
lstore_<n>
lsub
lushr
lxor
0x83
monitorenter
monitorexit
multianewarray
new
newarray
nop
0x00
pop
pop2
putfield
putstatic
ret
return
saload
sastore
sipush
swap
tableswitch
wide
Opcodes and descriptions can be found here (http://en.wikipedia.org/wiki/Java_bytecode_instruction_listings).
It sounds interesting, but do you not need a VM to maintain the state of all the objects and run threads?
That depends on what you mean by "Virtual machine." The JVM is essentially nothing more than an interpreter. It just happens to interpret the machine code for a virtual machine.
-
Okay, I took the liberty of spending a few days exploring the JVM and how it works. It's surprisingly simple. I see absolutely no reason why would we couldn't get a JVM running on the Prizm.
I spent an hour tonight and wrote a routine to parse/validate about half of the .class file format (the rest should be fairly easy to parse). It could probably be used as initialization code for such a JVM.
General Parser form:
If R0 holds a pointer to the first byte 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
RET
(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
ROTL R1
CLRT
ROTR R1
MOV.L R1,R8
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:
CLRT
XOR R2,R2
XOR R4,R4
MOV.L @R0-,R1
MOV.B 0x10,R3
Loop1:
ADD 0xFF,R3
ROTR 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 R8,R1
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:
Etc...
Also, I have a full instruction list of the JVM, along with a few SH3 ASM routines I wrote that happen to perform those operations.
During runtime, the following are assumed:
R12 is a 32 bit flag register.
R13 holds PC.
R14 points to the operand stack.
R15 is a stack for interpreter use.
aaload
0x32
aastore
0x53
aconst_null
0x01
aload
0x19
Also supports Wide format, which means the opcode is preceded by 0xC4
aload_<n>
aload_0 opcode = 0x2A
aload_1 opcode = 0x2B
aload_2 opcode = 0x2C
aload_3 opcode = 0x2D
anewarray
0xBD
areturn
0xB0
arraylength
0xBE
astore
0x3A
Also supports Wide format, which means the opcode is preceded by 0xC4
astore_<n>
astore_0 opcode = 0x4B
astore_1 opcode = 0x4C
astore_2 opcode = 0x4D
astore_3 opcode = 0x4E
athrow
0xBF
baload
0x33
bastore
0x54
bipush
0x10
breakpoint
0xCA
Reserved opcode. Should not appear in any .class file.
caload
0x34
castore
0x55
checkcast
d2f
d2i
d2l
dadd
daload
dastore
dcmpg
dcmpl
dconst_<d>
ddiv
dload
dload_<n>
dmul
dneg
drem
dreturn
dstore
dstore_<n>
dsub
dup
dup2
dup2_x1
dup2_x2
dup_x1
dup_x2
f2d
f2i
f2l
fadd
0x62
faload
fastore
fcmpg
fcmpl
fconst_<f>
fconst_0 opcode = 0x0B (11)
fconst_1 opcode = 0x0C (12)
fconst_2 opcode = 0x0D
fdiv
0x6E
fload
fload_<n>
fmul
0x6A
fneg
0x6A
frem
freturn
fstore
fstore_<n>
fsub
getfield
getstatic
goto
goto_w
i2b
i2c
i2d
i2f
i2l
i2s
iadd
0x60
iaload
iand
0x7E
iastore
iconst_<n>
iconst_m1
idiv
0x6C
if_acmpeq
if_acmpne
if_icmpeq
if_icmpge
if_icmpgt
if_icmple
if_icmplt
if_icmpne
ifeq
ifge
ifgt
ifle
iflt
ifne
ifnonnull
ifnull
iinc
iload
iload_<n>
impdep1
impdep2
imul
ineg
instanceof
invokeinterface
invokespecial
invokestatic
invokevirtual
ior
0x80
MOV.L @R14+,R1
MOV.L @R14+,R2
OR R2,R1
MOV.L R1
irem
0x70
MOV.L @R14+,R0
MOV.L @R14+,R2
MOV R2,R3
SUB R0,R3
MOV $20,R4
DIV0U R0,R1
Startdiv:
ADD $FF,R4
DIV1 R0,R1
TST R4,R4
BT/S Startdiv
ROTCL R2
DMULU.L R2,R3
STS MACL,R2
MOV.L R2,@-R14
ireturn
ishl
ishr
istore
istore_<n>
isub
iushr
ixor
0x82
MOV.L @R14+,R1
MOV.L @R14+,R2
XOR R2,R1
MOV.L R1
jsr
0xA8
jsr_w
0xC9
l2d
l2f
l2i
ladd
0x61
laload
land
lastore
lcmp
lconst_<l>
ldc
ldc_w
ldc2_w
ldiv
lload
lload_<n>
lmul
lneg
lookupswitch
lor
lrem
lreturn
lshl
lshr
lstore
lstore_<n>
lsub
lushr
lxor
0x83
monitorenter
monitorexit
multianewarray
new
newarray
nop
0x00
pop
pop2
putfield
putstatic
ret
return
saload
sastore
sipush
swap
tableswitch
wide
Opcodes and descriptions can be found here (http://en.wikipedia.org/wiki/Java_bytecode_instruction_listings).
It sounds interesting, but do you not need a VM to maintain the state of all the objects and run threads?
That depends on what you mean by "Virtual machine." The JVM is essentially nothing more than an interpreter. It just happens to interpret the machine code for a virtual machine.
Qwerty: That looks awesome!
Do compiled programs need Java or some special app in the calculator to run? How fast is it?
Java on the Prizm, now I want a PRIZM even more.
-
What will be needed is some sort of JVM to run .class files. There are two ways to do this:
1. The JVM is made like a shell that loads the program into ram and then executes it.
2. My other plan was in the asm shell I'm currently working on is to allow programs to register an extension
-hold on for more, bell just rang
-
I finished the routine to parse .class file headers right before you posted this...
EDIT:
The extensions are going to be stored in whatever file allocation table the Prizm uses, probably appended to the name of the file itself. That table would also contain a pointer to the file for easy access.
Also:
General Parser form:
If R0 holds pointer to the first byte 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
RET
(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...
When it's reached the end of the header, the stack contains pointers to the Attributes table, the methods table, the fields table, the constant pool table, as well as a pointer to a the location to exit to. There might are a few bugs in this code that I still have to fix, but it's mostly functional.
-
@Qwerty I see an optimization in there. When you use the MULU.L instruction do not follow it with the STS MACL. If you access the MAC following a multiply instruction, MULU will take 3 cycles, but if you put at least one other instruction in between the MULU and the STS, then MULU only takes 1 cycle ;)
And the idea with the extensions was for the asm shell. Just like Doors the shell doesn't have to be for asm programs only. Added features could be BASIC progs too. But my main idea was that the shell would have something like a registry found on windows systems. Because on windows for example Microsoft word will register the .doc file extension to itself. So whenever you select a .doc file, word will open that file. The same idea could apply to a .class file on the shell. When a .class file is selected then the JVM will be ran with a pointer to the file to run, passed as an argument.
-
Nice catch. I must have missed that.
However, I just noticed a simpler way of detecting .class files: use the "magic" number 0xCAFEBABE. It's present in all .class files, so it can identify them and my file format can easily allow that particular header to be invalid.
-
[A bit Offtopic]
Qwerty, I just noticed you're already writing SH3 (PRIZM) assembly very well, never expected you guys to dominate it so fast :) Nice job
-
Nice catch. I must have missed that.
However, I just noticed a simpler way of detecting .class files: use the "magic" number 0xCAFEBABE. It's present in all .class files, so it can identify them and my file format can easily allow that particular header to be invalid.
Yes that is an easier way of detecting class files, but when it comes to a shell that is designed for any file format type, using something like 0xCAFEBABE is not universal. So it might be easier if the first time you run the java program it does a call to the libraries of the shell with "class" and an icon as an argument. Then when viewing files in a screen similar to Doors, all class files will have a coffee cup icon and when you click on it java will be run with the class file as an arg
-
I wonder how fast would Java be on the Prizm. Could a game like Nightmare be possible?
-
This code just keeps growing :P
Trying to write an interpreter in Assembly really gives you an appreciation for why they're so large.
-
This code just keeps growing :P
Trying to write an interpreter in Assembly really gives you an appreciation for why they're so large.
That's likely, it's a Java interpreter for a calculator :P
-
I re-wrote a good portion of the initialization code to accommodate the Java Native Interface. It now handles both the .class format and the .sh3 format that I wrote awhile back. Packet based formats are significantly more difficult to parse, though :-\
-
I hope it fits on-calc, lol. :P
-
Yeah, I can see in the readme: "You can only make 2 kb games. Each game must include a 1.9kb header."
-
Well, 1.97kb, but close enough :P
In reality, the area available for program use will probably be on the order of 100 kb. That's what the OS will handle and I don't really want to throw Flash management into the JVM (in addition to the garbage collector, JNI, threading, etc) in order to get more.
-
Does the SH3 have anything like Jazzelle in its CPU? That would help a lot.
-
Nope, there's nothing like Jazelle.
-
Do you mean calculator Java games will be limited to 2 KB? ???
-
No, that was a joke. They'll be limited to declaring 100 KB or so of usable memory during runtime. The actual program can be whatever size will fit in memory.
-
Phew. :P And 100 KB seems good at least.
-
Now are we talking about 100 kb of executable, data, or executable and data. Remember that for the executable we can run that from flash which would give a possible size of several MB's and the heap looks like a promising area to keep data at 128 kB. There's also the system and add-in stack which for the most part are empty and combined are at a size of 1 MB. Also if it is not being used by anything the back buffer is a lot of ram.
-
Does the SH3 have anything like Jazzelle in its CPU? That would help a lot.
Not sure of how helpful that is, nobody has made Java on the NSpire yet and it has jazelle. Perhaps it's not Jazelle's problem and the nspire's.
Nice to see this progressing Qwerty.55.
-
Does the SH3 have anything like Jazzelle in its CPU? That would help a lot.
Not sure of how helpful that is, nobody has made Java on the NSpire yet and it has jazelle. Perhaps it's not Jazelle's problem and the nspire's.
Nice to see this progressing Qwerty.55.
how Jazelle works is that it executes the simple Java bytecode instructions in hardware just like they were any other CPU instruction, and then for the more complex instructions that are not implemented in hardware, Jazelle will pass off the instruction to the JVM to execute. Unfortunately the SH4A does not include Jazelle so we can't use it. I believe the current layout of our JVM for the Prizm is that several instructions are translated to machine code at a time and then that block is executed. That prevents all of the branches that would be done if you executed the instructions one at at a time.
-
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.
-
So does this mean MINECRAFT?! Omg minecraft on a calc :D
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 ;)
-
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!
-
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 :P. It still has all that inflated crap in the header and GC, but at least it's meant for smaller size constraints.
-
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.
-
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 :P. 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? :o
Heck no. I don't have the next three years of my life to dedicate to this one program :P
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 :P
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:
...
-
this is looking nice, qwerty55
I'll be happy when I can program in a language that I'm familiar with :P
-
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
-
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.
-
Threading shouldn't be terribly difficult (famous last words :P), 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.
-
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...
-
I'm glad to see progress on this. I can't wait to see some examples of programs running :D
-
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 ;D
-
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.
-
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.
-
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.
So is Khavi a random name you invented?
-
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.
So is Khavi a random name you invented?
Khavi means coffee in some language (I don't know which one), and coffee = java
-
Nice work here! The fact that it's going to support LUA is pretty sweet too! =)
-
Khavi means coffee in some language (I don't know which one), and coffee = java
Finnish, I believe.
-
Here's a quick description of how Khavi works, for anyone who'se interested:
When a program is opened from the shell, the shell recognizes the extension and passes it on to Khavi, along with some other information such as a pointer to the program. If Khavi hasn't been opened in a thread before, then it overwrites the Interrupt table to set up its thread manager, starts it, and passes control to what will become the primary thread. Back in the thread, Khavi looks up the proper parsing algorithm in a table and jumps to that algorithm. Each algorithm goes through the file header and extracts all of the useful information from it. Once that's completed, Khavi selects the proper interpreter to parse the bytecode with.
The interpreter for each type of bytecode is mostly custom and implements a complete instruction set for the virtual machine as well as the interpreter itself. The Khavi framework itself imposes no restrictions on each interpreter and they can do as they like. This allows each interpreter to be as powerful as the designer wants them to be. However, it also means a lot of redundant code with multiple languages written in. Therefore, Khavi also offers a small library of "threadcalls" to do common things like add float point numbers, write strings to the screen. It also provides programs with ways of doing things that would be extremely difficult to do within the confines of the instruction set itself, such as passing arguments to other threads.
Behind all of this lies the Thread manager (or context switcher, if you prefer). This component transparently handles the threading so that no individual thread is aware of the fact that it isn't always operating. Its other important task is to handle interactions between threads as well as manage their interaction with the rest of the system, both of which are done through the "threadcalls."
There's actually a lot more small stuff going on with cache management and the heap, but that's the simple explanation :)
-
So basically this allows multiple languages to use this? I am a bit confused because I though all this was was a java interpreter/virtual machine. ???
-
It's a virtual machine for any instruction set that has been written for it. That's currently Java and Lua.
-
Ah ok I see now. I wonder how many languages it will support in the future...
-
it could quite possibly support emerald, though most likely not as optimized because most instructions in the Emerald Opcode Language are controlled primarily by the VM (there's only even 1 math command that tells the VM to evaluate the expression and perform all lower-level math specified) -- most of the opcodes are even undo-able without support for Emerald Ideals. Maybe we can collaborate for an emerald extension later on, but for now I don't think it would fare very well ;)
-
Ashbad, it's precisely as optimized as you write the code to be ;)
Getting the instruction and looking up the address of that instruction handler takes less than 10 cycles. The inefficiencies in your C compiler outweigh that.
-
GCC-based code can be pretty darn close to assembly code ;) if it weren't GCC or LLVM, I would be concerned -- but GCC is close enough, ~10 more cycles doesn't hurt anything ;)
Also, qwerty, I think your VM is a bit different than mine -- yours is more low-level in the sense it does the bare bones interpretation, whereas mine basically wraps the program around like a snake 5 coils around and acts as a whole surrogate OS in a sense. Emerald is meant to be ran on a more suitable environment meant for emerald-only programming (of course any language that can compile to Emerald Bytecode is welcome, though) because the VM and the program react almost as two living creatures, as it implements my "Living VM" theory.
-
And I'd like to implement my 84+ emulator on Khavi too as that is technically a bytecode VM as well. I do have a question though. Is Khavi a standalone program or is it more like a framework to be used to make VM's? Sort of like libraries that you attach to a program except this library controls the program flow.
-
It's kind of both, except I haven't added support for external libraries (not that it would be terribly difficult). Khavi is a standalone program except in that it needs certain arguments to be passed to it when it's booted. After that, it will be able to run independently of other programs. I will be releasing an official version supporting multiple languages to reduce the number of add-ins necessary. However, anyone who wants to will be able to use the Kavi framework with minor changes to the actual interpreter and only have to write the instruction set, so it's a framework in that sense.
BASIC, though, presents some special challenges to bytecode interpretation, since it's not pure bytecode. You'll need to tokenize the arguments and the expressions, which is where you're going to lose a lot of speed.
-
Would Khavi have a break button by any chance. That could be useful to break from buggy programs using the ON button.
-
I could write it in, since the ON button normally isn't used anyway.
-
Would that be interrupt based to prevent slowdowns or is it simple enough to within standard code.
-
It'd be interrupt based simply because there's no need to test for it within every thread and the thread manager in the interrupt table is the only code that's *always* executed. The thing about some interpreted languages is that the specifications sometimes force threads to be lockable, which means break code would otherwise have to run in every thread or risk being possible to disable.
-
Will this provide options for compressing code? Java code can be extremely large, and the amount of memory a JVM takes up to implement all features is enormous and time consuming. How does multithreading work with Khavi? Up to what Java version will it support? Will it support Java-based things such as Jruby, Groovy and *groan* Jython? Will it only be an interpreter, or will it also have some sort of an IDE built in so you can write code on calc (because I personally dislike using a computer to code calculator stuff). Will it have a terminal similar to one in something like Netbeans and Eclipse with full interaction, or just bare bones? What's the time table for release, and what's the current progress? What languages will be supported out of the box without further configurations? How will the speed compare with Prizm C, or on-comp Java? How will GC be administered, if it will be administered? How will objects be treated in memory, and how will memory be allocated for them? Will Java programs be able to access low-level things such as individual bytes in memory, or just the higher level stuff? How many libraries will work for this -- most (if not all) graphics libraries for Java are platform-dependent.
Just a few things I thought of asking :P
-
Will this provide options for compressing code? Java code can be extremely large, and the amount of memory a JVM takes up to implement all features is enormous and time consuming. How does multithreading work with Khavi? Up to what Java version will it support? Will it support Java-based things such as Jruby, Groovy and *groan* Jython? Will it only be an interpreter, or will it also have some sort of an IDE built in so you can write code on calc (because I personally dislike using a computer to code calculator stuff). Will it have a terminal similar to one in something like Netbeans and Eclipse with full interaction, or just bare bones? What's the time table for release, and what's the current progress? What languages will be supported out of the box without further configurations? How will the speed compare with Prizm C, or on-comp Java? How will GC be administered, if it will be administered? How will objects be treated in memory, and how will memory be allocated for them? Will Java programs be able to access low-level things such as individual bytes in memory, or just the higher level stuff? How many libraries will work for this -- most (if not all) graphics libraries for Java are platform-dependent.
Just a few things I thought of asking :P
Okay I'll take as many questions as I can
1. I've been wanting to implement zip, tar.gz, and tar.qz file systems on my shell system so that when Khavi is launched the code is temporarily extracted to be ran.
2. The amount of memory taken is based off the size of java code ran and however well the JVM is coded. Because this is low level coded the size will be much smaller then on your comp
3. Multi threading is handled using the WDT which is a countdown timer and generates an interrupt when it reaches 0. Upon reaching an interrupt the code jumps to an interrupt handler where a new thread is ran.
4. I doubt it will be any particular version as features from 6 may be included while features from 2 may still be missing.
5. Size is a little big for those programs, but it might be small enough to fit one of them. The only issue is that some of the libs are in native machine code so an SH3 port would be required.
6. Yes an editor could be made as a separate program, but you would still have to transfer the source to your computer for compilation.
7. It will probably just use my shell's default terminal, but that could be expanded for more features.
8. Time table, I wouldn't be the one to ask, but I'd say that it would never be done as more features could be added, optimizations to be made, and newer versions of java to support.
9. The progress so far is that the class loader Khavi is made so that now all the core Java features can now be made. This being the routines for the bytecode interpreter.
10. As in languages if you mean spoken languages then that would be English for now or if you mean prog languages then that would be Java, but Lua for Khavi is also in the works.
11. Well on comp Java is probably faster than Prizm C :P but because Java is the fastest interpreted language imho it should be up there. I would mention that floating point math will cause slowdowns as there is no fpu, but everything else will be fast because the Super H is well optimized for stack oriented languages such as Java. It will become even faster once JIT is supported.
12. I believe Qwerty is writing some fast routines to handle GC the same way any other JVM would, but the coder still shouldn't abuse that feature as the Prizm is still a low power device
13. Well in java bytecode objects don't exist. It's just standard data types. The objects are all handled by the java compiler which already exists.
14. Memory will be allocated by a new set of advanced malloc calls that would allow significantly more memory to be allocated than the default Casio one.
15. I'm not entirely sure what you mean by accessing individual bytes. If you mean being able to read any location in memory via a pointer then this would be allowed contrary to the on comp JVM as there are no security checks other than array bounds.
16. Any library that runs off pure bytecode can be ran while everything that uses native code will have to be ported. And I was planning an OpenGL port as I've been reading the book Real Time Rendering which discusses how to make a port.
-
interesting ;) seems as if you're got more of the specifics down already, nice job! :D
just wondering, how many bytes would you estimate be open for developers to use? How many does the VM take up?
-
interesting ;) seems as if you're got more of the specifics down already, nice job! :D
just wondering, how many bytes would you estimate be open for developers to use? How many does the VM take up?
I believe Qwerty planned 128 kb of data with code size limited at the size of your flash chip being limited to 16 Mb + any compression techniques used. I do have several ideas though for acquiring more space in ram to possibly as high as 1 MB. The VM size I'd have no idea and we won't know till it is finished.
-
I'll probably be out this week, so I'll answer while I can:
Speed wise, a reasonable estimate for a non-overclocked Prizm running a single thread of decent code might be approximately as fast as an ASM program on a TI-z80 in normal mode. Multiple threads will decrease the speed significantly as will heavy math/data allocation, but that's basically impossible to work around. Also, Khavi will support any language that compiles to Java bytecode, which includes Groovy. Khavi will also support any language that compiles to Lua bytecode or a few other unannounced VM's as well in the final version. However, there will be no IDE. I have enough compilers to deal with without trying to write one for languages I don't even understand. You'll have to find some other way of compiling the bytecode.
PS: Multi-threading is handled kind of like z80man said. The hardware tells Khavi when to switch threads and the context switcher does a little magic to make that happen.
-
Sorry to hear you'll be gone, I hope you don't have too much stuff to do D:
Glad to see the speed will be similar to z80 ASM speed. Hopefully some good stuff can be done in this.
-
Okay, rewrote a few things to make the threading a lot more efficient, at the cost of some size. Still not entirely sure how I'm going to handle the library calls, though. I also implemented more of the instruction sets for the Lua and Java VMs.
EDIT: Also implemented the full Brainf*ck instruction set :P
-
Cool to hear there is some progress :D
-
I've been kind of busy with other, more immediate things recently, but Khavi is still progressing. If everything goes well, I should have a working demo by the end of this week.
However, this demonstration will leave out a lot of crucial stuff, so here's a partial list of things waiting to be completed:
- Full multi-threading support
- Privileges
- Khavi Scripting Language (KSL): This will be almost entirely undocumented, so don't worry about learning a new language. The syntax is only slightly better than brainf*ck, so you're not missing out on much except the chance to brick your calc :P
- Shell dependencies: This will most likely be one of the last things implemented
- Interpreter run-time libraries: Dependent on KSL and the booting process
- Native interfaces: Depends heavily on KSL
- Full Java VM instruction set
- Full Lua instruction set: It's relatively close to completion, though.
- Boot code: It's a major PITA to write and will probably be one of the last things written, since it's dependent on so many other factors. Also depends somewhat on KSL
- The "Nuke(char *City)" function of the Java VM: Don't ask...
- The context switcher: It's written, but I need to copy it from my notebook.
- Memory management (distinct from garbage collection): Lookup-tables, lookup-tables, lookup-tables
- Garbage collection: Screw it. Garbage collection is for wimps :P
- Anything else I've forgotten: Have you seen the size of this list?
-
Will this ever run *.jar files? It would be hard, as Prizm has no QWERTY keyboard, not all the QWERTY keyboard keys are on the Prizm, and it has no mouse. (There goes Logisim :'()
-
Khavi will accept both specially prepared .sh3 files containing Java bytecode and normal .class files when it opens a file. However, it does not accept .jar files, mostly because I don't have enough information on them to write a parser capable of handling arbitrary files. If anyone would like to point me to some decent documentation for them, I'd be happy to consider adding support for the filetype.
-
http://en.wikipedia.org/wiki/JAR_file (http://en.wikipedia.org/wiki/JAR_file)
Basically just zip'd .class files and stuff. There's the META-INF folder, which I'm sure is also well-documented.
-
Thanks. I'll just ignore the META-INF folder since no one likes it :P
Anyway, apparently I screwed something up in the source and the Java instructions were lost. No idea what happened. Either way, I spent a few hours today and rewrote most of them to be faster and more efficient. Also, I slowed down the interpreter loop by an outrageous 400 nanoseconds to eliminate around 4 KB of parser overhead PER THREAD. The runtime memory used by the interpreter itself should now be roughly the same whether there are 2 threads in a given language or 20. The side effect to this is that the interpreter (ironically) has to ask for almost as much memory as was saved from the system :P
-
Any recent progress as of September? :)
-
Not as much as I'd like. There's been some IRL work that's taken a lot of my time.
-
In any case I'm glad this progressed in the past few months. I hope it eventually gets finished :D
-
Once the Prizm contest ends this Thursday feel free to ask me for any help with routines, libraries, memory management, multi threading, and so on. I'd really like to see some test examples running soon.
-
In case anyone missed the announcement in the updates thread, I had a bit of an accident with my hard drive and the entire source was deleted. I've had to restart from basically nothing.
-
In case anyone missed the announcement in the updates thread, I had a bit of an accident with my hard drive and the entire source was deleted. I've had to restart from basically nothing.
That's too bad, you should always make backups... In fact, the best way is to have a repository...
-
Can someone port this to FX-series?
-
Can someone port this to FX-series?
The main priority is to get it working on *one* platform before even considering going through porting process. It's not wise to ask for a port when the project in subject isn't even near completion yet.
-
I have been considering a port, but I definitely want to get it working once before even attempting to port it anywhere.
-
Of course. But I just wanted to know if it was on the agenda. probably should have stated that. BTW: will this pave the path for getting other languages.....Like Python?
-
Probably not. Normal Python interpretation relies on parsing plaintext. This is typically handled much differently than the bytecode interpretation Khavi implements. If you were to compile python to a bytecode, though, there's absolutely no reason you couldn't get khavi to execute it.
-
OK. cuz I LOVE Python 2.7!
-
Yeah for now the goal is to get it back into its state from before the hard drive incident and also worry more about backups in the future :P
-
Backup, Backup, Backup. (thats why national backup day was made.)
-
Yeah for now the goal is to get it back into its state from before the hard drive incident and also worry more about backups in the future :P
I set it up with a repository for more permanent storage as well as a directory [on a different server] that auto-syncs with all of my major project folders.
Thanks for the concern everyone.
-
You should maybe also copy your progress every hour on a CD or DVD plus an extra copy on a flash drive, in case that fails too. :P
-
I sound like an annoying spammy advertiser (maybe I am :P), but Dropbox is your friend. Anything I regard as important (documents, essays, projects, interesting files, etc.) I place into my Dropbox folder. (You basically install Dropbox and then put everything you want to sync in the folder, and the daemon automatically syncs it to the server.) There is no revision control (at least not that I know of for the free plan, but it may have changed).
My workflow for wxWabbitemu is pretty much: checkout from SVN, modify code in Dropbox folder, verify that the code works, and then push the changes to SVN. That way, there's no way you could lose ANY code, unless you delete the folder by accident, or the world explodes. ;)
** Admitting, I never do this for my on-calc projects. :P I want to make an iTunes like app to sync programs and apps back and forth, without the bloat...
EDIT: A portable version is available for Dropbox, if you can't install. PM me/poke me/etc.
-
Personally, I keep things safe with a multitude of thumb drives. Those also work well.
Either way, good luck qwerty :(
-
Here's the current source for the context switcher. It's mostly completed, aside from a single call to the [currently unwritten] scheduling algorithm.
/* Khavi context switcher (to be located in RAM and accessed from */
/* Uses Round robin for simplicity */
/* Table bitfields:
* First node: [Address of current linked list][Address of next linked list][registers]
* All secondary nodes: [Address of next linked list][registers]
*/
/* Should also store/reload the table if planning to implement process/thread distinction */
Start_switcher:
mov.l r2,@-r15 /* Store registers for use */
mov.l r1,@-r15
mov.l r0,@-r15
mov.l first_table,r0
mov.l @r0,r0 /* move address of current table into r0 */
add #0x7F,r0 /* Offset r0 to end of table. Needs to be tuned properly. */
mov.l @r15+,r2 /* Store r0 to table */
mov.l r2,@-r0
mov.l @r15+,r2 /* Store r1 to table */
mov.l r2,@-r0
mov.l @r15+,r2 /* Store r2 to table */
mov.l r2,@-r0
mov.l r3,@-r0 /* Store rest of registers */
mov.l r4,@-r0
mov.l r5,@-r0
mov.l r6,@-r0
mov.l r7,@-r0
mov.l r8,@-r0
mov.l r9,@-r0
mov.l r10,@-r0
mov.l r11,@-r0
mov.l r12,@-r0
mov.l r13,@-r0
mov.l r14,@-r0
mov.l r15,@-r0
stc sr,r1 /* Switch register banks */
mov.l mask,r2 /* These lines derived and modified from Linux kernel 2.6.* */
xor r2,r1
bra rest
ldc r1,sr
mask: .long 0x40000000
rest:
stc.l r1,@-r0
stc.l gbr,@-r0
stc.l vbr,@-r0
stc.l ssr,@-r0
stc.l spc,@-r0
stc.l r0_bank,@-r0
stc.l r1_bank,@-r0
stc.l r2_bank,@-r0
stc.l r3_bank,@-r0
stc.l r4_bank,@-r0
stc.l r5_bank,@-r0
stc.l r6_bank,@-r0
stc.l r7_bank,@-r0
sts.l mach,@-r0
sts.l macl,@-r0
sts.l pr,@-r0
add #-4,r0 /* Go to table to be restored */
mov.l @r0,r0
mova Start_switcher,r2
lds.l @r0+,pr /* restore system registers */
lds.l @r0+,macl
lds.l @r0+,mach
ldc.l @r0+,r7_bank
ldc.l @r0+,r6_bank
ldc.l @r0+,r5_bank
ldc.l @r0+,r4_bank
ldc.l @r0+,r3_bank
ldc.l @r0+,r2_bank
ldc.l @r0+,r1_bank
ldc.l @r0+,r0_bank
ldc.l @r0+,spc
ldc.l @r0+,ssr
ldc.l @r0+,vbr
ldc.l @r0+,gbr
ldc.l @r0+,sr
stc sr,r1 /* Switch register banks */
mov.l mask,r2 /* These lines derived and modified from Linux kernel 2.6.* */
xor r2,r1
ldc r1,sr
mov.l @r0+,r15
mov.l @r0+,r14
mov.l @r0+,r13
mov.l @r0+,r12
mov.l @r0+,r11
mov.l @r0+,r10
mov.l @r0+,r9
mov.l @r0+,r8
mov.l @r0+,r7
mov.l @r0+,r6
mov.l @r0+,r5
mov.l @r0+,r4
mov.l @r0+,r3
add #-12,r15 /* Set SP properly */
mov #8,r1 /* modify linked lists */
add r0,r1 /* Need to add call to scheduling algorithm to choose next thread/process */
mov r1,@r2
mov.l @r0+,r1
mov.l r1,@-r15
mov.l @r0+,r1
mov.l r1,@-r15
mov.l @r0+,r1
mov.l r1,@-r15
mov.l @r15+,r2
mov.l @r15+,r1
rte
mov.l @r15+,r0
first_table: .long 0x00000000 /* address of first node in linked list */
-
So, when will LWJGL be ported so we can run minecraft? :P
Also Albert, actually there is revision control to a point: You can recover up to 5 older versions of a file that completely uploaded. That could mean weeks, days, or seconds, depending on how save-happy you are.
But then, dropbox wasn't designed as a replacement for svn. It was designed as a replacement to NFS drives.
-
It'll be ported when you compile the native stuff for Prizm :P
-
Okay, it's been a whole two days (::)) since I posted on progress.
As it turns out, there were a few things in the old Java interpreter that didn't quite mesh with the official Sun spec, so I'm in the process of fixing those. I'm also going to be doing garbage collection a bit differently and I've started on the beast that is memory management. There will be a repository up sometime in the near future as soon as I get the project approved.
-
The project is going to sun approved? cool!
-
I doubt it will ever be approved by Sun/Oracle. I'm just making it somewhat compatible with the Java Virtual Machine specification.
-
The project is going to sun approved? cool!
You'd probably have to pony up some fee to get it officially approved, but having this fit the entire spec sounds like a great idea. This looks like a really useful project -- good luck!
-
It will be able to run native code inside, right? (like android can, often used for emus) That means if we can get TI to put it in 3.0.3 and later, then we'd have Asm access! :P
You know, sans ndless. (which is still awesome, but the no 3.x atm is a downer)
-
It can definitely run native code (after all, the interpreters are nothing but well documented native code that the framework was designed to handle), but it's not on the Nspire :P
-
Oh yeah *facepalm* I fail at memory.
Still cool though!
-
Just so everyone knows, the Lua available will be the latest version I have available, which probably means 5.2 beta. This may introduce some problems for compilers, although I believe 5.2 is largely backwards compatible.
-
Yay! Now I can play minecraft on a calculator!
if only.
EDIT: Seriously, why am I always the one to start pages??????
-
I do it too, on occasion :P
Anyway, I've been way too busy to do as much work on this as I'd like. I did manage to write a better (read: faster) brainf*ck interpreter and I did a bunch of interpreter ABI documentation for the other interpreters. The Lua interpreter is also progressing, if slowly. Unfortunately, I lost all of the floating point routines with that crash, so I'm not looking forward to actually writing the math stuff...
-
Okay, after a lot of pain, I finally figured out how to set up a repository and use SVN.
http://khavi.googlecode.com/svn/trunk/ (http://khavi.googlecode.com/svn/trunk/)
-
@boot it's a statistical thing. Really. We generally have our times where we check omni, and you happen to line up as the number which starts a new page.
Stats are fun :P
And yay for progress!! Khavi should be able to run ADOM soon, right? There are CLI-only java versions ;D
-
Okay, after a lot of pain, I finally figured out how to set up a repository and use SVN.
http://khavi.googlecode.com/svn/trunk/ (http://khavi.googlecode.com/svn/trunk/)
All the source files seem to be .txt though :S
-
That's mostly because I don't like using .s files. Everything except the Gnu GPL is still source, though.
-
I'M glad some progress is still being made. The Lua interpreter will definitively help a lot. Make sure to make it compatible with LuaFX if it comes out for the prizm, though. It's only for AFX calcs right now but they planned to port it to the FX-9860G eventually, which has a similar processor as the Prizm.
-
It won't be entirely LuaFX compatible, as far as I'm aware. LuaFX is a complete implementation of the Lua interpreter. Khavi is an implementation of the Lua virtual machine (which is admittedly all that LuaFX includes at the moment).
-
Oh ok what are the main differences? ???
Also a while ago, there was a project to implement something like Axe Parser on the prizm, for BASIC coders unwilling to learn a totally new language (Axe had similarities with TI-83+ BASIC for example). Was it gonna be included in Khavi or was it another side project?
-
The main difference between LuaFX and Khavi's Lua virtual machine is that LuaFX will be more like TI's Lua interpreter; It will be able to take plaintext Lua code, compile it to bytecode, and then execute that bytecode. All Khavi does is execute the bytecode. The compilation is left to the user and computer side compilers.
As for the Prizm Compiler, that was z80man's project, so I'm not sure how far he got on it. As I recall, he put it on hold to work on Walnut. It would have compiled to native ASM, so it wouldn't have been a part of Khavi (although Khavi can indeed run non-Khavi programs alongside the interpreters).
-
Okay, life is starting to ease up a bit, so I managed to get some work in. Khavi now supports single precision floating point and I'll probably add double precision support tomorrow, since it shouldn't be too much extra work.
-
Improved the library interface, reduced the size of several of the Java commands, and added some more stuff to the library.
-
Glad this is progressing again. I wonder if it will reach the status where a demo program can be ran soon? :D
-
are you guys still going to try to do this for FX-9860, or is it a PRIZM-only thing?
-
Technically, it should be able to run on any SH3 chip, but it's still more of a Prizm only kind of thing.
-
I thought prizm was SH-4A ???
-
So Khavi also includes a Lua (bytecode) interpreter?
Interesting :)
-
whats a bytecode interpretor?
-
I thought prizm was SH-4A ???
for the most part yes but it's actually a customized chip designed exclusively for Casio. Because Khavi will most likely interface with the core peripherals heavily it is important to note the differences.
-
How is this coming along?
Would be epic to play java games on the prizm O.o
-
Are you still developing this?
-
I hope this is still being developed. I have dreams of mincraft on calc :P
-
Is this still being worked on. How much progress has there been?
-
Sorry, I've been working on another more important project lately. This one has kind of stalled in the meantime. :(
-
After you finish the project you are working on, you should get this rolling again.
-
D: sorry to hear. Hopefully you can get back to it soon. :)
-
The original Minecraft will never work on this calculator, it requires waay too much power (even school computers run it a little slow). I do think though that a Minecraft clone could work fine with Doom engine or other.
-
Holy necro! O_o
Have you seen: http://ourl.ca/15365 (http://ourl.ca/15365)?