So I'm trying to set up SD boot with P123-A9. I have a pullup on P60 (only)
The SD card has _BOOT_P2.BIX and _BOOT_P2.BIY files in its root directory. I can see the cog start very briefly and then give up.
The documentation indicates we don't have to change the MBR nor VOL sector at all, is this correct?
Is there any particular reason the SD card failure just stops the cog, rather than dropping back to serial like flash does??
This might be a good question to ask on Cluso's P2 ROM Booter thread. (I see he is using that thread for documentation instead )
I believe that Chip wanted the Prop to cogstop if it failed SD but SD was before Flash and that was wrong so it was a last minute change to boot Flash, SD, and then supposed to try serial again. I wanted to have diagnostic POST style pulses or something on one of the pins so we could tell what happened, and then maybe shutdown after 10 seconds. The reason for the shutdown is to prevent batteries being drained.
@Cluso99 - Your terminal configurations are all wrong, there are no extra line feeds from TAQOZ so please try a proper terminal first. They look like they are inserting LFs on a CR and LFs on LFs!!!!!! None of the terminals I use look anything like what you are showing. The long line of dashes is a "discard line" when TAQOZ discards anything that may have been compiled temporarily and also flushes the rx buffer. Whenever you hit an escape from the console it will do this as it does a CR only to return to the start of the line and then writes the dashes over it. Another good reason why terminals should not automatically insert line feeds.
Four times I cancel and discard my input and so end up with 4 lines of dashes
----------------------------------------------------------------
Parallax P2 .:.:--TAQOZ--:.:. V1.0
----------------------------------------------------------------
TAQOZ# MOUNT
Mounted WIDGET 8C0D.A960-6338.6430 [SDSL08G] FAT32 7,944MB (32kB/cluster) ok
TAQOZ# ls
/WIDGET
DUMPV4 .FTH EASYFILE.FTH EASYNET .FTH EXTEND .FTH LIFE .FTH
LOVE .WAV POPCORN .WAV SEEDAWN .FTH SPLAT-V4.FTH TACHYO~1.SPI
WARPEACE.TXT ROM_136X.OBJ ok
---------------------------------------------------------------- ok
---------------------------------------------------------------- ok
---------------------------------------------------------------- ok
---------------------------------------------------------------- ok
TAQOZ#
@Cluso99 - I've redirected the emit output to print the output in hex bytes through the output
TAQOZ# : SHOWHEX uemit W~ .BYTE SPACE ' SHOWHEX uemit W! ; ok
TAQOZ# 0 SHOWHEX 00 20 6F 6B 0D 0A 54 41 51 4F 5A 23 20 6C 73 69 6F 20 0D 0A 50 49 4E 53 20 0D 0A 50 3A 30 30 30 30 30 30 30 30 30 30 31 31 31 31 31 31 31 31 31 31 32 32 32 32 32 32 32 32 32 32 33 33 33 33 33 33 33 33 33 33 34 34 34 34 34 34 34 34 34 34 35 35 35 35 35 35 35 35 35 35 36 36 0D 0A 0D 50 3A 30 31 32 33 34 35 36 37 38 39 30 31 32 33 34 35 36 37 38 39 30 31 32 33 34 35 36 37 38 39 30 31 32 33 34 35 36 37 38 39 30 31 32 33 34 35 36 37 38 39 30 31 32 33 34 35 36 37 38 39 30 31 0D 0A 0D 3D 3A 7E 7E 7E 7E 64 64 64 64 64 7E 64 64 7E 7E 7E 7E 7E 7E 7E 7E 7E 7E 7E 7E 7E 7E 7E 7E 7E 7E 7E 7E 7E 7E 7E 7E 68 68 68 68 68 7E 64 7E 64 64 64 7E 7E 7E 64 64 64 64 64 64 7E 7E 68 7E 68 68 20 6F 6B 0D 0A 54 41 51 4F 5A 23 20
Then I type in "lsio<CR>" while it is active and as you can see there are only single CRLFs in the output. The very first bytes that are printed are " ok"+CRLF
Back to normal and do an lsio again:
TAQOZ# lsio
PINS
P:00000000001111111111222222222233333333334444444444555555555566
P:01234567890123456789012345678901234567890123456789012345678901
=:~~~~ddddd~dd~~~~~~~~~~~~~~~~~~~~~~~~hhhhh~d~ddd~~~dddddd~~h~hh ok
TAQOZ#
edit: Perhaps I can remove the "PINS" header, so I patched my code and ran BACKUP into Flash.
TAQOZ# ' lsio 4+ 7 $0D FILL ok
TAQOZ# lsio
P:00000000001111111111222222222233333333334444444444555555555566
P:01234567890123456789012345678901234567890123456789012345678901
=:~~~~ddddd~dd~~~~~~~~~~~~~~~~~~~~~~~~hhhhh~d~ddd~~~dddddd~~~~hh ok
TAQOZ# BACKUP ok
That LSIO command is really useful. It showed up the jaycar xc4598 SD breakout actually has some pulldown resistors on the back which were affecting things or at least explaining what was going on even without an SD card in the socket. I think those pulldowns are actually affecting the boot sequence contrary to the diagrams Cluso has put in his new thread.
Using the P123-A9. Initially I thought perhaps the buttons PB1-3 might be causing issues but thanks to LSIO I see these are on P55-57 and out of the way. And PB0 does the reset.
I generally use RealTerm which is working very nicely with current CR + LFs. I also have Putty, Teraterm and PST and can post some screen shots later from a PC perspective.
There are a lot of fake FTDI chips in the wild. These often work very well, but when testing serial drivers and serial to USB converters, it's always worth trying to discover if your chip is a fake and trying several different converters from different suppliers - even though they appear to use exactly the same chip.
There are a lot of fake FTDI chips in the wild. These often work very well, but when testing serial drivers and serial to USB converters, it's always worth trying to discover if your chip is a fake and trying several different converters from different suppliers - even though they appear to use exactly the same chip.
I wouldn't know about fake chips as I always get mine from Mouser/Digikey etc. But the fake chips are quite different as you can see from the link.
@Cluso99 - much better, now change the font! I use Terminal regular 12 or Parallax font with a bright green text on dark green background, looks really good.
So I'm trying to set up SD boot with P123-A9. I have a pullup on P60 (only)
The SD card has _BOOT_P2.BIX and _BOOT_P2.BIY files in its root directory. I can see the cog start very briefly and then give up.
The documentation indicates we don't have to change the MBR nor VOL sector at all, is this correct?
Is there any particular reason the SD card failure just stops the cog, rather than dropping back to serial like flash does??
It's a one-way jump right now. We would have to do more integration work before he could jump back into my ROM code. Maybe we can get that straightened out over the next few days. This is Cluso's code that does the SD booting. I think we just need to agree on which registers need leaving-alone, so that a safe reentry can be made. This would blow up the timing for host systems that only wait 100ms for a connection to be made, but it would leave the door open for TAQOZ, the Monitor, and the Prop_??? commands.
Has anyone tried to follow along in my document and learn to use TAQOZ and play with the P2?
How is it going?
What improvements can I make to the existing examples?
What things would you like to see added?
I've tried to take it slowly and introduce new words and examples and also if a scope capture is appropriate I include a print friendly negative of it too.
While this is a work in progress, it probably will be for quite some time but it is also very helpful for me in that I get to think about things I might change or add to TAQOZ in the next few days as I can submit an updated version for ROM. But then it is locked in!
The time for real feedback is now!
(Paragraph indentation and formatting are cosmetics, I'm talking content).
Here's a sample from that document if you haven't yet clicked the link (and were afraid to do so).
Has anyone tried to follow along in my document and learn to use TAQOZ and play with the P2?
How is it going?
What improvements can I make to the existing examples?
What things would you like to see added?
I've tried to take it slowly and introduce new words and examples and also if a scope capture is appropriate I include a print friendly negative of it too.
While this is a work in progress, it probably will be for quite some time but it is also very helpful for me in that I get to think about things I might change or add to TAQOZ in the next few days as I can submit an updated version for ROM. But then it is locked in!
The time for real feedback is now!
(Paragraph indentation and formatting are cosmetics, I'm talking content).
Here's a sample from that document if you haven't yet clicked the link (and were afraid to do so).
I started but didn't get very far before I had to head off to a meeting. I'll continue tomorrow. What I'm wanting to do is learn how to start code running on other COGs and communicate between COGs.
@"David Betz" - Thanks, since each cog has already been preloaded with a TAQOZ kernel and left idling you can run code very easily with this very simple example:
TAQOZ# : BLINKER BEGIN 7 HIGH 100 ms 7 LOW 100 ms AGAIN ; ok
TAQOZ# ' BLINKER 1 TASK W! ok
I will expand a bit more on this and cog-to-cog communication as I enhance TAQOZ to take advantage of some of P2's features.
@"David Betz" - Thanks, since each cog has already been preloaded with a TAQOZ kernel and left idling you can run code very easily with this very simple example:
TAQOZ# : BLINKER BEGIN 7 HIGH 100 ms 7 LOW 100 ms AGAIN ; ok
TAQOZ# ' BLINKER 1 TASK W! ok
I will expand a bit more on this and cog-to-cog communication as I enhance TAQOZ to take advantage of some of P2's features.
I don't understand this. I know that
' BLINKER
will put the code address of BLINKER on the stack. What does the rest of the line do?
1 TASK W!
I assume W! writes a word into the variable TASK? How does that cause the BLINKER code to run on another COG?
@"David Betz" - I will probably polish that a bit more by adding a RUN word but remember that TAQOZ is already running an idle loop in all other cogs. It is checking its task register addressed by TASK and COGID for a non-zero value which when set will cause it to call that address.
@"David Betz" - I will probably polish that a bit more by adding a RUN word but remember that TAQOZ is already running an idle loop in all other cogs. It is checking its task register addressed by TASK and COGID for a non-zero value which when set will cause it to call that address.
Does
1 TASK
return the address of the task register for COG 1?
@"David Betz" - I will probably polish that a bit more by adding a RUN word but remember that TAQOZ is already running an idle loop in all other cogs. It is checking its task register addressed by TASK and COGID for a non-zero value which when set will cause it to call that address.
Does
1 TASK
return the address of the task register for COG 1?
there is a tasks array with 8 bytes per task.
' TASK ( cog -- addr ) Return with address of task control register in "tasks"
TASK word _3,_SHL,_WORD,tasks,PLUS,EXIT
here you see the specified cog# is shifted left by 3 == *8
and then added with the tasks base address and left on the stack for the following W! to use.
The 'thing' in front of a W! is not always the name of a variable,
but could be anything generating the address to store a value to.
@"Peter Jakacki"
I see you using DO LOOP
but in Tachyon 5 you were using the generalized FOR NEXT
wouldn't it be good for the user to have the same mechanisms in TAQOZ that you will
have in TACHYON, to avoid some confusion?
It will take a few bytes more, but CLUSO99 said there are a few bytes free ;-)
@"Peter Jakacki"
I see you using DO LOOP
but in Tachyon 5 you were using the generalized FOR NEXT
wouldn't it be good for the user to have the same mechanisms in TAQOZ that you will
have in TACHYON, to avoid some confusion?
It will take a few bytes more, but CLUSO99 said there are a few bytes free ;-)
I had thought about that but time was pressing and other details needed my attention. Dropping DO LOOPs and enhancing FOR NEXT was for a couple of reasons sensible for the P1. In TAQOZ we could have both, including the enhanced FOR NEXT. I can do without DO LOOPs myself though but how have you found the new FOR NEXT when it comes to coding?
BTW - It would actually save memory to remove DO LOOPs
@"David Betz" - I will probably polish that a bit more by adding a RUN word but remember that TAQOZ is already running an idle loop in all other cogs. It is checking its task register addressed by TASK and COGID for a non-zero value which when set will cause it to call that address.
Does
1 TASK
return the address of the task register for COG 1?
there is a tasks array with 8 bytes per task.
' TASK ( cog -- addr ) Return with address of task control register in "tasks"
TASK word _3,_SHL,_WORD,tasks,PLUS,EXIT
here you see the specified cog# is shifted left by 3 == *8
and then added with the tasks base address and left on the stack for the following W! to use.
The 'thing' in front of a W! is not always the name of a variable,
but could be anything generating the address to store a value to.
so
x TASK
just indexes into the tasks array
Yeah, that's what I figured. Thanks for confirming. There wasn't any other way that I could make sense of that line of code.
@"Peter Jakacki"
I see you using DO LOOP
but in Tachyon 5 you were using the generalized FOR NEXT
wouldn't it be good for the user to have the same mechanisms in TAQOZ that you will
have in TACHYON, to avoid some confusion?
It will take a few bytes more, but CLUSO99 said there are a few bytes free ;-)
I had thought about that but time was pressing and other details needed my attention. Dropping DO LOOPs and enhancing FOR NEXT was for a couple of reasons sensible for the P1. In TAQOZ we could have both, including the enhanced FOR NEXT. I can do without DO LOOPs myself though but how have you found the new FOR NEXT when it comes to coding?
BTW - It would actually save memory to remove DO LOOPs
The more code compatible TACHYON and TAQOZ are, the better !
@"David Betz" - I will probably polish that a bit more by adding a RUN word but remember that TAQOZ is already running an idle loop in all other cogs. It is checking its task register addressed by TASK and COGID for a non-zero value which when set will cause it to call that address.
Does
1 TASK
return the address of the task register for COG 1?
there is a tasks array with 8 bytes per task.
' TASK ( cog -- addr ) Return with address of task control register in "tasks"
TASK word _3,_SHL,_WORD,tasks,PLUS,EXIT
here you see the specified cog# is shifted left by 3 == *8
and then added with the tasks base address and left on the stack for the following W! to use.
The 'thing' in front of a W! is not always the name of a variable,
but could be anything generating the address to store a value to.
so
x TASK
just indexes into the tasks array
Yeah, that's what I figured. Thanks for confirming. There wasn't any other way that I could make sense of that line of code.
@"Peter Jakacki"
I see you using DO LOOP
but in Tachyon 5 you were using the generalized FOR NEXT
wouldn't it be good for the user to have the same mechanisms in TAQOZ that you will
have in TACHYON, to avoid some confusion?
It will take a few bytes more, but CLUSO99 said there are a few bytes free ;-)
I had thought about that but time was pressing and other details needed my attention. Dropping DO LOOPs and enhancing FOR NEXT was for a couple of reasons sensible for the P1. In TAQOZ we could have both, including the enhanced FOR NEXT. I can do without DO LOOPs myself though but how have you found the new FOR NEXT when it comes to coding?
BTW - It would actually save memory to remove DO LOOPs
Actually I like the explicit nature of the new FOR loops.
If I didn't use Tachyon for a while I always need to think which way the two DO arguments are.
Mostly I used ADO anyway with LOOP.
In
10 BY 100 FROM 10 FOR I . CR NEXT
it is pretty obvious
Also I expect most users of TAQOZ to NOT be Forth users.
So at least it sounds a bit like BASIC ;-) ... the wrong way round
Pretty easy to learn
And if it saves space you can use for SPLAT ;-) or s.th. useful ... great
Peter, before I forget, when you pass control to me, you leave the other cogs running TAQOZ.
Btw when I call you I jump to entry-TAQOZ as there is no need to reset smart pins from the monitor.
@MJB - I'd like to change TAQOZ over to the newer way of FOR NEXT loops but I've been pressed for time Maybe we can get another shot at it yet?
If you need to know what your pins on your board are doing and also which pins are which you can use this simple PROBE word which continuous generates the same output as the lsio word but also uses P0 as a digital probe and will indicate the port it is connected to with a * instead. This uses CR to stay on the same line, another reason for CR and LF to do what they do.
: PROBE
CRLF ." P:" 62 0 DO I 10 / . LOOP
CRLF ." P:" 62 0 DO I 10 // . LOOP
CRLF
BEGIN
CR 3 SPACES 62 1
DO I LOW 0 PIN@ NOT I HIGH 0 PIN@ AND I FLOAT
IF ." *"
ELSE
I LOW 200 WAIT I FLOAT 200 WAIT I PIN@ 1 AND 2* ( 1 = pullup )
I HIGH 200 WAIT I FLOAT 200 WAIT I PIN@ 1 AND ( 0 = pulldown) OR
" d~ch" + C@ EMIT
THEN
LOOP
50 ms KEY UNTIL
;
Here's the output with P0 probing P28:
TAQOZ# PROBE2
P:00000000001111111111222222222233333333334444444444555555555566
P:01234567890123456789012345678901234567890123456789012345678901
~~~~~~~~~~~~~~~~~~~~~~~~~~~*hhhhhddhhhhhhhhhhhhhhdddddddd~~~~ ok
This btw was tested on a DE2-115 and there is a DE2-115.FTH in the Forth folder that has words that know about the LEDs and switches etc. An external SD card works and a Flash chip in the socket on the Parallax breakout works fine too.
Where are we with the benchmarks now? Ok, so I dug out my old Fibonacci benchmark and ran it again:
TAQOZ# : fibo ( n -- f ) 0 1 ROT FOR BOUNDS NEXT DROP ; ok
TAQOZ# 47 6 DO CRLF ." fibo(" I . ." ) = " I LAP fibo LAP .LAP ." result =" . 10 +LOOP
fibo(6) = 685 cycles = 8.562us result =8
fibo(16) = 1245 cycles = 15.562us result =987
fibo(26) = 1805 cycles = 22.562us result =121393
fibo(36) = 2365 cycles = 29.562us result =14930352
fibo(46) = 2925 cycles = 36.562us result =1836311903 ok
If P2 is on-track for 180Mhz then this translates to a fibo(46) in TAQOZ of 16.25us
Very impressive benchmark numbers, Peter! (Although usually when we do a fibo benchmark we define it recursively rather than iteratively... but Forth is a kind of functional language already, so the iterative version is pretty natural.)Fastspin is a bit faster, but considering that it's compiling to native code the difference is remarkably small. It looks like the iterative fibo takes about 24 cycles/iterations with fastspin, vs. 56 cycles/iteration with Tachyon. That's a very low interpretation overhead.
[ Entering terminal mode. Press ESC to exit. ]
fibo(6) 121 cycles, result = 8
fibo(16) 361 cycles, result = 987
fibo(26) 601 cycles, result = 121393
fibo(36) 841 cycles, result = 14930352
fibo(46) 1081 cycles, result = 1836311903
Just for reference here's the code (for fastspin 3.8.3/spin2gui 1.0.3). Tachyon is a *lot* more compact than Spin, although perhaps not quite as easy to read .
OBJ
ser: "SimpleSerial"
PUB demo | i, n, t
ser.start(115_200)
repeat i from 6 to 46 step 10
ser.str(string("fibo("))
ser.dec(i)
ser.str(string(") "))
t := CNT
n := fibolp(i)
t := CNT - t
ser.dec(t)
ser.str(string(" cycles, result = "))
ser.dec(n)
ser.str(string(13, 10))
PUB fibolp(n) : r | lastr
r := 1
lastr := 0
repeat n-1
(lastr,r) := (r, r+lastr)
Very impressive benchmark numbers, Peter! (Although usually when we do a fibo benchmark we define it recursively rather than iteratively... but Forth is a kind of functional language already, so the iterative version is pretty natural.)Fastspin is a bit faster, but considering that it's compiling to native code the difference is remarkably small. It looks like the iterative fibo takes about 24 cycles/iterations with fastspin, vs. 56 cycles/iteration with Tachyon. That's a very low interpretation overhead.
Hey, that's great to know how fast Fastspin is, so I guess it's fast! What a great plug for Fastspin and the P2. No more slow code! I'd be interested in a listing of the code that it generates.
The fibo itself takes 16 bytes of code, but that is of course, on top of the supporting code it is built on.
While the main part of the interpreter uses only 4 instructions for cog calls, the looping instruction NEXT uses stacked & latched branches so there is no reading and calculating branch addresses, just load and go.
' NEXT ( -- ) Decrement count (on loop stack) and loop until 0, then pop loop stack
forNEXT djz index,#POPBRANCH ' exit loop
_ret_ mov PTRA,branchadr ' loop again
Comments
This might be a good question to ask on Cluso's P2 ROM Booter thread. (I see he is using that thread for documentation instead
I believe that Chip wanted the Prop to cogstop if it failed SD but SD was before Flash and that was wrong so it was a last minute change to boot Flash, SD, and then supposed to try serial again. I wanted to have diagnostic POST style pulses or something on one of the pins so we could tell what happened, and then maybe shutdown after 10 seconds. The reason for the shutdown is to prevent batteries being drained.
@Cluso99 - Your terminal configurations are all wrong, there are no extra line feeds from TAQOZ so please try a proper terminal first. They look like they are inserting LFs on a CR and LFs on LFs!!!!!! None of the terminals I use look anything like what you are showing. The long line of dashes is a "discard line" when TAQOZ discards anything that may have been compiled temporarily and also flushes the rx buffer. Whenever you hit an escape from the console it will do this as it does a CR only to return to the start of the line and then writes the dashes over it. Another good reason why terminals should not automatically insert line feeds.
Four times I cancel and discard my input and so end up with 4 lines of dashes
Back to normal and do an lsio again:
edit: Perhaps I can remove the "PINS" header, so I patched my code and ran BACKUP into Flash.
Using the P123-A9. Initially I thought perhaps the buttons PB1-3 might be causing issues but thanks to LSIO I see these are on P55-57 and out of the way. And PB0 does the reset.
I generally use RealTerm which is working very nicely with current CR + LFs. I also have Putty, Teraterm and PST and can post some screen shots later from a PC perspective.
Resetting TeraTerm to use CR (default) instead of CR+LF removes the extra lines.
I wouldn't know about fake chips as I always get mine from Mouser/Digikey etc. But the fake chips are quite different as you can see from the link.
@Cluso99 - much better, now change the font! I use Terminal regular 12 or Parallax font with a bright green text on dark green background, looks really good.
It's a one-way jump right now. We would have to do more integration work before he could jump back into my ROM code. Maybe we can get that straightened out over the next few days. This is Cluso's code that does the SD booting. I think we just need to agree on which registers need leaving-alone, so that a safe reentry can be made. This would blow up the timing for host systems that only wait 100ms for a connection to be made, but it would leave the door open for TAQOZ, the Monitor, and the Prop_??? commands.
How is it going?
What improvements can I make to the existing examples?
What things would you like to see added?
I've tried to take it slowly and introduce new words and examples and also if a scope capture is appropriate I include a print friendly negative of it too.
While this is a work in progress, it probably will be for quite some time but it is also very helpful for me in that I get to think about things I might change or add to TAQOZ in the next few days as I can submit an updated version for ROM. But then it is locked in!
The time for real feedback is now!
(Paragraph indentation and formatting are cosmetics, I'm talking content).
Here's a sample from that document if you haven't yet clicked the link (and were afraid to do so).
I will expand a bit more on this and cog-to-cog communication as I enhance TAQOZ to take advantage of some of P2's features.
there is a tasks array with 8 bytes per task.
here you see the specified cog# is shifted left by 3 == *8
and then added with the tasks base address and left on the stack for the following W! to use.
The 'thing' in front of a W! is not always the name of a variable,
but could be anything generating the address to store a value to.
so just indexes into the tasks array
I see you using DO LOOP
but in Tachyon 5 you were using the generalized FOR NEXT
wouldn't it be good for the user to have the same mechanisms in TAQOZ that you will
have in TACHYON, to avoid some confusion?
It will take a few bytes more, but CLUSO99 said there are a few bytes free ;-)
I had thought about that but time was pressing and other details needed my attention. Dropping DO LOOPs and enhancing FOR NEXT was for a couple of reasons sensible for the P1. In TAQOZ we could have both, including the enhanced FOR NEXT. I can do without DO LOOPs myself though but how have you found the new FOR NEXT when it comes to coding?
BTW - It would actually save memory to remove DO LOOPs
The more code compatible TACHYON and TAQOZ are, the better !
Jason
as always -- if in doubt read the soure code ;-)
Actually I like the explicit nature of the new FOR loops.
If I didn't use Tachyon for a while I always need to think which way the two DO arguments are.
Mostly I used ADO anyway with LOOP.
In it is pretty obvious
Also I expect most users of TAQOZ to NOT be Forth users.
So at least it sounds a bit like BASIC ;-) ... the wrong way round
Pretty easy to learn
And if it saves space you can use for SPLAT ;-) or s.th. useful ... great
Btw when I call you I jump to entry-TAQOZ as there is no need to reset smart pins from the monitor.
If you need to know what your pins on your board are doing and also which pins are which you can use this simple PROBE word which continuous generates the same output as the lsio word but also uses P0 as a digital probe and will indicate the port it is connected to with a * instead. This uses CR to stay on the same line, another reason for CR and LF to do what they do.
Here's the output with P0 probing P28:
This btw was tested on a DE2-115 and there is a DE2-115.FTH in the Forth folder that has words that know about the LEDs and switches etc. An external SD card works and a Flash chip in the socket on the Parallax breakout works fine too.
TAQOZ# : fibo ( n -- f ) 0 1 ROT FOR BOUNDS NEXT DROP ; ok TAQOZ# 47 6 DO CRLF ." fibo(" I . ." ) = " I LAP fibo LAP .LAP ." result =" . 10 +LOOP fibo(6) = 685 cycles = 8.562us result =8 fibo(16) = 1245 cycles = 15.562us result =987 fibo(26) = 1805 cycles = 22.562us result =121393 fibo(36) = 2365 cycles = 29.562us result =14930352 fibo(46) = 2925 cycles = 36.562us result =1836311903 okIf P2 is on-track for 180Mhz then this translates to a fibo(46) in TAQOZ of 16.25us
OBJ ser: "SimpleSerial" PUB demo | i, n, t ser.start(115_200) repeat i from 6 to 46 step 10 ser.str(string("fibo(")) ser.dec(i) ser.str(string(") ")) t := CNT n := fibolp(i) t := CNT - t ser.dec(t) ser.str(string(" cycles, result = ")) ser.dec(n) ser.str(string(13, 10)) PUB fibolp(n) : r | lastr r := 1 lastr := 0 repeat n-1 (lastr,r) := (r, r+lastr)Hey, that's great to know how fast Fastspin is, so I guess it's fast! What a great plug for Fastspin and the P2. No more slow code! I'd be interested in a listing of the code that it generates.
The fibo itself takes 16 bytes of code, but that is of course, on top of the supporting code it is built on. While the main part of the interpreter uses only 4 instructions for cog calls, the looping instruction NEXT uses stacked & latched branches so there is no reading and calculating branch addresses, just load and go.
' NEXT ( -- ) Decrement count (on loop stack) and loop until 0, then pop loop stack forNEXT djz index,#POPBRANCH ' exit loop _ret_ mov PTRA,branchadr ' loop again