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

0 Members and 1 Guest are viewing this topic.

Offline z80man

  • Casio Traitor
  • LV8 Addict (Next: 1000)
  • ********
  • Posts: 977
  • Rating: +85/-3
    • View Profile
Re: Khavi: Java on the Prizm
« Reply #60 on: May 13, 2011, 02:43:53 am »
Would that be interrupt based to prevent slowdowns or is it simple enough to within standard code.

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)

Offline AngelFish

  • Is this my custom title?
  • Administrator
  • LV12 Extreme Poster (Next: 5000)
  • ************
  • Posts: 3242
  • Rating: +270/-27
  • I'm a Fishbot
    • View Profile
Re: Khavi: Java on the Prizm
« Reply #61 on: May 13, 2011, 02:46:38 am »
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.
∂²Ψ    -(2m(V(x)-E)Ψ
---  = -------------
∂x²        ℏ²Ψ

Ashbad

  • Guest
Re: Khavi: Java on the Prizm
« Reply #62 on: May 14, 2011, 06:20:18 pm »
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

Offline z80man

  • Casio Traitor
  • LV8 Addict (Next: 1000)
  • ********
  • Posts: 977
  • Rating: +85/-3
    • View Profile
Re: Khavi: Java on the Prizm
« Reply #63 on: May 14, 2011, 08:44:34 pm »
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.

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)

Ashbad

  • Guest
Re: Khavi: Java on the Prizm
« Reply #64 on: May 14, 2011, 09:22:57 pm »
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?

Offline z80man

  • Casio Traitor
  • LV8 Addict (Next: 1000)
  • ********
  • Posts: 977
  • Rating: +85/-3
    • View Profile
Re: Khavi: Java on the Prizm
« Reply #65 on: May 14, 2011, 10:08:08 pm »
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.

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)

Offline AngelFish

  • Is this my custom title?
  • Administrator
  • LV12 Extreme Poster (Next: 5000)
  • ************
  • Posts: 3242
  • Rating: +270/-27
  • I'm a Fishbot
    • View Profile
Re: Khavi: Java on the Prizm
« Reply #66 on: May 15, 2011, 01:41:05 am »
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.
∂²Ψ    -(2m(V(x)-E)Ψ
---  = -------------
∂x²        ℏ²Ψ

Offline DJ Omnimaga

  • Clacualters are teh gr33t
  • CoT Emeritus
  • LV15 Omnimagician (Next: --)
  • *
  • Posts: 55941
  • Rating: +3154/-232
  • CodeWalrus founder & retired Omnimaga founder
    • View Profile
    • Dream of Omnimaga Music
Re: Khavi: Java on the Prizm
« Reply #67 on: May 17, 2011, 11:36:01 pm »
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.

Offline AngelFish

  • Is this my custom title?
  • Administrator
  • LV12 Extreme Poster (Next: 5000)
  • ************
  • Posts: 3242
  • Rating: +270/-27
  • I'm a Fishbot
    • View Profile
Re: Khavi: Java on the Prizm
« Reply #68 on: May 30, 2011, 06:27:32 pm »
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
∂²Ψ    -(2m(V(x)-E)Ψ
---  = -------------
∂x²        ℏ²Ψ

Offline DJ Omnimaga

  • Clacualters are teh gr33t
  • CoT Emeritus
  • LV15 Omnimagician (Next: --)
  • *
  • Posts: 55941
  • Rating: +3154/-232
  • CodeWalrus founder & retired Omnimaga founder
    • View Profile
    • Dream of Omnimaga Music
Re: Khavi: Java on the Prizm
« Reply #69 on: May 30, 2011, 08:36:29 pm »
Cool to hear there is some progress :D

Offline AngelFish

  • Is this my custom title?
  • Administrator
  • LV12 Extreme Poster (Next: 5000)
  • ************
  • Posts: 3242
  • Rating: +270/-27
  • I'm a Fishbot
    • View Profile
Re: Khavi: Java on the Prizm
« Reply #70 on: June 18, 2011, 04:07:07 am »
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?
∂²Ψ    -(2m(V(x)-E)Ψ
---  = -------------
∂x²        ℏ²Ψ

Offline Spyro543

  • LV9 Veteran (Next: 1337)
  • *********
  • Posts: 1189
  • Rating: +74/-3
    • View Profile
Re: Khavi: Java on the Prizm
« Reply #71 on: July 12, 2011, 10:45:29 pm »
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 :'()

Offline AngelFish

  • Is this my custom title?
  • Administrator
  • LV12 Extreme Poster (Next: 5000)
  • ************
  • Posts: 3242
  • Rating: +270/-27
  • I'm a Fishbot
    • View Profile
Re: Khavi: Java on the Prizm
« Reply #72 on: July 13, 2011, 12:00:39 am »
Quote
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.
∂²Ψ    -(2m(V(x)-E)Ψ
---  = -------------
∂x²        ℏ²Ψ

Offline calcdude84se

  • Needs Motivation
  • LV11 Super Veteran (Next: 3000)
  • ***********
  • Posts: 2272
  • Rating: +78/-13
  • Wondering where their free time went...
    • View Profile
Re: Khavi: Java on the Prizm
« Reply #73 on: July 13, 2011, 12:03:07 pm »
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.
"People think computers will keep them from making mistakes. They're wrong. With computers you make mistakes faster."
-Adam Osborne
Spoiler For "PartesOS links":
I'll put it online when it does something.

Offline AngelFish

  • Is this my custom title?
  • Administrator
  • LV12 Extreme Poster (Next: 5000)
  • ************
  • Posts: 3242
  • Rating: +270/-27
  • I'm a Fishbot
    • View Profile
Re: Khavi: Java on the Prizm
« Reply #74 on: August 04, 2011, 04:46:10 am »
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
« Last Edit: August 04, 2011, 04:48:44 am by Qwerty.55 »
∂²Ψ    -(2m(V(x)-E)Ψ
---  = -------------
∂x²        ℏ²Ψ