Java development on the Propeller
Daniel B.
Posts: 5
- Would it make sence to consider Java development on the Propeller?
- It would certainly require development of an Java interpretor?
- But consider the capabilities that it would be unique in a Java environment.
- For development, might an existing code interpretor be ported?
- And lastly, would special classes be required to make use of the Propeller's capabilities?
Comments
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,
Simon
www.norfolkhelicopterclub.com
You'll always have as many take-offs as landings, the trick is to be sure you can take-off again
BTW: I type as I'm thinking, so please don't take any offence at my writing style
http://forums.parallax.com/showthread.php?p=703261
Near the last post you will find the latest package including the jvm.
Java code development is done using the Javelin IDE.
regards peter
·
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,
Simon
www.norfolkhelicopterclub.com
You'll always have as many take-offs as landings, the trick is to be sure you can take-off again
BTW: I type as I'm thinking, so please don't take any offence at my writing style
Peter, Hippy, Thomas (kaio), and I all worked on this in various incarnations. Peter wrote most if not all of the current version's bytecode interpreter. Hippy wrote the first version of the VM. I produced a workable version of the Virtual Peripheral PASM. Thomas' JVM interpreter PASM has not been fully integrated; his efforts will be valuable for the faster variation but I'm not sure how that can be finished for now. The current JVM is mostly spin and is somewhat slower than it could be. The JVM was Peter's idea and we submitted all big-picture decisions for his judgement. A different JVM is of course entirely possible.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,
Simon
www.norfolkhelicopterclub.com
You'll always have as many take-offs as landings, the trick is to be sure you can take-off again
BTW: I type as I'm thinking, so please don't take any offence at my writing style
Only 16kB ram can be used to store the java program (Javelin has 32 kB).
I think we must await the Prop II, then convert the JVM from Spin to C.
The Prop II will have 256 kB ram. We can set aside 64 kB for javelin code
(the address space is limited to 16bits) which leaves 192 kB for a JVM in C
and perhaps some virtual memory devices.
If you like, you can start with converting the JVM to C already but for
Prop I that means there will be only 8 kB left for storing java code
because C requires more memory than Spin, but it is faster.
regards peter
Simonl, please don't feel bad ... nobody wants that to happen.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
ImageJ is exactly the kind of platform that you would like to have communicating with the Propeller. It has a plugin architecture and a full featured macro language.
As a strategic tool... this would open up the Prop to act as an image-based controller for all kinds of image sensitive tasks... microscopy, machine vision, etc. etc. etc.
It would probably take you a day or two to understand the plugin architecture and dittos for the macro language.
It would actually serve as a platform for much more development as well... it speaks javascript... which I think is also what you would want your app to do.
Please consider it.
http://rsb.info.nih.gov/ij/notes.html
Rich
Back to JVM on Propeller .... One of the things important to do for any project is define the "WHY" and "WHAT" then "HOW" and eventually "WHO". Javelin had the WHY and WHAT clearly defined and the HOW was provided by the WHO.
Thing is, a JVM does not have to be Javelin compatible. Being able to break away from the Javelin "box" allows some interesting things.
For some quick Javelin offshoots that could use some of the current JVM spin ported to C, some things would need redefined: First off, the JVM could use an SD file or an EEPROM file for storing the java bytecode. Secondly, one can dump the Javelin IDE requirement entirely and use a small monitor function for "user interface".
An alternative would be to use another VM. I've spent some time this morning studying the feasibility of porting nanovm to Propeller using ICC. I have code that compiles, and the resulting image is about 25KB. This leaves a little room for using nanovm's heap management. I have no idea what's left to be done with that or what kind of user experience nanovm provides. The package does have lots of java code which I believe is an IDE. The compiling VM code is missing some features like uart and eeprom interface. If anyone is interested, I'll post what I have on the port.
Back to other fun stuff now [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
'Jazzed', Would you mind posting you code, if you wish, for others to examine and consider your work & approach (?)
--and--
'rjo_': I must say that that your proposal sounds mighty appealing! Can you provide any more backgroud for others on this topic to serve as
an introduction to "ImageJ" (?) The idea that you propose, along with such capability as you have described, would make such an exercise
applicable to a greater set of applications than limited by the propoeller only. Potentially, coded applications might be crafted more quickly
using the method that you describe - which is certainly very appealing and makes the effort more worthwhile (IMHO). However, I do
wonder if or what penalties might be associated with such an approach? For instance, might one expect the the VM (which serves as the
interpretor) might be slower that the alternatives? We can we we learn more of this approach? Can you post a reccomended URL or would
you care to have a go at an introduction for the rest of us? You have our (at least my) curiousity aroused!
-Daniel
Like I said in so many words, this is the beginnings of a "port" ... there is much work to do. One can look for __ICC_VERSION and P8X32A #ifdefs to see where some things are needed ... especially in uart.c and eeprom.c. The native code will be the biggest headache. All code is GPL.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Post Edited (jazzed) : 9/8/2008 4:59:24 AM GMT
linker is also integrated into·the·public commandline tool·JavelinDirect). So you need at least that linker.
What could easily be changed is the serial protocol to transfer the image to the prop which
would be useful if the image could be stored faster onto some media.
regards peter
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
You can load the image (.jem file) directly from file as I presume that's what you did.
However, the IDE does incorporate the source level debugger and that code is
not public. Then again, I normally do not use the source level debugger, but rather
use System.out.print() calls for debugging.
When converting to C we could/should create several layers with a·'minimum' jvm
as the core. So we can select from which media to run the java code.
Are there are already any plans to create an IOCTRL scheme that allows to hook
up different I/O devices via a general interface (I assume ImageCraft C allows pointers to function)?
regards peter
Actually I had a monitor program for downloading over a serial port with other features like break, step, continue, finish stack frame, etc..., but embedding a file is also possible and would of course have an even smaller program footprint.
I was thinking of ioctl functions after succeeding in attaching and executing from external text segment memory (on hold pending an ICC fix). This would of course be necessary for a "propellinux" port. Ioctl would help in resource management, but it seems memory might still be an issue regarding file descriptors even with all text in external memory. An aside: It seems multiple service points might be offered in a COG via ioctl.
One thing that you have done for SX that I would like to see running with ICC is software multi-threading. The LMM kernel can have virtual interrupts and I plan to use this for external instruction fetch; it would not be too hard to use the same procedure for task switching. Alas, memory is always an issue [noparse]:sigh:[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve