I've been working with prof_braino on a laser range finder project on the Sensors => Time of Flight Laser Project thread. The design consists of a laser module, a receiver module, a timer, a power supply and a processor. The central controller for the LRF is a custom designed chip (DS00VQ100) and the processor is a Propeller.
We have decided to try Forth to write the hardware drivers for the project. The main advantage seems to be the way that Forth interacts with hardware. In this design, most of the hardware is indirectly accessible via a SPI bus linked to registers inside the controller chip. There are also a number of signal lines that connect directly to the Propeller chip.
Initially, the Forth software will be used to debug the design and check the basic operation of the controller chip. Thereafter, the challenge will be to provide good software controls and signal analysis tools. There is a slight problem in that I know nothing about Forth...
... any comm link that supports Rx/Tx might be usable (e.g. bluetooth). .... module defaults to 9600 baud and all I saw was gibberish on Tera Term. An AT command can set the baud rate to 57600, but I was not able to get the baud rate change to take.
... tried bluetooth or XBee to PropForth?
... pair a propeller device to android.
Yes, it is designed so any Rx/Tx can work. I believe you have to change the baud rate in propforth by editing the spin code to change the default. If you want settable baud rate for the initial forth command line prompt, you have to write the word, Sal did not add this to save space.
The AT command is setting which to 9600? I tink the AT command sets TeraTerm, you can also do this in the Setup->Serial Port-> Baud Rate menu selection. Remember to SaVe Setup.... afterwards if you want them at next program start. (I always forget this last part).
Suggestion is to leave the default serial connection on pin 30 31 (that runs on cog7) as-is for tera term command / line forth interface and programming. Implement a second serial connection on any other unused pair of pins. Determine the clock setting for the baud rate from the system clock as done in the default kernel, and make a word that sets this up and runs itt on an unused cog. This is pretty straight forward (per Sal) but I haven't done it yet. I was going to do just as you request and include user settable baud rate for the seconf serial connection for the project http://forums.parallax.com/showthread.php?131548-Holly-s-Request&p=998125&viewfull=1#post998125, but as you can guess, I havent gotten around to it.
But all the parts as in the documentation/regression tests, the second serial example is in multi-prop regression, the baud rate calculation is in the kernel, and boot time behavior is in the "onboot" usage examples.
I also plan to use an android phone as an interface, but I haven't gotten the phone yet (I'm REALLY cheap these days) so it is not on top of my list yet.
Initially, the Forth software will be used to debug the design and check the basic operation of the controller chip. Thereafter, the challenge will be to provide good software controls and signal analysis tools. There is a slight problem in that I know nothing about Forth...
Given that Forth is different from the block structured languages I am used to. I've decided to teach myself Forth by reading online tutorials and writing simple CS 101 programs. After that I'll tackle Forth programming on the propeller to solve real problems. I wrote the following using gforth because I didn't have access to a propeller at the time.
\ determines n2 is a factor of n1
: factor? mod 0= ;
\ prints all factors of a number except 1 and the number
: factors
dup 2
do
dup i
factor? if
i .
then
loop
drop ;
\ seeds the stack to generate a fibonacci sequence.
: fibonacci_seed
1 .
2 .
1 2 ;
\ determines if n1 is greater or equal to n3
: fibonacci_done
dup
3 pick
>= ;
\ generates a fibonacci sequence to the first number greater than n1.
: fibonacci
fibonacci_seed
begin
tuck
+
dup .
fibonacci_done
until
drop
drop
drop ;
Using only stack manipulation versus local variables has been a bit of a mind bender. My style probably betrays my heritage as a mostly C language family programmer. The postfix notation hasn't been a big deal, nor are Forth control structures which seem pretty good. But I'm not hung up on infix notation and used to be a big Lisp fan which is prefix based.
Out of curiosity I wrote the same simple program in both Forth and Spin. I ran the program on the propeller using PropForth and the Propeller tool, while using the PC's clock to get an estimate of the elapsed time.
Forth took ten seconds to print all the factors of 100,000, while Spin took five seconds. It would be interesting for someone to compare Catalina as well.
Here's the source code for both programs as it is entirely possible I botched this test somehow.
Forth:
\ determines n2 is a factor of n1
: factor?
/mod drop 0= ;
\ prints all factors of a number except 1 and the number
: factors
dup 2
do
dup i
factor? if
i .
then
loop
drop ;
Spin:
CON
_clkmode = xtal1 + pll16x
_xinfreq = 5_000_000
OBJ
pst : "Parallax Serial Terminal"
VAR
PUB Main | x, number
waitcnt(5 * clkfreq + cnt)
pst.Start(115200)
pst.str(STRING("Factor.Start", 13))
number := 100000
repeat x from 2 to number
if ((number // x)== 0)
pst.Dec(x)
pst.str(STRING(" "))
pst.NewLine
pst.str(STRING("Factor.Done", 13))
Disclaimer: These program are not supposed to be optimal, just computational similar for both languages. I know there are ways to optimize these programs, but I am trying to burn CPU cycles to compare things.
Out of curiosity I wrote the same simple program in both Forth and Spin.
Forth took ten seconds to print all the factors of 100,000, while Spin took five seconds.
Forth can be faster if values are handled on the stack rather than named variable, as this eliminates the overhead of memory access.
But, in other cases the overhead of the dictionary structure and interpreter end up costing more.
There are several areas where forth has advantages and disadvantages (I can't think of many of the others right now).
As always, its as matter of deciding the right tool for the right job.
If you do any more comparisons, please consider trying them when 5.0 comes out in a couple weeks. The next release should have most of the assembler optimization to the kernel. It would be interesting to see if there is a difference between the "final version" 5.0 and the "functional demo" version 4.5/4.6
If you do any more comparisons, please consider trying them when 5.0 comes out in a couple weeks. The next release should have most of the assembler optimization to the kernel. It would be interesting to see if there is a difference between the "final version" 5.0 and the "functional demo" version 4.5/4.6
Sure thing. Right now I am trying to get a feel for using arrays. I have a bit more of a learning curve to climb before I can do anything thing more useful.
Propforth is different from other forths in this area.
Usually arrays are defined with CREATE ARRAY-NAME followed by <bytes> ALLOT. CREATE is used to start a dictionary definition and allot allocate a stretch of memory.
But in propforth, create does not work the same due to the archtecture. There's a long explanation Sal gave me, but don't recall if it made it into the notes.
Instead, we use VARIABLE ARRAY-NAME followed by <bytes> ALLOT. The difference is that VARIABLE automatically allocates memory, and you need to adjust the size to allocate ( one less ) or beaware that the extra space is used, in case it makes a difference or can be used for something.
Usually WVARIABLE is used, as word allocation is most efficient for HUB memory, and LVARIABLE is use in the cog, as long is are most efficient in cog memory (in the current propforth architecture)
Prof_brainio, thanks for the array tidbit. I have selection sort using arrays and execution tokens working in gforth, so I'm now going to port it to prop forth. In gforth I use create does> so I can bind an action to an array name. Here's my code:
\ Used to allocate an array of cells of the desired size passed on stack
: array \ ( n -- addr )
create
cells \ converts count into size in bytes
here over erase \ clear the buffer and
allot \ allocate space
Does>
swap cells + ; \ run time gives address of cell at index
9 array foo \ from now on n foo puts the address of foo(n) on the stack.
I'm not sure how I would do the same thing using Variable array-name in PropForth.
As an aside, it seems gforth and prop forth are slightly different dialects as nothing works out of the box. For example gforth uses \ or ( for comments, but it seems PropForth only uses \, gforth has 2over and -rot, so I defined my own for PropForth.
I also have a recursive tower of hanoi working in gforth and I am trying to port it to prop forth. Gforth supports recursion by using the keyword recurse where you want to use the word you are defining. But that gets an undefined word error in PropForth. Here's the code in question:
fl
\ 2over from gforth
: 2over \ ( n1 n2 n3 -- n1 n2 n3 n1 n2 )
>r 2dup r> rot rot ;
\ Move disk simply prints the move.
\ arguments unused dest_post source_post disk_number
: hanoi_move_disk \ ( n1 n2 n3 n4 -- )
." Move disk " . ." from " . ." to " . cr
drop ;
\ Recursively moves sub-tower, a disk, and sub-tower
\ arguments spare_post dest_post source_post disk_number
: hanoi_move_tower \ ( n1 n2 n3 n4 -- )
dup 0=
if
hanoi_move_disk \ needs all arguments except spare_post
else
\ Push arguments dest_post, spare_post, source_post, disk_number - 1
2over swap 2over 1-
recurse
\ Duplicate the stack and move the disk.
2over 2over
hanoi_move_disk
\ Last call, consume arugments rather than duplicate them.
\ Reformat the stack to contain source, dest, spare, disk - 1
>r rot rot swap r> 1-
recurse
then ;
\ seeds the stack and calls moves tower
: hanoi_move_4 ( -- spare dest source disk )
2 3 1 4
cr
hanoi_move_tower ;
The usual CREATE ... DOES> ... construct has not lent itself well to the way Sal's architecture for propforth. The overhead and complexity to implement it were deemed "not worth it" at the time of implementation, as Sal did not have a particular use for it at the time. As more advanced users begin to port to propforth, we are looking into the need for implementing this in the kernel. But so far its still not on the to do list.
The suggested solution is to a) experiment with CREATE ... DOES> ... and make suggestions to Sal, and b) allocate the memory with one (set of) word(s) at compile time and process with a different (set of) word(s) at execution time.
I believe Mick and Ron (and maybe Peter) are looking at (a) so you might want to start conversations with them, and off-load that discussion from Sal till the 5.0 kernel comes out. (Its over my head, I just do the documentation and test).
Option (b) is a little more work on the developers part, but we are are confident (guessing) that anyone that uses DOES> can work around this for a bit.
Recursion - since the prop doesn't have all that much memory, the thought was that recursion in the default kernel might not be a good fit. There is a way to do it, but it fills up memory very fast, and therefore deemed too limited to be of much use, and not worth the effort to implement at this time. However, now that we have SD memory access so fast, the plan is to put recursion as an extension that can be used when executing from scripts on SD. The access time to the SD is not too bad considering the size of SD and cost of alternatives. There should be more work in this area after 5.1, when the multi-prop configurations become the main focus.
Martin: If you examine the code for the analog computer emulation (first post on this thread), you will find words used to define different kinds of arrays where create..does> is not available.
FYI
I have found Brian's list of forth references very interesting. I would add the following two references which can be accessed at the indicated addresses.
"Evolution of Forth" Rather, Colburn & Moore (Forth.com)
"Programming Forth" Stephen Pelc (mpeforth.com)
NickL
The Pelc book as available as a pdf. Anyone who is still hesitant in trying forth shoul read chapters 15 (Embedded Systems) and 21 (Adapting and Managing Forth)
Thanks NickL, I will definitely read your analog computer code to learn how to create arrays. I've also been reading through the content Brian assembled and found Pelc's "Programming Forth" particularly helpful. I've been working through that coupled with gforth because I can work with both at any PC.
prof_braino, recursion isn't that big a deal as I rarely used it. But tower of hanoi and quick sort were two of the CS exercises I was trying to write in forth so it came up.
Overall I can see how the interactive nature of Forth could be handy on the Propeller. Spin has a few gotchas which can be a pain to find without debugging tools.
The Pelc name rang a bell, I was pretty sure that I had it. I did, but had forgotten to u/l it. It has been added to the "Forth Resources" directory. Unfortunately, like "Starting Forth," R,C, & M's "Evolution of Forth seems only to be available in online HTML, which doesn't lend itself to collection in a single PDF file easily.
.... create arrays... content Brian assembled ... gforth because I can work with both at any PC....recursion...
In additon to gforth, also give a glance at pygmy forth for the PC. http://pygmy.utoh.org/ This is my favorite PC forth and was intended to be the "PC companion" for propforth. I would be interested to see which of gforth or pygmy forth turns out to be more compatible with propforth.
I had started on the "Sieve of Eratosthenes" for parallel processing and recursion experiments, but decided to leave off until the 5.x releases. Many folks have stated these are silly on any microcontroller, prop in particular; but these are still fun and will be on the list later for benchmarking if nothing else. PLease continue to keep us posted on your progress, or at least know that this will be bigger in the proforth v5.x time frame.
Also, let us know any feedback for improvements on the docs. You are currently the target audience of the documentation.
pygmy forth requires a 32-bit DOS environment and doesn't run on 64-bit Windows 7 without DOSBox or some other such 16-bi/32-bitt DOS emulator.
gForth runs just fine under 64-bit windows 7 and is cross-platform, which I think gives things a big advantage these days. I'm becoming a more and more cross-platform kind of guy lately.
I think an I/O Channel type vocabulary for gForth would be interesting so you could reach out to PropForth platforms across a serial port with transparency similar to what we have now on multi-prop PropForth setups. That sounds like an interesting project to put on my plate for my "spare time"!!
prof_braino, I'll take a pass at the documentation on the Wiki and post my questions and comments.
I now have gForth code that is sorting an array of cells that are pointers. So my comparison function uses @ @ to double dereference and get the actual value. Unless I'm missing something about PropForth syntax, it requires the use of width decoratored ! and @ operators. So L@ L@ is used to double dereference. Basically you always need to specify C, W, or L during a load or store onto the stack.
But I think this impacts the ability to re-use or write Forth that is portable to 16, 32, or 64 bits machines. If I understand Forth its memory model is an array of cells, where the cell width is the same as a pointer width. So I can load an address onto the stack and then store that address into a cell. With the ! operator the width is implied to be a cell width which is also a pointer width.
But if I have to use L! with PropForth then I've explicitly coded a 32 bit pointer width dependency. While I can define ! and @ words, that does introduce an extra call.
Martin, just redefine the names in the Spin source and recompile it like I did. There are some words which make more sense such as @ instead of L@ although I do understand the principle but compatibility requires more standard names. There are also the EEPROM words which I also renamed as most are really just i2c access primitives. Then there was this "delms" which just seems so unnecessary and reads more like "delete ms" when you can just say "100 ms" and it's readable.
Of course the correct way to modify the source is to go back to the original PropForthKernel source and run it through SpinMaker and then run the Spin source through the Prop Tool into the Prop.
But I'm just glad that Sal went to the effort to port a usable Forth to the Prop as the Prop's architecture is very different and that combined with the limitations of the Prop Tool it makes it awkward to write a Forth for it. It's a lot of time and bother, but Sal's done it.
Peter, your redefinition in the Spin source is a good idea. I'd like to be able to cut and paste as much as possible with other Forth dialects.
I'm definitely appreciative of the effort put forth on Forth by Sal, Prof Brainio, and Brian. I'm having a pretty good time with PropForth, but I'm still in the learning phase. Although things are starting to click more and I feel I'm struggling less.
Peter, your redefinition in the Spin source is a good idea. I'd like to be able to cut and paste as much as possible with other Forth dialects.
Remember, forth dialects can only be compatible at the application level, and are necessarily less compatible the closer you get to the primative kernel, This is because of the basic differences in each targeted processor archtecture and assembler.
Re-defining L@ and L! as @ and ! is and option, but avoid shooting yourself in the feet. L@ and L! are used to differentiate 32 bit HUB memory access from COG@ and COG! in the COG memory, as COG is always 32 bit access. HUB memory can be W@ W! word access(most efficient), L! and L@ (Long, less efficeient) or byte (character) C@ C! (less efficireent). The standard forth memory fetch and store words (@ and !) imply the default cell size. Since there are TWO defaults in the prop (32 bit in COG and 16 bit in HUB), we explicitely chose to NOT use the "normal" default words, as the concept is misleading here and therefore does not apply. Thus we chose to explicitely differentiate the memory access by size.
This is an example where one simply has to be aware of details about the specific processor to effictively use it. This is why propforth is not "standard" in many ways, the prop is not a "standard" architecture. When you get down to each chip is different, so anything below the hardware abstraction layer (HAL) has to be different. In the case of embedded software on a microcontroller, EVERYTHING can be below the HAL.
Of course, we are encouraged to make any changes and find a better way, so the kernel can be improved. This post is just to explain the design decisions that necessiate the current configuration.
Back to your discussion, if you redefine L! and L@ (the HUB 32 bit memory access words) as ! and @, be careful to include documentation that these now mean LONG (instead of WORD) access, or you risk making your code LESS compatible with other forth dialects (and other propforth routines). Be aware we discussed this at length before making this decision and determined that the default words @ and ! should not be used, since COG has 32 bit default and HUB has 16 bit default.
prof_braino, as a Forth noob I won't question the PropForth team's design decisions. It is definitely a strength of PropForth that it allows cog ram access via the COG@ and COG! operators.
What confused me is that the propeller feels like a 32 bit processor, but the RAM address space much more constrained than that. So normally the default load/store unit is the same as register width and by extension is the same as pointer width. But that's not the case here although Spin tends to encourage 32 bit thinking.
I'm thinking I'll be better off leaving word definitions alone and trying 16 bit wide pointer to pointers tonight. Hub ram isn't a 32 bit address space anyway, so I'll save hub RAM as well. To make my code portable I'll add words explicitly for pointer to pointer store and dereference with platform specific implementations.
Spin's lack of function pointers means that I never created generic logic with callbacks on the propeller before. Also Spin only runs on the propeller, so I never gave a thought about creating portable Spin code before either.
the propeller feels like a 32 bit processor, but the RAM address space much more constrained than that.
normally the default load/store unit is the same as register width and by extension is the same as pointer width.
Spin's lack of function pointers ... Spin only runs on the propeller... portable Spin code
Questions are good, changing is good, and understanding is mandatory for success. COGS are 32 bit, but Sal determined 16 bits in the HUB is most efficient.
This is just his arbitrary descision based on forth experience. You can change this if you see a need, I just want you to understand the original line of thought, which is the prop is so cool because of these little things that make such a big difference. Don't worry, you are questioning exactly what you need to be questioning.
"Portable" code is only ABOVE the hardware abstraction layer. Propforth kernel is defined as BELOW the hardware abstraction layer. Sal nearly always works below the HAL (Portability not an issue as its the kernel), and I nearly always think above the HAL (applications), unless I'm doing drivers. Our mission, should we decide to accept it, is to determine what we mean by HAL on the prop and in the context of propforth. However, if we do NOT chose to accept this mission, we won't necessarily self destruct in 60 seconds.
How much of "portable" and "HAL" is needed to get us what we are actually going to end up using? I tend toward "minimum necessary and sufficeint to completely achive the stated goal". Then I tailor the "necessary and sufficient" for the specific goal.
I finally got around to replacing PropForth 4.0 with 4.6 - and discovered that PropFACS (1st post) would not load. I made adjustments in the code and increased the flexibility of the plot functions (attached PropFACS 12.rft). I also combined the graphics routine with the terminal program, eliminating the editor function & sd routines (attached GraphicsTerminal.zip). My setup is shown in the attached image (PFTerminalSetup.jpg). The forth engine is installed on the base GG platform. The top propeller shield acts as a text/graphics terminal. Models are installed on the base eeprom. The terminal allows the user to load a model, make appropriate changes in parameters and view simulation results in the graphics mode. The user has the option to select the ty-plot, xy-plot or strip chart modes.
Attached is a FACS model of the Lorenz equations ( LORENZ.txt) and an image showing one example of its solution as an xy-plot.
I also have considered the timing differences between spin and forth versions of a program, such as Martin_H's post where the forth version was significantly slower than the spin version. I have also observed this in comparing FHT forth and spin versions. I have determined that words such as /mod and */ are major factors in the forth versions performance. For example, /mod is responsible for 6+ seconds of the 10+ seconds in Martin_H's example. These words are examples of functions which should be redefined in pasm for PropForth 5.
Sal sent me some details on the pf 5.0 kernel. I'll start a separate thread to preview particulars, it looks like pf 4.0 will be much easier for assembly optimization. Of course we will need a couple of iteration on the instructions, maybe optimizing the dividision routines will be good as an example.
FYI - Sal is traveling for the next seven weeks, we don't anticipate more progress till December.
Sal sent me some details on the pf 5.0 kernel. I'll start a separate thread to preview particulars, it looks like pf 4.0 will be much easier for assembly optimization. Of course we will need a couple of iteration on the instructions, maybe optimizing the dividision routines will be good as an example.
FYI - Sal is traveling for the next seven weeks, we don't anticipate more progress till December.
I thought I understood execution tokens, but I've just realized that they don't seem to work when you try to use the ' inside a word definition. So interactively these commands:
over
' bubble_up_loop?
swap
Perform as expected. But if I put them inside a word definition like this:
That error came out of gForth. I write code in that and port to PropForth. What I was doing is getting the execution token for bubble_up_loop so I could pass it to another word. It turns out the syntax is different in interactive versus compiled mode. ' is used in interactive mode while is used in compiled mode, at least in gForth.
Execution tokens are like function pointers, so you can build generic logic and then callback into code which specializes the behavior.
Propforth does not have very much error handling implemented. There are "stubs" present, but mostly propforth just returns a code if it does anything at all. It will be up to us, the users, to come up with a set of extensions that do error messages etc. when the kernel is ready.
The idea is that error checking is expensive. It takes up execution time, and take lots of space. So the key is to do error checking at the most appropriate time. When you get right down to it, usually the data can be checked at input time and if proven "good" and the application works correctly, no other checking is needed. So the application determines what error checking is needed, and the phases of completion will have different needs during the course of development. Ultimately, the appropriate set of error code messages is determined by the application and evolves over time.
Error message extensions for propforth will be tackled as a separate activity after the kernel is complete, and will need input from all the users. For example, a general "library" of functions can be made, and the user selects which to add based on the area of development.. But this is all a bit further down the road.
Comments
I've been working with prof_braino on a laser range finder project on the Sensors => Time of Flight Laser Project thread. The design consists of a laser module, a receiver module, a timer, a power supply and a processor. The central controller for the LRF is a custom designed chip (DS00VQ100) and the processor is a Propeller.
We have decided to try Forth to write the hardware drivers for the project. The main advantage seems to be the way that Forth interacts with hardware. In this design, most of the hardware is indirectly accessible via a SPI bus linked to registers inside the controller chip. There are also a number of signal lines that connect directly to the Propeller chip.
Initially, the Forth software will be used to debug the design and check the basic operation of the controller chip. Thereafter, the challenge will be to provide good software controls and signal analysis tools. There is a slight problem in that I know nothing about Forth...
Yes, it is designed so any Rx/Tx can work. I believe you have to change the baud rate in propforth by editing the spin code to change the default. If you want settable baud rate for the initial forth command line prompt, you have to write the word, Sal did not add this to save space.
The AT command is setting which to 9600? I tink the AT command sets TeraTerm, you can also do this in the Setup->Serial Port-> Baud Rate menu selection. Remember to SaVe Setup.... afterwards if you want them at next program start. (I always forget this last part).
Suggestion is to leave the default serial connection on pin 30 31 (that runs on cog7) as-is for tera term command / line forth interface and programming. Implement a second serial connection on any other unused pair of pins. Determine the clock setting for the baud rate from the system clock as done in the default kernel, and make a word that sets this up and runs itt on an unused cog. This is pretty straight forward (per Sal) but I haven't done it yet. I was going to do just as you request and include user settable baud rate for the seconf serial connection for the project http://forums.parallax.com/showthread.php?131548-Holly-s-Request&p=998125&viewfull=1#post998125, but as you can guess, I havent gotten around to it.
But all the parts as in the documentation/regression tests, the second serial example is in multi-prop regression, the baud rate calculation is in the kernel, and boot time behavior is in the "onboot" usage examples.
I also plan to use an android phone as an interface, but I haven't gotten the phone yet (I'm REALLY cheap these days) so it is not on top of my list yet.
If you haven't seen TOF range fiinder thread yet, please check it out http://forums.parallax.com/showthread.php?133632-Time-machine-TOF-laser-project
We might asking for input from the group. I am thinking about writing up an example for creating drivers for new hardware based on this project.
\ determines n2 is a factor of n1 : factor? mod 0= ; \ prints all factors of a number except 1 and the number : factors dup 2 do dup i factor? if i . then loop drop ; \ seeds the stack to generate a fibonacci sequence. : fibonacci_seed 1 . 2 . 1 2 ; \ determines if n1 is greater or equal to n3 : fibonacci_done dup 3 pick >= ; \ generates a fibonacci sequence to the first number greater than n1. : fibonacci fibonacci_seed begin tuck + dup . fibonacci_done until drop drop drop ;Using only stack manipulation versus local variables has been a bit of a mind bender. My style probably betrays my heritage as a mostly C language family programmer. The postfix notation hasn't been a big deal, nor are Forth control structures which seem pretty good. But I'm not hung up on infix notation and used to be a big Lisp fan which is prefix based.
Forth took ten seconds to print all the factors of 100,000, while Spin took five seconds. It would be interesting for someone to compare Catalina as well.
Here's the source code for both programs as it is entirely possible I botched this test somehow.
Forth:
\ determines n2 is a factor of n1 : factor? /mod drop 0= ; \ prints all factors of a number except 1 and the number : factors dup 2 do dup i factor? if i . then loop drop ;Spin:
CON _clkmode = xtal1 + pll16x _xinfreq = 5_000_000 OBJ pst : "Parallax Serial Terminal" VAR PUB Main | x, number waitcnt(5 * clkfreq + cnt) pst.Start(115200) pst.str(STRING("Factor.Start", 13)) number := 100000 repeat x from 2 to number if ((number // x)== 0) pst.Dec(x) pst.str(STRING(" ")) pst.NewLine pst.str(STRING("Factor.Done", 13))Disclaimer: These program are not supposed to be optimal, just computational similar for both languages. I know there are ways to optimize these programs, but I am trying to burn CPU cycles to compare things.
Forth can be faster if values are handled on the stack rather than named variable, as this eliminates the overhead of memory access.
But, in other cases the overhead of the dictionary structure and interpreter end up costing more.
There are several areas where forth has advantages and disadvantages (I can't think of many of the others right now).
As always, its as matter of deciding the right tool for the right job.
If you do any more comparisons, please consider trying them when 5.0 comes out in a couple weeks. The next release should have most of the assembler optimization to the kernel. It would be interesting to see if there is a difference between the "final version" 5.0 and the "functional demo" version 4.5/4.6
Sure thing. Right now I am trying to get a feel for using arrays. I have a bit more of a learning curve to climb before I can do anything thing more useful.
Propforth is different from other forths in this area.
Usually arrays are defined with CREATE ARRAY-NAME followed by <bytes> ALLOT. CREATE is used to start a dictionary definition and allot allocate a stretch of memory.
But in propforth, create does not work the same due to the archtecture. There's a long explanation Sal gave me, but don't recall if it made it into the notes.
Instead, we use VARIABLE ARRAY-NAME followed by <bytes> ALLOT. The difference is that VARIABLE automatically allocates memory, and you need to adjust the size to allocate ( one less ) or beaware that the extra space is used, in case it makes a difference or can be used for something.
Usually WVARIABLE is used, as word allocation is most efficient for HUB memory, and LVARIABLE is use in the cog, as long is are most efficient in cog memory (in the current propforth architecture)
\ Used to allocate an array of cells of the desired size passed on stack : array \ ( n -- addr ) create cells \ converts count into size in bytes here over erase \ clear the buffer and allot \ allocate space Does> swap cells + ; \ run time gives address of cell at index 9 array foo \ from now on n foo puts the address of foo(n) on the stack.I'm not sure how I would do the same thing using Variable array-name in PropForth.
As an aside, it seems gforth and prop forth are slightly different dialects as nothing works out of the box. For example gforth uses \ or ( for comments, but it seems PropForth only uses \, gforth has 2over and -rot, so I defined my own for PropForth.
I also have a recursive tower of hanoi working in gforth and I am trying to port it to prop forth. Gforth supports recursion by using the keyword recurse where you want to use the word you are defining. But that gets an undefined word error in PropForth. Here's the code in question:
fl \ 2over from gforth : 2over \ ( n1 n2 n3 -- n1 n2 n3 n1 n2 ) >r 2dup r> rot rot ; \ Move disk simply prints the move. \ arguments unused dest_post source_post disk_number : hanoi_move_disk \ ( n1 n2 n3 n4 -- ) ." Move disk " . ." from " . ." to " . cr drop ; \ Recursively moves sub-tower, a disk, and sub-tower \ arguments spare_post dest_post source_post disk_number : hanoi_move_tower \ ( n1 n2 n3 n4 -- ) dup 0= if hanoi_move_disk \ needs all arguments except spare_post else \ Push arguments dest_post, spare_post, source_post, disk_number - 1 2over swap 2over 1- recurse \ Duplicate the stack and move the disk. 2over 2over hanoi_move_disk \ Last call, consume arugments rather than duplicate them. \ Reformat the stack to contain source, dest, spare, disk - 1 >r rot rot swap r> 1- recurse then ; \ seeds the stack and calls moves tower : hanoi_move_4 ( -- spare dest source disk ) 2 3 1 4 cr hanoi_move_tower ;The suggested solution is to a) experiment with CREATE ... DOES> ... and make suggestions to Sal, and b) allocate the memory with one (set of) word(s) at compile time and process with a different (set of) word(s) at execution time.
I believe Mick and Ron (and maybe Peter) are looking at (a) so you might want to start conversations with them, and off-load that discussion from Sal till the 5.0 kernel comes out. (Its over my head, I just do the documentation and test).
Option (b) is a little more work on the developers part, but we are are confident (guessing) that anyone that uses DOES> can work around this for a bit.
Recursion - since the prop doesn't have all that much memory, the thought was that recursion in the default kernel might not be a good fit. There is a way to do it, but it fills up memory very fast, and therefore deemed too limited to be of much use, and not worth the effort to implement at this time. However, now that we have SD memory access so fast, the plan is to put recursion as an extension that can be used when executing from scripts on SD. The access time to the SD is not too bad considering the size of SD and cost of alternatives. There should be more work in this area after 5.1, when the multi-prop configurations become the main focus.
FYI
I have found Brian's list of forth references very interesting. I would add the following two references which can be accessed at the indicated addresses.
"Evolution of Forth" Rather, Colburn & Moore (Forth.com)
"Programming Forth" Stephen Pelc (mpeforth.com)
NickL
The Pelc book as available as a pdf. Anyone who is still hesitant in trying forth shoul read chapters 15 (Embedded Systems) and 21 (Adapting and Managing Forth)
prof_braino, recursion isn't that big a deal as I rarely used it. But tower of hanoi and quick sort were two of the CS exercises I was trying to write in forth so it came up.
Overall I can see how the interactive nature of Forth could be handy on the Propeller. Spin has a few gotchas which can be a pain to find without debugging tools.
I am glad everyone is finding this stuff useful.
In additon to gforth, also give a glance at pygmy forth for the PC. http://pygmy.utoh.org/ This is my favorite PC forth and was intended to be the "PC companion" for propforth. I would be interested to see which of gforth or pygmy forth turns out to be more compatible with propforth.
I had started on the "Sieve of Eratosthenes" for parallel processing and recursion experiments, but decided to leave off until the 5.x releases. Many folks have stated these are silly on any microcontroller, prop in particular; but these are still fun and will be on the list later for benchmarking if nothing else. PLease continue to keep us posted on your progress, or at least know that this will be bigger in the proforth v5.x time frame.
Also, let us know any feedback for improvements on the docs. You are currently the target audience of the documentation.
gForth runs just fine under 64-bit windows 7 and is cross-platform, which I think gives things a big advantage these days. I'm becoming a more and more cross-platform kind of guy lately.
I think an I/O Channel type vocabulary for gForth would be interesting so you could reach out to PropForth platforms across a serial port with transparency similar to what we have now on multi-prop PropForth setups. That sounds like an interesting project to put on my plate for my "spare time"!!
I now have gForth code that is sorting an array of cells that are pointers. So my comparison function uses @ @ to double dereference and get the actual value. Unless I'm missing something about PropForth syntax, it requires the use of width decoratored ! and @ operators. So L@ L@ is used to double dereference. Basically you always need to specify C, W, or L during a load or store onto the stack.
But I think this impacts the ability to re-use or write Forth that is portable to 16, 32, or 64 bits machines. If I understand Forth its memory model is an array of cells, where the cell width is the same as a pointer width. So I can load an address onto the stack and then store that address into a cell. With the ! operator the width is implied to be a cell width which is also a pointer width.
But if I have to use L! with PropForth then I've explicitly coded a 32 bit pointer width dependency. While I can define ! and @ words, that does introduce an extra call.
Of course the correct way to modify the source is to go back to the original PropForthKernel source and run it through SpinMaker and then run the Spin source through the Prop Tool into the Prop.
But I'm just glad that Sal went to the effort to port a usable Forth to the Prop as the Prop's architecture is very different and that combined with the limitations of the Prop Tool it makes it awkward to write a Forth for it. It's a lot of time and bother, but Sal's done it.
I'm definitely appreciative of the effort put forth on Forth by Sal, Prof Brainio, and Brian. I'm having a pretty good time with PropForth, but I'm still in the learning phase. Although things are starting to click more and I feel I'm struggling less.
Remember, forth dialects can only be compatible at the application level, and are necessarily less compatible the closer you get to the primative kernel, This is because of the basic differences in each targeted processor archtecture and assembler.
Re-defining L@ and L! as @ and ! is and option, but avoid shooting yourself in the feet. L@ and L! are used to differentiate 32 bit HUB memory access from COG@ and COG! in the COG memory, as COG is always 32 bit access. HUB memory can be W@ W! word access(most efficient), L! and L@ (Long, less efficeient) or byte (character) C@ C! (less efficireent). The standard forth memory fetch and store words (@ and !) imply the default cell size. Since there are TWO defaults in the prop (32 bit in COG and 16 bit in HUB), we explicitely chose to NOT use the "normal" default words, as the concept is misleading here and therefore does not apply. Thus we chose to explicitely differentiate the memory access by size.
This is an example where one simply has to be aware of details about the specific processor to effictively use it. This is why propforth is not "standard" in many ways, the prop is not a "standard" architecture. When you get down to each chip is different, so anything below the hardware abstraction layer (HAL) has to be different. In the case of embedded software on a microcontroller, EVERYTHING can be below the HAL.
Of course, we are encouraged to make any changes and find a better way, so the kernel can be improved. This post is just to explain the design decisions that necessiate the current configuration.
Back to your discussion, if you redefine L! and L@ (the HUB 32 bit memory access words) as ! and @, be careful to include documentation that these now mean LONG (instead of WORD) access, or you risk making your code LESS compatible with other forth dialects (and other propforth routines). Be aware we discussed this at length before making this decision and determined that the default words @ and ! should not be used, since COG has 32 bit default and HUB has 16 bit default.
What confused me is that the propeller feels like a 32 bit processor, but the RAM address space much more constrained than that. So normally the default load/store unit is the same as register width and by extension is the same as pointer width. But that's not the case here although Spin tends to encourage 32 bit thinking.
I'm thinking I'll be better off leaving word definitions alone and trying 16 bit wide pointer to pointers tonight. Hub ram isn't a 32 bit address space anyway, so I'll save hub RAM as well. To make my code portable I'll add words explicitly for pointer to pointer store and dereference with platform specific implementations.
Spin's lack of function pointers means that I never created generic logic with callbacks on the propeller before. Also Spin only runs on the propeller, so I never gave a thought about creating portable Spin code before either.
Questions are good, changing is good, and understanding is mandatory for success. COGS are 32 bit, but Sal determined 16 bits in the HUB is most efficient.
This is just his arbitrary descision based on forth experience. You can change this if you see a need, I just want you to understand the original line of thought, which is the prop is so cool because of these little things that make such a big difference. Don't worry, you are questioning exactly what you need to be questioning.
"Portable" code is only ABOVE the hardware abstraction layer. Propforth kernel is defined as BELOW the hardware abstraction layer. Sal nearly always works below the HAL (Portability not an issue as its the kernel), and I nearly always think above the HAL (applications), unless I'm doing drivers. Our mission, should we decide to accept it, is to determine what we mean by HAL on the prop and in the context of propforth. However, if we do NOT chose to accept this mission, we won't necessarily self destruct in 60 seconds.
How much of "portable" and "HAL" is needed to get us what we are actually going to end up using? I tend toward "minimum necessary and sufficeint to completely achive the stated goal". Then I tailor the "necessary and sufficient" for the specific goal.
Attached is a FACS model of the Lorenz equations ( LORENZ.txt) and an image showing one example of its solution as an xy-plot.
I also have considered the timing differences between spin and forth versions of a program, such as Martin_H's post where the forth version was significantly slower than the spin version. I have also observed this in comparing FHT forth and spin versions. I have determined that words such as /mod and */ are major factors in the forth versions performance. For example, /mod is responsible for 6+ seconds of the 10+ seconds in Martin_H's example. These words are examples of functions which should be redefined in pasm for PropForth 5.
NickL
Sal sent me some details on the pf 5.0 kernel. I'll start a separate thread to preview particulars, it looks like pf 4.0 will be much easier for assembly optimization. Of course we will need a couple of iteration on the instructions, maybe optimizing the dividision routines will be good as an example.
FYI - Sal is traveling for the next seven weeks, we don't anticipate more progress till December.
Thanks for update
Perform as expected. But if I put them inside a word definition like this:
I get a really strange error a
bubble_sort
:309: Attempt to use zero-length string as a name
bubble_sort>>><<<
I'm guessing that there's different syntax to generate one at compile time. But I can't figure it out.
Update: I found out that in a word definition you need to use .
What is [bubble_up_loop?]?
WORD get pfa for next WORD.
What does getting pfa mean?
I can't find out message[:309: Attempt to use zero-length string as a name] inside PropForthBootKernel.f and PropForthKernel.f.
Execution tokens are like function pointers, so you can build generic logic and then callback into code which specializes the behavior.
The idea is that error checking is expensive. It takes up execution time, and take lots of space. So the key is to do error checking at the most appropriate time. When you get right down to it, usually the data can be checked at input time and if proven "good" and the application works correctly, no other checking is needed. So the application determines what error checking is needed, and the phases of completion will have different needs during the course of development. Ultimately, the appropriate set of error code messages is determined by the application and evolves over time.
Error message extensions for propforth will be tackled as a separate activity after the kernel is complete, and will need input from all the users. For example, a general "library" of functions can be made, and the user selects which to add based on the area of development.. But this is all a bit further down the road.