I've used Forth a few times in the past but feel I must be missing some things since it really hasn't sunk in yet. I'd really like to learn more about it and I wish I knew as much about it as others.
The only exposure I've had to Forth was to work with some older robots. Forth was used extensively by an old robot company called Androbot. The TOPO II/III robots were programmed using Forth running on an Apple IIe computer with and IR link to tell the robot what to do. Their prototype BOB robots were based on the 8088 processor which had Forth built-in and would boot up and start running Forth. It was like a PC but instead of a standard BIOS it had Forth in ROM. I've been able to use some of the Forth definitions and routines and make a few tiny programs but there are some concepts I just don't fully understand. Perhaps some of the Forth experts out there can help me learn a bit more about Forth and help me unravel the mystery's still in the code of these old robots. I particular I'd like to understand the BOB code since it would help me revive that robot. Ideally if the higher level Forth routines can be isolated then perhaps I could eventually get that code to run on Propeller Forth and emulate the lower level stuff.
Any Forth experts out there want to help me out and convert someone new to Forth??
I've used Forth a few times in the past but feel I must be missing some things since it really hasn't sunk in yet. I'd really like to learn more about it and I wish I knew as much about it as others.
<snip>
Any Forth experts out there want to help me out and convert someone new to Forth??
Robert
It's that last sentence that caught my eye and I let out an exasperated "oh no" (BTW, I just realized, doh, I thought you wrote "something" but the post is still applicable anyway")
Anybody who has tried "converting" a program from one language into Forth, even if they are some kind of an expert, have met with discouraging results. The problem is that you end up trying to convert not just the syntax but the whole way of thinking which just does not translate.
Have you ever read book "Thinking Forth" which was Leo Brodie's second Forth book after the well known "Starting Forth"? Well, if you have then you will gain a little insight into not just Forth but also into how to view and approach problems and the merits of coming up with a simple solution rather than "use the library". Forth itself is very simple and easy, but it provides the foundation and building blocks on which you impress your "thinking" and does not artificially constrain you to a rigid syntax and structure common to conventional languages. Like a blank canvas and a palette of colors you are free to express yourself, if you let yourself express yourself freely.
I'm sure that to anyone reading this it sounds like a fairy story or something fanciful and not really true. The truth is that it is hard to describe and descriptions tend to be more of an understatement. I remember once many years ago I wanted to use a new type of PLD chip but the programmer for it was $$$$$ and the compiler for it was $$$$$ and so it didn't seem possible. But armed with a datasheet and odd bits of information about the device plus volumes 1, 2 &3 of the Fortran source code I sat down and analyzed both the sketchy in-circuit programming requirements plus what it would take to implement a compiler myself.
First off I did foolishly try to convert the source code into Forth but it became a horrible mess which just needed to be flushed down the sink. Then I thought, if I slightly rearrange the PLD source (not compiler) to fit in more with how Forth processes source then it should become more natural. So it was, and in ONE afternoon I had written a PLD compiler in Forth that took logic equations in and generated the "fuse" map files necessary to program the device. With a little interactive use of Forth on the chip itself I perfected the ICP routines and next day it was running. That is only one story.
Now, if you want to "try" Forth then please read the book and sit down with a blank canvas and paint it with Forth words that then becomes your robot language, what is most natural for it and you. Don't try to write lots of code and then expect it to run. Just interact and build up little tiny words (definitions) where the name of the word describes the functions and it's use such as " FAST FORWARD LEFT MOTOR" where each word does something that can be easily tested without those other words. This can then become "SLOW REVERSE RIGHT MOTOR" causing the robot in this instance to a quick turn. BTW, SLOW is just a constant as is REVERSE as is RIGHT which then pass parameters to the word MOTOR which performs the action. This is the power of stack based postfix notation if used well.
BTW again we could then implement a new word for a quick turn like this:
: QuickTurn ........ FAST FORWARD LEFT MOTOR ........ SLOW REVERSE RIGHT MOTOR ;
Typing in QuickTurn at the keyboard will execute the function as will typing the individual words. QuickTurn is now part of the "language", so it's not really the Forth language, it's your's and the robot's language. (The ........ 's are just there as the forum editor seems to cleanup white space)
I'm trying to keep this post short but it doesn't work, maybe I should write a book!
Thanks for your response! I have at least one of those Forth books (if not both of them) but there are still some concepts (screens and such) that haven't sunk it. It just hasn't clicked for me yet. I have found a definition called vocabulary that helped show some of the things that were defined in Forth. I've been basically avoiding Forth and when I had to add a brain to an old empty Androbot prototype I did most of the coding in C. I named my routines similar to the ones that would have been defined in Forth. For my purposes it worked out well. However, it would be nice to dig a little deeper into how each one of the Forth commands was defined to make sure I understand all the things each command could do. So, I can see a list of specific Forth definitions just for the robot and I've been able to create some new ones that leverage what is there. That part seems simple on the surface. Issues that throw a wrench in that is when you tell Forth to forget a definition or redefine one.
What I would rather do instead of converting all the Forth code to a different language would be to port the higher level Forth code over to another Forth system. So, all the higher level Forth code would stay the same. So, I could then in theory use a propeller running PropForth and use that as the main controller. With that I should be able to run any High level Forth programs as they are on the new controller. Although I read about Forth programming that is a point I never see covered. It isn't clear how that would be done.
If that is something that could be done then that would give me a real world application for Forth and a real reason to use it. My experience so far is that it isn't very portable but I hope I am wrong on that point.
So, if I wanted to use Prop Forth how would I go about making sure the lower level definitions get created and port over the higher level Forth definitions? That would be a good topic for a book and one that I would read!
Hopefully I have read your post correctly this time! First, in regards to portability you will find this is a problem in all languages, and Forth can also suffer from it. If a program is well written and structured then it is fairly easy to port to another platform. Of course embedded systems vary considerably unlike a PC so low-level drivers need to be redone as long as they are on their own layer and not mangled in with a dozen different high-level definitions. Sometimes all you need is a translation layer (redefined and extra words) between the new Forth system and the old source.
If you use Forth exclusively on the new system you will be far more creative and enjoy the whole experience a lot more than sitting down coding and debugging which sometimes includes "debugging" the compiler.
A low level definition is very easy and the trick is to make sure no one word (definition) is more than a few lines long, less if possible. Sure, this might not be the case say with a CASE definition but for most words this should be possible. A low-level definition for a temperature sensor for instance can be tested first.....then written, simply because you can interact with the hardware at both a low and high level.
Do you understand your hardware? Good! Not sure about some aspects of it? No problem, exercise the hardware interactively and end up knowing more than the manufacturer's application engineers!
- Although long out of print, Brodie's "Starting Forth' can be gotten, used, through Amazon. Simply search on "Leo Brodie Starting Forth". I picked up a copy labeled "used, like new" for around $25 with shipping and it was as advertised.
- Brodie's "Thinking Forth" is available as a PDF at the link in my post #26 of this thread.
- I have been slowly working my way through the various essays and discourses by Chuck Moore and Jeff Fox that are also available at the above mentioned link. I have learned a lot about "thinking Forth" (note lower case t) in the essays about the early days of Forth and why various design decisions were made.
Now a question I think I read before, and in this thread. How fast is PropForth in general, 1/3-1/2 of Spin?
As you can see, forth can be nearly as fast as assembler, despite being interpreted. This is achieved by several means.
One is using the stack instead of named variables when possible; this eliminates the overhead of memory fetch and memory store operations, and of memory address processing.
Another is the interpreter and dictionary architecture, the "words" in the dictionary are either "chunks of assembler" implementing the simplest functions, or a list of addresses of primitive functions. Since the list implementation can be optimized for the particular processor, It turns out that the trade offs result in very fast execution.
Another is the fact that bottle necks can be optimized directly in assembler. This means that we only have to code one tiny fragment in assembler (very tedious and skill intensive) and leave the rest in "simple" high level forth.
Another less obvious contributor is the fact that if one only implements exactly what is needed, there is less code and logic to process. This is the real "skill", deciding what is needed and what is superfluous. At first I did TONS of redundant error checking, after a bit I figured out that checking once at "the key place" is all that's needed, then the task is determining "the key place". It gets to be like a puzzle, but has more of a pay-off than a crossword, etc.
Remember, a skilled coder can easily make something faster and possibly smaller in assembler, and a well written C compiler can often produce executables as good and better than forth, if used by a skilled developer. But just as SPIN allows many more less-than-expert users make very solid but slower code, forth allows us "less than expert" folks to produce results that approach the level of "assembler experts" without the years of "assembler on a single specific chip" investment.
EDIT - and, obviously, experts can do amazing things with forth, that they say would be difficult (if even possible) to do by other means.
Well, tried Forth back in the 80's and thought it was really cool.
Didn't get very far on my own, and had a hard time really getting to grips with it.
However it does seems to be a very uniquely fitting type of language for the uC arena.
Should be fun trying to get this going on my Gadget Gangster board.
Well, tried Forth back in the 80's and thought it was really cool.
Didn't get very far on my own, and had a hard time really getting to grips with it.
However it does seems to be a very uniquely fitting type of language for the uC arena.
PropForth comes out of the box with the SD card set to run on the Spinneret, the Gadget Gangster card uses different pins. I just added the above and comment out whichever I need to load.
Going through the regression test in the doc folder are a great way to get started in a nice incremental way. Just start at the beginning and go as far as you need or want to go.
Please note: The initial SD access is NOT FAT compatible by design. By eliminating the FAT compatibility requirement, the propforth SD driver is must faster and much more compact (than it would have been with FAT support). Access to the SD is through the prop chip only, like the internal memory of an iPhone is internal only. Caskaz might be implementing forth FAT support, but that would still be in development and an extension.
If one writes SD files with propforth and also with a PC, the two methods will appear to be unaffected by each other, and invisible to each other, until one steps on the other, and then it will appear to be crazy.
@Prof and Caskaz
I decided not to wait until Sal is back on deck, so I have made a temporary change to the Kernel. I can now run Ramblade on 4.6
It turned out to be a fairly trivial hack. It will do until Sal gets a chance to look at a better solution.
I have my tiny Editor working now in External memory (up to 512K sram) and can now work on the SD file system. I will post the code once the SD I/O system is working.
CasKaz, your SD system is very Forthish, (Block by Block ) if you know what I mean.
I can live with that and will use it for the Editor I/O, it is fast.
The only problem ATM is that I cannot write to external ram whilst the sd card it mounted. SD pins clk, sdi and sdo share three of the data lines d0, d1 and d2. External Ram is disabled whilst accessing the SD card in my xramdriver, but it looks like the sd card is always selected in the sd driver( or have I missed something). I would like the option of disabling the SD card whilst writing a to external ram, by deselecting the SD cs pin and reselecting after the external ram write. I can build that into the xramdriver but does this mean that I will have to re mount the SD card if I need to access the SD card after each external mem write? I think the answer is going to be yes, but being lazy, a quick answer might just save me wasting a day of my life ! )
@Prof and Caskaz
I decided not to wait until Sal is back on deck, so I have made a temporary change to the Kernel. I can now run Ramblade on 4.6
It turned out to be a fairly trivial hack.
Is this external RAM similar to the C3, that is, could this hack be applied there with equal ease?
Pins 24..31 are the data lines for external rsram on the Ramblade. Only Pins 22, 23 are available for I/O. See Config below.
Whilst you can download Propfoth.spin to eeprom via 31..30, when it boots there was no way to communicate with Propforth.
What I have done is changed the default pins (31,30) in the kernel so that when it boots the first time
Propforth I/O is via pins 22, 23.
RAMBLADE config
P0..18 Sram adr
P19 cs micro SDcard
P20 ce Sram and eeprom
P21 we Sram and eeprom there is a jumper on board to enable the eeprom, normally write disabled, read always.
P22,23 Serial port
P24 sdo
P25 sdi
P26 clk
P24..31 data lines to external sram NOTE that that P24..P26 are shared. Hence my query to Caskaz.
I decided not to go with C3 because the 64K sram was too small and spi ram would be too slow from random access. (IMO)
What do you want to do with C3 ? You can pretty well configure anything once you have the kernal booted.(Prof must have said that a thousand times LOL )
You will be able to run the editor on C3, I/O will default to 31,30. You will have to provide forth code to do read/write byte random. IT WILL BE DOCUMENTED.
I get little time to work on this stuff. From Monday I will be off air again until mid October, but then I am clear for three months.
Just a friendly reminder that even with Forth a second COG caching solution can be beneficial.
Using a cache can dramatically speed up access with any existing hardware solution. The encapsulation of the hardware access in a cache solution can also make any hardware more transparent and thus easier to connect to the system. The cache manager running in a secondary COG is not restricted to using bit-flipping with "andn bus, #$FF" + "or bus, data" for example. Other restrictions required of a single COG solution such as Z/C flag preservation may not be required. There are other advantages.
The Propeller GCC uses the same cache files can be used with xBasic. It would be nice to leverage the same API interface and files with another language like Forth if you find the API and PASM attractive.
I seriously considered a cache solution for C3, (when I read the threads) but decided not to add the extra degree of complexity and just consentrate on getting a text editor up on Ramblade and to do this with nothing more than a minimal boot kernel.
I have yet to see how small the kernel will end up being.
Then it will be up to individuals to expand the kernel to suit their own requirements.(and they will) Its a case of first things first.
BTW the GCC project seems to be gainig some traction now. I use GGC nowadays quite a bit, but don't understand the need for
C or C++ on a micro controller. Anyway that's an old debate and not for this thread
I'm interesting about your Ramblade.
Are there documents(curcuit diagram and codes)?
I can't solve your problem about Ramblade.
I merely made original sd_driver.
Sal made internal SD system. So I perfectly can't understand its system yet.
Well all this chatter piqued my curiosity. So I downloaded PropForth and loaded it onto my Propeller Platform. I've been able to add some numbers and do a hello world. It's kind of cool to telnet to a propeller chip.
Now the Forth image is in EEPROM and when I define new words I'm guessing they are stored in hub ram? When I save an image it copies hub ram back to EEPROM?
With C or Spin your source remains on a PC and you compile and download to the Prop. With Forth is the typical development done by creating new words and saving an image or file loading via the terminal program?
Now the Forth image is in EEPROM and when I define new words I'm guessing they are stored in hub ram?
When I save an image it copies hub ram back to EEPROM?
With C or Spin your source remains on a PC and you compile and download to the Prop.
With Forth is the typical development done by creating new words and saving an image or file loading via the terminal program?
1) New forth words are in hub ram, assembler definitions can be in COG memory (but this is a bit advanced usage)
2) SAVEFORTH writes the current forth dictionary from RAM into EEPROM
3) Forth development can be done via command line by typing definitions directly, or source code text files can be loaded into the command line. Either way the code is fed to the interpreter, and it compiles them into the dictionary.
The SDdriver takes control of the SDcard cs pin from the SDdriver cog . See the code in the SDdriver shown below.
_sd_cs_out_l \ select the card forever
Ramblade shares the SDcard pins sdi,sdo and clk with the external memory data lines. Therefore I need to deselect
the SDcard. ATM this can only be done from the SDdriver cog ( _sd_cs_out_h )or by stopping the SDdriver cog everytime
I want to write a block to external memory.
I will see what I can do to work around this problem, I could put the external sram driver in the same cog as the SDdriver
but that would slow down the xram access.
Most people keep Forth code on their PC in the form of a text file. Prof mentioned that in his reply (3), but if you use this method, and you should, then you must add fl to the top of your text file, then leave a couple of blank lines before you start your code proper. You can then just copy from your text file and paste it to the terminal (Free VT100 terminals AKA Tera Term or Putty are most commonly used by Forthers )
Saving words using saveforth are only used for words which you frequently use. Make sure the words are bug free if you use saveforth. Personally I only save words using saveforth for drivers which are applicable to my own system.
Thanks Ron and prof_braino. The development model sounds pretty similar to Spin, except that when the propeller boots, it boots into Forth, then the user downloads the program. But with Spin development the last program downloaded to the EEPROM starts running.
In any event I've written a few more toy programs and read through a few online Forth tutorials. I've also been looking through code included with the PropForth distribution. My head is spinning a bit, because the syntax is alien, but the concepts make sense. I can definitely see why words operating on a stack in cog ram would be faster than Spin byte codes fetched from hub ram which then operate on hub ram.
Does PropForth have anything like Spin's BS2 functions module? If so which file would be good to look through to get a feel for them?
I use trig pretty frequently for inverse kinematic transforms and odometry. Any built in words for that?
I would strongly recommend that you download Starting Forth by Leo Brodie.
It is a fun read with lots of exercises to test at the command line.
The speed issue is complex, but Forth is fast by any standards. If you could leave interpret out of the loop
then only PASM would beat it. The tokens that the word interpret returns are (in the case of primitives) the Cog address of the PASM code. I speak with forked tongue, it's not really quite that fast because there is quite a bit of house keep going which slows things up., but it stands up well against most languages.
There is less emphasis on extensive use of the stack now with multicore processors. The kernel is small so there is room (128 longs) at least plus the two stacks in each cog for variables.
Create your own words, e.g a debug routine.
: db st? key drop ;
Place db at any place in your code and you will see what’s on the stack, strike any key to continue.
Start another cog to run background stuff for example
: do_stuff ;
: background do_stuff ;
: start_cog4 c" background" 4 cogx ;
How simple is that ? start_cog4 from the current cog. No I didn’t check to see if cog4 was available, but its easy to check.
Go for it.
Cheers
Ron
Some say FORTH is for FUN
do_stuff would have use lockdict when accessing the dictionary, but great for flashing leds etc.
...similar to Spin, except that when the propeller boots, it boots into Forth, then the user downloads the program. But with Spin development the last program downloaded to the EEPROM starts running
You have it mostly right, the difference is propforth allows skipping the re-download of completed development, by saving it to the kernel image with saveforth.
During development, ones starts with the bare kernel, then downloads source. As each supporting word is designed coded, tested, and completed; there are saved to the boot image using saveforth.
This way, the kernel boots with you current set of extensions, and you only have to re-load the whole show in extreme cases, for example when you step on the eeprom image space.
When the final aaplication is complete, the onboot word can be tailored to launch your final app at power up.
With spin, the last program loaded starts at boot time. If that program was propforth.spin, then forth starts running. If the propforth image was extended ans saved with saveforth, then that image starts running.
I was trying something a bit crazy and it didn't work, but I think it might. So I'll explain and hope other people have a few ideas.
It occurred to me that PropForth allows you to program via a terminal, so RTS isn't needed as it is in Spin. In theory any comm link that supports Rx/Tx might be usable (e.g. bluetooth). The problem is that my 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.
Has anyone else tried bluetooth or XBee to PropForth?
The reason bluetooth would be handy is Android devices support bluetooth serial ports, so you could pair a propeller device to android.
Comments
The only exposure I've had to Forth was to work with some older robots. Forth was used extensively by an old robot company called Androbot. The TOPO II/III robots were programmed using Forth running on an Apple IIe computer with and IR link to tell the robot what to do. Their prototype BOB robots were based on the 8088 processor which had Forth built-in and would boot up and start running Forth. It was like a PC but instead of a standard BIOS it had Forth in ROM. I've been able to use some of the Forth definitions and routines and make a few tiny programs but there are some concepts I just don't fully understand. Perhaps some of the Forth experts out there can help me learn a bit more about Forth and help me unravel the mystery's still in the code of these old robots. I particular I'd like to understand the BOB code since it would help me revive that robot. Ideally if the higher level Forth routines can be isolated then perhaps I could eventually get that code to run on Propeller Forth and emulate the lower level stuff.
Any Forth experts out there want to help me out and convert someone new to Forth??
Robert
If anyone here finds something interesting that's not here email it to me and I will add to the folder
Anybody who has tried "converting" a program from one language into Forth, even if they are some kind of an expert, have met with discouraging results. The problem is that you end up trying to convert not just the syntax but the whole way of thinking which just does not translate.
Have you ever read book "Thinking Forth" which was Leo Brodie's second Forth book after the well known "Starting Forth"? Well, if you have then you will gain a little insight into not just Forth but also into how to view and approach problems and the merits of coming up with a simple solution rather than "use the library". Forth itself is very simple and easy, but it provides the foundation and building blocks on which you impress your "thinking" and does not artificially constrain you to a rigid syntax and structure common to conventional languages. Like a blank canvas and a palette of colors you are free to express yourself, if you let yourself express yourself freely.
I'm sure that to anyone reading this it sounds like a fairy story or something fanciful and not really true. The truth is that it is hard to describe and descriptions tend to be more of an understatement. I remember once many years ago I wanted to use a new type of PLD chip but the programmer for it was $$$$$ and the compiler for it was $$$$$ and so it didn't seem possible. But armed with a datasheet and odd bits of information about the device plus volumes 1, 2 &3 of the Fortran source code I sat down and analyzed both the sketchy in-circuit programming requirements plus what it would take to implement a compiler myself.
First off I did foolishly try to convert the source code into Forth but it became a horrible mess which just needed to be flushed down the sink. Then I thought, if I slightly rearrange the PLD source (not compiler) to fit in more with how Forth processes source then it should become more natural. So it was, and in ONE afternoon I had written a PLD compiler in Forth that took logic equations in and generated the "fuse" map files necessary to program the device. With a little interactive use of Forth on the chip itself I perfected the ICP routines and next day it was running. That is only one story.
Now, if you want to "try" Forth then please read the book and sit down with a blank canvas and paint it with Forth words that then becomes your robot language, what is most natural for it and you. Don't try to write lots of code and then expect it to run. Just interact and build up little tiny words (definitions) where the name of the word describes the functions and it's use such as " FAST FORWARD LEFT MOTOR" where each word does something that can be easily tested without those other words. This can then become "SLOW REVERSE RIGHT MOTOR" causing the robot in this instance to a quick turn. BTW, SLOW is just a constant as is REVERSE as is RIGHT which then pass parameters to the word MOTOR which performs the action. This is the power of stack based postfix notation if used well.
BTW again we could then implement a new word for a quick turn like this:
: QuickTurn ........ FAST FORWARD LEFT MOTOR ........ SLOW REVERSE RIGHT MOTOR ;
Typing in QuickTurn at the keyboard will execute the function as will typing the individual words. QuickTurn is now part of the "language", so it's not really the Forth language, it's your's and the robot's language. (The ........ 's are just there as the forum editor seems to cleanup white space)
I'm trying to keep this post short but it doesn't work, maybe I should write a book!
Thanks for your response! I have at least one of those Forth books (if not both of them) but there are still some concepts (screens and such) that haven't sunk it. It just hasn't clicked for me yet. I have found a definition called vocabulary that helped show some of the things that were defined in Forth. I've been basically avoiding Forth and when I had to add a brain to an old empty Androbot prototype I did most of the coding in C. I named my routines similar to the ones that would have been defined in Forth. For my purposes it worked out well. However, it would be nice to dig a little deeper into how each one of the Forth commands was defined to make sure I understand all the things each command could do. So, I can see a list of specific Forth definitions just for the robot and I've been able to create some new ones that leverage what is there. That part seems simple on the surface. Issues that throw a wrench in that is when you tell Forth to forget a definition or redefine one.
What I would rather do instead of converting all the Forth code to a different language would be to port the higher level Forth code over to another Forth system. So, all the higher level Forth code would stay the same. So, I could then in theory use a propeller running PropForth and use that as the main controller. With that I should be able to run any High level Forth programs as they are on the new controller. Although I read about Forth programming that is a point I never see covered. It isn't clear how that would be done.
If that is something that could be done then that would give me a real world application for Forth and a real reason to use it. My experience so far is that it isn't very portable but I hope I am wrong on that point.
So, if I wanted to use Prop Forth how would I go about making sure the lower level definitions get created and port over the higher level Forth definitions? That would be a good topic for a book and one that I would read!
Robert
If you use Forth exclusively on the new system you will be far more creative and enjoy the whole experience a lot more than sitting down coding and debugging which sometimes includes "debugging" the compiler.
A low level definition is very easy and the trick is to make sure no one word (definition) is more than a few lines long, less if possible. Sure, this might not be the case say with a CASE definition but for most words this should be possible. A low-level definition for a temperature sensor for instance can be tested first.....then written, simply because you can interact with the hardware at both a low and high level.
Do you understand your hardware? Good! Not sure about some aspects of it? No problem, exercise the hardware interactively and end up knowing more than the manufacturer's application engineers!
- Although long out of print, Brodie's "Starting Forth' can be gotten, used, through Amazon. Simply search on "Leo Brodie Starting Forth". I picked up a copy labeled "used, like new" for around $25 with shipping and it was as advertised.
- Brodie's "Thinking Forth" is available as a PDF at the link in my post #26 of this thread.
- I have been slowly working my way through the various essays and discourses by Chuck Moore and Jeff Fox that are also available at the above mentioned link. I have learned a lot about "thinking Forth" (note lower case t) in the essays about the early days of Forth and why various design decisions were made.
http://www.forth.com/starting-forth/
There is also a free copy of Thinking Forth here:
http://prdownloads.sourceforge.net/thinking-forth/thinking-forth-color.pdf?download
Now a question I think I read before, and in this thread.
How fast is PropForth in general, 1/3-1/2 of Spin?
http://forums.parallax.com/showthread.php?132995-Empty-Loop-Benchmarks&highlight=benchmark
As you can see, forth can be nearly as fast as assembler, despite being interpreted. This is achieved by several means.
One is using the stack instead of named variables when possible; this eliminates the overhead of memory fetch and memory store operations, and of memory address processing.
Another is the interpreter and dictionary architecture, the "words" in the dictionary are either "chunks of assembler" implementing the simplest functions, or a list of addresses of primitive functions. Since the list implementation can be optimized for the particular processor, It turns out that the trade offs result in very fast execution.
Another is the fact that bottle necks can be optimized directly in assembler. This means that we only have to code one tiny fragment in assembler (very tedious and skill intensive) and leave the rest in "simple" high level forth.
Another less obvious contributor is the fact that if one only implements exactly what is needed, there is less code and logic to process. This is the real "skill", deciding what is needed and what is superfluous. At first I did TONS of redundant error checking, after a bit I figured out that checking once at "the key place" is all that's needed, then the task is determining "the key place". It gets to be like a puzzle, but has more of a pay-off than a crossword, etc.
Remember, a skilled coder can easily make something faster and possibly smaller in assembler, and a well written C compiler can often produce executables as good and better than forth, if used by a skilled developer. But just as SPIN allows many more less-than-expert users make very solid but slower code, forth allows us "less than expert" folks to produce results that approach the level of "assembler experts" without the years of "assembler on a single specific chip" investment.
EDIT - and, obviously, experts can do amazing things with forth, that they say would be difficult (if even possible) to do by other means.
Didn't get very far on my own, and had a hard time really getting to grips with it.
However it does seems to be a very uniquely fitting type of language for the uC arena.
Should be fun trying to get this going on my Gadget Gangster board.
BTW, this guy also has an online copy of Starting Forth, that I find a bit easier on the eyes.
http://home.iae.nl/users/mhx/sf.html
Welcome to the fun!
If you have any questions specific to the prop forth kernel, there is a thread for for each release. Current one is
http://forums.parallax.com/showthread.php?133312-PropForth4.6-is-available-for-download
Please ask LOTS of questions, the target audience is kids on up (including parents), and some of the material is unnecessarily terse.
If you want to use the SD card on you Gadget Gangster, you'll need to make the following changes to the sd_driver.f file.....around line 114
PropForth comes out of the box with the SD card set to run on the Spinneret, the Gadget Gangster card uses different pins. I just added the above and comment out whichever I need to load.
Going through the regression test in the doc folder are a great way to get started in a nice incremental way. Just start at the beginning and go as far as you need or want to go.
If one writes SD files with propforth and also with a PC, the two methods will appear to be unaffected by each other, and invisible to each other, until one steps on the other, and then it will appear to be crazy.
I'll bookmark the thread too.
I decided not to wait until Sal is back on deck, so I have made a temporary change to the Kernel. I can now run Ramblade on 4.6
It turned out to be a fairly trivial hack. It will do until Sal gets a chance to look at a better solution.
I have my tiny Editor working now in External memory (up to 512K sram) and can now work on the SD file system. I will post the code once the SD I/O system is working.
CasKaz, your SD system is very Forthish, (Block by Block ) if you know what I mean.
I can live with that and will use it for the Editor I/O, it is fast.
The only problem ATM is that I cannot write to external ram whilst the sd card it mounted. SD pins clk, sdi and sdo share three of the data lines d0, d1 and d2. External Ram is disabled whilst accessing the SD card in my xramdriver, but it looks like the sd card is always selected in the sd driver( or have I missed something). I would like the option of disabling the SD card whilst writing a to external ram, by deselecting the SD cs pin and reselecting after the external ram write. I can build that into the xramdriver but does this mean that I will have to re mount the SD card if I need to access the SD card after each external mem write? I think the answer is going to be yes, but being lazy, a quick answer might just save me wasting a day of my life ! )
Ron
Is this external RAM similar to the C3, that is, could this hack be applied there with equal ease?
Pins 24..31 are the data lines for external rsram on the Ramblade. Only Pins 22, 23 are available for I/O. See Config below.
Whilst you can download Propfoth.spin to eeprom via 31..30, when it boots there was no way to communicate with Propforth.
What I have done is changed the default pins (31,30) in the kernel so that when it boots the first time
Propforth I/O is via pins 22, 23.
RAMBLADE config
P0..18 Sram adr
P19 cs micro SDcard
P20 ce Sram and eeprom
P21 we Sram and eeprom there is a jumper on board to enable the eeprom, normally write disabled, read always.
P22,23 Serial port
P24 sdo
P25 sdi
P26 clk
P24..31 data lines to external sram NOTE that that P24..P26 are shared. Hence my query to Caskaz.
I decided not to go with C3 because the 64K sram was too small and spi ram would be too slow from random access. (IMO)
What do you want to do with C3 ? You can pretty well configure anything once you have the kernal booted.(Prof must have said that a thousand times LOL )
You will be able to run the editor on C3, I/O will default to 31,30. You will have to provide forth code to do read/write byte random. IT WILL BE DOCUMENTED.
I get little time to work on this stuff. From Monday I will be off air again until mid October, but then I am clear for three months.
Ron
Just a friendly reminder that even with Forth a second COG caching solution can be beneficial.
Using a cache can dramatically speed up access with any existing hardware solution. The encapsulation of the hardware access in a cache solution can also make any hardware more transparent and thus easier to connect to the system. The cache manager running in a secondary COG is not restricted to using bit-flipping with "andn bus, #$FF" + "or bus, data" for example. Other restrictions required of a single COG solution such as Z/C flag preservation may not be required. There are other advantages.
The Propeller GCC uses the same cache files can be used with xBasic. It would be nice to leverage the same API interface and files with another language like Forth if you find the API and PASM attractive.
Cheers and thanks.
--Steve
I seriously considered a cache solution for C3, (when I read the threads) but decided not to add the extra degree of complexity and just consentrate on getting a text editor up on Ramblade and to do this with nothing more than a minimal boot kernel.
I have yet to see how small the kernel will end up being.
Then it will be up to individuals to expand the kernel to suit their own requirements.(and they will) Its a case of first things first.
BTW the GCC project seems to be gainig some traction now. I use GGC nowadays quite a bit, but don't understand the need for
C or C++ on a micro controller. Anyway that's an old debate and not for this thread
Keep rocking the boat LOL
Cheers
Ron
I'm interesting about your Ramblade.
Are there documents(curcuit diagram and codes)?
I can't solve your problem about Ramblade.
I merely made original sd_driver.
Sal made internal SD system. So I perfectly can't understand its system yet.
Now the Forth image is in EEPROM and when I define new words I'm guessing they are stored in hub ram? When I save an image it copies hub ram back to EEPROM?
With C or Spin your source remains on a PC and you compile and download to the Prop. With Forth is the typical development done by creating new words and saving an image or file loading via the terminal program?
2) SAVEFORTH writes the current forth dictionary from RAM into EEPROM
3) Forth development can be done via command line by typing definitions directly, or source code text files can be loaded into the command line. Either way the code is fed to the interpreter, and it compiles them into the dictionary.
Thanks for your reply.
The SDdriver takes control of the SDcard cs pin from the SDdriver cog . See the code in the SDdriver shown below.
_sd_cs_out_l \ select the card forever
Ramblade shares the SDcard pins sdi,sdo and clk with the external memory data lines. Therefore I need to deselect
the SDcard. ATM this can only be done from the SDdriver cog ( _sd_cs_out_h )or by stopping the SDdriver cog everytime
I want to write a block to external memory.
I will see what I can do to work around this problem, I could put the external sram driver in the same cog as the SDdriver
but that would slow down the xram access.
cheers
Ron
Most people keep Forth code on their PC in the form of a text file. Prof mentioned that in his reply (3), but if you use this method, and you should, then you must add fl to the top of your text file, then leave a couple of blank lines before you start your code proper. You can then just copy from your text file and paste it to the terminal (Free VT100 terminals AKA Tera Term or Putty are most commonly used by Forthers )
Saving words using saveforth are only used for words which you frequently use. Make sure the words are bug free if you use saveforth. Personally I only save words using saveforth for drivers which are applicable to my own system.
Cheers
Ron
In any event I've written a few more toy programs and read through a few online Forth tutorials. I've also been looking through code included with the PropForth distribution. My head is spinning a bit, because the syntax is alien, but the concepts make sense. I can definitely see why words operating on a stack in cog ram would be faster than Spin byte codes fetched from hub ram which then operate on hub ram.
Does PropForth have anything like Spin's BS2 functions module? If so which file would be good to look through to get a feel for them?
I use trig pretty frequently for inverse kinematic transforms and odometry. Any built in words for that?
I would strongly recommend that you download Starting Forth by Leo Brodie.
It is a fun read with lots of exercises to test at the command line.
The speed issue is complex, but Forth is fast by any standards. If you could leave interpret out of the loop
then only PASM would beat it. The tokens that the word interpret returns are (in the case of primitives) the Cog address of the PASM code. I speak with forked tongue, it's not really quite that fast because there is quite a bit of house keep going which slows things up., but it stands up well against most languages.
There is less emphasis on extensive use of the stack now with multicore processors. The kernel is small so there is room (128 longs) at least plus the two stacks in each cog for variables.
Create your own words, e.g a debug routine.
: db st? key drop ;
Place db at any place in your code and you will see what’s on the stack, strike any key to continue.
Start another cog to run background stuff for example
: do_stuff ;
: background do_stuff ;
: start_cog4 c" background" 4 cogx ;
How simple is that ? start_cog4 from the current cog. No I didn’t check to see if cog4 was available, but its easy to check.
Go for it.
Cheers
Ron
Some say FORTH is for FUN
do_stuff would have use lockdict when accessing the dictionary, but great for flashing leds etc.
Trig functions? Write your own. Forth is what you want it to be, there is plenty of words (definitions) around on the net to do what you want to do..
Cheers
Ron
You have it mostly right, the difference is propforth allows skipping the re-download of completed development, by saving it to the kernel image with saveforth.
During development, ones starts with the bare kernel, then downloads source. As each supporting word is designed coded, tested, and completed; there are saved to the boot image using saveforth.
This way, the kernel boots with you current set of extensions, and you only have to re-load the whole show in extreme cases, for example when you step on the eeprom image space.
When the final aaplication is complete, the onboot word can be tailored to launch your final app at power up.
With spin, the last program loaded starts at boot time. If that program was propforth.spin, then forth starts running. If the propforth image was extended ans saved with saveforth, then that image starts running.
It occurred to me that PropForth allows you to program via a terminal, so RTS isn't needed as it is in Spin. In theory any comm link that supports Rx/Tx might be usable (e.g. bluetooth). The problem is that my 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.
Has anyone else tried bluetooth or XBee to PropForth?
The reason bluetooth would be handy is Android devices support bluetooth serial ports, so you could pair a propeller device to android.