I just re-read the "Low-Fat Computing" article linked above, and it leaves me hungering for more--
I had this copied and pasted from comp.lang.forth, but I lost the URL. It's from 'foxchip', and it seems very likely that it's Jeff Fox. I also fixed a couple of minor typos. He is very eloquent when he's angry.
Adam Warner wrote:
> And elsewhere in this thread you write, "Our goal is to make the hardware
> and software smaller, cheaper, faster, and easier to program." I don't see
> a conceptual foundation for the claim this hardware/software combination
> is easier to program.
The documentation goes back almost twenty years. If you have been following it you have seen the explanations of the conceptional foundation for each of the changes introduced. Because much of it is ancient history now probably the only place you will find it is in the old pages at my site that document that fifteen year period where Dr. Ting and I wrote the only documentation.
Take the removal of ELSE for instance.
This clearly had nothing to do with hardware in that an ELSE is just a jump and the machines all have had jump instructions.
Like dozens of other things Chuck explained his reasoning.
People had experimented with factoring Forth code many different ways and there were many debates about favoring using ; or factoring using IF ELSE THEN or IF THEN or nested IFs and BEGINs and FORs and DOs and CASE and RECURSE etc.
He concluded that he wanted to enforce a higher degree of factoring than he saw in other people's code where their definitions didn't use ; factoring very much. I can think of many people who have posted Forth definitions in c.l.f that had 100 lines between semicolons and deeply nested IF BEGIN DO constructs between the : and ;
This looked very much like the C code from which it was copied, but it never looked like good Forth to Chuck who felt that more factoring into Forth words was better.
And the idea of Forth chips was to make things that are good to Forth, less of a penalty to encourage their use. So calls and returns were emphasized as were all the other Forth primitives. The idea was that people were writing unreadable page long Forth words perhaps because they were afraid of the overhead of using : ; on some architecture, or because they were copying C, or because it was their habit to only nest IFs 7 levels deep and DOs 7 levels deep inside of a single definition
So instead of using ELSE, Chuck wanted to use ; instead.
This would keep words short and simple as in:
: DEMO blah if this ; then that ;
Chuck said, for those interested in the conceptual foundation for why he removed ELSE, that this would enforce factoring into smaller definitions and make the code easier to write, to read, and to maintain.
He said, if you make your code that simple that most of the errors that happen to people in the page long definitions, that are so popular in c.l.f, would not happen. He said if you use that kind of simple one liner definitions and test them that most of the errors that other people see will be impossible.
And for those interested in the conceptual foundation we followed through reporting that this had indeed had the effect that Chuck had hoped. Forth code with short definitions is easier to read, easier to write, and easier to maintain.
And pretty much everyone in Forth seems to agree with that last sentence. The problem is that there is no hard definition for short. I hear people say, I write short words in Forth they use usually less than one page. I see a lot of 100 line Forth words in c.l.f along with people saying that short definitions are good things.
This is why I added that in measurements I made over a year words averaged 1.2 40 character lines in Length, and the typical word was the size of DEMO above or smaller.
There are about 20 things like that that explain the reasoning why things were done the way they were done in the last twenty years by the inventor of Forth to try to improve the language and make Forth more Forth-like. And the 20 things over 20 years are all documented and explained.
But when people skip over the hows and whys and look at what appears to be more or less the same old Forth instruction set, and they don't appreciate how the instructions work with one another, how one puts them together, how the compiler works, how the code is intended to be written to make Forth work better they are easily confused.
And if they read c.l.f where 90% of what is written about this is confusion and guesses they are likely to be very confused.
We say, we did this particular thing to de-emphasize JUMPs and emphasize proper Forth factoring yet people ask why we 'emphasize jumps.'
We say that we emphasize the use of the stack but people ask why we de-emphasize the use of the stack.
We say that we want to encourage the use of Forth by showing how the code can be made smaller, faster, easier to read and write and maintain, and at the same time the hardware can be made smaller and faster and cheaper if both work together nicely in a Forth way. And we say, if you want C hardware and C software then this doesn't apply to you. We are talking Forth.
And I like to remind people that the opinion of most of the programmers who have done the 100 man years of work using this stuff have said that Chuck was right in his conceptual foundation and that the optimizations did increase their productivity. But of the people with that 100 man years of experience I am about the only one who posts in c.l.f. And for the most part those who do post about things like the MISC instruction set have at most a few hours or a few days exposure and have been exposed to 90% wrong guesses anyway and that is mostly what they remember.
> On the contrary I see no support for Forth's primary abstract data type:
> the stack.
Forth is about words, and words need a stack so most of Forth words manipulate the stack.
I am at a complete loss to understand how you can't see that Forth needs stacks.
> Non-tail recursion will very quickly use up the six or so free
> slots in "these kinds of stacks" before wrapping around and corrupting
> data.
P21 only had 4 levels on the return stack. My old fashioned style Forth didn't fit well. And I wrote an ANS Forth. In fact I wrote about 30 to compare.
And I learned more about what Chuck thought was 'good' Forth and realized that one of the big differences was that because my code was not well thought out or well factored it was wasteful and easily used up resources without doing much. But I learned what Chuck had meant when he said that he had put in about all that was really needed for good Forth code.
You have to understand the conceptual foundation about how Forth code should be constructed and factored. And people do get confused about how code can have short words and lots of : and ; and also use a minimal amount of the stacks! It is no different than people having trouble understanding how someone can balance on a bicycle, once they learn to do it they do it by reflex and it is easy. If you have never done it it might look hard. And some people try it, fall off, and decide it is hard and never try again. So we see page long Forth words.
> If this hardware/software combination has no effective support for
> non-tail recursion it will be less expressive and harder to program for
> than hardware and software with support for large stacks.
>
> So what is the abstract data type driving this programming model? If one
> depends upon the semantics of pushing/popping
* pushing and popping is what you do at the top of a stack
* that use is what defines them as stacks
* stacks are not infinite, they are finite
* what goes on at the bottom is optional, wrap or error throwing hardware
> a wrap-around bank of slots
> then code will be tied to the specific number of slots implemented by the
> hardware. Such code will break if the number of slots is ever increased,
> and this is bound to occur in future revisions of hardware.
OK, more conceptual foundation review:
P21 had 3 and 6 and F21 had 18 and others have had different stack depths and it has not been a problem.
Stack depths are configurable in most Forths and it is not a big deal. It is called an environmental dependency in ANS language.
> In other words you're writing assembly code!
OK, more conceptual foundation review:
Yes. We have created a Forth that is also assembler.
This eliminates the need for an assembler vocabulary and separate function that makes Forth a lot simpler and easier.
This makes the operation of the optimizing compiler straightforward so we have the isomorphic properties of old fashion threaded Forth that are what still have some people using those 35 year old Forths. They don't have the complications imposed by optimizing compilers that produce code that doesn't directly match up against the source code, which are not easily manipulated in a mechanical fashion, and which may complicate debugging problems introduced by hidden optimizations.
So we get the added benefit that the compiler is also made simpler and smaller and faster.
I find it interesting to read things Chuck wrote about Forth ten years before I met him. He was explaining this stuff 30 years ago and I sure didn't get it then. I felt that I began to get it fifteen years ago and began trying to document it. Chuck said that he thought I got it and that I did a better job of documenting it than he. And he encouraged me to document it.
Some people have hated that I documented it. But I still try to answer people's questions when they ask.
> What is the higher level
> language that is easier to program for that generates code for this CPU?
Forth. Classic Forth with some enhancements in the last twenty years called machineForth and some in the last ten years called colorforth. And we have had variants for parallel programming as well that are other variants of Forth. Forth.
> And how is this hardware a good fit for that higher level language?
OK, more conceptual foundation review:
The compiler is simpler, smaller and easier to understand.
The generated code is simpler, smaller, and easier to understand.
There is no extra assembler language.
There is no underlying foreign architecture to understand or map to Forth.
The mapping is direct and simple.
The generated code is easy to debug.
The generated code is easy to manipulate.
Those are the advantages of classic threaded Forth, combined with the advantages of assembler, combined with the advantages of optimizing compilers, and yet when combines still simpler than any single one of them in a conventional system.
We usually have the shortest source.
We usually have the least object code.
We sometimes lose on speed on things we want to do to chips that cost hundreds of times more.
We sometimes beat those chips by a huge margin on things we want to do.
We don't try to compete for Windows or FP apps.
But we have clearly demonstrated shorter, simpler, and faster code, ad-nauseum for many years. And I often repeat the explanations for those who have somehow missed the megabytes of explanations of the conceptual foundation in the past and want it again in c.l.f.
> You've already described how a DUP DROP combination cannot be optimised
> away because DUP is destructive.
OK, review:
I can when you don't care about the bottom of the stack. But if you are using the whole stack then you can't optimize it away, because it is an optimization already.
> In an abstract programming model it
> should be a conceptual no-op and a compiler will be required to make DUP
> appear non-destructive by handling slot spills
What is a slot spill?
We have four slots for op-codes in an instruction word.
> instead of corrupting other slots.
Every item written to any stack overwrites something. period. There is no system in which that doesn't happen.
> This sounds a lot like the handling of register spills by compilers
> for register machines.
I realize that many people try to understand Forth in the context of compilers for register machines. You really can't understand what we are doing however that way as it is completely different than that. That is the whole point. It is completely different than that.
> You may be able to make the case for a new programming model based upon a
> different abstract data type and virtual machine that is arguably superior
> to the Forth two-stack virtual machine.
The inventor of Forth said that he has been making improvements to the language and to the underlying virtual machine since he invented the language. He has provided a conceptual foundation and explanation for each of the improvements.
Some people heard about his Forth 35 years ago and made copies. And people made copies of the copies. And 40,000 people joined FIG and made a standard of the copies of the copies. And people followed those standards and modified them for standards from the late 70s, early 80s, and staring in the mid 80s.
And many quit paying attention to the step by step improvements the the inventor of Forth was explaining for thirty years and then said, "I have been doing Forth for 30 years and know all about it, and I don't know what this guy is doing, but it isn't Forth!"
I think it is funny that so many people in c.l.f say that they know so much about Forth that they know that the inventor of Forth isn't doing Forth, doesn't understand Forth, doesn't know what Forth word is, doesn't know what a stack is, and simply doesn't understand programming or computers.
Sure he "may" be able to "make the case" for some "new programming model" based on a "different abstract data type" and a "virtual machine", that isn't the Forth virtual machine, and then conceivably "argue" with you, that it is "somehow" (since you doubt it) superior to Forth but to do that they would have to accept your expert opinion that it isn't Forth in the first place. That's very gracious of you.
Perhaps you should write to Mr. Moore and tell him about his Forth language that he should consider instead of "whatever thing he is chasing down at the moment" instead of your language, Forth.
Maybe he hasn't heard about this language that you invented called Forth.
Login
Register
FAQ
Search
.