Propeller JVM Project: PASM Java VM
jazzed
Posts: 11,803
Javelin Propeller JVM Project
The latest code required for EEPROM based PropellerJVM is here:
PropellerJVM Spin/PASM, Javelin library, and Tools
Replace the .zip PropellerJVM-32K-EeCache/bin/jlink.exe with this one
This is the continuation of a PASM JVM partially based on Peter's spin bytecode interpretations. It uses Java byte code generated by a variant of the Javelin tool or Jikes and PropDirect. Since the JVM is written in PASM, Java code runs at a very comfortable speed even with Spin managing program execution.
The original functional Spin JVM implementation was so slow it was funny[noparse]:)[/noparse] This version is much faster and is slower than Spin by about a factor of 2. In FIBO tests, this implementation actually out-performs the Javelin by 2:1.
The comm protocol/code is large and the IDE is really not worth much for debugging to me, so I have no plan to use it. Including the COMM code will waste about 2KB of precious bytecode space and that is unreasonable.
A separate lib.zip is included that I'm using for testing. The lib has a compareTo() method for String.java, but other than that and PROP.java, it should be the same as on yahoo groups. All Propeller I/O pins are accessible through the PROP.java class.
Building
Caveats
The scaled down version of Java being "emulated" is used on the JavelinStamp, so the Java section of the Javelin manual defines the abilities (assuming no bugs and full implementation) of the jvm.
The original Javelin has room for 32KB of Java code. Only 20KB is available on Propeller.
The latest EEPROM based solution will allow running programs up to 96KB.
Javelin does not have garbage collection "GC" ... a big problem for Java purists.
Another horrible limitation is the lack of a "long" data type. The "float" and "double" data types are also not natively supported. These issues somewhat mitigated with library classes provided by Peter.
The Throw byte code PASM method is not done. Thus, try...catch Exception handling does not exist. Exceptions are reported back to the main loop. The program is designed for now to hang on exceptions.
The native handling code is still in spin; It does not buy much to move it to PASM since native methods are less often executed and can stand to be slower. The VP functions are implemented in PASM.
Cheers.
--Steve
Comments
Thanks for the files.
I just posted my VP library for SXB 2.0 here:
http://forums.parallax.com/showthread.php?p=784673
For the sx I encoded the 6 VP types in just over 256 instructions (interrupt code),
each VP runs for 31 cycles per interrupt, so VP code is threaded. I still feel the Prop should
be able to manage that in a single cog (496 instructions).
The sx VP code is in file DynamicVP_DEF.SXB, encoded in macro dvpCore.
If anyone feels up to it see if you can convert it to PASM.
regards peter
Post Edited (jazzed) : 3/20/2010 6:06:33 PM GMT
Post Edited (jazzed) : 4/4/2010 6:15:22 AM GMT
Here is an Unsorted Singly Linked List ADT test running on Propeller with a tiny tribute to Pete Carr
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Short answers? Not available at this time since I think you deserve more information than you requested.
A special String.java is attached that provides a String object compareTo() method for list insertion sorting.
Save lib\java\lang\String.java to lib\java\lang\String_old.java. Download and copy the file to lib\java\lang\String.java
I'll start some stamp.cpu hardware interface testing sometime this week.
Garbage collection is a high priority, but some things like user input are more important.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Short answers? Not available at this time since I think you deserve more information than you requested.
Please use the attached pjvm_demo_TerminalTest2 files for development.
Use the attached make.bat for building a new image with your own java source.
Make sure to save make.bat rather than run it from your browser.
The TerminalTest2.java program is a little lame if using PST; the flash command particularly does not work in PST the way it should.
Here is PST output with $10 translation turned off.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Short answers? Not available at this time since I think you deserve more information than you requested.
Impressive work. I know there is a Java backend for GCC - how close are you to being able to run GCC-compiled programs? I don't think I would ever bother with this for plain old C, but it occurs to me it might be a way of getting both C++ and Java on the Propeller.
Also, how is the execution speed of this JVM compared to SPIN?
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Thanks Ross.
Getting GNU to compile to "native" PASM (LMM that is), is difficult. I've used Cygwin for development and one of the Cygwin "advancements" has made that less desirable. I could move my Linux box to my office I guess .... [noparse]:)[/noparse]
One problem with GCJ is the Java "vintage" ... pre Java2 it seems ... but so is the Javelin. Both C++ and Java are a little "big" for Propeller I also. Maybe Propeller 2 makes more sense.
My interest in Java is mostly for serving the education market if that makes sense. It is also a language on humanoidio's list, but to me the current "character spitting" implementation to me is not worth anyone's time. Being able to add "any" peripheral rather than choosing one of the Javelin VP types via Spin/PASM is also attractive.
Spin is faster because it's more compact (one cog -vs- three) and some of the Java implementation is in Spin like the Native JNI code and the execution control loop. Getting the execution loop in PASM would help speed by about 10x I guess.
Some of my goals may be unreachable, but they are desirable. Some Java GUI running on a Propeller and LCD like Rayman's PSM or other platform would be neat. Just getting garbage collection to work on top of a rock solid Java VM would be a big win for me at least.
Getting real Java to load/run from an externally attached Propeller device would be sweet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Short answers? Not available at this time since I think you deserve more information than you requested.
In theory that GCC will also compile Java for ZPU and hence Zog/Prop. No idea how to get it working though.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Gee, missing "string" in C++ is like an elephant missing its trunk. Not a good thing for Propeller C++ hopefuls.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Short answers? Not available at this time since I think you deserve more information than you requested.
I meant C++ or Java running at a speed that was comparable with SPIN.
Have either of you benchmarked C++ or Java programs running under ZOG or the JVM with a comparable SPIN program?
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
C++ and Zog are at the stage of "wow it's amazing that works at all"
Java and Zog I have yet to get working, not sure it's on my agenda.
Zog is for C. There are some serious optimizations that can be done to what we have now. Then we can think about a comparison with Spin, Catalina, ICC, whatever. I don't expect much due to the very nature of the ZPU architecture.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Finding a winner is seemingly not the point. Having a performance survey would be good though.
There is a table that I've published several times that shows some relative performance between
Spin, PASM, and ICC LMM C. Maybe that would be a useful low level start.
I don't plan to spend a lot of time optimizing - a good, stable feature set is more important.
Having something that works well given the constraints of the environment is my goal.
Today this Java solution has the current attributes:
- 16KB of Java bytecode space available in HUB RAM.
- One COG used for controlling JVM (room for some JNI functions).
- Three COGs for JVM interpreter.
- One COG for Full-Duplex Console, One COG for Spin.
- Two COGs for VirtualPeripherals (not tested).
I'm more intrigued by the possibilities:- Add Garbage Collection.
- Add support for SDCARD FAT file-system.
- Add support for executing from byte-wide external memory.
- Try to add support for executing programs from SDCARD.
- Try to add support the full Java2 JVM specification.
- Add interface layer for XVGA LCD with video memory.
I'm a C programmer of course, but Java is elegant and gets much attention in education.Whether that is an argument for a market or not is debatable. There are all kinds of users.
Since I've had a some success making PASM JVM work, it makes sense to find a good finish.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Short answers? Not available at this time since I think you deserve more information than you requested.
My JVM appears to have a problem with FIBO24+ so I'll be fixing that.
Meanwhile here are the results for fibo(23) using 80MHz clkfreq.
- Spin fibo(23) takes about 2.4 seconds
- Java fibo(23) takes between 3 and 4 seconds
I'll get better performance measurements after testing the JNI Timers.▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Short answers? Not available at this time since I think you deserve more information than you requested.
FIBO(23) 4 Seconds
FIBO(24) 7 Seconds
FIBO(25) 11 Seconds
FIBO(26) 17 Seconds
Or all of them in 41 seconds. Measure by eye against my PC's clock, so give or take a second.
fibo(00000017) = 00006ff1
fibo(00000018) = 0000b520
fibo(00000019) = 00012511
fibo(0000001a) = 0001da31
Sorry Zog only knows how to print hex for now.
Seems Zog is not doing as badly as I expected.
We have some optimizations in mind for Zog. Bascally the ZPU architecture is stack based with no processor registers (except PC and SP), we can optimize away a lot of redundant PUSH/POPS. But as FIBO is very stack intensive those optimizations may not have much effect.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Output from Catalina (using program attached) @ 80Mhz:
The program should be compiled using:
Ross.
P.S. @heater - no fair using a 104MHz clock!!!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
I am surprised at how well spin has done. Guess I should dust off my Fast Interpreter for +20-25%.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
Catalina executing from XMM (on the Hybrid):
Same program as previously, compiled using:
Interestingly, almost exactly 4 times slower than the LMM version.
Ross.
Edit: forgot HYBRID command line flag!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Post Edited (RossH) : 3/18/2010 10:35:41 AM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
Do you mean Catalina, JVM or ZOG? If you mean JVM or ZOG, then heater or jazzed should answer - but if you mean Catalina then even though there is currently no Catalina RamBlade target, you don't really need one just to run an LMM program on an 80Mhz Prop using a PC terminal emulator for output (and no keyboard or mouse). Try this:
Of course, to use XMM you will need to write the necessary XMM access routines and also create a RAMBLADE target.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com 5.0" VGA LCD in stock!
Morpheus dual Prop SBC w/ 512KB kit $119.95, Mem+2MB memory/IO kit $89.95, both kits $189.95 SerPlug $9.95
Propteus and Proteus for Propeller prototyping 6.250MHz custom Crystals run Propellers at 100MHz
Las - Large model assembler Largos - upcoming nano operating system
I've been testing stamp.core.cpu.Timer along with FIBO, and it appears to work within the 16 bit limitations, but the tick counts need to be translated.
The pjvm_demo package has been updated in the top post.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Short answers?
Not available since you deserve more information than you requested.
May the road rise to meet you; may the sun shine on your back.
May you create something useful, instead of just another hack.
Post Edited (jazzed) : 3/22/2010 5:41:41 PM GMT
- Added a reasonable garbage collector.
- Verified several source libraries work including Format.java and ScaledTimer16.java from Javelin Code Files
- Verified CPU pin I/O function correctly. The Timer works of course in the FIBO example.
- Still testing VirtualPeripherals.
- Also 20KB is available for Javelin Programs.
Current FIBO24 results:Do you have the Fibo Java code that I can test on the Javelin to compare the performances?
I'm thinking about buy a Prop to help on the testing part. I only know how to code in Java. So might not pe able to help with the PASM [noparse]:([/noparse]
JM
Thanks for your interest. Any help at all is appreciated. Having someone other than me try comparisons on
Javelin is of great value for ensuring compatability. I have a Javelin here somewhere ... will find it if necessary[noparse]:)[/noparse]
Thanks.
Later I'll send you or anyone else a free Propeller Dip40 (you pay shipping) after your reasonable contribution.
At minimum a 5MHz Crystal and USB serial cable with DTR reset are needed, but I'm not ready to provide that.
Try this code:
// FiboTest // import stamp.core.*; import stamp.math.*; import stamp.util.text.*; public class FiboTest { private ScaledTimer16 timer; public FiboTest() { timer = new ScaledTimer16(400,200); //timeUnit = 1000usec = 1msec } private static int fibo(int n) { if ( n > 2 ) { return fibo(n-1) + fibo(n-2); } else { return 1; } } public void test(int count, int end) { int result = 0; int ms = 0; int passed = 0; while(count <= end) { Format.printf("FIBO(%02d)", count); timer.mark(); result = fibo(count); //CPU.delay(1000); // delay 95.48ms according to Javelin definition passed = timer.passedTicks(); ms = timer.TicksToTime(passed); Format.printf(" = %5u ", result); Format.printf("(%5u ms)\r\n", ms); count++; } } public static void main() { System.out.println(""); FiboTest fibo = new FiboTest(); while (true) fibo.test(0,24); } public static void main(String[noparse][[/noparse]] args) { FiboTest fibo = new FiboTest(); fibo.test(24,40); } } // end class▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
May the road rise to meet you; may the sun shine on your back.
May you create something useful, even if it's just a hack.
Here are the results...
Is barely 2 times slower on the Javelin!
Does it really mean this 8$ chip can do better than my 90$ one? [noparse]:([/noparse]
My Javelin is installed for my home automation. It's easy for me to access it and update it to do any testing if required.
Regarding the "Free" propeller, thanks for the offer. But I will still have to buy a board, a power suply, and so on [noparse];)[/noparse] So if I have to do some testing with it, I will probably order some board and cables. Probably the pro board because it looks very complete.
Let me know if there is anything I can do for help with my Javelin and my Java knowledge. I'm pretty good in Java, but that's the only language I know.
JM
For 1msec units (= 100 * 10usec) you must use
··public·FiboTest()·{
····timer·=·new·ScaledTimer16(400,100);·//timeUnit·=·100*10usec·=·1msec
··}
On the prop, the internal free-running 32bits timer must increment every 8.68 usec
just as on the javelin (the function TicksToTime relies on·that).
regards peter
Are the 2 counting wrong?
I mean, if the code is wrong on the 2 plateforms, does it mean they both display a wrong result? So we can still compare the performances? Or I should re-run the program to compare it?
Thanks,
JM
al realtime values are calculated. I have not inspected the pasm code
but since Jazzed specified 200 to get a 1msec unit, it could be the
prop uses a 4.34 usec tick.
regards peter
There are differences in the FiboTest results that are obvious. The FIBO(1) for example takes about 18ms on the Propeller with the PASM JVM, and 1ms on Javelin. This tells me that Javelin is better at straight code. The performance increase on Propeller at FIBO(24) is more likely due to less work required for it to POP data off the stack.
Regarding the question about an $8 vs $90 "chip" there are obvious differences. Javelin has been around a while and Peter has made massive professional level contributions (without compensation AFAIK). The PASM code I've produced (based in part on Peter's interpretation of Javelin) is still new and lacks some features. Javelin is a module that has an external SRAM which allows 32KB of Java bytecode. Propeller is a self contained chip that allows for 20KB of Java bytecode as of now, but it still needs EEPROM for code storage and a power strategy. Note that the SpinStamp is roughly equivalent to the Javelin except for the memory difference. Javelin offers 6 virtual peripherals. Today's Propeller code offers 4 but they are still not entirely functional (the functionality will be complete in time and I will try to make 6 VPs possible). A plus for Propeller of course is that it is an open design that is capable of practically anything within limits and offers up to 28 free IO pins.
Straight talk on all fronts.
Cheers.
--Steve
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
May the road rise to meet you; may the sun shine on your back.
May you create something useful, even if it's just a hack.