@#$ Search function- Forth comparison thread
koehler
Posts: 598
OK, the Search function does not want to Search for Forth in titles, so....
Can anyone give an updated comparison of the Forth versions available on the Prop.
I've read many posts about all of them, however after a while they all seem to blend together.
I am thinking of sticking with an ANSI-compatible simply because I expect that would be easiest with all the documentation/samples around.
1 Speed- I understand Tachyon is the fastest in many cases, however does that require 'tricks' or ???
2 ANSI- I know there is variability on ANSI compatability, for the ones that are non-compliant, how 'non' is non?
3 Prop-customized Forth may also be a good place to start, since that is where I expect primarily be using it.
What are the most important Prop-customized benefits?
Interested in hearing from people who have experience in more than 1 version, and have picked one or another for any particular reason.
Can anyone give an updated comparison of the Forth versions available on the Prop.
I've read many posts about all of them, however after a while they all seem to blend together.
I am thinking of sticking with an ANSI-compatible simply because I expect that would be easiest with all the documentation/samples around.
1 Speed- I understand Tachyon is the fastest in many cases, however does that require 'tricks' or ???
2 ANSI- I know there is variability on ANSI compatability, for the ones that are non-compliant, how 'non' is non?
3 Prop-customized Forth may also be a good place to start, since that is where I expect primarily be using it.
What are the most important Prop-customized benefits?
Interested in hearing from people who have experience in more than 1 version, and have picked one or another for any particular reason.
Comments
Okay, I was waiting for someone else to say what they say so I will go ahead and say what I say. Tachyon is fast and there are no tricks and no inline assembly either, it's just fast but it's also very compact as all the core opcodes are a single byte. But TF doesn't even try to be ANSI, since the Prop itself is a very different beast from anything out there I simply made a Forth that took advantage of it and the tools. Some of the additions or adaptions are simply to make Forth more comfortable for Spin and Prop users and I make no bones nor apologies for choosing uppercase for actions or opcodes and lowercase for variables etc.
One of the most important aspects of TF is that I use it in real commercial product and projects so it has to perform, so it's not a pretty hobby Forth, you can do that with a PC. The other aspect is that the source is totally open and available and the kernel can be compiled in one keystroke, there are no converters to make it Spin tool friendly, it already is.
There are of course all the utilities I manage to cram in a standard system without any memory expansion tricks so that it can run real peripherals easily and implements my multifile FAT32 file system and Ethernet servers for HTTP, FTP, and TELNET plus room left for an actual application all in the standard 32K memory.
But if ANSI is more important than all this than TF is not the horse to ride.
A lot of times, I just add an *, (FORTH*), to the search term. This works with three letter searches also, (GPS). (The search function will not accept less than four letters.)
The best way to search is using Google. "Forth site:forums.parallax.com"
+1 "Darned" would have been appropriate.
Propforth is ANSI compliant in that the standards, all the way back to the originals, say something like:
"These are the expected words, and these are the expected ways to do things. ADJUST THESE AS NECESSARY per your particular hardware and application."
If you are missing a given word, even a core word? Are you non-compliant? NOT IF YOU NOTE THE DIFFERENCES.
The more words that are difernet, the more thingsyou have to remember when switching from one forth to another. How often do you switch from one forth to another? Unless you doing side by side comparisons, such as comparing Peter's threading model to Sal's, we seldom do. (At least I seldom do).
According to the "real" or "practical" standards, you do whatever is practical on a real processor. If you don't like a given implementation you are of course free to take or leave what ever currently exists, and make your own, which is what Dave did. And the result is also very popular, as we see from the number of folks using it.
Regarding Propforth, Propforth is as ANSI compliant as possible within the constraints of the prop hardware, and ALL execptions due to hardware are noted in the documentation. (As far as I know, if you find other I will add them, as always).
In practical terms, once you get started and see each difference ONCE, you move on and it becomes natural, like switching from a Chrysler to a Ford. No impact.
Propforth is written specifically for Sal's individual needs, which is maximum flexibility for long term project use on the prop, and able to take full advantage of ALL prop unique capabilities.
Tachyon is faster and probably smaller but may be limited when is comes to larger more complex applications.
Ptfh is 100% ANSI compliant in that is include every word listed in the standard, even the word you won't use (if I recall correctly) and can run nearly any forth example with no changes (please verify, I have not tried this)
Right tool for the right job.
Learning? From a previous familliarity with forth? Maybe Pfth is a good choice.
ME/EE, and you just want to interface to a couple devices, and time and speed are the only concerns? Maybe Tachyeon is a good choice.
Following along on Sal's automation and multitasking work; and Caskaz's driver and application work; or my kids roboitc class work? Maybe propforth is a good choice.
Me, I only use Propforth, but I talk to Sal every Sunday morning, and get all my questions answered from the source, and can steer or influence the overall project to some degree.
There are at least two other forths out there for the prop, but I don't know what their best use case would be.
What speed are we talking about anyway:
The real speed we are concerned with is time to flip and I/O pin, or to detect and I/O pin flip. The Prop clock speed limits this to 12.5ns. Propforth is specifically design to do this in all cases. Unless you the developer chooses to do something in between events to slow it down, that is one of the engineering design options available in forth.
Compliation/interpreation speed: This is limited by the baud rate of the serial connection. There are little bumps when a word is actually written into the dictionary, but this is a function of the memory speed. Propforth buffers the input stream (in an unused cog in the case of v5.5, there will be a more transparent method in v6) so you don't have to worry about the bumps OR the 64 byte pad (input buffer scrath area) size limitation. We typically load source code files many pages long, on the fly.
Execution speed: All the critical parts of propforth have been optimize in assemby. There is overhead for the forth interpreter, it is as fast as it possilby can go (as far as we can tell). If this is too great, we can further optimize a given routine to remove the forth interpreter overhead. Then we can have one cog wailing away on whatever time ciritical task you have. This will be the maximum speed of the prop. In this situation it makes no differnece which forth, or C, or PASM, because this all boils down to PASM (that you write per the current need).
In reality, the time of events we deal with on the prop are more or less either (a) clock speed or (b) user speed. The prop already does (a), and we usually don't find situations where (b) is an issue.
There is the case where we have to read and write large amounts of data to and from EEPROM or SD in a short time. In these case, we do the "engineering" part of embedded systems engineering, (i.e. the fun part) and figure out the best way to get the data we need where it needs to go in the time allotted. Or we determine that the size time contraints don't fit, (due to bandwidth of the EEPROM / SD) and adjust accordingly.
This the exent of my knowledge of the speed of the various forth options; that is, my knowledge is limited to a cursory (but mostly sufficient) understanding of propforth.
Tackyon's tricks are to have a serial interface that is half-resident with the Forth kernel, and half on a separate cog. Also, it has more than the usual two stacks that are original to Forth.
PropForth has its own tricks about how cogs can communicate between the terminal. Basically one cog is dedicated to the Terminal interface and 7 cogs have duplicate Forth kernels that can be switched on or off.
pfth is likely the easiest kernel to study the code, especially in versions in PASM of 1.00 or earlier. But it starts up in just one Cog, leaving other cogs to your imagination and deployed in a more formal way.
In all cases, it seems to me that Forth is significantly faster than SPIN.. but a bit slower than pure PASM. Which is the fastest is likely to start a huge debate.
I suspect you should consider whether you want to work with Peter J., Prof Braino, or Dave Hein when you get really stuck. And if you want to also learn ANSI Forth as provided these days for a regular computer in GForth. GForth can be used on Apples, Windows, and Linuxs.... and it is documented.
Customized Forth (such as Tackyon and PropForth) have their own different systems to deploy a new cog or to stop an old one in real-time. Actually, pfth can do this too; but it requires a bit more formal effort to do so.
Peter, thanks. Full ANSI isn't really required as I doubt I'll ever bother writing desktop apps I need, as Python or even VB would suffice for speed needs and HLL RAD.
Having additions targeting Prop directly are probably more useful in the long run. Not sure though if learning from Brodie/ANSI might be more useful simply as an educational excursion to begin with though.
Publison, thanks for the tip, I'm sure I'm not the only who has complained about that quirk.
Would it really be that hard to have that tip added directly to the Search page?
SRLM/Publison, I appreciate that younger folks may be looking at the site.
However, that sort of scrambled verbiage is used in Sunday comics, and honestly, its pretty innocuous compared to most of the everyday language school kids are exposed to every day at school.
Personally, and logically, I fail to see how it is any worse than danged/darned, which just replace an 'm' with one letter. There is a well known multi-meter Manf. that has 3 letters difference, that should be OK as well then?
Prof. Braino/Loopy, thanks very much for the opinions.
From my POV, it seems like it might be more useful to me, to start with Ptfh simply because it has a the backup of Brodie's books from which I would be re-learning.
I would think that after getting up to speed with the formal standard, it would somewhat easy to slip over to PropForth or TF if/when speed or ease of Prop-specific h/w use becomes an impediment.
Being able to use Gforth, or even better http://repl.it/languages/Forth or compileonline.com/execute_forth_online.php from a tablet on the couch/lazy-boy is rather attractive...
Thanks everyone, I think Ptfh is going to be where I will start for now.
I didn't make any particular statements about the other Forths but I will make some corrections to statements about Tachyon though.
First off, having a serial receive cog is not a trick, it's a peripheral and it is not responsible for making the Forth run faster.
Secondly TF is indeed smaller and faster but that does not make it limited to "more complex" applications as how many Forths or even Spin or C implementations for that matter have multifile FAT32 and Ethernet servers plus the whole "O/S" etc on a standard Prop?
Spare cogs are initialized with a TF kernel and put in an idle loop just awaiting a run address or else be overwritten by a coginit etc. The next update will include being able to load "OBEX" type modules from the top 32k of a 64k EEPROM at runtime.
Anyway, there is a lot of actual real world projects I have made available for anyone to get the feel of it and rather than being arcane it is very friendly, you never have to delve into machine code and the multiple stacks are normally transparent but make many more things possible.
That is really cool. We talked about this with propforth, but I never could explain how the use case would look. We couldn't decide what the "right way" to do it would be. I'll be interested to see how this works out.
I'm not exactly sure what the "more complex" is refering to either, but Sal had said something about it whe we where discussing differences between implementations. It might be something to do with the way propforth automation talks to the task on the PC side, or maybe I just didn't understand the statement. I probably said it wrong, I did not mean Tachyon was not for complex applications. I meant to express that Sal did it different because he's working towards something that needs that difference.
No offence taken, I just have to clarify the issue that the reader may imagine. I know Sal has designed PF to work with multiple Props or PCs/RPis whereas I want a no-holds-barred Forth both for minimal systems and for expanded systems but I'm not interested in offloading to external processing at this stage anyway.
BTW, the OBEX modules are essentially PASM binaries plus any other code necessary that can be loaded as if they were on an SD filesystem, so that the system could have a larger EEPROM or multiple EEPROMS, or an SD present for this. I will probably include serial Flash as well. I might be getting around to releasing this fairly soon too. The P16X64 version will be implemented as soon as I can get an FPGA binary and some time. I gave up on the original P2.2013 as that kept changing day by day until it no longer looked like a Prop.
But after a year or two, it is not really a big issue that Tackyon is non-standard. Sooner or later, you will really want to make the Propeller jump through its paces in a manner that it was intended to do so. ANSI standard Forth or C or Basic never had a vision of such a device. AND that is where all the fun comes in... it is so different and useful.
In sum, try all three and find the niche where you feel you are comfortable learning more about the Propeller.
These days I am studying GCC on the Propeller and while I can see its usefulness in big programs, Forth is really handy for fast and interactive programs. I also think it is a great way to begin to learn PASM in snippets as optimized Forth lexicon.
Good luck.