Further, can these 144 cores actually pump data out of one "hole", as it were, at video rates?
Heater: There was a crazy blog linked to the GreenArray site a year or two ago that documented some early experiments with the GreenArray chip. It boggled the mind what they were doing and how they were doing it. Video was the main focus of their experiments. I'll look for it again, and will link it here if I find it. To try and explain any more, from my dim recollection, simply wouldn't do it justice. It was amazing...especially the 'how' part.
The only authoritative sources I see are GreenArrays or the author of the Hack-A-Day project...all of us are just hoping and dreaming!
I remember Beau was talking about the efforts he went to to provide Vdd/Vss capacitance in the Prop2. Perhaps the GreenArray chip is so fast that all the important power supply decoupling takes place on the chip itself.
It has recently been explained to me that the Forth language does not exist. Rather it is whatever the implementer wants it to be at the time.
This has been rattling around in my head all day. It doesn't sound right. Doesn't this logic mean assembly doesn't exist either?
I would guess assembly (and FORTH) are dependent on the hardware architecture of target processor.
Anyway, forth only exists to the extent you believe it exits, or at least to the extent you think its useful. Beyond that, it doesn't matter if it exists or not since you either use it or you don't.
But arrayFORTH might prove a challenge to some. They say it takes a whole afternoon to learn how to use colorFORTH, which is the single core version. Google colorFORTH, try it on your oldest laptop, is insanely cool. Gave me a headache, too.
I tried a schmart board for the prop, and it worked. I even soldered it with my regular soldering tip, which was way too huge for surface mount. I was thinking I would just get good at soldering up these things, and if I didn't destroy too many, ask the recipients to work on a group project. Or at least contribute to the docs. I will not guarantee "pretty". Of course, the recipients will pay for parts and shipping, and beers if I ever meet up with them.
I've had a real love/hate relationship with the GA chip since I first heard about it. At first glance, it's fantastic! 1.5 ns per instruction times 144 processors equals something like 96 billion operations per second. OTOH, the reality is far more mundane. It takes four processors (potentially capable of 2 billion operations per second) just to interface with a PS/2 keyboard! It is both the best and the worst chip I have ever seen. The fact that more sophisticated applications (and application notes) by the design team are still works-in-progress is a sign (to me at least) that the chip is very difficult to exploit. Is it too communications-bound and memory-restricted ever to be a great success?...or even viable?
This has been rattling around in my head all day. It doesn't sound right. Doesn't this logic mean assembly doesn't exist either?
Well, of course thay all exist, as much as each other and a s much a s C for example.
What I meant my "Forth language does not exist" is that there is no Forth standard to which you can compare an implementation and say "this is Forth" or "this is not Forth" as you might with C, Ada, Java, etc etc. Rather there are "Forth like" things that all take on the same name without actually being language compatible.
Further it was put to me that "Forth" is more a philosophy than a particular language. I.e. just a guide or suggestion rather than a rigorous definition.
I would guess assembly (and FORTH) are dependent on the hardware architecture of target processor.
This is perhaps my big mistake. We accept that assemblers are architecture specific and hence all different. That is why high level languages were invented, to provide a common language usable on many different architectures. Hence the need for a standards or rigorous definitions of the language. I had assumed that Forth was such an HLL but now I'm told it is not. Well, that is what you have just said above.
Which is odd because in the opening pages of "Starting Forth" is the statement by Charles H. Moore
The first time I combined the ideas I had been developing into a single entity, I was working on an IBM 1130, a "third-generation" computer. The result seemed so powerful that I considered it a "fourth-generation computer language."
Which turns out to be non-sense or at least an extreme exaggeration.
Anyway would it be so hard for all Forths to be able to run the same syntax/semantics as defined in that book for example? I guess that is all I was expecting.
Yes, I do wonder what is going on with this device. 144 incredibly fast cores, but only 64 words of RAM each, surrounded by some serdes and analog I/O and GPIO. How on earth do you do anything with that?
Well, I have not delved into much at all but my immediate comparison is with an FPGA.
In an FPGA you have a pile of similar logic blocks that are very simple, they can just about perform logical, operations, AND, OR, NOR, NAND, XOR. They can provide latches and flip flops, perhaps addition/subtraction etc. They are all connected together in a matrix. The particular function of a logic block and the way it is connected up to others is determined by your configuration in away to perform some higher level functionality such as, well, being a CPU or other complex task.
When working with FPGA's you don't really deal with those logic blocks or their interconnection directly but rather work in a high level language like VHDL that allows you to describe the logic and pathways and timing you want in your design. That description is then compiled and synthesized into a configuration for an FPGAs logic blocks.
So, in the GA chip we might see those tiny processors as rather more sophisticated logic blocks than those found in FPGA. (but a lot less capable than a familiar CPU). Again the GA a chip has a matrix to connect it's logic blocks together.
Now, should you really be programming those individual logic blocks/cores by hand? Or rather should there be a high level language like VHDL to handle the thing as a whole? Can Forth perform the role of VHDL in this scenario?
I'm curious, If this beast is running without a clock how on earth are you going to get the accurate timing required for video?
Further, can these 144 cores actually pump data out of one "hole", as it were, at video rates?
Actually, there are two modes - clockless and asynchronous. The best answer I can come up with is is 'explore'. Contempt prior to investigation tends to bar discovery. If Columbus hated the sea, he never would have discovered America.
Like the Propeller, the thing is so different that one has to actually get to know it. It may be useless or it may make a very interesting solution to an auto-pilot for a quad-copter. Nearly all large array parallel processors do a lot of tiny tasks quickly at high speeds. That is what Nvidia does with 3-D display. So this is a potential opportunity to get into such with merely 144 parallel processors.
@Dr_Braino
Send me a private message for how you want to collect money and to exchange delivery info. I will buy 3 if you need that many to fill the minimum order of 10. But you can sell me less. If you don't want to bother with sending to Taiwan, please let me know as I can order the whole item directly from Schmartz Board. Either way, I have to pay extra for overseas delivery.
@Heater: The GA chip does indeed resemble an FPGA at first glance. But there are glaring and confounding differences, too. For one, a logic unit buried in the middle of a sea of logic units (in an FPGA), still has direct access to the outside world, if needed. In the GA, a node in the middle of the array has no communication with the outside world except by completely stymieing several other nodes for the duration of the communication. Seems to me the GA would have been better served by sharing I/O pins amongst nodes in much the way the Propeller does.
The GA's use of Forth seems like the very least of its problems, if indeed it is a problem at all. (I think it is a benefit, but I'm not looking to argue the point.)
The F18 Forth processor is a very interesting item (read the available PDFs). This chip has 144 of them in an 18x8 grid (not 12x12). It also provides two 18bit wide parallel ports.
I find the whole concept quite exciting as this is parallel processing, but without a hub - the architecture that the Propeller uses. Instead, each computer has i/o that takes from and feeds to adjacent processors Up/Down/Left/Right. Of course, corners have only 2 i/o ports and edges only have 3 i/o ports that lead to other processors. But the edge processors have other specialized functions to bring in and output data.
It is up to you to decide where and how the data moves through the 144 processors.
Besides all that, this is neither Harvard or Von Neumann architecture - it is a two-stack (aka Forth) architecture and one of only a few Forth processors that actually have Forth not as a virtual machine imposed on the more mainstream processors. The hardware documentation makes the whole concept of Forth much clearer that studying virtual machine code on some other platform.
I suspect if anyone really wants to investigate the utility of Forth, Forth in hardware is going to make a lot of attributes (both Pro and Con) much clearer. Being asynchronous/clockless, the device will just wait with very little power until i/o creates a change of state that requires processing.
It is all quite fascinating. But I need to ponder what I might actually want to do with it. It does seem ideal for some very intense bit banging or number crunching. 18 bits words might work well with Unicode, but I don't think the chip is really ideal for text based data processing.
I'm quite interested in playing with one of these but I'm not at all confident that I'll be able to successfully solder it onto the board. Let me know if you come up with a pre-soldered option.
Thanks,
David
Looks like qty 1 is available with a schmartboard.
I suspect that Forth is the most mis-understood of computer architectures, or is it computer languages? Or is it both? Maybe Forth was never really a language at all, just a two-stack machine. Just maybe, the languages should have had all their own separate names.
re: heater - no forth standard; all forths portable, etc -
There IS a standard, and it contains "standard functions, and optional optional. It turns out the re are only "three required" functions: i think they are read memory, write memory, access the stack.
Any forth with at least these three functions can be considered "forth". Anything with more than three can be considered "bigger forth". Anything that claims to comply with every word of the Dpans or ANSI standard and/or claims to be all things to all people and/or completely portable across all platforms can be considered suspect.
re: heater - no forth standard; all forths portable, etc -
there IS a standard, and it contains typical stuff, and optional stuff. It turns out the re are only "three. required" functions: i think they are read memory, write memory, access the stack.
any forth with at least these three functions can be considered "forth". anything with more than three can be considered "bigger forth". anything that claims to comply with every word of the dpans or ansi standard and/or claims to be all things to all people and/or completely portable across all platforms can be considered suspect.
That's interesting. Only three required functions. Can you show us a sample of a program written using only the required functions?
I really don't see why standardization is so important in forth.
Here's why in the most objective tone I can muster:
1) It is almost entirely based on the concept of creating user words/functions on the fly, saving, and loading them.
2) It is a stack based language which to me means that it tries to get closer to the metal than a mid to high level language.
3) Further refining 2, it doesn't seem possible to standardize the practice.
There may be other reasons, but I don't know since I'm not a forther.
Edit: well maybe i'm wrong on 3, I'll accept whatever the experts say.
Don't you also need : and ; so you can compile words?
I would think there are a few more but it's really not many before you can start using Forth to extend Forth. Once you are to that point, the sky's the limit.
It's interesting to look at Peter's early Tachyon kernel. You can see the rather small core of words he wrote in PASM before he started writing words in Tachyon byte code. There are many examples of threaded interpreted languages (Forth's language family, sortof) and see how little machine specific code is written before the language begins to be written in itself. Many Forth interpreter implementations follow this design: the minimum to get the thing going and then a file written in the language itself that starts extending it. That's part of the beauty I see in Forth, the ability to start very small and extend as needed, when needed, optimize as needed and trim unused parts as needed.
The rapid development of Peter's Tachyon is an excellent example of a Forth (Forth Family Language - FFL?) - it went very quickly from not existing to be a very functional, feature filled Forth implementation.
The F18 documentation has a rather short list of machine codes (5 bit op field) for hardware deployment of Fourth. Since this was created by Charles Moore, I'd have to say it is a rather good short list of Forth commands.PB003-110412-F18A.pdf
Yes, indeed! I see AND on the list.
For the guy that knows what he is doing, Forth seems to be extremely fast to deploy and quite useful; but for the rest of us, we can sit around and argue about languages and preferences and never get much done .
I guess Forth makes computers too simple, no OS and so on.
For the guy that knows what he is doing, Forth seems to be extremely fast to deploy and quite useful; but for the rest of us, we can sit around and argue about languages and preferences and never get much done .
If I had nothing better to do, I might enjoy a challenge to see how fast it would take me to learn forth.
Well, if you want to deploy ArrayForth to emulate the GA144 array, it seems that it only runs in Windows. And while it is based on ColorForth, don't bother with ColorForth as it only ran in DOS. Wikipedia has explaination of what ColorForth enhances, but I think you can no longer download it. It has been replaced by PolyForth.
And there are some new books on Forth for reading.
It just has an interesting vibe to it all - some attributes are very leading edge (like the GA144), others are very retro (like Leo Brodie's intoduction, Starting Forth).
I'm not having a downer on Forth, and I'm not digging at anybody but this whole debate is getting stranger and stranger. As such I would like to pursue it. If that's OK?
...there IS a standard, and it contains typical stuff, and optional stuff.
The obvious question is "where is that standard?" Can you give me a link to it so I can make a Forth of my own for whatever machine I have here?
It turns out the re are only "three. required" functions: i think they are read memory, write memory, access the stack.
This cannot be true, or if it is it's totally useless. What it says is that I can access memory or the stack, which is memory anyway. I can move data around but I cannot do any manipulations on it, like arithmetic or logical operations.
Worse still it says I cannot make decisions or create loops. The fundamental operations of computing, after the arithmetic or logical ops, are:
Sequence - as in "do this, then do that, then do the other..." to be executed in order.
Selection - as in "if someCondition do something else do someting different"
Iteration - as in "do something until some condition is reached"
Worse still it does not allow me to give names to a bunch of instructions,. I cannot define my own words. And that I thought was a big thing in Forth.
Now, I have open in front of me the online version of "Starting Forth" by Leo Brodie complete with a foreword by Charles Moore himself. The first piece of Forth we see in there is the definition of a word:
: WASHER WASH SPIN RINSE SPIN ;
Immediately we learn that ":" and ";" are fundamental to the language in order to define one thing in terms of other things, whatever they may be.
On the same page we see:
: STARS 0 DO STAR LOOP ;↵ok
Obviously a definition of a word that performs an iteration, "DO" and "LOOP" are a clue. Now that iteration construct cannot be defined in terms of anything less so I guess "DO" and "LOOP" are essential parts of Forth.
On the same page again we have:
3 4 +
Which apparently produces the result "7". So now we see that "+" is an essential part of the Forth language. (Unless it can be defined in terms of an "if" and a comparison which we have not seen yet).
And so on, I'm sure I will find an "if" in there at some point.
So if that book is not setting a standard what on earth is?
I really don't see why standardization is so important in forth...
1) It is almost entirely based on the concept of creating user words/functions on the fly, saving, and loading them...
I have no qualms with that idea of infinite, on the fly, flexibilty. Sound great. However the means to create those user word/functions must be standardized in the language itself. If not we have no way of exchanging programs between different machines or different humans for that matter.
2) It is a stack based language which to me means that it tries to get closer to the metal than a mid to high level language.
No. Clearly the Propeller, and other machines, have no built in stack handling hardware. If you want a stack you have to make one in software. As such Forth is far away from the metal. Besides, pretty much all languages are dependent on a stack one way or another.
If the absolute minimum required for the user to define Forth words is standardized you can always ship those definitions with your application, indeed they are part of the application.
No. Clearly the Propeller, and other machines, have no built in stack handling hardware.
Other languages don't even try to expose the stack even though that's what is generally done internally. Being forced to think stack is what separates forth from most other languages except major ASM coding as a matter of choice for modularity.
Other languages don't even try to expose the stack...
Hmmm.... I see what you mean but it's not so cut and dried to me.
In C you learn that it's a bad idea to return pointers to local variables from a function. They may not be valid after the function returns. Why? Well they don't say "because those variables are on the machines stack along with return addresses etc and will be clobbered by subsequent function calls". No they just talk about "scope" and "automatic variables". Then you learn about recursive function calls. Well how is that supposed to happen without a stack somewhere?. And as it happens that implied stack need not be anything to do with the machines hardware stack, although it normally is.
Conversly, in Forth the stack is emphasized. This is nothing to do with being "close to the metal". It's just a model of how the language works. Again that need not be the actuall machines hardware stack. Especially if it does not have hardware stack support. How do I know that when I write "4 2 +" that those numbers are not kept in registers or on the heap? As a HLL that really should not concern me. It's just a conceptual model. Why should we not have Forth code running in a COG, which has no stack, for example?
There are a certain number of words that you need to have in the kernel (and should be standard) in order to get a Forth environment up and running to the point where you can start adding words and extending the language. There are a handful of compiling words and dictionary words that should be there, the basic stack manipulation words should be there, basic arithmetic support, etc. Beyond that core (and it should be a standard core of words), you could consider everything else to be "application" versus kernel. If you don't need to add (for some strange reason), you could leave the definition for plus '+' out of the kernel. If you needed some things to be very fast, you could build them into the kernel. As you develop your application, you could make changes to what is in the kernel and what is added application vocabulary.
I'm basing this on Peter's Tachyon Forth VM because it was handy.
In fewer than 1000 lines of PASM, Peter came up with rather robust Forth Kernel that covers all the basics plus because of his goal for speed and size, added a large number of PASM defined words to support the Propeller hardware (I/O and COGs) and other features he knew from experience should be fast and coded in PASM. After he wrote the kernel in PASM, he switched to defining additional words in terms of the Forth byte codes for the PASM primitives he defined. For the most part, these bytecode based definitions could be moved to external files and added in as parts when/if he needed the words. At one point, Peter changed the : compiling word to pri and pub so it would be more readable by Spin programmers!
In the short life of Tachyon, he has a fast, powerful, feature packed Forth interpreter/compiler/environment. If he wants to take Tachyon to another hardware platform, he rewrites the 100 lines of PASM, adjusts anything he needs to adjust for architecture (COG and I/O) portions and he's got Tachyon on a new micro. Obviously, the smaller you keep that PASM kernel, the easier it is to change architectures. Your application files (.fth, .f, .whatever) should all run on your Tachyon. Will they carry over directly to PropForth? No, but they can be changed as needed or depending on what you are missing, you can create it in PropForth as words to extend PropForth to do some things like Tachyon.
Is it a universal as porting C code? Probably not, because you never have to change anything in a C application when you port it, right? Just recompile and run.
Is it as easy as moving an application from say the AIX version of UNIX to HP/UX? Certainly not, because they're both UNIX, right?
So back to the thought here: Yes, there needs to be a core of words that defines Forth to the point that you can extend Forth and build your application on it. Should they be globally known an excepted? Sure! Are they? Kind of, sort of mostly.....
Is it productive? Forth people say it is, non-Forth people say it isn't.
If you don't try it, you'll never know if you like it.
Some folks will never like it, some folks will never try it.
People are funny that way. I've programmed in many different languages for fun and money. For some reason, Perl and I just don't get along. I use it, I've written small tools with it, I've taken classes and read books and something just won't click for me. I even see the power and beauty in it but my mind just won't accept it without a struggle. Would I sit down and play with Perl for fun? No. Would I sit down and play with Forth for fun? Sure!
OK, everybody, back to your corners for the next round!!
Other languages don't even try to expose the stack even though that's what is generally done internally. Being forced to think stack is what separates forth from most other languages except major ASM coding as a matter of choice for modularity.
There are discussion with Charles Moore about the stack. One big reason for that is because he despises local variables. Globals are fine but if you need locals, then the rod you've defined is too complex and should be factored. If the stack is to deep and you need to rummage through it to find the value you need to work on, then the word is too complex and should be factored. On machines that support a stack, the kernel implementation is nice and fast because you have a one to one relationship between a Forth Push and a hardware Push to the stack, so Forth stack manipulation words become faster and are closer to the machine.
It's a language abstraction for the most part and a philosophy thing. I keep meaning to look and see which of the machines Moore first did Forth for actually had a hardware stack.
There are a certain number of words that you need to have in the kernel (and should be standard) in order to get a Forth environment up and running to the point where you can start adding words and extending the language.
Thank you, yes, I suspected as much. Now all I need to do is identify that minimal system and I'll finally have found the "real Forth".
Charles Moore ...despises local variables. Globals are fine...
And there he stands in defiance of all the percieved wisdom and best practice in programming language design since ever we had high level languages.
That's interesting. Only three required functions. Can you show us a sample of a program written using only the required functions?
I was looking for the link all day, I thought it was Brad Rodrigez but maybe it was Frank Sargent. Anyway, one of those forth guys was writing about "when is it a forth". Because we always have to start with assembler or some other language, and start wrting something until we have a a forth that scan re-generate itself; at that point we can use forth to write the improvements (very quick dev time, and interactive). The author showed that once we can do those three functions, we can use them to make more functions, like placing opcodes in memory to make more forth definitions, and build the dictionary till we have a useable forth.
This in fact is always does when one write a new forth, so there's your example. When Sal wrote propforth, he started with spin, and implemented a crude dictionary and interpreter, then used that to make an "improved" version. Right now, propforth generates spin code to make the next version. Sal does this to take advantage of the spin interpreter to resolve forward references, etc. But most folks couldn't write the current propforth in spin from scratch, not even Sal. If you don't have this kind of tool, and you have to use assembler, you try to get away from writing in assembler as quick as possible, since coding is so slow (for regular people, assembler experts just do everything n assembler anyway and wouldn't use forth). So when do you have a "real forth"? Some folks say "when it can re generate its own kernel", some say "when you can read and write to memory".
By the first definition, propforth is still not forth, as propforth must generate spin code, and the spin tool generates the kernel image we load. By the second definition, almost anything can be considered forth. I don't particularly care either way, just as long as its fun.
while it is based on ColorForth, don't bother with ColorForth as it only ran in DOS. Wikipedia has explaination of what ColorForth enhances, but I think you can no longer download it. It has been replaced by PolyForth.
AFAIK - PolyFORTH is (was?) Forth Inc commercial product, you have to pay lots for it and it is hard to get.
If anyone can find this as a free download, its great. Otherwise, avoid it until you can make somebody else pay for it.
But Frank Sargent's pygmy Forth is pretty close to polyforth, maybe better, and runs on the PC. http://pygmy.utoh.org/forth.html
Comments
Heater: There was a crazy blog linked to the GreenArray site a year or two ago that documented some early experiments with the GreenArray chip. It boggled the mind what they were doing and how they were doing it. Video was the main focus of their experiments. I'll look for it again, and will link it here if I find it. To try and explain any more, from my dim recollection, simply wouldn't do it justice. It was amazing...especially the 'how' part.
This has been rattling around in my head all day. It doesn't sound right. Doesn't this logic mean assembly doesn't exist either?
I would guess assembly (and FORTH) are dependent on the hardware architecture of target processor.
Anyway, forth only exists to the extent you believe it exits, or at least to the extent you think its useful. Beyond that, it doesn't matter if it exists or not since you either use it or you don't.
But arrayFORTH might prove a challenge to some. They say it takes a whole afternoon to learn how to use colorFORTH, which is the single core version. Google colorFORTH, try it on your oldest laptop, is insanely cool. Gave me a headache, too.
I tried a schmart board for the prop, and it worked. I even soldered it with my regular soldering tip, which was way too huge for surface mount. I was thinking I would just get good at soldering up these things, and if I didn't destroy too many, ask the recipients to work on a group project. Or at least contribute to the docs. I will not guarantee "pretty". Of course, the recipients will pay for parts and shipping, and beers if I ever meet up with them.
Well, of course thay all exist, as much as each other and a s much a s C for example.
What I meant my "Forth language does not exist" is that there is no Forth standard to which you can compare an implementation and say "this is Forth" or "this is not Forth" as you might with C, Ada, Java, etc etc. Rather there are "Forth like" things that all take on the same name without actually being language compatible.
Further it was put to me that "Forth" is more a philosophy than a particular language. I.e. just a guide or suggestion rather than a rigorous definition.
This is perhaps my big mistake. We accept that assemblers are architecture specific and hence all different. That is why high level languages were invented, to provide a common language usable on many different architectures. Hence the need for a standards or rigorous definitions of the language. I had assumed that Forth was such an HLL but now I'm told it is not. Well, that is what you have just said above.
Which is odd because in the opening pages of "Starting Forth" is the statement by Charles H. Moore Which turns out to be non-sense or at least an extreme exaggeration.
Anyway would it be so hard for all Forths to be able to run the same syntax/semantics as defined in that book for example? I guess that is all I was expecting.
Yes, I do wonder what is going on with this device. 144 incredibly fast cores, but only 64 words of RAM each, surrounded by some serdes and analog I/O and GPIO. How on earth do you do anything with that?
Well, I have not delved into much at all but my immediate comparison is with an FPGA.
In an FPGA you have a pile of similar logic blocks that are very simple, they can just about perform logical, operations, AND, OR, NOR, NAND, XOR. They can provide latches and flip flops, perhaps addition/subtraction etc. They are all connected together in a matrix. The particular function of a logic block and the way it is connected up to others is determined by your configuration in away to perform some higher level functionality such as, well, being a CPU or other complex task.
When working with FPGA's you don't really deal with those logic blocks or their interconnection directly but rather work in a high level language like VHDL that allows you to describe the logic and pathways and timing you want in your design. That description is then compiled and synthesized into a configuration for an FPGAs logic blocks.
So, in the GA chip we might see those tiny processors as rather more sophisticated logic blocks than those found in FPGA. (but a lot less capable than a familiar CPU). Again the GA a chip has a matrix to connect it's logic blocks together.
Now, should you really be programming those individual logic blocks/cores by hand? Or rather should there be a high level language like VHDL to handle the thing as a whole? Can Forth perform the role of VHDL in this scenario?
Actually, there are two modes - clockless and asynchronous. The best answer I can come up with is is 'explore'. Contempt prior to investigation tends to bar discovery. If Columbus hated the sea, he never would have discovered America.
Like the Propeller, the thing is so different that one has to actually get to know it. It may be useless or it may make a very interesting solution to an auto-pilot for a quad-copter. Nearly all large array parallel processors do a lot of tiny tasks quickly at high speeds. That is what Nvidia does with 3-D display. So this is a potential opportunity to get into such with merely 144 parallel processors.
@Dr_Braino
Send me a private message for how you want to collect money and to exchange delivery info. I will buy 3 if you need that many to fill the minimum order of 10. But you can sell me less. If you don't want to bother with sending to Taiwan, please let me know as I can order the whole item directly from Schmartz Board. Either way, I have to pay extra for overseas delivery.
Can't argue with that. But there is a lot of ground to cover and I'm happy to let a scouting party get there first and report back in this case:)
The GA's use of Forth seems like the very least of its problems, if indeed it is a problem at all. (I think it is a benefit, but I'm not looking to argue the point.)
I find the whole concept quite exciting as this is parallel processing, but without a hub - the architecture that the Propeller uses. Instead, each computer has i/o that takes from and feeds to adjacent processors Up/Down/Left/Right. Of course, corners have only 2 i/o ports and edges only have 3 i/o ports that lead to other processors. But the edge processors have other specialized functions to bring in and output data.
It is up to you to decide where and how the data moves through the 144 processors.
Besides all that, this is neither Harvard or Von Neumann architecture - it is a two-stack (aka Forth) architecture and one of only a few Forth processors that actually have Forth not as a virtual machine imposed on the more mainstream processors. The hardware documentation makes the whole concept of Forth much clearer that studying virtual machine code on some other platform.
I suspect if anyone really wants to investigate the utility of Forth, Forth in hardware is going to make a lot of attributes (both Pro and Con) much clearer. Being asynchronous/clockless, the device will just wait with very little power until i/o creates a change of state that requires processing.
It is all quite fascinating. But I need to ponder what I might actually want to do with it. It does seem ideal for some very intense bit banging or number crunching. 18 bits words might work well with Unicode, but I don't think the chip is really ideal for text based data processing.
Why Forth still matters in this ARM/Linux/Android world
Again, it's another version of Forth under the Forth Family of Languages and another insight into why one might use Forth.
Maybe it's like broccoli - for some people, there isn't enough cheese sauce in the world to make it edible!
Speaking of broccoli, has anyone tried the GA144 simulator that is supposed to be in ArrayForth (or maybe PolyForth, now)?
Looks like qty 1 is available with a schmartboard.
http://www.schmartboard.com/index.asp?page=products_csp&id=532
These are pretty easy to solder. I did two Propeller boards with no rework.
I suspect that Forth is the most mis-understood of computer architectures, or is it computer languages? Or is it both? Maybe Forth was never really a language at all, just a two-stack machine. Just maybe, the languages should have had all their own separate names.
There IS a standard, and it contains "standard functions, and optional optional. It turns out the re are only "three required" functions: i think they are read memory, write memory, access the stack.
Any forth with at least these three functions can be considered "forth". Anything with more than three can be considered "bigger forth". Anything that claims to comply with every word of the Dpans or ANSI standard and/or claims to be all things to all people and/or completely portable across all platforms can be considered suspect.
Here's why in the most objective tone I can muster:
1) It is almost entirely based on the concept of creating user words/functions on the fly, saving, and loading them.
2) It is a stack based language which to me means that it tries to get closer to the metal than a mid to high level language.
3) Further refining 2, it doesn't seem possible to standardize the practice.
There may be other reasons, but I don't know since I'm not a forther.
Edit: well maybe i'm wrong on 3, I'll accept whatever the experts say.
Don't you also need : and ; so you can compile words?
I would think there are a few more but it's really not many before you can start using Forth to extend Forth. Once you are to that point, the sky's the limit.
It's interesting to look at Peter's early Tachyon kernel. You can see the rather small core of words he wrote in PASM before he started writing words in Tachyon byte code. There are many examples of threaded interpreted languages (Forth's language family, sortof) and see how little machine specific code is written before the language begins to be written in itself. Many Forth interpreter implementations follow this design: the minimum to get the thing going and then a file written in the language itself that starts extending it. That's part of the beauty I see in Forth, the ability to start very small and extend as needed, when needed, optimize as needed and trim unused parts as needed.
The rapid development of Peter's Tachyon is an excellent example of a Forth (Forth Family Language - FFL?) - it went very quickly from not existing to be a very functional, feature filled Forth implementation.
Yes, indeed! I see AND on the list.
For the guy that knows what he is doing, Forth seems to be extremely fast to deploy and quite useful; but for the rest of us, we can sit around and argue about languages and preferences and never get much done
I guess Forth makes computers too simple, no OS and so on.
And there are some new books on Forth for reading.
http://www.forth.com/forth/forth-books.html
It just has an interesting vibe to it all - some attributes are very leading edge (like the GA144), others are very retro (like Leo Brodie's intoduction, Starting Forth).
I'm not having a downer on Forth, and I'm not digging at anybody but this whole debate is getting stranger and stranger. As such I would like to pursue it. If that's OK? The obvious question is "where is that standard?" Can you give me a link to it so I can make a Forth of my own for whatever machine I have here? This cannot be true, or if it is it's totally useless. What it says is that I can access memory or the stack, which is memory anyway. I can move data around but I cannot do any manipulations on it, like arithmetic or logical operations.
Worse still it says I cannot make decisions or create loops. The fundamental operations of computing, after the arithmetic or logical ops, are:
Sequence - as in "do this, then do that, then do the other..." to be executed in order.
Selection - as in "if someCondition do something else do someting different"
Iteration - as in "do something until some condition is reached"
Worse still it does not allow me to give names to a bunch of instructions,. I cannot define my own words. And that I thought was a big thing in Forth.
Now, I have open in front of me the online version of "Starting Forth" by Leo Brodie complete with a foreword by Charles Moore himself. The first piece of Forth we see in there is the definition of a word: Immediately we learn that ":" and ";" are fundamental to the language in order to define one thing in terms of other things, whatever they may be.
On the same page we see: Obviously a definition of a word that performs an iteration, "DO" and "LOOP" are a clue. Now that iteration construct cannot be defined in terms of anything less so I guess "DO" and "LOOP" are essential parts of Forth.
On the same page again we have: Which apparently produces the result "7". So now we see that "+" is an essential part of the Forth language. (Unless it can be defined in terms of an "if" and a comparison which we have not seen yet).
And so on, I'm sure I will find an "if" in there at some point.
So if that book is not setting a standard what on earth is?
I have no qualms with that idea of infinite, on the fly, flexibilty. Sound great. However the means to create those user word/functions must be standardized in the language itself. If not we have no way of exchanging programs between different machines or different humans for that matter.
No. Clearly the Propeller, and other machines, have no built in stack handling hardware. If you want a stack you have to make one in software. As such Forth is far away from the metal. Besides, pretty much all languages are dependent on a stack one way or another.
If the absolute minimum required for the user to define Forth words is standardized you can always ship those definitions with your application, indeed they are part of the application.
Other languages don't even try to expose the stack even though that's what is generally done internally. Being forced to think stack is what separates forth from most other languages except major ASM coding as a matter of choice for modularity.
Hmmm.... I see what you mean but it's not so cut and dried to me.
In C you learn that it's a bad idea to return pointers to local variables from a function. They may not be valid after the function returns. Why? Well they don't say "because those variables are on the machines stack along with return addresses etc and will be clobbered by subsequent function calls". No they just talk about "scope" and "automatic variables". Then you learn about recursive function calls. Well how is that supposed to happen without a stack somewhere?. And as it happens that implied stack need not be anything to do with the machines hardware stack, although it normally is.
Conversly, in Forth the stack is emphasized. This is nothing to do with being "close to the metal". It's just a model of how the language works. Again that need not be the actuall machines hardware stack. Especially if it does not have hardware stack support. How do I know that when I write "4 2 +" that those numbers are not kept in registers or on the heap? As a HLL that really should not concern me. It's just a conceptual model. Why should we not have Forth code running in a COG, which has no stack, for example?
I'm basing this on Peter's Tachyon Forth VM because it was handy.
In fewer than 1000 lines of PASM, Peter came up with rather robust Forth Kernel that covers all the basics plus because of his goal for speed and size, added a large number of PASM defined words to support the Propeller hardware (I/O and COGs) and other features he knew from experience should be fast and coded in PASM. After he wrote the kernel in PASM, he switched to defining additional words in terms of the Forth byte codes for the PASM primitives he defined. For the most part, these bytecode based definitions could be moved to external files and added in as parts when/if he needed the words. At one point, Peter changed the : compiling word to pri and pub so it would be more readable by Spin programmers!
In the short life of Tachyon, he has a fast, powerful, feature packed Forth interpreter/compiler/environment. If he wants to take Tachyon to another hardware platform, he rewrites the 100 lines of PASM, adjusts anything he needs to adjust for architecture (COG and I/O) portions and he's got Tachyon on a new micro. Obviously, the smaller you keep that PASM kernel, the easier it is to change architectures. Your application files (.fth, .f, .whatever) should all run on your Tachyon. Will they carry over directly to PropForth? No, but they can be changed as needed or depending on what you are missing, you can create it in PropForth as words to extend PropForth to do some things like Tachyon.
Is it a universal as porting C code? Probably not, because you never have to change anything in a C application when you port it, right? Just recompile and run.
Is it as easy as moving an application from say the AIX version of UNIX to HP/UX? Certainly not, because they're both UNIX, right?
So back to the thought here: Yes, there needs to be a core of words that defines Forth to the point that you can extend Forth and build your application on it. Should they be globally known an excepted? Sure! Are they? Kind of, sort of mostly.....
Is it productive? Forth people say it is, non-Forth people say it isn't.
If you don't try it, you'll never know if you like it.
Some folks will never like it, some folks will never try it.
People are funny that way. I've programmed in many different languages for fun and money. For some reason, Perl and I just don't get along. I use it, I've written small tools with it, I've taken classes and read books and something just won't click for me. I even see the power and beauty in it but my mind just won't accept it without a struggle. Would I sit down and play with Perl for fun? No. Would I sit down and play with Forth for fun? Sure!
OK, everybody, back to your corners for the next round!!
There are discussion with Charles Moore about the stack. One big reason for that is because he despises local variables. Globals are fine but if you need locals, then the rod you've defined is too complex and should be factored. If the stack is to deep and you need to rummage through it to find the value you need to work on, then the word is too complex and should be factored. On machines that support a stack, the kernel implementation is nice and fast because you have a one to one relationship between a Forth Push and a hardware Push to the stack, so Forth stack manipulation words become faster and are closer to the machine.
It's a language abstraction for the most part and a philosophy thing. I keep meaning to look and see which of the machines Moore first did Forth for actually had a hardware stack.
Thank you, yes, I suspected as much. Now all I need to do is identify that minimal system and I'll finally have found the "real Forth". And there he stands in defiance of all the percieved wisdom and best practice in programming language design since ever we had high level languages.
Brave man.
I was looking for the link all day, I thought it was Brad Rodrigez but maybe it was Frank Sargent. Anyway, one of those forth guys was writing about "when is it a forth". Because we always have to start with assembler or some other language, and start wrting something until we have a a forth that scan re-generate itself; at that point we can use forth to write the improvements (very quick dev time, and interactive). The author showed that once we can do those three functions, we can use them to make more functions, like placing opcodes in memory to make more forth definitions, and build the dictionary till we have a useable forth.
This in fact is always does when one write a new forth, so there's your example. When Sal wrote propforth, he started with spin, and implemented a crude dictionary and interpreter, then used that to make an "improved" version. Right now, propforth generates spin code to make the next version. Sal does this to take advantage of the spin interpreter to resolve forward references, etc. But most folks couldn't write the current propforth in spin from scratch, not even Sal. If you don't have this kind of tool, and you have to use assembler, you try to get away from writing in assembler as quick as possible, since coding is so slow (for regular people, assembler experts just do everything n assembler anyway and wouldn't use forth). So when do you have a "real forth"? Some folks say "when it can re generate its own kernel", some say "when you can read and write to memory".
By the first definition, propforth is still not forth, as propforth must generate spin code, and the spin tool generates the kernel image we load. By the second definition, almost anything can be considered forth. I don't particularly care either way, just as long as its fun.
Link to linux version of colorforth is on:
http://wiki.forthfreak.net/index.cgi?colorForth
AFAIK - PolyFORTH is (was?) Forth Inc commercial product, you have to pay lots for it and it is hard to get.
If anyone can find this as a free download, its great. Otherwise, avoid it until you can make somebody else pay for it.
But Frank Sargent's pygmy Forth is pretty close to polyforth, maybe better, and runs on the PC.
http://pygmy.utoh.org/forth.html
Oh, and there's the three instruction forth write up, so it was Franks
http://pygmy.utoh.org/3ins4th.html
The whole deal with colorforth is "you don't need windows OS with this, you just need your smallest old DOS box, and that will be more than plenty".