Heater, I think you need to be more specific about what code would need to be implemented. The articles in that issue of Byte contain various examples of Forth code that aren't complete programs. Can you provide a listing of the code that needs to be implemented? I think I can implement any of the Forth code in the articles under pfth. Some of it is an early version of Moore's work, but it can probably be implemented in the Forth interpreters that are available for the Prop. The real question is, how much effort would it take to implement it? Some interpreters will require more effort than others.
Peter, you're using my "inefficient" comment out of context. I said it was inefficient for implementing large stacks. For the small stacks used in Tachyon it is quite efficient. For many Forth applications there is really no need to have a stack greater than 10 entries, so I think the tradeoff you use for Tachyon is reasonable. There are cases where a deeper stack is needed, such as for recursion and large programs that have many embedded loops or a large calling depth.
I was curious how pfth compares to Tachyon, so I ran your benchmarks under pfth. The empty "do loop" is very slow compared to Tachyon. pfth takes 39.4us per loop. About 66 times slower. pfth implements DO and LOOP as fairly large COLON words, which makes it slow. Maybe I need to implement those as primitive kernel words.
The loop "do 0 drop loop" takes 41.0us per loop. Subtracting 39.4us yields 1.6us for the "0 drop" pair. This isn't too bad compared to the 1.2us time in Tachyon.
I wasn't worried about any "inefficient" tags being applied, I used the opportunity to show that doing one part of Forth an inefficient way can make the rest of it far more efficient etc. The 0 drop timing in your loop is about what I would expect as I made an estimate of what it would take if I implemented the stack in hub ram. A shuffled stack in cog ram vs an an indexed stack in hub has about the same execution time but the big big advantage of the cog stack is that not only is the stack in fast cog ram but instructions can directly address each stack element in a fixed and unchanging location which is ideal for the P1.
So it's the P1 that forces Tachyon to be different because even at the cog level the P1 is a very different beast from any other micro I have worked with.
I'm thinking that a hybrid stack might be even faster. Keeping the top 2 items in cog RAM speeds up unary and binary operators. Maybe the top 3 entries should be in cog RAM to handle ROT also. Putting the rest of the stack in hub RAM speeds up PUSH and POP operations, and allows for a larger stack. I'll have to investigate it a bit further.
The phrase "force it into the mold specified by FORTH's virtual machine" makes it sound to me as though implementations on different processors *would* be the same. Or maybe I'm not understanding what is meant by "FORTH's virtual machine".
If Forth were used for general-purpose computing then you would want the virtual machine to behave the same way. But in embedded uses just as we are inclined to use the CPU's assembler language and it's architecture and peripherals to get the most out of it then so too with Forth because as a "virtual machine" it behaves like a CPU with it's own instruction set. For Forth though to get the most out of the physical CPU it needs to be molded to suit as too are the applications to a lesser degree if at all.
BTW, Chuck was discussing very specialized applications as he always does, just look at the GA144 chip for instance.
Speaking of Byte ... some generous soul, obviously a glutton for punishment, at ATARI AGE, took it upon himself to scan, page by page, every issue of Byte on which he could get his hands. One mirror is located at http://malus.exotica.org.uk/~buzz/byte/pdf/.
I downloaded the Byte Forth Issue, August 1980, and then uploaded to my Forth Resources directory. Warning, it is a collection of images of 308 pages in PDF form, not your typical easily searchable PDF. The file is 212 MB.
Thanks for the link Brian, I clicked DownThemAll and grabbed the lot of them. I had downloaded some scans from somewhere before but here they all are. I even have a hardcopy of the December 76 issue and the March 78 issue, it's like gold. I remember those Sphere computer ads, I think they got into trouble and started to advertise bogus products.
as heater says all forths for the prop are slightly different. with the possible exeption being pfth, which might be ansii compatible, and might run something forth code that runs on the pc.
am i to understand that all for example c code will run on all c compilers for the prop? i know image craft when code from the DS00 laser range finder will not run on catalina or gcc. do all verions of basic on the prop run on every basic interpreter for the prop? or on any other basic?
im afraid i dont see the point, unless it is at the top of my head. but this "forth way" seems to be the of all computer languages and environments?
There must be thousands of assembly languages, all different. So no I don't count it as a language but as an uncountable many. That's the whole point, when you say "Forth" it's not clear what you actually mean.
Braino,
...am I to understand that all for example c code will run on all c compilers for the prop?
C is a very rigorously defined language. Beyond it's syntax and semantics it also has a array of defined functions that are supposed to be provided in any standards compliant implementation. That is how it is possible to move C code around between so many different machine architectures and operating systems.
All C code written to the C standards will compile and run on the Propeller (Within size and other hardware constraints). RossH is very fastidious about standards compliance. I see no reason why propgcc should be any less rigorous.
Of course in the messy real world of micro-controllers we find that compilers sprout their own extensions and differences as they make use of special device features. For example propgcc can compile C to raw prop instructions to run in a COG instead of LMM. Catalina cannot do that. There is no way my C version of FullDuplexSerial will work with Catalina.
So you are right, you can't just move projects from compiler to compiler if they use non-standard libraries and builtins or inline assembler or whatever.
However having that rock solid C standard as a base is incredibly helpful.
Ouch! What did I get myself into now? All I said was:
I bet none of the code in that "holy grail" article runs on any Forth we have been discussing on these threads:)
I was thinking int terms of things like the BYTE Unix benchmarks which are still runnable to this day on any computer that has a C compiler, including the Propeller.
Dave Hein,
...I think you need to be more specific about what code would need to be implemented...Can you provide a listing of the code that needs to be implemented?
Well, no. I don't have the article and have perhaps never even seen it:)
All anyone had to do was cut and paste the code into their preferred Forth system and run it.
The real question is, how much effort would it take to implement it? Some interpreters will require more effort than others.
I think that is what I'm always ribbing the Forth guys about and hence my off hand comment. There is no Forth:)
Anyway, I'm looking forward to eating humble pie when someone shows me to be wrong.
Must get back to building that parallel FFT I promised as a prize....
The phrase "force it into the mold specified by FORTH's virtual machine" makes it sound to me as though implementations on different processors *would* be the same. Or maybe I'm not understanding what is meant by "FORTH's virtual machine".
At the time, this may have been taken to mean the exact same forth environment would result on all hardware. What we've found is that A GIVEN AUTHOR could implement a similar environment on any hardware SHOULD CHOOSE to do so.
In reality, the starting kernel is much smaller than the complete environment. If forth is defined as the starting point to get me going, then yes, this is what we notice. But to say that everyone will always end up with DPANS94 on every microcontroller, or something as complete as FPC on and ATMEGA, is just a little bit of a stretch.
But we do usually something between the MOST basic 3 word forth (discussed elsewhere) and IE propforths start kerenel. From forth diverges depending on the hardware and target application, which only makes sense.
It's one of the few issues that I kept which also includes the Smalltalk and Lisp issues. I guess I'm a language geek!
Hi David, I did a lot of work in LISP and Smalltalk. I still have a Symbolics Lisp Machine in the Garage ... and the very first Smalltalk for PC which did fit on two 5 1/4" floppies, including sourcecode.
Do you remember the dates of those two issues. Then I don't have to download everything.
Thanks
So you are right, you can't just move projects from compiler to compiler if they use non-standard libraries and builtins or inline assembler or whatever.
However having that rock solid C standard as a base is incredibly helpful.
So by "rock solid" and "incredibly helpful" you mean "probably won't actually be portable even on the same hardware without extensive rework", exactly as with forth? Are we done with this topic now?
I only mention this since you keep repeating this nonsense ...
Firstly it is my observation so far that this language called Forth around here comes in many different flavors and none of them is able to run another's code. I am told that is the "Forth way".
.... as if it were different from any other computer language in this regard.
EIDT - OK, I saw you subsequent posts. Looking forward to more wore on parallel FFT! This is going to be useful on upcoming projects!
Hi David, I did a lot of work in LISP and Smalltalk. I still have a Symbolics Lisp Machine in the Garage ... and the very first Smalltalk for PC which did fit on 5 1/4" floppies, including sourcecode.
Do you remember the dates of those two issues. Then I don't have to download everything.
Thanks
BYTE language issues:
LISP: August 1979
FORTH: August 1980
Smalltalk: August 1981
LOGO: August 1982
So by "rock solid" and "incredibly helpful" you mean "probably won't actually be portable even on the same hardware without extensive rework"
No, I meant what I said. Those BYTE Unix benchmarks from the 1980's run out of the box on the Propeller under propgcc and Catalina (And Zog if you are a
masochist). My FFT is also usable across many compilers and machines without change. There are millions of other such programs. Not just in C of course but
in other well defined languages.
...exactly as with forth?
Did you just admit that Forth is not a well defined language and it's programs are not portable without extensive rework?:)
Are we done with this topic now?
Might be:)
Looking forward to more work on parallel FFT! This is going to be useful on upcoming projects!
Might take a little while. The FFT gave me a big enough headache in the first place and parallelizing it moves me on to serous migrane. How ever as penance for being such an argumentative and nit picking git recently I have promised to do it. If it's useful or not I have no idea.
My FFT is also usable across many compilers and machines without change. There are millions of other such programs. Not just in C of course but in other well defined languages.
Did you just admit that Forth is not a well defined language and it's programs are not portable without extensive rework?:)
I'm saying that a tool is a tool, and neither of these is "broken", these just have different uses.
I'm still not getting your point. Are you saying that your FFT runs on both Catalina and prop GCC with no changes? And that we can expect all programs to have the same results? The example I tried, an Image Craft compiler C program for the prop, did not work in either Catalina or prop GCC. AND I got a C expert to port it do either (his choice) and after a few hours he wandered away. Unfortunately, the only program I need is not one of the millions of programs that are completely portable.
By necessity, in forth we implement what ever we feel we need to to get a core kernel running in forth, and proceed from there. But we don't (can't) require everyone to implement for say text support to the extent one could run wordstar on every micro controller. Only pfth is heading in that direction, with its goal of "full ANSI compliance". One COULD to that, but in my case its a waste of effort until such time as I need to implement a word processor on my Jupiter ACE terminal, which may actually arise, but hasn't yet.
I still see not difference between the way forth selectively implements functions in the kernel, then adds to that kernel with extensions; and the way C implements a core set, and adds to it with libraries. The only difference (that I see) is that C is used for operating systems (and below) and forth is used for embedded systems (and above).
And the same applies to basic, LISP, PERL, etc. Just as assember is different on every processor, every implementation MUST be unique at some level, and can be made consistent at another level.
"Are you saying that your FFT runs on both Catalina and prop GCC with no changes?"
I believe that is true. RossH posted benchmark results from the fft_bench version. We ran it under propgcc, under Linux on a PC and ARM boards and on
XMOS devices with no changes. I have yet to try it on an AVR. The same should hold true for heater_fft.
My latest FFT in C is using features of the C99 standard and I'm not sure Catalina supports that, if not the changes required run compile it to an older standard are trivial.
And that we can expect all programs to have the same results?
No. As I said, once you start using functionality tailored to a particular device or operating system you are creating portability problems. Ideally a program would isolate all those system dependent things to a "hardware abstraction" module or modules that are easy to identify and tweak for a new platform. However many small programs don't do that. Perhaps they don't do that because that little abstractions has a performance penalty.
I still see not difference between the way forth selectively implements functions in the kernel, then adds to that kernel with extensions; and the way C implements a core set, and adds to it with libraries.
I agree not much difference at all. Except C has a syntax and semantics independent of the libraries where as Forth does not:)
By the way, I forgot to mention, whilst tweaking with the parallel FFT I wrote a version in Go, a language I think you were enthusing about. I must say I quite like it as well. I wanted to do this because Go has checks for out of bounds array accesses and it's very easy to recast a C program as a Go program. Have a look here: https://github.com/ZiCog/fftbench
Sadly we may never get Go on Propeller so an integer only FFT in Go is a bit pointless. No, wait a minute, there is a Go compiler based on GCC as used in propgcc, we might be in luck one day. Firing off COGs as goroutines would be very cool.
changes required run compile it to an older standard are trivial..
So you mean no you code is NOT directly portable, and in general source code of any language is not directly portable to any other platform or other environment on the same environment without at least some changes. And (I'm informing here) these changes are the same as required by forth, to move from one implementation to another. QED.
Unless you actually try at least one of these forths (propforth, Tachyon, pfth), your discussion comments will unfortunately continue to loose merit on this topic.
I say Heater should try parallel FFT in forth, THEN he will know something about forth, and his comments will carry the same weight in the context of forth as on all other subjects.
So you mean no you code is NOT directly portable, and in general source code of any language is not directly portable to any other platform or other environment on the same environment without at least some changes. And (I'm informing here) these changes are the same as required by forth, to move from one implementation to another. QED.
Unless you actually try at least one of these forths (propforth, Tachyon, pfth), your discussion comments will unfortunately continue to loose merit on this topic.
I say Heater should try parallel FFT in forth, THEN he will know something about forth, and his comments will carry the same weight in the context of forth as on all other subjects.
I think the difference is that in C the core language, data structures, types, control statements, expression and function syntax, etc are the same in all implementations of C. There may be differences in the libraries of different implemenations but there is almost certainly a basic set of functions that will be available everywhere. If you write a program that does simple console I/O, it is very likely that you'll be able to port it to another compiler/platform and it will work unchanged.
What is that core language in FORTH? Is there a useful subset of FORTH words that is available on all FORTH systems? What is it? I think the problem is that FORTH is *all* library and a minimal core language and the set of words that all FORTH implementations share (dup, drop, etc) may not be sufficient to write useful programs without having to resort to implementation-specific words.
Now, this isn't to say I think FORTH is bad. I think it is a very interesting language. It doesn't seem to be a language for writing portable code though.
Folks, this topic is getting old and taking up space in threads that really aren't related to it. This is a dis-service to Peter's contest.
If you must decide if Forth deserves to be called a language, if it really exists or not or if strictly a hoax carried on by Charles Moore to make people write funny looking code, then start a thread for the Great Forth Debate and go there to beat the horse.
No, the heater_fft and fft_bench are directly portable with no changes. If not that is a bug and can be fixed.
Unless you actually try at least one of these forths (propforth, Tachyon, pfth), your discussion comments will unfortunately continue to loose merit on this topic.
You are right. Can't argue with that. I will hence forth (Forth?) drop any campaigning for standards and portability in the Forth world. If time permits, I may one day have another look at Forth.
I say Heater should try parallel FFT in forth...
Heck, there is a challenge. I'd have a hard enough time getting a sequential version working. Might need you help some time...
I still see not difference between the way forth selectively implements functions in the kernel, then adds to that kernel with extensions; and the way C implements a core set, and adds to it with libraries. The only difference (that I see) is that C is used for operating systems (and below) and forth is used for embedded systems (and above).
Doug I think you have the wrong view of where C and Forth are used. C is used in almost every aspect of computing from low-level drivers to high-level GUIs. Of course object-oriented languages, such as C++ tend to be used more for things like GUIs. Most processors have a C compiler that provides functions and macros to access processor-specific features. C is commonly used for embedded systems (and above).
Forth implementations are divided into two segments -- standard Forth and machine Forth. There are various Forth standards, but the primary one is ANS Forth. Chuck Moore himself promotes ANS Forth through his company's product SwifthForth. Machine Forths are designed for a specific processor, and are generally smaller and faster than standard Forths. Tachyon is an excellant example of a machine Forth for the Prop that is very fast and compact. pfth is an example of a standard Forth. I'm not sure where PropForth fits. It's definately not a standard Forth, but it doesn't seem to have the speed and compactness attributes of a machine Forth.
Machine Forths are great for writing efficient code for a specific processor. However, the code is not portable to other processors. Standard Forth allows portability of code from one processor to another. I think Forth can be used effectively on small embedded systems, but I think it becomes cumbersome to use on larger applications. There are other languages that are a much better choice for large multi-developer projects.
There are really just two types of Forths -- machine Forth and standard Forth. Of course, there are lots of different machines, and each machine could have lots of different Forth implementations. There are a small number of Forth standards, with ANS Forth being the most widely accepted. Tachyon is an excellent machine Forth for the Prop. I'm hoping that some day pfth will become an excellent ANS Forth for the Prop.
There are really just two types of Forths -- machine Forth and standard Forth. Of course, there are lots of different machines, and each machine could have lots of different Forth implementations. There are a small number of Forth standards, with ANS Forth being the most widely accepted. Tachyon is an excellent machine Forth for the Prop. I'm hoping that some day pfth will become an excellent ANS Forth for the Prop.
Absolutely NOT!
Four Forths is one MOORE, and in no way equal to one whole.
I am not well enough informed to say that there are only two types of Forth, but I do think that some of the descriptions of Forth on the Propeller have been counter-productive.
First, I don't think that claiming your Forth is non-ANSI Forth compliant is helpful --- lets just say several versions of Forth on the Propeller take a Modernists approach to deploying Forth. And saying one's Forth is Minimalistic is a bit of hazard too. Let's just say that Forth on the Propeller seeks to optimize space constraints with a Reduced Forth Lexicon.
See.... it that so hard? ( Okay, I really realize that Peter will have none of this and jump in with a big BUT. but I tried.)
Comments
I wasn't worried about any "inefficient" tags being applied, I used the opportunity to show that doing one part of Forth an inefficient way can make the rest of it far more efficient etc. The 0 drop timing in your loop is about what I would expect as I made an estimate of what it would take if I implemented the stack in hub ram. A shuffled stack in cog ram vs an an indexed stack in hub has about the same execution time but the big big advantage of the cog stack is that not only is the stack in fast cog ram but instructions can directly address each stack element in a fixed and unchanging location which is ideal for the P1.
So it's the P1 that forces Tachyon to be different because even at the cog level the P1 is a very different beast from any other micro I have worked with.
by Forth inventor Moore
Sorry but that quote seems like gibberish to me. What does it mean? And who said it?
We could say the same about C or any other language could we not?
Not assembly
Or do you not count assembly as a language, is it just assembly like forth is just well forth.
If Forth were used for general-purpose computing then you would want the virtual machine to behave the same way. But in embedded uses just as we are inclined to use the CPU's assembler language and it's architecture and peripherals to get the most out of it then so too with Forth because as a "virtual machine" it behaves like a CPU with it's own instruction set. For Forth though to get the most out of the physical CPU it needs to be molded to suit as too are the applications to a lesser degree if at all.
BTW, Chuck was discussing very specialized applications as he always does, just look at the GA144 chip for instance.
Thanks for the link Brian, I clicked DownThemAll and grabbed the lot of them. I had downloaded some scans from somewhere before but here they all are. I even have a hardcopy of the December 76 issue and the March 78 issue, it's like gold. I remember those Sphere computer ads, I think they got into trouble and started to advertise bogus products.
am i to understand that all for example c code will run on all c compilers for the prop? i know image craft when code from the DS00 laser range finder will not run on catalina or gcc. do all verions of basic on the prop run on every basic interpreter for the prop? or on any other basic?
im afraid i dont see the point, unless it is at the top of my head. but this "forth way" seems to be the of all computer languages and environments?
There must be thousands of assembly languages, all different. So no I don't count it as a language but as an uncountable many. That's the whole point, when you say "Forth" it's not clear what you actually mean.
Braino, C is a very rigorously defined language. Beyond it's syntax and semantics it also has a array of defined functions that are supposed to be provided in any standards compliant implementation. That is how it is possible to move C code around between so many different machine architectures and operating systems.
All C code written to the C standards will compile and run on the Propeller (Within size and other hardware constraints). RossH is very fastidious about standards compliance. I see no reason why propgcc should be any less rigorous.
Of course in the messy real world of micro-controllers we find that compilers sprout their own extensions and differences as they make use of special device features. For example propgcc can compile C to raw prop instructions to run in a COG instead of LMM. Catalina cannot do that. There is no way my C version of FullDuplexSerial will work with Catalina.
So you are right, you can't just move projects from compiler to compiler if they use non-standard libraries and builtins or inline assembler or whatever.
However having that rock solid C standard as a base is incredibly helpful.
Have you heard of the BYTE magazine benchmarks from the 1980's? They run fin eon the Prop. http://code.google.com/p/byte-unixbench/
Probably not. BASIC was never very well defined and has morphed a lot over the years.
Dave Hein, Well, no. I don't have the article and have perhaps never even seen it:)
All anyone had to do was cut and paste the code into their preferred Forth system and run it. I think that is what I'm always ribbing the Forth guys about and hence my off hand comment. There is no Forth:)
Anyway, I'm looking forward to eating humble pie when someone shows me to be wrong.
Must get back to building that parallel FFT I promised as a prize....
At the time, this may have been taken to mean the exact same forth environment would result on all hardware. What we've found is that A GIVEN AUTHOR could implement a similar environment on any hardware SHOULD CHOOSE to do so.
In reality, the starting kernel is much smaller than the complete environment. If forth is defined as the starting point to get me going, then yes, this is what we notice. But to say that everyone will always end up with DPANS94 on every microcontroller, or something as complete as FPC on and ATMEGA, is just a little bit of a stretch.
But we do usually something between the MOST basic 3 word forth (discussed elsewhere) and IE propforths start kerenel. From forth diverges depending on the hardware and target application, which only makes sense.
Do you remember the dates of those two issues. Then I don't have to download everything.
Thanks
So by "rock solid" and "incredibly helpful" you mean "probably won't actually be portable even on the same hardware without extensive rework", exactly as with forth? Are we done with this topic now?
I only mention this since you keep repeating this nonsense ... .... as if it were different from any other computer language in this regard.
EIDT - OK, I saw you subsequent posts. Looking forward to more wore on parallel FFT! This is going to be useful on upcoming projects!
BYTE language issues:
LISP: August 1979
FORTH: August 1980
Smalltalk: August 1981
LOGO: August 1982
masochist). My FFT is also usable across many compilers and machines without change. There are millions of other such programs. Not just in C of course but
in other well defined languages. Did you just admit that Forth is not a well defined language and it's programs are not portable without extensive rework?:) Might be:) Might take a little while. The FFT gave me a big enough headache in the first place and parallelizing it moves me on to serous migrane. How ever as penance for being such an argumentative and nit picking git recently I have promised to do it. If it's useful or not I have no idea.
I'm saying that a tool is a tool, and neither of these is "broken", these just have different uses.
I'm still not getting your point. Are you saying that your FFT runs on both Catalina and prop GCC with no changes? And that we can expect all programs to have the same results? The example I tried, an Image Craft compiler C program for the prop, did not work in either Catalina or prop GCC. AND I got a C expert to port it do either (his choice) and after a few hours he wandered away. Unfortunately, the only program I need is not one of the millions of programs that are completely portable.
By necessity, in forth we implement what ever we feel we need to to get a core kernel running in forth, and proceed from there. But we don't (can't) require everyone to implement for say text support to the extent one could run wordstar on every micro controller. Only pfth is heading in that direction, with its goal of "full ANSI compliance". One COULD to that, but in my case its a waste of effort until such time as I need to implement a word processor on my Jupiter ACE terminal, which may actually arise, but hasn't yet.
I still see not difference between the way forth selectively implements functions in the kernel, then adds to that kernel with extensions; and the way C implements a core set, and adds to it with libraries. The only difference (that I see) is that C is used for operating systems (and below) and forth is used for embedded systems (and above).
And the same applies to basic, LISP, PERL, etc. Just as assember is different on every processor, every implementation MUST be unique at some level, and can be made consistent at another level.
XMOS devices with no changes. I have yet to try it on an AVR. The same should hold true for heater_fft.
My latest FFT in C is using features of the C99 standard and I'm not sure Catalina supports that, if not the changes required run compile it to an older standard are trivial. No. As I said, once you start using functionality tailored to a particular device or operating system you are creating portability problems. Ideally a program would isolate all those system dependent things to a "hardware abstraction" module or modules that are easy to identify and tweak for a new platform. However many small programs don't do that. Perhaps they don't do that because that little abstractions has a performance penalty. I agree not much difference at all. Except C has a syntax and semantics independent of the libraries where as Forth does not:)
By the way, I forgot to mention, whilst tweaking with the parallel FFT I wrote a version in Go, a language I think you were enthusing about. I must say I quite like it as well. I wanted to do this because Go has checks for out of bounds array accesses and it's very easy to recast a C program as a Go program. Have a look here: https://github.com/ZiCog/fftbench
Sadly we may never get Go on Propeller so an integer only FFT in Go is a bit pointless. No, wait a minute, there is a Go compiler based on GCC as used in propgcc, we might be in luck one day. Firing off COGs as goroutines would be very cool.
So you mean no you code is NOT directly portable, and in general source code of any language is not directly portable to any other platform or other environment on the same environment without at least some changes. And (I'm informing here) these changes are the same as required by forth, to move from one implementation to another. QED.
Unless you actually try at least one of these forths (propforth, Tachyon, pfth), your discussion comments will unfortunately continue to loose merit on this topic.
I say Heater should try parallel FFT in forth, THEN he will know something about forth, and his comments will carry the same weight in the context of forth as on all other subjects.
What is that core language in FORTH? Is there a useful subset of FORTH words that is available on all FORTH systems? What is it? I think the problem is that FORTH is *all* library and a minimal core language and the set of words that all FORTH implementations share (dup, drop, etc) may not be sufficient to write useful programs without having to resort to implementation-specific words.
Now, this isn't to say I think FORTH is bad. I think it is a very interesting language. It doesn't seem to be a language for writing portable code though.
Folks, this topic is getting old and taking up space in threads that really aren't related to it. This is a dis-service to Peter's contest.
If you must decide if Forth deserves to be called a language, if it really exists or not or if strictly a hoax carried on by Charles Moore to make people write funny looking code, then start a thread for the Great Forth Debate and go there to beat the horse.
Thanks!
Sincerely,
Someone who likes horses.
No, the heater_fft and fft_bench are directly portable with no changes. If not that is a bug and can be fixed. You are right. Can't argue with that. I will hence forth (Forth?) drop any campaigning for standards and portability in the Forth world. If time permits, I may one day have another look at Forth. Heck, there is a challenge. I'd have a hard enough time getting a sequential version working. Might need you help some time...
Forth implementations are divided into two segments -- standard Forth and machine Forth. There are various Forth standards, but the primary one is ANS Forth. Chuck Moore himself promotes ANS Forth through his company's product SwifthForth. Machine Forths are designed for a specific processor, and are generally smaller and faster than standard Forths. Tachyon is an excellant example of a machine Forth for the Prop that is very fast and compact. pfth is an example of a standard Forth. I'm not sure where PropForth fits. It's definately not a standard Forth, but it doesn't seem to have the speed and compactness attributes of a machine Forth.
Machine Forths are great for writing efficient code for a specific processor. However, the code is not portable to other processors. Standard Forth allows portability of code from one processor to another. I think Forth can be used effectively on small embedded systems, but I think it becomes cumbersome to use on larger applications. There are other languages that are a much better choice for large multi-developer projects.
Braino, mindrobots,
Oops sorry. OK, I'm done until I get some Forth under my belt.
Those of us who get it will never convince those who don't get it.
Take this argument somewhere else.
If the thread is about forth just leave it alone and go away.
Duane J
And that is alone while programmers have to argue about what it is.
Bye, bye
One Forth is one Forth, two Forths are two Forths, three Forths are three Forths. One must learn this profoundly.
There are really just two types of Forths -- machine Forth and standard Forth. Of course, there are lots of different machines, and each machine could have lots of different Forth implementations. There are a small number of Forth standards, with ANS Forth being the most widely accepted. Tachyon is an excellent machine Forth for the Prop. I'm hoping that some day pfth will become an excellent ANS Forth for the Prop.
Absolutely NOT!
Four Forths is one MOORE, and in no way equal to one whole.
I am not well enough informed to say that there are only two types of Forth, but I do think that some of the descriptions of Forth on the Propeller have been counter-productive.
First, I don't think that claiming your Forth is non-ANSI Forth compliant is helpful --- lets just say several versions of Forth on the Propeller take a Modernists approach to deploying Forth. And saying one's Forth is Minimalistic is a bit of hazard too. Let's just say that Forth on the Propeller seeks to optimize space constraints with a Reduced Forth Lexicon.
See.... it that so hard? ( Okay, I really realize that Peter will have none of this and jump in with a big BUT. but I tried.)