- Either emulate the VP "in the spirit" of the JavelinStamp, with some restrictions, also possibly needing external Hardware... ("Closed System") This has a huge advantage for an "out of the box solution", also taking advantage of existing documentation... It is in the spirit of a VM, but crippling the Propeller, as with all emulations
- Or define a framework (= interface) where a user can plug-in his Assembly Code for a COG, so he can define his own VM ("Open System"). There should be more than one VP per COG. A "reference implementation" is also required, of course
That is a fascinating idea with great possibilities ... for a future phase. One of the reasons
we've gotten where we are is because we have a well defined specification. Until we meet
that specification, we shall not wander far off course. As you know, correctly specifying a
product is almost as hard as producing it. I've seen many multi-million dollard disasters.
Phase I first. Phase II is for the wish list. Your idea certainly merits phase II consideration.
I did some calculations:
On the javelin with 25MHz clock, 217 clockcycles make up 8.68 usec.
On the prop with a 80MHz clock, (80/25)*217 = 694 clockcycles make up 8.68 usec.
If each instruction in PASM executes in 1 clockcycle, as do most SX instructions,
there should be more than enough time to·run all VP code in a single COG.
This cog would emulate the SX48 interrupt routine.
Since the VP code only deals with the vpRambank registers,
and we·want the same flexible use of VP as on the javelin, meaning any type of VP
can be started while there are free banks, the following outline in spin code
should be·implemented in PASM.
DAT · vpBank· byte 0 ···
PUB isr | i,type
{{ Run all VP code }} · repeat ··· waitTick 'wait for 8.68 usec tick ··· repeat i from 0 to jd#MAX_NUM_VPS-1 ····· vpBank := jd#nmPeriph0Bank + (i<<4)······················ 'set currently accessed bank ····· type := jd.readRegister(vpBank + jd#nmPeriphISRVec) & $0F 'nmPeriphISRVec holds VP type ····· case type ······· NONE:·· vpNone ······· TIMER:· vpTimer ······· ADC:··· vpAdc ······· DAC:··· vpDac ······· PWM:··· vpPwm ······· UARTRX: vpUartRx ······· UARTTX: vpUartTx ······· other:
PRI waitTick
{{ wait until 8.68 usec have passed since last call }}
PRI vpNone
{{ optional: wait an average time to minimize jitter }}
PRI vpTimer
{{ increment 32bits timer in bank specified by vpBank }}
PRI vpAdc
PRI vpDac
PRI vpPwm
PRI vpUartRx
PRI vpUartTx
To enhance (eg. in phase II) we can add the ability to include a userdefined set of additional VP's,
which would then run in a different cog from the default VP's.
I solved the try/catch/finally issue.
The stored values were not offsets but absolute addresses, so I needed
to compare those against jvmPC.
Attached is the updated jvmException file.
The only issue still standing is when using 'step over' in the source level debugger.
This combines activity setting kRun with breakpoints.
I will focus on that next.
regards peter
Post Edited (Peter Verkaik) : 2/25/2008 8:37:28 AM GMT
I did some calculations:
On the javelin with 25MHz clock, 217 clockcycles make up 8.68 usec.
On the prop with a 80MHz clock, (80/25)*217 = 694 clockcycles make up 8.68 usec.
If each instruction in PASM executes in 1 clockcycle, as do most SX instructions,
there should be more than enough time to·run all VP code in a single COG.
...
The datasheet says 4 clock cycles for xor and many typical instructions.
Measuring xor pin toggle time with pll16x, infreq 5Mhz, I see 4 clock cycles.
It seems·that for similar ASM in one cog, Prop will run slower than SX48b.
Then actually the prop appears to run @20MHz giving (20/25)*217 = 174
But the prop can test multiple flags (c,nc,z,nz) in a single instruction (which the SX48 cannot).
That should be enough to make up for the missing cycles (I hope).
Debug 'step over' works now. Only when using try/catch and there is a catch
the 'step over' continues to run further than one line. This is due to dropped
frames by the exception handler. (this is also so for a true javelin).
I let jvmEngine return a positive value in case a native function must
be performed. So native functions are now executed from jvmMain.
The advantage of this is that only jvmMain needs editing for adding
new native functions (by including a new object for the new functions).
I also moved some constants that are local to specific objects, from
jvmData to those object.
The java method Terminal.getChar() is working, so it is possible to
use user input in the java programs.
The attached java test program will demonstrate this.
I believe the jvm now fully supports the bytecodes generated by
the javelin IDE. Some native functions may not work. The Virtual Peripheral
code needs still to be written. But it is possible to write java programs
that only require terminal input/output (such as the attached java program).
The source level debugger·is also working.
Edit: I also attached the latest Javelin IDE.
To use that, first install IDE version 2.0.3 that you can download from here: http://www.parallax.com/tabid/443/Default.aspx
Install version 2.0.3 and then unzip javelin.zip into the IDE working folder.
Download the jvm firmware into the propeller using the proptool.
Then startup javelin.exe instead of "Javelin Stamp IDE.exe" from the working IDE folder.
regards peter
Post Edited (Peter Verkaik) : 2/26/2008 12:02:14 PM GMT
Are you saying all java-only bytecodes are working?
So the following things can be used:
- declaring variables (int, char, String, arrays)
- declaring void and int methods
- declaring objects with local variables
- doing math with variables
- using statements (if, else, do ... while, while, switch)
The modified Javelin IDE can recognize a PropJavelin, and download java programs into memory?
If so (or maybe some points not), you all have done a great job in such a short time!
That's right. All·javelin constructs can be used.
The same limitations apply: ints are 16bits, no floats or longs for now.
The new javelin.exe has additional commands:
Project->Download to RAM
Project->Program to RAM
Project->Debug to RAM
to support the propeller's ability to download only to ram.
Using the regular commands will copy the bytecodes into propeller eeprom.
At the moment the JVM provides a 16KByte memoryspace for the bytecodes.
(The javelin has 32KByte memoryspace).
There are still more than 1000 longs free so that space could be cranked up to 20KByte.
I hope once alot of the spin code is converted to PASM that we can
crank it up·to 24KByte.
Most native functions have code (in spin) but these need to be tested.
No VP code is available, meaning there also is no Timer. Since most
native CPU methods depend on a 8.68 usec tick, that needs to be realized
first. The CPU.readPort(), CPU.writePort(), CPU.readPin(),·CPU.writePin(),·CPU.shiftIn(),·CPU.shiftOut()
have code and do not rely on the timer tick, so these may work but they
need to be tested to be sure.
After downloading the new IDE, I unzipped it, placed it in the existing IDE folder and renamed it.
After starting I get the message "Unable to open file (null)".
I tried clicking on "New" three times, the same error.
After clicking on "Open" and selecting a file, I get about the same error.
You probably have no printer installed in windows.
Go to start->settings->printers
and install a generic/text-only printer
Then restart the IDE and you should have no trouble.
It should work also·with a true javelin.
You need to make sure·the javelin is on the first available
com port (See Project->Global option, tab debugger, edit port list).
Even if you use Project->Program to RAM, when it connects to
a true javelin it will do Project->Program as you would normally use
with the javelin.
I usually edit the port list to only include the comport to which the device is connected.
Try Project->Identify.
If it finds a true javelin it should show version $50.
For a propeller/spinstamp programmed via the Propeller TX/RX pins
(setting commPort = 1 in jvm·spin program) the version is $78.
For a spinstamp programmed via the SOUT/SIN pins (setting commPort = 2 in jvm program)
the version is $70.
I always made a list with the ports from 1 to 14, to make sure that the IDE found my Javelin.
(because my laptop assigns a different number each time I reconnect the USB2serial device)
re Propeller timings.
The timing of Propeller instructions is well known.... What is not well known is how they compare to an 8-bit machine. The enormious advantage of 32 against 8 bits cannot always be utilzed! On the other hand allow the conditional instructions terrific shortcuts.Third: The propeller instruction set is not well suted for VMs... Fourth: There is the panalty for HUB accesses. To write fast PASM code needs some good experience with it..... After reading the above I should not expect the Propeller VW running faster than the SX
@DeSilva, since you have better knowledge of PASM than me, do you expect
a PASM JVM would yield the same speed, or even considerable less?
I think you are right that hub access will put the greatest limit on the speed,
so someone with detailed knowledge of PASM should do the conversion to PASM,
and that isn't me.
The·JVM is running properly at this moment so I think we can keep it in this
state so it can be·converted. The fact that some native routines are not working
or not tested to be working should be not a problem for the JVM itself.
@Peter: Astonishing work. I'll _have_ to learn Java now
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,
Simon
www.norfolkhelicopterclub.co.uk
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 offense at my writing style
I hear you Peter - I've already downloaded the Javelin doc's and will be studying them over the next few weeks and months I guess.
Thanks again.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,
Simon
www.norfolkhelicopterclub.co.uk
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 offense at my writing style
I am complete Javelin Novice I have a read of the Javelin Stamp Manual today got the Prop JIDE up and running.
I don't seem to be able to access pins above 0..15, am I missing something ?
Could it be that there are only 16 pins available on Stamp ?
Compile Error Stamp/core/CPU .......no pin19 defined
The true javelin has 16 I/O pins, and pins SOUT, SIN and ATN.
Those last three are also available on the spinstamp (for System.out.print and Terminal.getChar).
Support for propeller pins 16-31 is scheduled·for later,
that is when all native functions and VP code runs, as if the
propeller was a javelin.
Peter said "Support for propeller pins 16..31 is schedued for later, that is when all native functions and VP code runs, as if the propeller was a javelin"
Attached is the jvmVirtualPeripheral spin file.
For the DAC I have inserted the vpDac method that needs to be converted
to pasm. This is a very simply task, the pin output is set to the overflowbit
after adding the dutycycle (0-255) to the·accumulator.
The idea is that this code is executed every 8.68 usec if the DAC is installed.
Who can help in translating this method into the most optimized pasm code?
Also, the method isr needs to be converted to pasm. isr the entry routine that
is to be started in a new cog from another spin file.
I also added code for method vpAdc. That too needs to be converted.
regards peter
Post Edited (Peter Verkaik) : 2/27/2008 9:46:22 PM GMT
a short update from me. I'm currently testing the first PASM bytecode decoder. I have put the bytecode handler til Jem_SWAP in one cog. If I have this sucessfully tested I'll publish it and you could test it with some little Java progs. In the next two days I'm to busy to proceed the testing. But on the weekend I'll have more time.
@Peter
Good progress of coding vp's. It would be helpfully if someone could translate this to assembly.
Comments
- Either emulate the VP "in the spirit" of the JavelinStamp, with some restrictions, also possibly needing external Hardware... ("Closed System") This has a huge advantage for an "out of the box solution", also taking advantage of existing documentation... It is in the spirit of a VM, but crippling the Propeller, as with all emulations
- Or define a framework (= interface) where a user can plug-in his Assembly Code for a COG, so he can define his own VM ("Open System"). There should be more than one VP per COG. A "reference implementation" is also required, of course
That is a fascinating idea with great possibilities ... for a future phase. One of the reasons
we've gotten where we are is because we have a well defined specification. Until we meet
that specification, we shall not wander far off course. As you know, correctly specifying a
product is almost as hard as producing it. I've seen many multi-million dollard disasters.
Phase I first. Phase II is for the wish list. Your idea certainly merits phase II consideration.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
jazzed·... about·living in·http://en.wikipedia.org/wiki/Silicon_Valley
Traffic is slow at times, but Parallax orders·always get here fast 8)
On the javelin with 25MHz clock, 217 clockcycles make up 8.68 usec.
On the prop with a 80MHz clock, (80/25)*217 = 694 clockcycles make up 8.68 usec.
If each instruction in PASM executes in 1 clockcycle, as do most SX instructions,
there should be more than enough time to·run all VP code in a single COG.
This cog would emulate the SX48 interrupt routine.
Since the VP code only deals with the vpRambank registers,
and we·want the same flexible use of VP as on the javelin, meaning any type of VP
can be started while there are free banks, the following outline in spin code
should be·implemented in PASM.
CON
· 'Virtual Peripheral types
· NONE·· = 0
· TIMER· = 1
· ADC··· = 2
· DAC··· = 3
· PWM··· = 4
· UARTRX = 5
· UARTTX = 6
·
OBJ
· jd: "jvmData"
DAT
· vpBank· byte 0
···
PUB isr | i,type
{{ Run all VP code }}
· repeat
··· waitTick 'wait for 8.68 usec tick
··· repeat i from 0 to jd#MAX_NUM_VPS-1
····· vpBank := jd#nmPeriph0Bank + (i<<4)······················ 'set currently accessed bank
····· type := jd.readRegister(vpBank + jd#nmPeriphISRVec) & $0F 'nmPeriphISRVec holds VP type
····· case type
······· NONE:·· vpNone
······· TIMER:· vpTimer
······· ADC:··· vpAdc
······· DAC:··· vpDac
······· PWM:··· vpPwm
······· UARTRX: vpUartRx
······· UARTTX: vpUartTx
······· other:
PRI waitTick
{{ wait until 8.68 usec have passed since last call }}
PRI vpNone
{{ optional: wait an average time to minimize jitter }}
PRI vpTimer
{{ increment 32bits timer in bank specified by vpBank }}
PRI vpAdc
PRI vpDac
PRI vpPwm
PRI vpUartRx
PRI vpUartTx
To enhance (eg. in phase II) we can add the ability to include a userdefined set of additional VP's,
which would then run in a different cog from the default VP's.
regards peter
The stored values were not offsets but absolute addresses, so I needed
to compare those against jvmPC.
Attached is the updated jvmException file.
The only issue still standing is when using 'step over' in the source level debugger.
This combines activity setting kRun with breakpoints.
I will focus on that next.
regards peter
Post Edited (Peter Verkaik) : 2/25/2008 8:37:28 AM GMT
Measuring xor pin toggle time with pll16x, infreq 5Mhz, I see 4 clock cycles.
It seems·that for similar ASM in one cog, Prop will run slower than SX48b.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
jazzed·... about·living in·http://en.wikipedia.org/wiki/Silicon_Valley
Traffic is slow at times, but Parallax orders·always get here fast 8)
But the prop can test multiple flags (c,nc,z,nz) in a single instruction (which the SX48 cannot).
That should be enough to make up for the missing cycles (I hope).
regards peter
the 'step over' continues to run further than one line. This is due to dropped
frames by the exception handler. (this is also so for a true javelin).
regards peter
be performed. So native functions are now executed from jvmMain.
The advantage of this is that only jvmMain needs editing for adding
new native functions (by including a new object for the new functions).
I also moved some constants that are local to specific objects, from
jvmData to those object.
The java method Terminal.getChar() is working, so it is possible to
use user input in the java programs.
The attached java test program will demonstrate this.
I believe the jvm now fully supports the bytecodes generated by
the javelin IDE. Some native functions may not work. The Virtual Peripheral
code needs still to be written. But it is possible to write java programs
that only require terminal input/output (such as the attached java program).
The source level debugger·is also working.
Edit: I also attached the latest Javelin IDE.
To use that, first install IDE version 2.0.3 that you can download from here:
http://www.parallax.com/tabid/443/Default.aspx
Install version 2.0.3 and then unzip javelin.zip into the IDE working folder.
Download the jvm firmware into the propeller using the proptool.
Then startup javelin.exe instead of "Javelin Stamp IDE.exe" from the working IDE folder.
regards peter
Post Edited (Peter Verkaik) : 2/26/2008 12:02:14 PM GMT
So the following things can be used:
- declaring variables (int, char, String, arrays)
- declaring void and int methods
- declaring objects with local variables
- doing math with variables
- using statements (if, else, do ... while, while, switch)
The modified Javelin IDE can recognize a PropJavelin, and download java programs into memory?
If so (or maybe some points not), you all have done a great job in such a short time!
Kind regards,
Robot Freak
The same limitations apply: ints are 16bits, no floats or longs for now.
The new javelin.exe has additional commands:
Project->Download to RAM
Project->Program to RAM
Project->Debug to RAM
to support the propeller's ability to download only to ram.
Using the regular commands will copy the bytecodes into propeller eeprom.
At the moment the JVM provides a 16KByte memoryspace for the bytecodes.
(The javelin has 32KByte memoryspace).
There are still more than 1000 longs free so that space could be cranked up to 20KByte.
I hope once alot of the spin code is converted to PASM that we can
crank it up·to 24KByte.
regards peter
One these days I get a pair of Protoboards to start testing the JVM.
All CPU native methods are done, and it looks like the PWM VP is ready?
No VP code is available, meaning there also is no Timer. Since most
native CPU methods depend on a 8.68 usec tick, that needs to be realized
first. The CPU.readPort(), CPU.writePort(), CPU.readPin(),·CPU.writePin(),·CPU.shiftIn(),·CPU.shiftOut()
have code and do not rely on the timer tick, so these may work but they
need to be tested to be sure.
regards peter
After starting I get the message "Unable to open file (null)".
I tried clicking on "New" three times, the same error.
After clicking on "Open" and selecting a file, I get about the same error.
Did I do something wrong?
Kind regards,
Robot Freak
Go to start->settings->printers
and install a generic/text-only printer
Then restart the IDE and you should have no trouble.
regards peter
I tried setting the "Microsoft XPS Document Writer" as default, but the same error comes up.
Kind regards,
Robot Freak
A window pops up. Click OK. Exit the IDe. Restart the IDE.
That should do it.
regards peter
Trying to download to my Javelin, but it didn't work.
So I guess this IDE can only be used with the PropJavelin?
Kind regards,
Robot Freak
You need to make sure·the javelin is on the first available
com port (See Project->Global option, tab debugger, edit port list).
Even if you use Project->Program to RAM, when it connects to
a true javelin it will do Project->Program as you would normally use
with the javelin.
I usually edit the port list to only include the comport to which the device is connected.
Try Project->Identify.
If it finds a true javelin it should show version $50.
For a propeller/spinstamp programmed via the Propeller TX/RX pins
(setting commPort = 1 in jvm·spin program) the version is $78.
For a spinstamp programmed via the SOUT/SIN pins (setting commPort = 2 in jvm program)
the version is $70.
regards peter
(because my laptop assigns a different number each time I reconnect the USB2serial device)
After deleting the others, it worked.
Thanks!
Kind regards,
Robot Freak
The timing of Propeller instructions is well known.... What is not well known is how they compare to an 8-bit machine. The enormious advantage of 32 against 8 bits cannot always be utilzed! On the other hand allow the conditional instructions terrific shortcuts.Third: The propeller instruction set is not well suted for VMs... Fourth: There is the panalty for HUB accesses. To write fast PASM code needs some good experience with it..... After reading the above I should not expect the Propeller VW running faster than the SX
a PASM JVM would yield the same speed, or even considerable less?
I think you are right that hub access will put the greatest limit on the speed,
so someone with detailed knowledge of PASM should do the conversion to PASM,
and that isn't me.
The·JVM is running properly at this moment so I think we can keep it in this
state so it can be·converted. The fact that some native routines are not working
or not tested to be working should be not a problem for the JVM itself.
regards peter
@Peter: Astonishing work. I'll _have_ to learn Java now
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,
Simon
www.norfolkhelicopterclub.co.uk
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 offense at my writing style
It's more like C with classes and objects.
regards peter
Thanks again.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,
Simon
www.norfolkhelicopterclub.co.uk
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 offense at my writing style
Hi
I am complete Javelin Novice I have a read of the Javelin Stamp Manual today got the Prop JIDE up and running.
I don't seem to be able to access pins above 0..15, am I missing something ?
Could it be that there are only 16 pins available on Stamp ?
Compile Error Stamp/core/CPU .......no pin19 defined
Regards Ron
Those last three are also available on the spinstamp (for System.out.print and Terminal.getChar).
Support for propeller pins 16-31 is scheduled·for later,
that is when all native functions and VP code runs, as if the
propeller was a javelin.
regards peter
That explains everything, thanks.
regards
Ron
For the DAC I have inserted the vpDac method that needs to be converted
to pasm. This is a very simply task, the pin output is set to the overflowbit
after adding the dutycycle (0-255) to the·accumulator.
The idea is that this code is executed every 8.68 usec if the DAC is installed.
Who can help in translating this method into the most optimized pasm code?
Also, the method isr needs to be converted to pasm. isr the entry routine that
is to be started in a new cog from another spin file.
I also added code for method vpAdc. That too needs to be converted.
regards peter
Post Edited (Peter Verkaik) : 2/27/2008 9:46:22 PM GMT
a short update from me. I'm currently testing the first PASM bytecode decoder. I have put the bytecode handler til Jem_SWAP in one cog. If I have this sucessfully tested I'll publish it and you could test it with some little Java progs. In the next two days I'm to busy to proceed the testing. But on the weekend I'll have more time.
@Peter
Good progress of coding vp's. It would be helpfully if someone could translate this to assembly.
Thomas