Excellent argument. However, since it is based on a false premise, the conclusion does not stand.
As people have been saying repeatedly, there is absolutely nothing in the design of ColorForth that requires color. Rewrite the editor and you can have a "ColorForth" that uses richtext or tone of voice or whatever. With 100% identical precompiled source in the original format.
The language is in fact accessible by design. The pilot implementation is not accessible, but if you toss out everthing that is accessible by design because it wasn't accessible in its first pilot implementation, how much of modern technology will you be left with?
There is no way that you would want to use all 25 processors all fecthing hash data from the main memory at the same time. You would organise the processors into work crews.
And, after all, the main point of mass producing Minimal Instruction Set chips interconnected together on the same die is that if you aren't using all the processors at some point in the process... so what! $1 a chip, it can be efficient for a few to be idling, just to provide low latency.
Think of the x25 organised into 5, 5 processor work crews, with one evaluating and the other four doing the work with hashes (on the assumption that the hashing is harder work for the cores than the evaluation). And if there's a memory bottleneck, either in access or quantity, add more x25's with their own 256K memory.
I reckon that's the notion of a cheap chip such as the X25... if you run into bottlenecks, apply more chips. Forth or a Forth-like language is going to be the assembly language of that kind of cheap chip, because you need operand free operations and seperation of datastacks and return stacks to sidestep the issues that drive you up CISC and RISC design paths.
First, for low priority threads, you can compile them in a bullet-proof Forth that does not allow access to memory it has not allocated or alloted. That will take care of a good number of 80-plus process right away.
Second, for high priority threads, you have processes that own their own processors... and own their threads. A direct connection that multiplexes memory access coming from processor #5 to the fifth 256K bank is harder hardware memory protection than traditional hardware memory protection.
Of course, Chuck said this, but he said it in very few words, so people used to reading fast are likely to miss it.
Is it surprising that there would be a number of Forth users of one sort or another on slashdot? Don't forget that Forth was a public domain language/operating-systems for a lot of personal computers down to Commodore 64's, Apple II's, and TRS-80's. And that forth is part of the Gnu stable of languages.
We mostly stay quiet and read, but its just not possible to read some of the nonsense people come up with about Forth and stay quiet!
I'm not joking. See the discussion of the latest EuroForth conference in a recent Forthwrite at
http://www.fig-uk.org
It is, in fact, pretty easy to run gforth as a CGI server on a linux system... what is impressive if using Forth to put the webserver into a lightswitch for a security system.
Since Forth at the moment is inside the little thingies that you sign for packages on for one of the major US delivery companies, manages the baggage system for some major airports, the European system for letting bank machines talk to each other, and provides the OpenFirmware pre-OS boot manager for Sun, IBM and Apple systems to help bring up new hardware faster, how can you possibly ask where people are using Forth on other machines?
Clearly, the current ANS Forth standard does not include everything needed for a more sociable forth, but work is ongoing.
And sure its got more presence in professional robotics than amateur robotics, but what about the Forth for Mindstorms?
Chuck Moore says he has no qualms requiring colour vision. And youse Americans want him to apologise.
I expect he means that if there was something intrinsic about colour in programming, he wouldn't have any qualms about making colour vision a requirement for programming.
But whatever he means, he either has qualms or he doesn't. Claiming that he did when he doesn't would be that thing which used to be called a "lie".
On the other hand, the whole thing is a complete storm in a teapot, because there is nothing intrinsic about colour vision, or even vision, in ColorForth. The foundation is in fact much more accessible to vision impaired than some "connector set" programming paradigms. It's all just names of things, with each name preceded by a token to indicate one of a limited set of possible states. Since eight states is 3 bits, you just need three distinct voice attributes: say, male/female, high/low pitch, strong/normal timber and you've got AuralForth. Or three rich text attributes and you have RichTextForth.
But he's just one guy building his tools to build his tools as he goes. Since he says he's interested in voice recognition, and having AuralForth would be part of that for him, we might see AuralForth built. But someone was colour blind and wanted RichTextForth, he'd probably have to pay. From what I hear, Chuck's vision is none too good, and he's much more comfortable with displaying ColorForth in big blocky letters in different colours than he would be displaying them in bold, italics, and underline.
That's an important point. You don't need a pipeline if you can execute an instruction in the time it takes to read the instruction, as with most hardwired stack processors, or in two with most microcoded. And without a pipeline, and with operand-free operands, you can implement interupts as simply a hardware procedure call, without pipeline latency or management overhead.
Of course, that's just ordinary state of the art in stack machines, and not leading edge asynchronous stuff like Chuck is doing.
The way some double stack processors (that is, return stack and data stack are seperate) do it is to spill half the stack on overflow, and refill on underflow. Others spill and refill on demand... the last stack item is spilled out for overflow, and the stack is refilled a cell at a time on underflow.
See Koopman's book, Stack Machines, a New Wave... give a collection of trade-offs, and a processor approach that places less demand on hardware than CISC and RISC processors, its not surprising that most alternative approaches have been implemented.
If you can't maintain the Forth you wrote, you wrote poor Forth. As with any other language, you have to follow the rules of writing readable Forth if you want to write readable Forth.
Of course, a lot of perfectly good Forth from earlier days appears to be maintainable, since they were in "blocks" with companion "shadow blocks" that are indispensible to reading the source. To simplify to a modern Forth source as a normal text file, you should be able to answer yes to each of the following (not an exhaustive list):
(1) Is each forth word preceded by one or more comment lines of explanation of WHY it is used and, if context-dependent, in what context?
(2) Does the name of each word evoke the reason it is used?
(3) Is every colon definition accompanied by a stack comment showing the state of the stack before and after use of the word?
(4) Is your average colon definition seven words or less?
(5) Have you designed your basic implementation words so that it is unecessary to manipulate the stack when using your public interface words together?
(6) Have you tested each word before putting it to use in the file?
If you have all of those things, you should be able to open the file up with a decent editors text editor, look at the use of the public interface wordset, and work your way back in the file to the point where you need added capability, and search through the file to find the bits and pieces of existing capabilities that need extending.
I recently opened up a long (64K) source file that I put aside a year and a half ago, and every point where it is hard to read is a point where I broke two or more of the rules above. And since I mostly followed the rules, it was much easier than I thought it was going to be to get back into it and make a substantial change to the way things were done.
Whether or not there will be any revolution coming from Chuck depends on whether someone uses one of his chips to start a revolution.
But don't confuse Chuck and Forth. Chuck has pursued his own very personal and eclectic path. If you are wondering how you are going to fit a SAX-like event driven XML parsing into a low resource microcontroller, search for JenX. Using Forth as a CGI server is even easier, at least in a Linux environment with gforth (Gnu Forth).
The impression I have from comp.lang.forth is that when most serious Forth programmers hear from Chuck, they stop, say, "that's very interesting" and then go back to doing what they normally do, whether that is embedded work or work in a PC environment.
Note that the curvature is up in the tower: the limit of the street grid applies to the block that the towers emerge from, not the towers themselves.
Indeed, supposing that the long axis of the street grid is N/S, it seems as if you would be able to swing orientation over a range in the decision of whether the towers will rise NE/SW, N/S, or NW/SE.
True: all you have to do is to provide the Forth words that change "color state" and use them to change the color token instead of saving them as text, since its seems that they are completely recoverable from the color text tokens.
And, indeed, as long as a screen reader knows how to read them as Forth words, you are set.
But all that the colors mean are one of a small number of states. Male/Female, low/high normal/firm tones of voice give eight different tones for the different "colors", and sorting them into a mneumonic hierarchy would make that an easy one to keep track of.
Similarly for color blind, italic, bold, and underlined give eight different possiblities, and the same hierarchy would make that as mneumonic for the color blind.
Since the "next color" spaces are just TOKENS, all you need is a display device that treats the tokens as changing some other state, and you are in business.
The point of the color source editor is that each word shows how it should be interpreted. There is no need to keep track.
"Production -> Unfortunately the Internet appliance market has not grown as big or as fast as we had hoped it would."
The next big growth market will be in mobiles (cellphones back home in the US) with flexible voice/text messaging on as many channels as possible. That's at the stage of mid 1980's PC's, when a number of people have gotten used to it, but capabilities are sufficiently constrained that a new unit with a big step ahead will bring in a big upgrade as well as new user market.
GREAT question! I would think its because of the C base for the kernel, so it would be mostly be for loadable drivers. Hop over to the Cliunux site at www.clienux.com to get one person's opinions on some roles of forth in Linux, and grab the eforthl package from the interim directory at the ftp site at
to get a minimal forth with the linux OS calls as built in procedures. Of course, the rub is that this is not a full featured implementation like you would get from MPE or Forth Inc., so there would be a lot of sweat equity involved in "rolling your own" for a lot of stuff you could get from libraries in C. However, an advantage of Open Source is that with access to the source, you can follow what the library is doing down to system call level, and then work out which parts you really need to port for the exact capability that you need.
Once you get the ball rolling, extending a Forth application is a fairly natural process, so it makes a lot of sense to build the application to exactly what you need, and the extend to meet new needs later, when they arise.
One point to bear in mind is why there are two stacks. It entirely eliminates the stack frame building overhead (rather than managing or reducing it, as with register punning, etc.). That is what makes it efficient to program much shorter procedures and then use the procedures by name.
Where is this missed above? In the assumption that the need to have X instructions for Y operation will inflate code size substantially. In fact, it will normally inflate code size by exactly X instructions, since it will exist once, in one word, and then used by calling that word. The data will be in the same format whether using a built-in opcode or a defined procedure. There is still a place for inlining code, but only when the inlined code substantially increases speed for either a reduction or only a mild increase in code size.
Then there is the point that if you can afford 25 processors for less than the cost of a single CISC or RISC chip, you can have a couple of processors set aside as arithmatic servers. Break up a 20 by 20 multiplication in a time critical section (if its not in a time critical section -- let it run slow!) into 5x4x20, and then combine the terms by calling the serving processors in turn and adding the terms as they arrive on the stack.
And unlike a CISC chip, the allocation of resources to tasks is not hardwired, so at a stage when there is not much mutiplication to do, you can fan out the parallelism of the chip.
Most of the innovations of the past 20-30 years have been dedicated to solving problems created by earlier innovations of the past 20-30 years.
But look at the basic stack machine process. If the operands are known, so the instruction does not have to specify them, and the operands are usually on-chip, so the processor does not have to use memory bandwidth to access them, you get 1 instruction, 1 clock cycle, hardwired, 1 instruction, 2 clock cycles, microcoded, and the processor clock can easily run at a multiple of the memory access clock without need for an associative cache. IOW, the on chip stack replaces both most registers and and reduces drastically the need for data cache. That's the normal, tried-and-true stack chips -- and its important to understand the Moores chips are leading/bleeding edge technology pushing an envelope already proven by a number of stack chips in current use, mostly embedded out of sight.
Then cut the instruction set down to a hardwired five bit set, and you can pack 4 instruction slots into a 20 bit word. That means that each instruction fetch is a equivalent to 1 off cache instruction access and 3 cache hits.
And finally combine that with a double stack approach that avoid stack-frame building overheads on procedure calls to support very small procedures, reused to a much greater extend, and the smaller code size that results from that, and in many cases your level 2 cache memory can just be your program memory.
However, the approach used by some "inside the envelope" chips is to explicitly nominate bottleneck procedures to fast memory, with no difference between the two except that they are present in a portion of the address space where instructions execute more quickly. So there you profile the application, identify the high frequency operations, and speed them up by declaration in the source. The same idea as declaring a register variable, except it is declaring a "cache procedure".
I, in fact, used a Forth that almost did that. Not in the part read by the human, but in the part read by the computer. In severely RAM constrained systems, it made every bit as much sense as 2 bytes for the year in a date. This was a Forth for the Commodore 64, which I bought at a time that standard RAM for a PC was 128 and maximum RAM was 640K (not that normal people would ever need more than 256K, excpet as RAMDisk), and the way it made the Commodore 64 glacially slow disk drive tolerable while developing was by allocating a lot of that 64K RAM to block buffers.
ANS Standard, as many people have mentioned, required 31 retained characters minimum. And if you have names more than 31 characters long, it normally means that you need vocabularies and you are not using them (just as in C it would mean that you need to structure your functions somehow and are not doing so) -- the equivalent of ProcessFooBarReadTilDone is, with one deep vocabularies,
FooBar-Process Read-Til-Done which means you have 31 characters for family and 31 characters for operation.
Notice that each work gang has its own dedicated row or column. Also, notice that three work gangs have each member on the outside, one has two, and the other four (2, 5, 6 and 7) have a single member on the outside edge, so you have natural specialisation between tasks requiring more memory access intensive processes and more processing intensive tasks, if it is handy for the application.
Don't forget that the reason that 20 bit words are held on the stack as 21 bit words is to retain a carry with each and every word on the stack, and the way that the sum-conditional-on-carry uses that to synthesize multiplication operations. The data stacks are part of the arithmetic hardware for a stack processor. Also, arithmetic intensive tasks would likely have bottlenecks addressed by grouping processors in teams of two, three, or four (which is part of the serendipity of 5x5 -- one superviser and/or interface processor plus 12 teams of 2, eight teams of three, or six teams of three), in which case the data stack is how the programmer makes sure that the data that needs to be readily accesible is going to be readily accessible, without the combinatorial complexity in tracking 5x5xregister-bank registers.
I think you hit the nail on the head... it's willingness to have a go. Elizabeth Rather from Forth Inc. says that when they run their Forth classes for, say, hardware systems engineers, they are doing useful things within a day or two and are competent in a week.
Of course, if you are used to infix "+", then getting used to also being able to see "take 5 and 4. add 'em." is a hurdle, but not a big one at all. Having the attitude of "prove to me without a shadow of a doubt that there is any purpose to me learning to see operators in an active 'just do it' sense" is a much bigger hurdle.
Similarly, learning to read "IF THEN" to mean
test IF-true this-action THEN-continue-with that-action
is a little hurdle to someone who comes in with an open mind, and a big hurdle to someone who comes in with an attitude of "that's not what I'm used to... FIX IT!!!".
The real benefit in readability comes when the stack operators and most of the standard FORTH words are used to define words that apply to the situation, and you can get code that reads like
XY-COORDS? IF XY>POLAR THEN GET-OFFSET APPLY-OFFSET
The danger is the Forth technique of extending the language to fit the problem. There are so many Forth coders who are not trained in effective commenting techniques for Forth. Also, in so many of the places that Forth is used, it is used by one or a few people as a personal productivity tool, so there are no "house standard rules" for naming and documentation. It certainly can become unreadable... just as unreadable as any newly created language without proper documentation. Just as unreadable, in fact, as C code would be to someone who did not have access to documentation about C.
This is a very good question. It gives Chuck an opportunity to talk about what some in the Forth community see as the differences between a ColorForth-ish approach and the ANS Forth standard approach. Are the full featured systems from Forth Inc. and MPE, for systems from Unix through Windows through embedded systems, a waste of time? Should people writing Open Source software ignore the possibility of adding gforth as a weapon in their armoury? Should people writing in C, whether for Windows or Linux, ignore the possibilities of using Forth as a built-in scripting language using FICL?
IMO the answers are NO, NO and NO, and despite Chuck's criticisms of the standardisation process and where it might take Forth, that a "horses for courses" strategy means there are situations where it makes sense to "roll your own" system, all the way down to the hardware level, and there are situations where it makes sense to "go along to get along". You might lose some of the factors in Chuck's "1000 times" along the way, but you still get the interactive command line debugging of each and every routine before the routines are put to use, the support for efficient factoring down to routines of one to four lines (unlike stack frame languages like C), and flexibility to extend Forth into the language that fits your problem.
But that is guessing what Chuck might answer... I can't wait until the answers come out.
I thought I would just point out that the "colourisation" is applied with a small collection of colour-change tokens that display as spaces. A text reader could generate distinctive tones of voice for each colour. A ColorForth editor for someone colour blind could "colour" the code with font changes instead of colour changes.
gforth (GnuForth -- check your favorite Gnu mirror, and available with Linux binaries) comes with three Object Oriented wordsets. One, a minimalist approach (that is, a "one screener", or toolkit within 16 lines), and two more full fledged versions.
The focus of much paid Forth work in the embedded environment means that there aren't as many generically useful public libraries as many newer languages, but it'll get there eventually.
Slashdot Mirror
Excellent argument. However, since it is based on a false premise, the conclusion does not stand.
As people have been saying repeatedly, there is absolutely nothing in the design of ColorForth that requires color. Rewrite the editor and you can have a "ColorForth" that uses richtext or tone of voice or whatever. With 100% identical precompiled source in the original format.
The language is in fact accessible by design. The pilot implementation is not accessible, but if you toss out everthing that is accessible by design because it wasn't accessible in its first pilot implementation, how much of modern technology will you be left with?
No worries mate. Just post your code on comp.lang.forth and say, "I can't come up with good names for a lot of these functions, suggestions welcome".
If people are interested in what is accomplished, you'll have plenty of names to use once the smoke clears.
There is no way that you would want to use all 25 processors all fecthing hash data from the main memory at the same time. You would organise the processors into work crews.
... so what! $1 a chip, it can be efficient for a few to be idling, just to provide low latency.
... if you run into bottlenecks, apply more chips. Forth or a Forth-like language is going to be the assembly language of that kind of cheap chip, because you need operand free operations and seperation of datastacks and return stacks to sidestep the issues that drive you up CISC and RISC design paths.
And, after all, the main point of mass producing Minimal Instruction Set chips interconnected together on the same die is that if you aren't using all the processors at some point in the process
Think of the x25 organised into 5, 5 processor work crews, with one evaluating and the other four doing the work with hashes (on the assumption that the hashing is harder work for the cores than the evaluation). And if there's a memory bottleneck, either in access or quantity, add more x25's with their own 256K memory.
I reckon that's the notion of a cheap chip such as the X25
First, for low priority threads, you can compile them in a bullet-proof Forth that does not allow access to memory it has not allocated or alloted. That will take care of a good number of 80-plus process right away.
... and own their threads. A direct connection that multiplexes memory access coming from processor #5 to the fifth 256K bank is harder hardware memory protection than traditional hardware memory protection.
Second, for high priority threads, you have processes that own their own processors
Of course, Chuck said this, but he said it in very few words, so people used to reading fast are likely to miss it.
Is it surprising that there would be a number of Forth users of one sort or another on slashdot? Don't forget that Forth was a public domain language/operating-systems for a lot of personal computers down to Commodore 64's, Apple II's, and TRS-80's. And that forth is part of the Gnu stable of languages.
We mostly stay quiet and read, but its just not possible to read some of the nonsense people come up with about Forth and stay quiet!
I'm not joking. See the discussion of the latest EuroForth conference in a recent Forthwrite at
... what is impressive if using Forth to put the webserver into a lightswitch for a security system.
http://www.fig-uk.org
It is, in fact, pretty easy to run gforth as a CGI server on a linux system
Since Forth at the moment is inside the little thingies that you sign for packages on for one of the major US delivery companies, manages the baggage system for some major airports, the European system for letting bank machines talk to each other, and provides the OpenFirmware pre-OS boot manager for Sun, IBM and Apple systems to help bring up new hardware faster, how can you possibly ask where people are using Forth on other machines?
Clearly, the current ANS Forth standard does not include everything needed for a more sociable forth, but work is ongoing.
And sure its got more presence in professional robotics than amateur robotics, but what about the Forth for Mindstorms?
Chuck Moore says he has no qualms requiring colour vision. And youse Americans want him to apologise.
I expect he means that if there was something intrinsic about colour in programming, he wouldn't have any qualms about making colour vision a requirement for programming.
But whatever he means, he either has qualms or he doesn't. Claiming that he did when he doesn't would be that thing which used to be called a "lie".
On the other hand, the whole thing is a complete storm in a teapot, because there is nothing intrinsic about colour vision, or even vision, in ColorForth. The foundation is in fact much more accessible to vision impaired than some "connector set" programming paradigms. It's all just names of things, with each name preceded by a token to indicate one of a limited set of possible states. Since eight states is 3 bits, you just need three distinct voice attributes: say, male/female, high/low pitch, strong/normal timber and you've got AuralForth. Or three rich text attributes and you have RichTextForth.
But he's just one guy building his tools to build his tools as he goes. Since he says he's interested in voice recognition, and having AuralForth would be part of that for him, we might see AuralForth built. But someone was colour blind and wanted RichTextForth, he'd probably have to pay. From what I hear, Chuck's vision is none too good, and he's much more comfortable with displaying ColorForth in big blocky letters in different colours than he would be displaying them in bold, italics, and underline.
That's an important point. You don't need a pipeline if you can execute an instruction in the time it takes to read the instruction, as with most hardwired stack processors, or in two with most microcoded. And without a pipeline, and with operand-free operands, you can implement interupts as simply a hardware procedure call, without pipeline latency or management overhead.
Of course, that's just ordinary state of the art in stack machines, and not leading edge asynchronous stuff like Chuck is doing.
The way some double stack processors (that is, return stack and data stack are seperate) do it is to spill half the stack on overflow, and refill on underflow. Others spill and refill on demand ... the last stack item is spilled out for overflow, and the stack is refilled a cell at a time on underflow.
... give a collection of trade-offs, and a processor approach that places less demand on hardware than CISC and RISC processors, its not surprising that most alternative approaches have been implemented.
See Koopman's book, Stack Machines, a New Wave
If you can't maintain the Forth you wrote, you wrote poor Forth. As with any other language, you have to follow the rules of writing readable Forth if you want to write readable Forth.
Of course, a lot of perfectly good Forth from earlier days appears to be maintainable, since they were in "blocks" with companion "shadow blocks" that are indispensible to reading the source. To simplify to a modern Forth source as a normal text file, you should be able to answer yes to each of the following (not an exhaustive list):
(1) Is each forth word preceded by one or more comment lines of explanation of WHY it is used and, if context-dependent, in what context?
(2) Does the name of each word evoke the reason it is used?
(3) Is every colon definition accompanied by a stack comment showing the state of the stack before and after use of the word?
(4) Is your average colon definition seven words or less?
(5) Have you designed your basic implementation words so that it is unecessary to manipulate the stack when using your public interface words together?
(6) Have you tested each word before putting it to use in the file?
If you have all of those things, you should be able to open the file up with a decent editors text editor, look at the use of the public interface wordset, and work your way back in the file to the point where you need added capability, and search through the file to find the bits and pieces of existing capabilities that need extending.
I recently opened up a long (64K) source file that I put aside a year and a half ago, and every point where it is hard to read is a point where I broke two or more of the rules above. And since I mostly followed the rules, it was much easier than I thought it was going to be to get back into it and make a substantial change to the way things were done.
Whether or not there will be any revolution coming from Chuck depends on whether someone uses one of his chips to start a revolution.
But don't confuse Chuck and Forth. Chuck has pursued his own very personal and eclectic path. If you are wondering how you are going to fit a SAX-like event driven XML parsing into a low resource microcontroller, search for JenX. Using Forth as a CGI server is even easier, at least in a Linux environment with gforth (Gnu Forth).
The impression I have from comp.lang.forth is that when most serious Forth programmers hear from Chuck, they stop, say, "that's very interesting" and then go back to doing what they normally do, whether that is embedded work or work in a PC environment.
Note that the curvature is up in the tower: the limit of the street grid applies to the block that the towers emerge from, not the towers themselves.
Indeed, supposing that the long axis of the street grid is N/S, it seems as if you would be able to swing orientation over a range in the decision of whether the towers will rise NE/SW, N/S, or NW/SE.
True: all you have to do is to provide the Forth words that change "color state" and use them to change the color token instead of saving them as text, since its seems that they are completely recoverable from the color text tokens.
And, indeed, as long as a screen reader knows how to read them as Forth words, you are set.
But all that the colors mean are one of a small number of states. Male/Female, low/high normal/firm tones of voice give eight different tones for the different "colors", and sorting them into a mneumonic hierarchy would make that an easy one to keep track of.
Similarly for color blind, italic, bold, and underlined give eight different possiblities, and the same hierarchy would make that as mneumonic for the color blind.
Since the "next color" spaces are just TOKENS, all you need is a display device that treats the tokens as changing some other state, and you are in business.
The point of the color source editor is that each word shows how it should be interpreted. There is no need to keep track.
"Production -> Unfortunately the Internet appliance market has not grown as big or as fast as we had hoped it would."
The next big growth market will be in mobiles (cellphones back home in the US) with flexible voice/text messaging on as many channels as possible. That's at the stage of mid 1980's PC's, when a number of people have gotten used to it, but capabilities are sufficiently constrained that a new unit with a big step ahead will bring in a big upgrade as well as new user market.
GREAT question! I would think its because of the C base for the kernel, so it would be mostly be for loadable drivers. Hop over to the Cliunux site at www.clienux.com to get one person's opinions on some roles of forth in Linux, and grab the eforthl package from the interim directory at the ftp site at
I eNUX/interim/eforthl.tgz
http://www.ibiblio.org/pub/linux/distributions/cL
to get a minimal forth with the linux OS calls as built in procedures. Of course, the rub is that this is not a full featured implementation like you would get from MPE or Forth Inc., so there would be a lot of sweat equity involved in "rolling your own" for a lot of stuff you could get from libraries in C. However, an advantage of Open Source is that with access to the source, you can follow what the library is doing down to system call level, and then work out which parts you really need to port for the exact capability that you need.
Once you get the ball rolling, extending a Forth application is a fairly natural process, so it makes a lot of sense to build the application to exactly what you need, and the extend to meet new needs later, when they arise.
One point to bear in mind is why there are two stacks. It entirely eliminates the stack frame building overhead (rather than managing or reducing it, as with register punning, etc.). That is what makes it efficient to program much shorter procedures and then use the procedures by name.
Where is this missed above? In the assumption that the need to have X instructions for Y operation will inflate code size substantially. In fact, it will normally inflate code size by exactly X instructions, since it will exist once, in one word, and then used by calling that word. The data will be in the same format whether using a built-in opcode or a defined procedure. There is still a place for inlining code, but only when the inlined code substantially increases speed for either a reduction or only a mild increase in code size.
Then there is the point that if you can afford 25 processors for less than the cost of a single CISC or RISC chip, you can have a couple of processors set aside as arithmatic servers. Break up a 20 by 20 multiplication in a time critical section (if its not in a time critical section -- let it run slow!) into 5x4x20, and then combine the terms by calling the serving processors in turn and adding the terms as they arrive on the stack.
And unlike a CISC chip, the allocation of resources to tasks is not hardwired, so at a stage when there is not much mutiplication to do, you can fan out the parallelism of the chip.
Most of the innovations of the past 20-30 years have been dedicated to solving problems created by earlier innovations of the past 20-30 years.
But look at the basic stack machine process. If the operands are known, so the instruction does not have to specify them, and the operands are usually on-chip, so the processor does not have to use memory bandwidth to access them, you get 1 instruction, 1 clock cycle, hardwired, 1 instruction, 2 clock cycles, microcoded, and the processor clock can easily run at a multiple of the memory access clock without need for an associative cache. IOW, the on chip stack replaces both most registers and and reduces drastically the need for data cache. That's the normal, tried-and-true stack chips -- and its important to understand the Moores chips are leading/bleeding edge technology pushing an envelope already proven by a number of stack chips in current use, mostly embedded out of sight.
Then cut the instruction set down to a hardwired five bit set, and you can pack 4 instruction slots into a 20 bit word. That means that each instruction fetch is a equivalent to 1 off cache instruction access and 3 cache hits.
And finally combine that with a double stack approach that avoid stack-frame building overheads on procedure calls to support very small procedures, reused to a much greater extend, and the smaller code size that results from that, and in many cases your level 2 cache memory can just be your program memory.
However, the approach used by some "inside the envelope" chips is to explicitly nominate bottleneck procedures to fast memory, with no difference between the two except that they are present in a portion of the address space where instructions execute more quickly. So there you profile the application, identify the high frequency operations, and speed them up by declaration in the source. The same idea as declaring a register variable, except it is declaring a "cache procedure".
I, in fact, used a Forth that almost did that. Not in the part read by the human, but in the part read by the computer. In severely RAM constrained systems, it made every bit as much sense as 2 bytes for the year in a date. This was a Forth for the Commodore 64, which I bought at a time that standard RAM for a PC was 128 and maximum RAM was 640K (not that normal people would ever need more than 256K, excpet as RAMDisk), and the way it made the Commodore 64 glacially slow disk drive tolerable while developing was by allocating a lot of that 64K RAM to block buffers.
ANS Standard, as many people have mentioned, required 31 retained characters minimum. And if you have names more than 31 characters long, it normally means that you need vocabularies and you are not using them (just as in C it would mean that you need to structure your functions somehow and are not doing so) -- the equivalent of ProcessFooBarReadTilDone is, with one deep vocabularies,
FooBar-Process Read-Til-Done
which means you have 31 characters for family and 31 characters for operation.
Suppose that you have one I/O and coordinator processor, and the other processors divided into eight work gangs of three processors each.
XX XX IO XX XX
XX XX XX XX XX
XX XX XX XX XX
XX XX XX XX XX
XX XX XX XX XX
Then each work gang has a supervisor, the 1 processor, and two followers, the "2", and "3" processors:
11 21 IO 31 41
12 22 51 52 53
63 62 61 32 42
13 23 71 72 73
83 82 81 33 43
Notice that each work gang has its own dedicated row or column. Also, notice that three work gangs have each member on the outside, one has two, and the other four (2, 5, 6 and 7) have a single member on the outside edge, so you have natural specialisation between tasks requiring more memory access intensive processes and more processing intensive tasks, if it is handy for the application.
Similarly, six work gangs of four could be:
11 21 IO 31 41
12 22 51 54 42
13 23 52 32 43
14 24 53 33 44
62 63 61 34 64
Anyway, I reckon that's how it would go.
Don't forget that the reason that 20 bit words are held on the stack as 21 bit words is to retain a carry with each and every word on the stack, and the way that the sum-conditional-on-carry uses that to synthesize multiplication operations. The data stacks are part of the arithmetic hardware for a stack processor. Also, arithmetic intensive tasks would likely have bottlenecks addressed by grouping processors in teams of two, three, or four (which is part of the serendipity of 5x5 -- one superviser and/or interface processor plus 12 teams of 2, eight teams of three, or six teams of three), in which case the data stack is how the programmer makes sure that the data that needs to be readily accesible is going to be readily accessible, without the combinatorial complexity in tracking 5x5xregister-bank registers.
I think you hit the nail on the head ... it's willingness to have a go. Elizabeth Rather from Forth Inc. says that when they run their Forth classes for, say, hardware systems engineers, they are doing useful things within a day or two and are competent in a week.
... FIX IT!!!".
... just as unreadable as any newly created language without proper documentation. Just as unreadable, in fact, as C code would be to someone who did not have access to documentation about C.
Of course, if you are used to infix "+", then getting used to also being able to see "take 5 and 4. add 'em." is a hurdle, but not a big one at all. Having the attitude of "prove to me without a shadow of a doubt that there is any purpose to me learning to see operators in an active 'just do it' sense" is a much bigger hurdle.
Similarly, learning to read "IF THEN" to mean
test IF-true this-action THEN-continue-with that-action
is a little hurdle to someone who comes in with an open mind, and a big hurdle to someone who comes in with an attitude of "that's not what I'm used to
The real benefit in readability comes when the stack operators and most of the standard FORTH words are used to define words that apply to the situation, and you can get code that reads like
XY-COORDS? IF XY>POLAR THEN
GET-OFFSET APPLY-OFFSET
The danger is the Forth technique of extending the language to fit the problem. There are so many Forth coders who are not trained in effective commenting techniques for Forth. Also, in so many of the places that Forth is used, it is used by one or a few people as a personal productivity tool, so there are no "house standard rules" for naming and documentation. It certainly can become unreadable
This is a very good question. It gives Chuck an opportunity to talk about what some in the Forth community see as the differences between a ColorForth-ish approach and the ANS Forth standard approach. Are the full featured systems from Forth Inc. and MPE, for systems from Unix through Windows through embedded systems, a waste of time? Should people writing Open Source software ignore the possibility of adding gforth as a weapon in their armoury? Should people writing in C, whether for Windows or Linux, ignore the possibilities of using Forth as a built-in scripting language using FICL?
... I can't wait until the answers come out.
IMO the answers are NO, NO and NO, and despite Chuck's criticisms of the standardisation process and where it might take Forth, that a "horses for courses" strategy means there are situations where it makes sense to "roll your own" system, all the way down to the hardware level, and there are situations where it makes sense to "go along to get along". You might lose some of the factors in Chuck's "1000 times" along the way, but you still get the interactive command line debugging of each and every routine before the routines are put to use, the support for efficient factoring down to routines of one to four lines (unlike stack frame languages like C), and flexibility to extend Forth into the language that fits your problem.
But that is guessing what Chuck might answer
I thought I would just point out that the "colourisation" is applied with a small collection of colour-change tokens that display as spaces. A text reader could generate distinctive tones of voice for each colour. A ColorForth editor for someone colour blind could "colour" the code with font changes instead of colour changes.
gforth (GnuForth -- check your favorite Gnu mirror, and available with Linux binaries) comes with three Object Oriented wordsets. One, a minimalist approach (that is, a "one screener", or toolkit within 16 lines), and two more full fledged versions.
The focus of much paid Forth work in the embedded environment means that there aren't as many generically useful public libraries as many newer languages, but it'll get there eventually.