6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Wed Nov 13, 2024 7:05 am

All times are UTC




Post new topic Reply to topic  [ 19 posts ]  Go to page 1, 2  Next
Author Message
PostPosted: Mon Apr 14, 2014 11:16 am 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10977
Location: England
"Forth is the simplest language. It is simpler than Logo and it should be taught to children after counting and before long addition."
ANSI Forth is ANTI Forth - Another politically incorrect essay

"One of the worst forms of Forth abuse in my opinion is to translate 'C' directly into Forth. The code needs to be designed to use the stacks or it is not really Forth. I can think of an example where an assignment to write a jpeg decode and display routine was given to two programmers. One simply translated the code from a 'C' program into Forth. The second wrote Forth code. The former program had bugs and was 100 times larger and 1000 times slower than the latter."
Low Fat Computing - A politically incorrect essay by Jeff Fox 1998

(I found it useful to use Readability.com to make both these pages readable: see http://rdd.me)

Cheers
Ed


Top
 Profile  
Reply with quote  
PostPosted: Mon Apr 14, 2014 5:59 pm 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8540
Location: Southern California
Wow-- very, very impressive! I bookmarked them. Thanks!

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?


Top
 Profile  
Reply with quote  
PostPosted: Mon Apr 14, 2014 6:11 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8483
Location: Midwestern USA
BigEd wrote:
"Forth is the simplest language. It is simpler than Logo and it should be taught to children after counting and before long addition."
ANSI Forth is ANTI Forth - Another politically incorrect essay

Good reading, although I currently have no interest in Forth. Fox's opinion that ANSI could be a Forth killer, while possibly a bit over-dramatic, does have an element of truth. Standards bodies abhor change, even when it's for the better.

From the article:

    What I see as the power in Forth is that it is interactive, real, and simple. You can get right down close to the metal and write the important functions to be as fast as possible and test them in a short amount of time.

That sort of describes assembly language, at least the part about getting close to the metal and making functions run real fast.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!


Top
 Profile  
Reply with quote  
PostPosted: Mon Apr 14, 2014 6:24 pm 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8540
Location: Southern California
I think what he meant, besides writing the code faster than you can in assembly, is that you can try it on the target computer instantly, without needing to re-assemble the whole thing and transfer the new image to the target computer. For my workbench computer, I use the PC for editing and storing programs, and the workbench computer (the target computer) is connected by RS-232 running at only 9600 bps yet I can write a short routine, mark it as a block on the editor, and send it to the workbench and have it running before I can turn around to see the process. From the time it exists only as source code to the time it is compiled into the bigger picture and actually running is often a fraction of a second.

I think the second article was more impressive though. He definitely skewered some sacred cows.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?


Top
 Profile  
Reply with quote  
PostPosted: Tue Apr 15, 2014 9:17 am 
Offline

Joined: Mon Jan 07, 2013 2:42 pm
Posts: 576
Location: Just outside Berlin, Germany
Thanks for those. One of the things I have noticed about the various Forths available is that they talk about being "close to the metal", but a lot of them just have a few core words in assembler, and then everything else is just hi-level, even when it could be easily optimized (like calling a subroutine for DROP). Of course, there are words where it is just silly or counterproductive to write them in assembler -- things like IF or LOOP -- but it has gotten me wondering if the portability of a Forth's source code (not of the Forth programs themselves) is not inverse proportional to its use for that one platform.

Then again, I just could be thinking that to justify all of the assembler I'm writing :-).


Top
 Profile  
Reply with quote  
PostPosted: Tue Apr 15, 2014 9:48 am 
Offline

Joined: Tue Jan 07, 2014 8:40 am
Posts: 91
Ah, there you touch on a long-standing debate: how much of the Forth kernel should be in assembler? If I recall correctly, the theoretical minimum is about 14 assembler primitives, but that's not a practical Forth -- just an intellectual exercise. eForth elected to have about 30 primitives, for ease of porting; but it was pretty slow. For CamelForth I settled on about 70 -- not too many to make a major project out of porting to a new CPU, but enough to include otherwise-slow operations like multiply, divide, and string compare. As a Forth implementation gets mature, and concentrates on a single platform, its authors tend to move more of the kernel into assembler. I think gForth has several hundred primitives.

The main arguments for high-level kernel words are portability and compactness. I've heard it argued that any kernel word which is smaller in assembler (for a given CPU) should be coded in assembler. That's a persuasive argument, but it does make life more difficult for the next person who wants to port that Forth to a new CPU.

_________________
Because there are never enough Forth implementations: http://www.camelforth.com


Top
 Profile  
Reply with quote  
PostPosted: Tue Apr 15, 2014 4:31 pm 
Offline

Joined: Sat Aug 21, 2010 7:52 am
Posts: 231
Location: Arlington VA
@Big Ed - Those were very cool articles! Thanks for the link.

To me, the ethos of Forth, that which gives it its "Forthiness" is this
    git er dun
    using minimal resources (tight code)
    there's a dictionary
    there's a data stack
    there's a return stack
    the programmer can get to bare metal

So ColorForth, embedded headerless target-compiled Forth, ANSI Forth, it's all Forth. Good Forth is well-factored. Ruby developers call this the DRY principle.

I discovered Forth when R.L. Loeliger's "Threaded Interpretive Languages" book came out when I was 19, working at ComputerLand in 1981, shortly before and after the time the IBM PC was first introduced. I'd been programming for 5 years, mostly BASIC but also Z-80 and 6502 assembler, and some time I stole on the mainframes at University of Michigan in Ann Arbor, and Delta College in Saginaw. I worked at a push rod factory in 1984 and managed to convince my boss to let me use MMSForth instead of TRSDOS, but that's my only professional experience in Forth. On my C=64 I worked a lot with Scott Ballantyne's Blazin' Forth in the late '80s.

Back then, I decided that the coolest thing about Forth was that Forth is written in Forth. Gforth does not do this. Nor does my PETTIL, which is currently implemented in 6502 assembler (buildable with xa65). Is this self-generating aspect a necessary ingredient?


Top
 Profile  
Reply with quote  
PostPosted: Tue Apr 15, 2014 4:50 pm 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10977
Location: England
The great thing about a self-hosted language is that you only need a flaky low-performance native implementation on any given platform to build the self-hosted version.


Top
 Profile  
Reply with quote  
PostPosted: Tue Apr 15, 2014 5:07 pm 
Offline

Joined: Sat Aug 21, 2010 7:52 am
Posts: 231
Location: Arlington VA
Consider this: On every processor I've ever seen, zero is a valid address. Apparently on my 8-core AMD bulldozer CPU, this is no longer the case. Or Gforth can't get there from here. Is the bare metal gone?
Code:
$ sudo gforth -e '100 . cr bye';sudo gforth -e '100 @ . cr bye';
100

*OS command line*:-1: Invalid memory address
100 >>>@<<< . cr bye
Backtrace:
$


Top
 Profile  
Reply with quote  
PostPosted: Tue Apr 15, 2014 5:12 pm 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10977
Location: England
You're running linux - that's not bare metal! To help with accidental use of zero pointers, it's normal to make some fraction of low memory inaccessible.


Top
 Profile  
Reply with quote  
PostPosted: Mon May 26, 2014 10:46 pm 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8540
Location: Southern California
I just re-read the "Low-Fat Computing" article linked above, and it leaves me hungering for more-- more on how to make better use of the computing power available at a given point of hardware cost and complexity, more on how to get so much useful programming in so little memory, more on how to keep a big (for me) project from getting out of control, more, more, more. My last project seems to have maxed everything out for the hardware I have been working on, yet this article makes me feel like kind of a novice. If you haven't read it yet, do! It will change your perspective!

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?


Top
 Profile  
Reply with quote  
PostPosted: Tue Jun 10, 2014 6:51 am 
Offline
User avatar

Joined: Sun Jun 30, 2013 10:26 pm
Posts: 1949
Location: Sacramento, CA, USA
GARTHWILSON wrote:
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.
Quote:
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. ;-)


Mike


Top
 Profile  
Reply with quote  
PostPosted: Tue Jun 10, 2014 7:24 am 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8540
Location: Southern California
In a debate in Forth Dimensions magazine, I remember one man who said Forth definitions should only be a line long, two maximum, and that screens were like 3x5 cards. I couldn't tell if he meant that in a positive or a negative way. Later he and I had some personal correspondence by mail (the internet didn't really exist yet), and he sent me his routine to do something, and it was over 100 lines for one word. Looking at it though, I couldn't really see any way to factor it and give the factors meaningful names that were any shorter or more descriptive than the code and comments in it. You would have ended up with code that was more unreadable, and more inefficient because of calling all these single-use "subroutines". I seem to remember it had a giant CASE statement that was very clear. I seem to remember Chuck Moore doesn't like CASE statements. Jump tables are good if the input numbers are consecutive and without big gaps; but that's not always the situation.

Quote:
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.

FWIW, my assembler does not need a separate vocabulary.

I do remember a couple of things Chuck Moore was preaching that he later recanted, because his experimenting with the new ideas didn't turn out as rosy as he had hoped. One was something about the map not being the land-- although I don't remember details of the analogy. I'm still somewhat interested in stack processors though, which definitely have a very, very high ratio of computing power to hardware complexity.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?


Top
 Profile  
Reply with quote  
PostPosted: Tue Jun 10, 2014 3:10 pm 
Offline
User avatar

Joined: Sun Jun 30, 2013 10:26 pm
Posts: 1949
Location: Sacramento, CA, USA
GARTHWILSON wrote:
... and it was over 100 lines for one word. Looking at it though, I couldn't really see any way to factor it and give the factors meaningful names that were any shorter or more descriptive than the code and comments in it. You would have ended up with code that was more unreadable, and more inefficient because of calling all these single-use "subroutines". I seem to remember it had a giant CASE statement that was very clear. I seem to remember Chuck Moore doesn't like CASE statements. Jump tables are good if the input numbers are consecutive and without big gaps; but that's not always the situation.


Global optimization is an inexact science, and you were probably correct that the word in question was optimal. The question I would ask: "If you step way back and look at the entire picture, is there a clever way to avoid having to code that particular word in the first place?"

It reminds me of a joke that I heard on the radio years ago that still makes me laugh. An astronaut and a cosmonaut were talking at a bar over a couple of drinks, and the astronaut pulled out a fancy ink pen that could survive extreme cold and heat, and write upside down and in zero G. He bragged about how NASA had spent hundreds of thousands of dollars developing it and the ink that it used, and that it was an example of what was possible in the 'free' world. The cosmonaut instantly recognized this dig at his country, but had a perfect reply: "On Soyuz, we use pencil."

You can see where my analogy is clumsily headed, right? Is the routine you mentioned the 'INK' for the pen?

Mike


Top
 Profile  
Reply with quote  
PostPosted: Tue Jun 10, 2014 7:01 pm 
Offline

Joined: Sat Aug 21, 2010 7:52 am
Posts: 231
Location: Arlington VA
barrym95838 wrote:
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.

Link to the original posting in comp.lang.forth

GARTHWILSON wrote:
FWIW, my assembler does not need a separate vocabulary.

I would really like to see it. Is it somewhere online?


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 19 posts ]  Go to page 1, 2  Next

All times are UTC


Who is online

Users browsing this forum: No registered users and 13 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to: