Slashdot Mirror

The original book is available as a free PDF. https://www.forth.com/starting... The second programming book I ever read... 5th or 6th grade was it... after my TI-99/4A's "Extended Basic" manual.

Ummh...The information I gave was as I remembered it from Threaded Interpretive Languages. I agree about the name, but I never claimed the name was derived from Fortran. And https://www.forth.com/resource... says that it was actually to "compute ephemerides, orbital elements, satellite station positions, etc. ", so I may have mis-remembered the original purpose. Or perhaps TIL got it wrong.

Perhaps "derived from" (did I say that?) is too strong, and I should have said inspired by Fortran. (Inspired by Fargo would be more reasonable, but few had access to Fargo or even knew it existed. Fargo was a cut down Fortranish something for the IBM 1401. I never actually used it, so it might have been an interpreter rather than a compiler.)

SwiftForth or Factor?

Bought a shareware floppy of F83 Forth by Laxen & Perry.
Contains all the code from assembler, compiler, interpreter, editor, +++, Learned from reading the code. Forth is great for writing a word then executing it on the command line.
Forth code snippets in early Dr Dobbs Journal, before the Forth branch fell off their programming tree.
Forth group on bbs.
Starting Forth and Thinking Forth by Leo Brodie
https://www.forth.com/starting...
https://sourceforge.net/projec...
IBM PC technical manual with circuit diagrams and BIOS listing.
Programming machine code on an 1802 with a thumb-wheel prom programmer.

It is presumably an attempt at a joke based on the fact that Forth makes use of RPN.
https://en.wikipedia.org/wiki/...

I for one find Forth to be a fascinating language. The fact that it has been around for a while does not diminish it in any way.

I first heard of it back in the 80's while learning assembler on the 6502. I noticed it again while getting to know FreeBSD (loader stage 3) and decided to finally learn it when I came across some old manuals and software for my newly acquired PET CBM 8032 just a few weeks ago.

Ever since, I seem to notice it mentioned more and more, perhaps partly because of renewed interest in stack machines, but also because it offers an interactive way to boot strap a very small system with minimal resources.

It is available in some form on almost every platform that I know.

Following are some resources that I have found to be of interest. Hopefully those sites will not get badly hurt.

http://www.forth.com/starting-...
http://thinking-forth.sourcefo...
http://playground.arduino.cc/C....
https://www.freebsd.org/cgi/ma...
https://uwaterloo.ca/independe...
http://www.ultratechnology.com...

...

The reason I promoted Forth as a graphics communications protocol alternative to NAPLPS is the Western Electric Videotex terminals for the Viewtron service were so limited in RAM and ROM (far more limited than the first 4.77MHz IBM PC) that it needed a highly compressed representation of the firmware for decent graphics performance. Forth provided that and it would have further allowed dynamically downloading tokenized Forth stack functions (called 'words'). I talked about this with the guys at PARC late 1982 (prior to PostScript spinning off). Forth was lousy as a high level language but great as a macro-assembler for a hardware Forth chip -- a macro-assembler in which implementing the Smalltalk -- or Simula -- as an OS user interface would have had a very small memory footprint compared to a full-blown Smalltalk environment. Performance wise, the NOVIX chip was 16,000 transistors and was a full 16-bit wide FORTH hardware machine running at 24MIPS whereas the 8088 was 29,000 transistors but had an 8 bit bus running at about 2-3MIPS. Both were 3um technology. This initial implementation wouldn't have had enough memory to allow the full optimizations, such as type inference w/JIT etc that were then known possible and are now realized in the V8 JS interpreter, but it would have been at least as fast as BASIC as well as providing a clear migration path to vastly superior software development. As for price, well, Tesler was at PARC and had published on type inference -- and Jobs got him away. There's no particular reason something like small Simula core couldn't have been quickly implemented atop the Forth machine and Chuck Moore's low level drivers etc. In any event, IBM could have gone to Xerox and offered to buy PARC from them and Xerox would probably have sold it cheap. Xerox undervalued the work at PARC.

Starting Forth by Leo Brodie. Possibly the best book I've ever read about how to decompose a problem into chunks, and turn those chunks into code to solve the problem. As an added bonus, Forth works very well in immediate mode, allowing one to write and test simultaneously.

One of the things that strikes me, after reading your linked article, is the fact that not only could Bill Gates write "uber" code, back in the day, but that, in one form or another, EVERYONE that denigrates him does so from computers that exist because of what he and his company (among others) did so long ago.

Actually, at that time, many people were doing things like this. I am not sure whether writing BASIC in the first place can be considered "uber-code". How does this compare to, e.g., the work of Chuck Moore of the Forth fame? Now that is a man who would deserve some credit for pushing the state of the art. Take a look at what he did at NRAO with just one PDP-11 - I believe the DEC people themselves would not push such a system *that* far.

Or what about microFORTH? A FORTH system written in FORTH (not in assembly language), capable of "metacompiling" itself (in the FORTH parlance) for several CPU architectures - CDP-1802, 8080, 6800, Z80 - with interactivity, multiprogramming, and you could even have a simple form of virtual memory when you felt that it was necessary. And with just a 1K basic nucleus. How exactly does that compare to a primitive dialect of BASIC?

According to this history Moore added a push down stack around 1965 - While Polish and RPN had been around for some time since then I don't think there were too many calculators, probably some desktops, but the earliest HP calc I could find is this one - "In 1968, the Hewlett-Packard company was primarily a test equipment manufacturer." etc.

Which calculators are you referring to? Forth was initially developed during the year 1968 at Mohasco Industries in Amsterdam, NY and has roots going back to Chuck Moore's work in the late 1950s at an observatory.

RPN seems more of a side effect of how the language was designed (using stacks for transient storage) than a preconceived feature. If you really want to know I suggest you ask Chuck Moore :-)

The Evolution of Forth

Elizabeth Rather http://www.forth.com/

What did it run? Forth, of course!

(Sorry, just had to show there was a better alternative to BASIC back in the early '80s. I still do Forth regularly in OpenFirmware)

Forth was invented by Charles H. (Chuck) Moore.

A direct outgrowth of Moore's work in the 1960's, the first program to be called Forth was written in about 1970.

CSIRAC was, of course, a vacuum-tube machine; most of its 2000 tubes were 6SN7, 6V6, EA50 and KT66. Eventually button-based tubes were used in the delay line store electronics, germanium diodes and, much later, George Semkiw re-designed the disk read electronics using germanium transistors.

She now works with Forth, Inc. Check out forth.com. They have an excellent history of the language here. BTW, there are free Forth interpreters for just about every platform out there. It's a cool language.

Chuck Moore's own site is here

She now works with Forth, Inc. Check out forth.com. They have an excellent history of the language here. BTW, there are free Forth interpreters for just about every platform out there. It's a cool language.

Chuck Moore's own site is here

Forth post!

I'm on a roll today folks!

One starts understanding Forth by thinking small. What makes Forth still an attraction for many computer users, even after three decades, is what made it so attractive in the first place. It goes very fast in very small places. In the 1970's, Forth was attractive because all computers were small. Today, there are still many applications that have need for small programs on small hardware. NASA uses Forth in space. Almost any application that puts a premium on small program size could use Forth. The embedded market comes to mind.

Forth is its own language, its own development system, its own API, and its own user interface. (Some also say that Forth is its own religion, but I digress.) Traditionally, Forth is built directly on top of the hardware so there is usually no operating system. This is something which it does particularly easily and well. With Forth, one doesn't need an OS. That hasn't stopped people from extending Forth so that it does run on an operating system. There are multiple Forth implementations for Linux. There's one that runs on the Palm Pilot, too.

Forth is extremely interactive. Working in Forth means interacting with Forth from beginning to end of a project. Forth is its own toolset. It includes editors, compilers, interpreters, etc. Often sophisticated tools unheard-of in other computing domains are available, like meta-compilers for compiling whole Forth systems from old ones, decompilers and disassemblers for creating source code from compiled code, and other fanciful things.

Windows users inevitably chafe at Forth. Not able to understand a simple Unux console where one is able to do everything a Windows user can do, the Forth console seems like a desert. To every typed command it responds with either cryptic gibberish or the equally puzzling ok. There is not only no graphical hand-holding, there isn't even an operating system to comfort the user. To the uninitiated it seems unnecessarily barren. To the everyday Forth user, that's just fine.

The Forth language and tools are small. There is only a rudimentary parser implementing an absolutely context-free and grammar free language. There is no error trapping unless you put it in yourself. All data is stored on a push down stack which operates with RPN just like an HP calculator. Floating point is not supported, but powerful rational integer arithmetic is. Savants won't have to dust off their rational approximations.

The language has compiler building elements built into it. You can create your own mini-compilers at will. The fact that floating point isn't part of Forth doesn't mean that it can't be. There are all sorts of extensions available for any number of purposes, including floating point and a bazillion operating system ports.

Although there is an ANSI standard, don't bet that adherence to the standard will mean code will be portable. Generally, so much of any given Forth installation is local enhancement, code just can't be made portable. Then there's the OS problem. A Forth running on top of an operating system is guaranteed to be non-portable to anything other than an identical installation. At least in the pure Forth environment one doesn't have the OS in the way of the standard Forth core functionality.

The Forth language is composed of a collection of words, each of which contains the implementation of a particular computing task. Forth words can be considered like functions in any of the more traditional computer languages. Where Forth differs is in the details of the implementation and the extent to which the Forth model is implemented throughout the system.

At the bottom, Forth starts with a core set of words which are written in the native language of the processor. But with Forth, even these core elements are not traditional machine language. All of Forth, including its machine language core, is implemented in Forth. Although Forth's machine code core is executed directly by the CPU, the entire process is under complete control of the Forth interpreter. Forth isn't slowed down by this interpreter control. The interpreter gets out of the way so that the native code runs at native code speed.

The Forth interpreter is tiny, even miniscule. On the general purpose processors of today, a Forth interpreter inner loop is a trivial task, often composed of a single CPU instruction which is assembled wherever it is needed. This kind of efficiency fairly screams for a hardware implementation. Thus, there are small, inexpensive processor chips which implement Forth in hardware.

The body of a Forth word is composed of two main elements, a code field and a data field. The code field contains the address of native code which executes the word; the data field contains information which depends on the type of word. For words coded in native code, the data field contains the actual assembled machine instructions for the word. The code field of such a word then points directly to the first machine instruction in the data field. For normal high level interpreted Forth, the data field contains the sequence of code field addresses of the Forth words that make up its definition. The word's code field then points to the Forth interpreter.

The inner loop of a typical Forth interpreter steps through the list of code field addresses in the data field of a word, dereferencing each, and passing the result to the CPU's instruction pointer for execution. On many architectures this is a single CPU instruction. If the referenced word is another high level Forth word, the current interpretive address is saved on the return stack (push context) and the interpreter inner loop is reentered at the next lower level. If the referenced word is one implemented in native code, nothing more need be done since the inner loop will have already pointed the CPU to the word's native code.

Each Forth word ends by jumping to the code that pops the stack to restore the interpreter to its context before it began executing the current word. Often a single instruction, this code is usually assembled in situ.

From another point of view, the Forth interpreter threads its way through the code until it eventually bottoms out at a word defined in native code, which the processor merely executes.

The reduction of a function call to a bare address saves considerable space. The interpreter for such encoding is so small that it can be placed in situ. There are Forth implementations which save the dereferencing step in the interpreter inner loop by placing the code in-line in the code field. Forgoing floating point for near native rational integer math adds tremendous efficiency. All of these savings are replicated from top to bottom in any Forth implementation. It's not surprising that compiled Forth is much smaller than almost any computer language known. Typically, entire Forth implementations are tens of kilobytes, not megabytes. Typical run-time programs are often very few kilobytes. That's tiny. To top it off, they run at near native code speed. That's fast and tiny.

Therein lies the longevity of Forth.

Want to know more?

Try the History of Forth at Forth, Inc.

Why Palm?
Try Something smaller like a true REX palm top. My goodness you might as well be carrying arround an ENIAC.

And why use such a large virtual machine, last time I looked the FORTH compiler was only 4K, not the 191K of storage / 64K heap of PALM Python.

From the comp.lang.forth FAQ:

"What is Forth?"

Forth is a stack-based, extensible language without type-checking. It is probably best known for its "reverse Polish" (postfix) arithmetic notation, familiar to users of Hewlett-Packard calculators: to add two numbers in Forth, you would type 3 5 + instead of 3+5. The fundamental program unit in Forth is the "word": a named data item, subroutine, or operator. Programming in Forth consists of defining new words in terms of existing ones. The Forth statement

: SQUARED DUP * ;

And, from Rather, Colbourn, and Moore: The Evolution of Forth in: History of Programming Languages (HOPL-II), ACM Press/Addison-Wesley 1996.

"The name FORTH was intended to suggest software for the fourth (next) generation computers, which Moore saw as being characterized by distributed small computers. The operating system he used at the time restricted file names to five characters, so the "U" was discarded. FORTH was spelled in upper case until the late 70's because of the prevalence of of upper-case-only I/O devices. The name "Forth" was generally adopted when lower case became widely available, because the word was not an acronym."
--
Cheers

I'm getting off topic, I suppose, but Legos aren't the only platform where FORTH is available and you are not going to waste your time learning it.

Versions, free and commercial, exist for any Unix with GCC, DOS, OS/2, Macintosh, Windows, the Palm Pilot, and dozens of microcontrollers. Did you know that FORTH is part of the Open Firmware provided in the Sun and the PowerMac boot proms? (Note IEEE requires a subscription, so check out Sun's OpenFirmware page)

The experience on one platform transfers well to another and there is lots to like about FORTH, especially when dealing with an environment with exceedingly limited resources in comparison to a PC.

This list of FORTH implementations by platform is a little dated but should point in the right direction.