Seems quite a few think the Fignition reminds them of the Jupiter Ace.
Guess which computer was the inspiration to use FORTH on the Fignition...
(The FORTH on the Fignition is many times faster than the the one on the Ace, though, and is still being optimised)
The really big point about the Fignition is that it's a KIT that just about everyone can assemble themselves. There's even a 'Flint' version for Stripboard...
(When was the last time anyone hand-soldered a Arduino or Pie?)
That gives it an edge when it comes to teaching kids about electronics and computers.
No reason you can't hand solder an Arduino. I'm surprised there are no kits on offer. Or perhaps there are.
The Pi, no chance. But it still has some GPIO and stuff for such electronics tinkering, much like we were not expected to solder together our own C64's and such back in the.
Mind you I never had a C64 era machine. I soldered together a 6809 board from a kit...
There are a number of Freeduino kits available aimed at different markets. My favorites are the bare bones models that rely on external USB to TTL conversion as they are really cheap.
I just wish people would understand that Forth on the Propeller is not just an average exemplar of Forth. It is multiple cogs of Forth sharing a common dictionary, and you have 28 i/o pins that are easy to manipulate with concise timing.
Via Forth, I can deploy or stop cogs on command, and I can redeploy cogs on the fly. Using the Propeller becomes very interesting as resources can be changed in real-time from a dumb terminal.
I don't just write, compile, and load a program into the Propeller. I can run the Propeller for a certain task and then redeploy it for something entirely different. And therein lies a lot of creative power.
The Arduino has substantial limitations due to dedicated designations of i/o to Analog and Digital use, and it just has less i/o. The Raspberry PI, the Beagle Board, and that ilk have a GPIO interface that limits i/o access even further to less pins and less precise control unless you can master over-riding the OS you are using.
In sum, Forth on the Propeller is not only excellent Forth... but more powerful as it allows Forth to do more at a low level with greater speed.
I am not interested in going Retro with a Jupiter Ace replica of Forth. I am interested in deploying 32 bit Forth in a parallel processing set up that can do so much more than an AVR or Arm9 in specific small contexts. And I am interested in Forth to help me develop more knowledge of the realities of low level programing of the Propeller 1 and 2 chips.
I don't need or want Forth on everything. But, it really fits well with the Propeller .. like toast and jam.
For me, deciding on the cell size and the definitions for ! and @ was a no brainer, prof_braino. The Prop is a 32-bit device, so the obvious choice for the CELL size is 32 bits. ! and @ access 32-bit values in hub RAM. Cog RAM is accessed using cog! and cog@, just like in propforth. CREATE makes a dictionary entry. What unique feature of the Prop would require CREATE to do anything different than what other Forth interpreters do?
Long as default is a good choice, that's certainly one way to do it. Except HUB is word by default, but you've obviously dealt with that.
For create, this was a design decision, it saves significant dictionary space. You would have to check the prop datasheet and the propforth code for the interpreter details; I think it has something to do with the way the prop buffers the top stack element. Sal explained it a couple times but I can only follow so much. And I don't particularly care all that much at this point about minutia.
Remember, EVERY forth is different, all are valid. Even one the implements everything in the standard, even though the standard itself says doing so would be silly. The only thing that matters is what you want to do, and is the result stable enough for you purpose, and does it fit in the target hardware.
Nearly every useful forth deviates from the standard at some point, particularly on micro controllers. This only affects the degree to which generic intro materials can be used. The decision usually is to steer the implementation more toward final usefulness, rather than strict adherence to the standard or compatibility with one time use of generic study materials.
This is the part I don't understand. HUB RAM is accessed from COG with [RD|WR][BYTE|WORD|LONG] instructions. 8, 16 or 32 bits are all on the same footing, not one of them is preferred over the other or "default".
The natural size of anything in the Prop is 32 bits so whey would a CELL be anything else?
I agree with Dave Hein that Propforth always requiring W or L with @ and ! is confusing, as is the nonstandard create. Now I don't complain too loudly because Propforth is also free, but pfth being ANS compliant is a selling point.
The nonstandard ! @ , and create only become an advantage when application become large and/or complex beyond a certain point and in the context of particular applications. If ANSI compatibility is most important, obviously pfth is a good choice. But there is a risk (an eventuality) that one might encounter difficulties and limitations right when things start getting interesting, requiring redesign. Propforth was designed for the long game, and addressed this in advance. Whether this was good idea remains to be seen.
The natural size of anything in the Prop is 32 bits so whey would a CELL be anything else?
Something about memory foot print and limited resources; but again, my tiny mind can only paid attention for short period, thats as far as I got. I didn't DO the design, I only ask about it.
Forth may be wonderful. However all those advantages you mention are to do with the Propeller architecture not any particular language used on it.
@Heater
Nope you are wrong............. Forth provides the interpreted language which is much more useful than other interpreted languages on the Propeller.
I found a link for a embedded Forth, CamelForth, that works on the Z80 (and other microcontroller)s at http://www.camelforth.com/news.php.
I just made my 500th post .
Camel Forth is merely 8 bit and one processor. Also, you have to add an EEPROM and RAM chip to get it to work. I think you may have to add a UART as well to get the serial i/o. It is a 'big build' compared to using the Propeller... and for a very tiny sort of Forth.
Nope, all I said was that the advantages you pointed out were all to do with the Prop architecture not Forth, or any other language, in particular.
True. Says nothing about those of us who investigate first though:)
I will restate this... Forth offers an interactive mode of use for the Propeller... That is it's advantage. One doesn't have to 'write/compile/load' to observe the Propeller's behavior or results. There are only a few interpeted languages for the Propeller; Forth may well be the most powerful and most flexible.
It guess contempt is something that is hard for the non-Forth user to recognize.
Having an interactive environment on the Prop is a great feature. Especially if you want to be able to tinker with the Props programming without having a PC and tools available.
It's not a big sell to me as edit/compile/load from the Prop Tool or BST or SimpleIDE is plenty fast enough not to annoy me.
The interesting part of FORTH is that it is extensible and interpreted. This allows you to build a domain specific language for a problem and couple that with the interactivity via serial I/O. The downside is that the language must conform to FORTH's RPN syntax. Now you can do the same thing in C, but you need to build the parser and then the application. So FORTH seems to get you there a bit quicker. But you have to be willing to live with FORTH's idiosyncrasies.
I imagine other interactive dynamic languages (e.g. Javascript, Python, and Scheme) have similar potential, but none are as lean as FORTH.
edit/compile/load from the Prop Tool or BST or SimpleIDE is plenty fast enough not to annoy me.
If you are comfortable that process and enjoy working with those bounds, you definitely should stick with it and have little motivation to change. It takes a long, painful investment to get accustomed any tools process, and the external compiler process is one I could not become friends with. The compiler is always "doing things for me" that are not what I want, and those things that I should pay attention to, seem to get hidden and bite me later. This is particularly annoying when I'm reviewing other folks code, and they insist that because the compiler "took care of it", it is not worth their time to look at and understand, and bugs remain eternally unresolved. I get enough of that nonsense at work. It might be different if I only worked with experts of your caliber.
It can be true that a language system and/or it's compiler can hide a lot of things from the coder. After all that is why we make high level languages, to get the machine to do the boring and error prone stuff for us.
Languages like Spin and C hide very little. They compile and load fast enough on a small machine like the Prop to be interactive enough. Where Forth scores is in not needing the PC or tools available to work with your target.
Moving up we get to higher level languages like C++ and Java which hide a lot more from the coder and may catch him out if he is not intimately aware of how they work. Which is impossible in the case of C++ as the language has grown into something that no one can understand in it's entirety. I suspect the same is true of Java now a days. Not only that compile and/or load times start to get huge, interactivity is totally lost. Worst of both worlds.
I'm coming around to feeling that higer level languages like Python and Javascript are what I want. Were the edit-test cycle is a lot quicker and they offer much higher level features as well. You just have to keep performance issues in mind all the time.
Of course those languages are impossible to use in small systems where Forth is a winner if interactivity is what you want. But then we have come full circle and working on Propeller sized code in Spin or C gives you the fast edit-test turn around anyway.
As for the caliber of my expertise, it's just a pea shooter compared to many around here.
@all
I suppose I should admit that I have always had a bit of difficulty with compilers. While RPN stacks may be a challenge for some; compiled language requirements can be for others.
I loose track of where things are getting done, why some things can't be done, and others have to be done in a certain way.
Besides, with interactive programing, the experience is almost game like.
Since you can save everything and it is extensible... one might eventually grow up and comprehend compiled languages as well.
@Heater
Don't take me too seriously, I just have a different point of view about programing.
No worries Loopy, I hope we can share our different point's of view without getting to, shall I say "heated" about it. There is always something to learn in there.
Comments
Guess which computer was the inspiration to use FORTH on the Fignition...
(The FORTH on the Fignition is many times faster than the the one on the Ace, though, and is still being optimised)
The really big point about the Fignition is that it's a KIT that just about everyone can assemble themselves. There's even a 'Flint' version for Stripboard...
(When was the last time anyone hand-soldered a Arduino or Pie?)
That gives it an edge when it comes to teaching kids about electronics and computers.
The Pi, no chance. But it still has some GPIO and stuff for such electronics tinkering, much like we were not expected to solder together our own C64's and such back in the.
Mind you I never had a C64 era machine. I soldered together a 6809 board from a kit...
Via Forth, I can deploy or stop cogs on command, and I can redeploy cogs on the fly. Using the Propeller becomes very interesting as resources can be changed in real-time from a dumb terminal.
I don't just write, compile, and load a program into the Propeller. I can run the Propeller for a certain task and then redeploy it for something entirely different. And therein lies a lot of creative power.
The Arduino has substantial limitations due to dedicated designations of i/o to Analog and Digital use, and it just has less i/o. The Raspberry PI, the Beagle Board, and that ilk have a GPIO interface that limits i/o access even further to less pins and less precise control unless you can master over-riding the OS you are using.
In sum, Forth on the Propeller is not only excellent Forth... but more powerful as it allows Forth to do more at a low level with greater speed.
I am not interested in going Retro with a Jupiter Ace replica of Forth. I am interested in deploying 32 bit Forth in a parallel processing set up that can do so much more than an AVR or Arm9 in specific small contexts. And I am interested in Forth to help me develop more knowledge of the realities of low level programing of the Propeller 1 and 2 chips.
I don't need or want Forth on everything. But, it really fits well with the Propeller .. like toast and jam.
Forth may be wonderful. However all those advantages you mention are to do with the Propeller architecture not any particular language used on it.
Long as default is a good choice, that's certainly one way to do it. Except HUB is word by default, but you've obviously dealt with that.
For create, this was a design decision, it saves significant dictionary space. You would have to check the prop datasheet and the propforth code for the interpreter details; I think it has something to do with the way the prop buffers the top stack element. Sal explained it a couple times but I can only follow so much. And I don't particularly care all that much at this point about minutia.
Remember, EVERY forth is different, all are valid. Even one the implements everything in the standard, even though the standard itself says doing so would be silly. The only thing that matters is what you want to do, and is the result stable enough for you purpose, and does it fit in the target hardware.
Nearly every useful forth deviates from the standard at some point, particularly on micro controllers. This only affects the degree to which generic intro materials can be used. The decision usually is to steer the implementation more toward final usefulness, rather than strict adherence to the standard or compatibility with one time use of generic study materials.
This is the part I don't understand. HUB RAM is accessed from COG with [RD|WR][BYTE|WORD|LONG] instructions. 8, 16 or 32 bits are all on the same footing, not one of them is preferred over the other or "default".
The natural size of anything in the Prop is 32 bits so whey would a CELL be anything else?
The nonstandard ! @ , and create only become an advantage when application become large and/or complex beyond a certain point and in the context of particular applications. If ANSI compatibility is most important, obviously pfth is a good choice. But there is a risk (an eventuality) that one might encounter difficulties and limitations right when things start getting interesting, requiring redesign. Propforth was designed for the long game, and addressed this in advance. Whether this was good idea remains to be seen.
Something about memory foot print and limited resources; but again, my tiny mind can only paid attention for short period, thats as far as I got. I didn't DO the design, I only ask about it.
@Heater
Nope you are wrong............. Forth provides the interpreted language which is much more useful than other interpreted languages on the Propeller.
Camel Forth is merely 8 bit and one processor. Also, you have to add an EEPROM and RAM chip to get it to work. I think you may have to add a UART as well to get the serial i/o. It is a 'big build' compared to using the Propeller... and for a very tiny sort of Forth.
@Heater and Mindrobots
"Nothing bars learning as well as contempt prior to investigation...."
I will restate this... Forth offers an interactive mode of use for the Propeller... That is it's advantage. One doesn't have to 'write/compile/load' to observe the Propeller's behavior or results. There are only a few interpeted languages for the Propeller; Forth may well be the most powerful and most flexible.
It guess contempt is something that is hard for the non-Forth user to recognize.
It's not a big sell to me as edit/compile/load from the Prop Tool or BST or SimpleIDE is plenty fast enough not to annoy me.
I imagine other interactive dynamic languages (e.g. Javascript, Python, and Scheme) have similar potential, but none are as lean as FORTH.
If you are comfortable that process and enjoy working with those bounds, you definitely should stick with it and have little motivation to change. It takes a long, painful investment to get accustomed any tools process, and the external compiler process is one I could not become friends with. The compiler is always "doing things for me" that are not what I want, and those things that I should pay attention to, seem to get hidden and bite me later. This is particularly annoying when I'm reviewing other folks code, and they insist that because the compiler "took care of it", it is not worth their time to look at and understand, and bugs remain eternally unresolved. I get enough of that nonsense at work. It might be different if I only worked with experts of your caliber.
Languages like Spin and C hide very little. They compile and load fast enough on a small machine like the Prop to be interactive enough. Where Forth scores is in not needing the PC or tools available to work with your target.
Moving up we get to higher level languages like C++ and Java which hide a lot more from the coder and may catch him out if he is not intimately aware of how they work. Which is impossible in the case of C++ as the language has grown into something that no one can understand in it's entirety. I suspect the same is true of Java now a days. Not only that compile and/or load times start to get huge, interactivity is totally lost. Worst of both worlds.
I'm coming around to feeling that higer level languages like Python and Javascript are what I want. Were the edit-test cycle is a lot quicker and they offer much higher level features as well. You just have to keep performance issues in mind all the time.
Of course those languages are impossible to use in small systems where Forth is a winner if interactivity is what you want. But then we have come full circle and working on Propeller sized code in Spin or C gives you the fast edit-test turn around anyway.
As for the caliber of my expertise, it's just a pea shooter compared to many around here.
I suppose I should admit that I have always had a bit of difficulty with compilers. While RPN stacks may be a challenge for some; compiled language requirements can be for others.
I loose track of where things are getting done, why some things can't be done, and others have to be done in a certain way.
Besides, with interactive programing, the experience is almost game like.
Since you can save everything and it is extensible... one might eventually grow up and comprehend compiled languages as well.
@Heater
Don't take me too seriously, I just have a different point of view about programing.