I wish I had the time to persue this but I am tight up in other projects right now.
The Delay() function is related to the 8.68 usec tick, in that each count for Delay(count)
takes exactly 11 ticks (11 * 8.68 usec = 95.48 usec).
The free running 32bits counter (= 1 long) must be updated by a cog. The jvm interpreter
when it must read the time (native function tickLo() and tickHi() ) latches the current time
value in another long when tickLo() is called. TickLo returns the lower 16bits of the latched value.
TickHi() returns the upper 16bits of the latched value without latching the current timervalue.
Not sure if it is really necessary to designate a cog just for updating the 32bits counter.
I think the jvm mainloop could do that by checking after every bytecode wether 8.68 usec
has passed, and if so increment the timervalue. Problem however would be the native functions
that may take a long time to complete. However, since no other java code can execute
while executing a native function, you could calculate passed time in 8.68 usec ticks
and add the calculated ticks to the timervalue.
Which mean Javelin is not 2 times slower, but times [noparse];)[/noparse]
But as you said, Steve, Javelin is not always slower, but only on some operations. Might be interesting to run some kind of benchmark.
Regarding the timer itself, I will agree with Peter appoach to use the kernel to keep track of it instead of using an entire cog just for that. If someone want a more accurate timer, he can use a VP or an external clock like the DS1302.
Let me know if there is anything you want me to try on the Javelin, or any java code you want me to look at.
jmspaggi said...
Here is the results for the same code with an additionnal DS1302 data display.
....
Let me know if there is anything you want me to try on the Javelin, or any java code you want me to look at.
JM
Interesting result. Any idea why the DS1302 would make such a difference? I don't have one. I'll look at the library when I get home. When I have a functional set of VPs running (UARTs are busted right now), I'll zip you a propeller package ...
BTW I highly recommend going with Propeller ProtoBoard with the accessory kit·($60??) or the DemoBoard ($70). The PPDB has a nice, big bread-board and other components if that's what you like (mine collects dust mostly). I plan to write VGA and mouse/keyboard Java JNI classes·later so that hardware will be useful. I also plan a QVGA LCD interface and possibly with touchscreen LCD.
One thing that would really help me·is if you try the tick-tock example from the Javelin manual and measure the interval using the ScaledTimer16 class.·If·I·remember correctly (from over·app.·7 years ago), the tick-tock example was not exactly a per second tick-tock. I could be wrong. Am I making sense?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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.
package org.spaggiari.javelin;
import stamp.core.ScaledTimer16;
import stamp.core.Timer;
public class TickTock
{
static boolean tick=true;
public static void main()
{
Timer clock = new Timer();
ScaledTimer16 scaledTimer = new ScaledTimer16 (400, 100);
while (true)
{
scaledTimer.mark();
for (clock.mark(); !clock.timeout(1000);) ; // wait for one second
System.out.print(scaledTimer.passedTicks());
System.out.print(" ");
System.out.println(tick?"tick":"tock");
tick=!tick;
} // end while
} // end main
}
If we look at the code, we have timeout(1000). As Peter said, this is in 8.68usec. So it shoud be a 0.868s delay. Not really a 1s delay. I don't really see how this can be linked to 1800 but I'm sure you will know [noparse];)[/noparse]
Regarding the DS1302, it's just to display the seconds from the RTC to have a reference. The main difference on the code is the ScaledTimer parameters.
Regarding the board, I don't like the controller to be solde on the board. I already burned few Javelins, don't want to buy a new board each time I will burn a Propeller [noparse];)[/noparse]
JM
Message Edité (jmspaggi) : 4/7/2010 1:18:41 AM GMT
Thanks for your code JM. I have a PPDB with the ds1302 RTC, and will try it later.
Surely there must be a class method somewhere to translate timer results for us in a friendly way.
FWIW, I have Garbage Collection working already.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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.
package org.spaggiari.javelin;
import stamp.core.ScaledTimer16;
import stamp.core.Timer;
public class TickTock
{
static boolean tick=true;
public static void main()
{
Timer clock = new Timer();
ScaledTimer16 scaledTimer = new ScaledTimer16 (400, 100);
while (true)
{
scaledTimer.mark();
for (clock.mark(); !clock.timeout(10000);) ; // wait for one second
int ticks = scaledTimer.passedTicks();
int time = scaledTimer.passedTime();
System.out.print(ticks);
System.out.print(" ticks. ");
System.out.print(time);
System.out.print(" ms. ");
System.out.println(tick?"tick":"tock");
tick=!tick;
} // end while
} // end main
}
I tried with a timeout(30000) and result was also very close to 30s.
If I buy the PPDB with all required wires and components, what will I need to try to put Java in it?
Also, is it possible to use the Javelin IDE? Since I don't want to use memory and CPU cycles for the garbage collector, it's sometime usefull to track memory lick [noparse];)[/noparse]
Just let me know if there is anything else I can do to help. I will be very happy to.
If I buy the PPDB with all required wires and components, what will I need to try to put Java in it?
Also, is it possible to use the Javelin IDE? Since I don't want to use memory and CPU cycles for the garbage collector, it's sometime usefull to track memory lick [noparse];)[/noparse]
Just let me know if there is anything else I can do to help. I will be very happy to.
JM
Don't forget to buy a Propeller ... it is sold separately as you probably know.
Often the PPDB comes up on the daily deal for about $100.·That's all you'll need to get started.
I'm not supporting the IDE yet but can later if you really need it; however, I want to get the non-IDE version working first.
The garbage collector is free right now other than some extra cycles. It is also written in PASM and is optional. The results I posted before were with the garbage collector running [noparse]:)[/noparse]
When I have a working VP set and fixed one other bug, I'll post a source package so you can start testing. Let me know when you have your Propeller.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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.
Adding new VP types means adding PASM/SPIN driver code and a native interface.
Unfortunately using the native keyword in java sources for new VP types is not possible
without changing the linker. I have given this some thought and I think the best way
is to do the interfacing using CPU.readRegister() and CPU.writeRegister() calls.
There are 256 registers ($00 to $FF) some of which are already dedicated.
Other registers are unused in java sources and can be used to read/write parameters to
new VP drivers and to load/start/stop new VP drivers via java source.
Thanks for bringing up the linker issue. Does this also consider the possibility of changes to Javelin Direct to incorporate the JNI?
JM,
I made some progress with Timer code today related to the JVM byte-code interpretation. There is still a bug there somewhere related to tick-time translations ... at least the tick counts are correct. I temporarily disabled garbage collection and managed memory allocation today and the low Fibonnaci sequence numbers went to 4ms; I'll have to increase the collection epoch time. Garbage collection will always cause some jitter, but it is very easy to turn off.
Any progress on testing the VP code is on hold. I'm travelling to the Los Angeles area tomorrow and this weekend, so I will not be doing anything Propeller related for a few days. Later .... Cheers.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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.
By JNI called, do you mean beeing able to put PASM code into some Java class? Will be awesome! We might be able to use Prop Objs + Javelin objs. The best of the 2 worlds...
I will order my propeler and my PPDB probably tomorrow, and have it by end of next week. I still need to find what I will try to do with it [noparse];)[/noparse] Coding PASM with 8 cogs seems to be amazing, but I don't know PASM. So I think I will start by testing Java in it.
The main thing I will need is an UART to have the Prop talking to the Javelin.
I will let you know when I will have it. Talk to you next week.
I don't know the Basic either, and if I have to learn one of the two, I will choose PASM instead. I already did a graphical battleship game in ASM 386 15y ago. So I should be able to learn PASM pretty quickly.
My preference remain on Java because it's more clear to read/develop/maintain (my personal opinion).
How this java interpreter is working? Do we have the code of it? If don't use all the cogs, will it be possible to add some "personal" code instide to use the remaining cogs?
Also, is it not possible to directly compile the java code into PASM to have it running directly in the Prop and not through an interpreter?
jmspaggi said...
... By JNI called, do you mean beeing able to put PASM code into some Java class? Will be awesome! We might be able to use Prop Objs + Javelin objs. The best of the 2 worlds...
Javelin uses JNI to access virtual peripherals and other hardware IO. Today, the System.out.println and other methods uses a Spin object to talk to the serial terminal. Assuming I can modify the Javelin Direct linker (which I can build today without those pascal modules[noparse]:)[/noparse] to support different native methods, one could include a limited set of other Spin object devices. Once the project is ready for general use, I'll look at ways to expand this.
jmspaggi said...
The main thing I will need is an UART to have the Prop talking to the Javelin.
...
How this java interpreter is working? Do we have the code of it? If don't use all the cogs, will it be possible to add some "personal" code instide to use the remaining cogs?
Today the UART VPs in my code-base are broken. Other VPs seem to work fine. I'm still trying to chase a bug related to the timer measurement and some math issues. I'll repost some code in a few days that you can look at and use.
jmspaggi said...
I don't know the Basic either, and if I have to learn one of the two, I will choose PASM instead. I already did a graphical battleship game in ASM 386 15y ago. So I should be able to learn PASM pretty quickly.
PASM is very different from x86 ASM, but it's fun to learn.
jmspaggi said...
Also, is it not possible to directly compile the java code into PASM to have it running directly in the Prop and not through an interpreter?
I'm not sure if there are other Java compilers, but GCJ is a common one. Today it is not possible to compile GCJ to PASM mainly because a native GCC compiler backend does not exist. heater is working on a project where one can run GCC code on his Zylin emulator called ZOG. One might be able to use GCJ for direct compile to run on ZOG, but that would take extra effort.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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.
Having a way to call Spin objects from Java might be very good. That can improve some performance critical process.
I already downloaded and installed pPropellerSim and BST tools and was able to play a little with it. I have still a lot to learn, but at least, I'm able to trace step by step in the code and understand what it's doing.
Regarding ZOG, It's "just" anotyer emulator. So it will not really be faster than what you are doing her. Will have to wait for someone with the knowledge to update gcc [noparse];)[/noparse]
jmspaggi: I'm not sure that Zog is a simulator or emulator. Given that there is no real ZPU chip it cannot really be simulating it[noparse]:)[/noparse]
The ZPU architecture was defined to be implemented in FPGA's and there are a number of such implementations.
Rather it is an interpreter of the ZPU byte codes or a virtual machine implementing the ZPU architecture that runs on the Prop. Much like a Java virtual machine.
Having said that Zylin do provide an implementation of the ZPU in Java for use in debugging programs on the PC. This they refer to as a "simulator".
In theory the GCC available for ZPU can already be used to compile Java into ZPU byte codes. It comes with a libjava for example. I have not had much luck building GCC to provide java yet but did manage to get a C++ and FORTRAN compiler out of it so I might give it another go some time.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Zog is probably never going to be fast.
The ZPU instruction set architecture is stack based with no registers (apart from PC and SP). This makes for a lot of memory reading and writing.
Currently I'm looking at optimizing Zog somewhat to reduce the amount of stack ops it has to do.
The ZPU was designed to be small in terms of logic blocks required in an FPGA, not fast.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I found my Javelin, but can't get it to work with my laptop (no serial port). What a waste.
Also I fixed the math problem I mentioned, but still have the tick to time conversion problem. Are the latest class libraries always posted on the yahoo groups Javelin site?
@JM, If I post a jem.bin test file for comparison that can be loaded with javelin direct, could you try it?
jmspaggi said...
Ok, so if it's still interpreting the code, will it be faster/easier than Jazzed solution which is also interpreting the code?
Focusing on performance may not be too productive although there is often some areas for improvement. Having a small memory footprint and a 32 bit instruction set is a challenge for performance -vs- program size.
The best performance for a high level language (that I know of or care about) is with C using the LMM trick. Most LMM instructions are PASM that propeller directly executes. LMM is also an interpreter designed to allow compiled code > 512 instructions to run on propeller. The problem with LMM is it's 3 times bigger than byte-code interpreted solutions like Spin, Java, or ZOG C and equivalent functionality would only be available with larger memory (external today). Spin, Java, or ZOG C allow us to do more with less without having to add external memory which is slower, clumsy, and costly. Javelin for example is a $90 solution primarily because it uses external memory.
jmspaggi said...
Jazzed, can you share the FIBO Spin code you are using? Would like to take a look to understand the difference with the Java code.
Here's my Spin FIBO test code.
{{
FiboTest.spin
}}
con
_clkmode = xtal1 + pll16x
_xinfreq = 5_000_000
'_clkmode = xtal1 + pll8x
'_xinfreq = 10_000_000
obj
sx : "FullDuplexSerial"
pub main
sx.start(31,30,0,115200)
waitcnt(clkfreq+cnt)
sx.str(string($d,"Spin FIBO Test",$d))
repeat
'sx.rx ' press enter to continue
fibotest(0,24)
pub fibotest(begin,end) | n, t1, t2
repeat n from begin to end
sx.str(string($d,"FIBO "))
sx.dec(n)
t1 := cnt/1000000
result := fibo(n)
t2 := cnt/1000000
sx.str(string(" = "))
sx.dec(result)
sx.tx(" ")
sx.dec((t2-t1)*1_000_000/(clkfreq/1000))
sx.str(string("ms"))
sx.tx($d)
pub fibo(num)
if (num < 2)
return num
else
return fibo(num-1) + fibo(num-2)
Aside regarding emulator -vs- simulator ... from yourdictionary.com
An emulator is "software or hardware that allows one computer to perform the functions of, or execute programs designed for, another type of computer." A simulator is "one that simulates; specif., a training device that duplicates artificially the conditions likely to be encountered in some operation, as in a spacecraft a flight simulator."
From my own experiences with the two ideas: An emulator can by design fully replace the hardware where a simulator can not.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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.
I wil try to understand it, an rewrite it on my own.
I understand the challenge with the memory. I'm trying to see how to get the best performances from the prop, but my actual code on the Javelin is only running every 10 seconds [noparse];)[/noparse] So I think I should not worries about the speed.
For the jem,bin, yes, I can do any test you want. But I will need someone to let me know how to load it on the Javelin. I usually load everything using the IDE... Just send me the file and the way to load it, and will will have the result within the next our.
Regarding Simulator vs Emulator, so shloud http://sourceforge.net/projects/ppropellersim/ have been named an emulator instead of a simulator? That the tool I'm using so play with the prop until I get the board.
I'm not really fussed, emulator, simulator, virtual machine who cares? Well except that no one would call the Java runtime system an emulator or simulator.
Interesting thoughts on the relative code sizes of LMM, Java Zog etc. Problem for me is that Zog was supposed to give us smaller executables than LMM due to it's byte code nature. That being the plus side of the trade off against its slower speed. I have yet to convince myself that it achieves that in practice.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
My modified version of JavelinDirect (v1.2) allows downloading
a .jem file. The Javelin IDE Beta generates a .jem file (= binary eeprom image).
Use the -load switch to only download a .jem file
Comments
I wish I had the time to persue this but I am tight up in other projects right now.
The Delay() function is related to the 8.68 usec tick, in that each count for Delay(count)
takes exactly 11 ticks (11 * 8.68 usec = 95.48 usec).
The free running 32bits counter (= 1 long) must be updated by a cog. The jvm interpreter
when it must read the time (native function tickLo() and tickHi() ) latches the current time
value in another long when tickLo() is called. TickLo returns the lower 16bits of the latched value.
TickHi() returns the upper 16bits of the latched value without latching the current timervalue.
Not sure if it is really necessary to designate a cog just for updating the 32bits counter.
I think the jvm mainloop could do that by checking after every bytecode wether 8.68 usec
has passed, and if so increment the timervalue. Problem however would be the native functions
that may take a long time to complete. However, since no other java code can execute
while executing a native function, you could calculate passed time in 8.68 usec ticks
and add the calculated ticks to the timervalue.
regards peter
And here is the result with Peter's update:
Which mean Javelin is not 2 times slower, but times [noparse];)[/noparse]
But as you said, Steve, Javelin is not always slower, but only on some operations. Might be interesting to run some kind of benchmark.
Regarding the timer itself, I will agree with Peter appoach to use the kernel to keep track of it instead of using an entire cog just for that. If someone want a more accurate timer, he can use a VP or an external clock like the DS1302.
Let me know if there is anything you want me to try on the Javelin, or any java code you want me to look at.
JM
BTW I highly recommend going with Propeller ProtoBoard with the accessory kit·($60??) or the DemoBoard ($70). The PPDB has a nice, big bread-board and other components if that's what you like (mine collects dust mostly). I plan to write VGA and mouse/keyboard Java JNI classes·later so that hardware will be useful. I also plan a QVGA LCD interface and possibly with touchscreen LCD.
One thing that would really help me·is if you try the tick-tock example from the Javelin manual and measure the interval using the ScaledTimer16 class.·If·I·remember correctly (from over·app.·7 years ago), the tick-tock example was not exactly a per second tick-tock. I could be wrong. Am I making sense?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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 is the code I tried:
package org.spaggiari.javelin; import stamp.core.ScaledTimer16; import stamp.core.Timer; public class TickTock { static boolean tick=true; public static void main() { Timer clock = new Timer(); ScaledTimer16 scaledTimer = new ScaledTimer16 (400, 100); while (true) { scaledTimer.mark(); for (clock.mark(); !clock.timeout(1000);) ; // wait for one second System.out.print(scaledTimer.passedTicks()); System.out.print(" "); System.out.println(tick?"tick":"tock"); tick=!tick; } // end while } // end main }Not 100% if it's what you are looking for.
And here is the output:
If we look at the code, we have timeout(1000). As Peter said, this is in 8.68usec. So it shoud be a 0.868s delay. Not really a 1s delay. I don't really see how this can be linked to 1800 but I'm sure you will know [noparse];)[/noparse]
Regarding the DS1302, it's just to display the seconds from the RTC to have a reference. The main difference on the code is the ScaledTimer parameters.
Regarding the board, I don't like the controller to be solde on the board. I already burned few Javelins, don't want to buy a new board each time I will burn a Propeller [noparse];)[/noparse]
JM
Message Edité (jmspaggi) : 4/7/2010 1:18:41 AM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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.
For timeUnit=100, the Timer16 tick = 555.52 usec
PassedTicks = 1806·equals 1806*555.52 usec = ·1003269.12 usec = 1003.26912 msec = 1.00326912 sec
regards peter
I will retry the same sample for a longer delay to see the accuracy.
Steve, here is the code with the DS1302.
package org.spaggiari.javelin; //FiboTest // import stamp.core.*; import stamp.peripheral.rtc.DS1302; import stamp.util.text.*; public class FiboTest { private ScaledTimer16 timer; private DS1302 ds1302 = new DS1302 (CPU.pin7, CPU.pin4, CPU.pin0); public FiboTest() { timer = new ScaledTimer16(400,100); //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) { int before = ds1302.readTD(0); Format2.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); int after = ds1302.readTD(0); if (after < before) passed = 60 - before + after; else passed = after - before; Format2.printf(" = %5u ", result); Format2.printf("(%5u ms)", ms); Format2.printf("(%02d s)\r\n", passed); count++; } } public static void main() { System.out.println(""); FiboTest fibo = new FiboTest(); fibo.test(0,25); } } // end classRegarding the cogs, it will be nice to have a way to use them in Java. To let the use choose what to put inside. VPs, Garbage Collect, etc.
JM
Surely there must be a class method somewhere to translate timer results for us in a friendly way.
FWIW, I have Garbage Collection working already.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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.
package org.spaggiari.javelin; import stamp.core.ScaledTimer16; import stamp.core.Timer; public class TickTock { static boolean tick=true; public static void main() { Timer clock = new Timer(); ScaledTimer16 scaledTimer = new ScaledTimer16 (400, 100); while (true) { scaledTimer.mark(); for (clock.mark(); !clock.timeout(10000);) ; // wait for one second int ticks = scaledTimer.passedTicks(); int time = scaledTimer.passedTime(); System.out.print(ticks); System.out.print(" ticks. "); System.out.print(time); System.out.print(" ms. "); System.out.println(tick?"tick":"tock"); tick=!tick; } // end while } // end main }Results with a timeout(10000):
I tried with a timeout(30000) and result was also very close to 30s.
If I buy the PPDB with all required wires and components, what will I need to try to put Java in it?
Also, is it possible to use the Javelin IDE? Since I don't want to use memory and CPU cycles for the garbage collector, it's sometime usefull to track memory lick [noparse];)[/noparse]
Just let me know if there is anything else I can do to help. I will be very happy to.
JM
Often the PPDB comes up on the daily deal for about $100.·That's all you'll need to get started.
I'm not supporting the IDE yet but can later if you really need it; however, I want to get the non-IDE version working first.
The garbage collector is free right now other than some extra cycles. It is also written in PASM and is optional. The results I posted before were with the garbage collector running [noparse]:)[/noparse]
When I have a working VP set and fixed one other bug, I'll post a source package so you can start testing. Let me know when you have your Propeller.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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.
Unfortunately using the native keyword in java sources for new VP types is not possible
without changing the linker. I have given this some thought and I think the best way
is to do the interfacing using CPU.readRegister() and CPU.writeRegister() calls.
There are 256 registers ($00 to $FF) some of which are already dedicated.
Dedicated registers (as specified by existing java sources)
$80-$DF = vpbank registers
$06-$09 = I/O pins
$12-$13 = stack pointer
$18-$19 = heap pointer
$4C-$4D = stack base
Other registers are unused in java sources and can be used to read/write parameters to
new VP drivers and to load/start/stop new VP drivers via java source.
regards peter
Thanks for bringing up the linker issue. Does this also consider the possibility of changes to Javelin Direct to incorporate the JNI?
JM,
I made some progress with Timer code today related to the JVM byte-code interpretation. There is still a bug there somewhere related to tick-time translations ... at least the tick counts are correct. I temporarily disabled garbage collection and managed memory allocation today and the low Fibonnaci sequence numbers went to 4ms; I'll have to increase the collection epoch time. Garbage collection will always cause some jitter, but it is very easy to turn off.
Any progress on testing the VP code is on hold. I'm travelling to the Los Angeles area tomorrow and this weekend, so I will not be doing anything Propeller related for a few days. Later .... Cheers.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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.
By JNI called, do you mean beeing able to put PASM code into some Java class? Will be awesome! We might be able to use Prop Objs + Javelin objs. The best of the 2 worlds...
I will order my propeler and my PPDB probably tomorrow, and have it by end of next week. I still need to find what I will try to do with it [noparse];)[/noparse] Coding PASM with 8 cogs seems to be amazing, but I don't know PASM. So I think I will start by testing Java in it.
The main thing I will need is an UART to have the Prop talking to the Javelin.
I will let you know when I will have it. Talk to you next week.
JM
not possible.
regards peter
Post Edited (Peter Verkaik) : 4/9/2010 11:21:14 AM GMT
My preference remain on Java because it's more clear to read/develop/maintain (my personal opinion).
How this java interpreter is working? Do we have the code of it? If don't use all the cogs, will it be possible to add some "personal" code instide to use the remaining cogs?
Also, is it not possible to directly compile the java code into PASM to have it running directly in the Prop and not through an interpreter?
JM
Today the UART VPs in my code-base are broken. Other VPs seem to work fine. I'm still trying to chase a bug related to the timer measurement and some math issues. I'll repost some code in a few days that you can look at and use.
PASM is very different from x86 ASM, but it's fun to learn.
I'm not sure if there are other Java compilers, but GCJ is a common one. Today it is not possible to compile GCJ to PASM mainly because a native GCC compiler backend does not exist. heater is working on a project where one can run GCC code on his Zylin emulator called ZOG. One might be able to use GCJ for direct compile to run on ZOG, but that would take extra effort.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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.
I already downloaded and installed pPropellerSim and BST tools and was able to play a little with it. I have still a lot to learn, but at least, I'm able to trace step by step in the code and understand what it's doing.
Regarding ZOG, It's "just" anotyer emulator. So it will not really be faster than what you are doing her. Will have to wait for someone with the knowledge to update gcc [noparse];)[/noparse]
JM
The ZPU architecture was defined to be implemented in FPGA's and there are a number of such implementations.
Rather it is an interpreter of the ZPU byte codes or a virtual machine implementing the ZPU architecture that runs on the Prop. Much like a Java virtual machine.
Having said that Zylin do provide an implementation of the ZPU in Java for use in debugging programs on the PC. This they refer to as a "simulator".
In theory the GCC available for ZPU can already be used to compile Java into ZPU byte codes. It comes with a libjava for example. I have not had much luck building GCC to provide java yet but did manage to get a C++ and FORTRAN compiler out of it so I might give it another go some time.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Jazzed, can you share the FIBO Spin code you are using? Would like to take a look to understand the difference with the Java code.
Thanks,
JM
The ZPU instruction set architecture is stack based with no registers (apart from PC and SP). This makes for a lot of memory reading and writing.
Currently I'm looking at optimizing Zog somewhat to reduce the amount of stack ops it has to do.
The ZPU was designed to be small in terms of logic blocks required in an FPGA, not fast.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Also I fixed the math problem I mentioned, but still have the tick to time conversion problem. Are the latest class libraries always posted on the yahoo groups Javelin site?
@JM, If I post a jem.bin test file for comparison that can be loaded with javelin direct, could you try it?
Focusing on performance may not be too productive although there is often some areas for improvement. Having a small memory footprint and a 32 bit instruction set is a challenge for performance -vs- program size.
The best performance for a high level language (that I know of or care about) is with C using the LMM trick. Most LMM instructions are PASM that propeller directly executes. LMM is also an interpreter designed to allow compiled code > 512 instructions to run on propeller. The problem with LMM is it's 3 times bigger than byte-code interpreted solutions like Spin, Java, or ZOG C and equivalent functionality would only be available with larger memory (external today). Spin, Java, or ZOG C allow us to do more with less without having to add external memory which is slower, clumsy, and costly. Javelin for example is a $90 solution primarily because it uses external memory.
Here's my Spin FIBO test code.
{{ FiboTest.spin }} con _clkmode = xtal1 + pll16x _xinfreq = 5_000_000 '_clkmode = xtal1 + pll8x '_xinfreq = 10_000_000 obj sx : "FullDuplexSerial" pub main sx.start(31,30,0,115200) waitcnt(clkfreq+cnt) sx.str(string($d,"Spin FIBO Test",$d)) repeat 'sx.rx ' press enter to continue fibotest(0,24) pub fibotest(begin,end) | n, t1, t2 repeat n from begin to end sx.str(string($d,"FIBO ")) sx.dec(n) t1 := cnt/1000000 result := fibo(n) t2 := cnt/1000000 sx.str(string(" = ")) sx.dec(result) sx.tx(" ") sx.dec((t2-t1)*1_000_000/(clkfreq/1000)) sx.str(string("ms")) sx.tx($d) pub fibo(num) if (num < 2) return num else return fibo(num-1) + fibo(num-2)Aside regarding emulator -vs- simulator ... from yourdictionary.com
An emulator is "software or hardware that allows one computer to perform the functions of, or execute programs designed for, another type of computer." A simulator is "one that simulates; specif., a training device that duplicates artificially the conditions likely to be encountered in some operation, as in a spacecraft a flight simulator."
From my own experiences with the two ideas: An emulator can by design fully replace the hardware where a simulator can not.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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.
I wil try to understand it, an rewrite it on my own.
I understand the challenge with the memory. I'm trying to see how to get the best performances from the prop, but my actual code on the Javelin is only running every 10 seconds [noparse];)[/noparse] So I think I should not worries about the speed.
For the jem,bin, yes, I can do any test you want. But I will need someone to let me know how to load it on the Javelin. I usually load everything using the IDE... Just send me the file and the way to load it, and will will have the result within the next our.
Regarding Simulator vs Emulator, so shloud http://sourceforge.net/projects/ppropellersim/ have been named an emulator instead of a simulator? That the tool I'm using so play with the prop until I get the board.
JM
Spin should be easy for you since you know Java. There are a few syntax differences, but you'll get it.
I think ppropellersim is appropriately named since it can not be used to replace the propeller hardware.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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.
Interesting thoughts on the relative code sizes of LMM, Java Zog etc. Problem for me is that Zog was supposed to give us smaller executables than LMM due to it's byte code nature. That being the plus side of the trade off against its slower speed. I have yet to convince myself that it achieves that in practice.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
a .jem file. The Javelin IDE Beta generates a .jem file (= binary eeprom image).
Use the -load switch to only download a .jem file
regards peter
So Jazzed, you can send me the file if you want.
JM
JM, try running the attached TickTock.jem file and post the output from "Hello!" to a few lines of tick-tock.
--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.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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.