Differences between version 25 and predecessor to the previous major change of Forth.
Other diffs: Previous Revision, Previous Author, or view the Annotated Edit History
| Newer page: | version 25 | Last edited on Saturday, July 29, 2006 11:24:50 am | by AristotlePagaltzis | Revert |
| Older page: | version 24 | Last edited on Saturday, July 29, 2006 11:24:02 am | by AristotlePagaltzis | Revert |
@@ -1,7 +1,7 @@
-!!! YOU FORTH LOVE IF HONK THEN
+!!! <tt>
YOU FORTH LOVE IF HONK THEN</tt>
-[Forth] is a ProgrammingLanguage developed by ChuckMoore in the 1960s (see the [history of Forth | http://www.forth.com/Content/History/History1.htm]). Forth is a [Stack] based language with a ReversePolish syntax. A function call is very fast as the arguments are those on the [Stack] when the program enters and the return value is left on the [Stack] when it exits.
A Forth program consists of many small functions, with just the essentials written in AssemblyLanguage.
+[Forth] is a ProgrammingLanguage developed by ChuckMoore in the 1960s (see the [history of Forth | http://www.forth.com/Content/History/History1.htm]). Forth is a [Stack] based language with a ReversePolish syntax. A function call is very fast as the arguments are those on the [Stack] when the program enters and the return value is left on the [Stack] when it exits. A Forth program consists of many small functions, with just the essentials written in AssemblyLanguage.
[Forth] is used in embedded systems. It produces very compact code. A whole [Forth] interpreter and development system will fit into 8 kilobytes, easily, and leave plenty of room for code. Back when the computer with 8 kilobytes of [RAM] that you were to write programs for was ''also'' the the computer you had to write programs ''on'' [Forth] was very popular.
!!! Implementations
@@ -18,9 +18,8 @@
It has a VirtualMachine and kernel (see below) written in [C].
It might be a good one to study.
[RetroForth | http://retro.tunes.org]:
Both a ForthOS and a [Forth] for [Linux] systems.
- It's written with a small AssemblyLanguage kernel and the rest is written in [Forth].
[bigFORTH | http://bigforth.sf.net/]:
A native code compiler for [x86] which includes a [GUI] library and form editor.
[Forth] is also the basis for the [RPL] language used in HewlettPackard calculators and OpenFirmware.
@@ -31,25 +30,27 @@
<br>— Jarkko Hietaniemi
''This is a general description of how [Forth] works. It's __different__. If you like [Brainf*ck] you will like [Forth].''
-[Forth] functions are called ''words''.
+[Forth] functions are called ''words''. which are organised in the ''user dictionary
''.
-A [Forth] machine has four
stacks. When subroutines (called ''words'' in [Forth] lingo) are called they pop arguments off the ''parameter stack'' and push back return values. The ''return stack'' holds the return addresses of word calls. Variables and ByteCode word definitions are pushed onto the ''user dictionary'' stack as they are defined. The last stack is just an input buffer for the [Forth] parser
.
+A [Forth] machine has two
stacks. When subroutines (called ''words'' in [Forth] lingo) are called they pop arguments off the ''parameter stack'' and push back return values. The ''return stack'' holds the return addresses of word calls.
-[Forth] programs are written in ReversePolish notation. [Forth] words access
the ''parameter stack'' directly to fetch arguments and leave return values. The stack is also used
for temporary storage, as there are no local variables in [Forth]. There are words for flipping around values on
the top of the stack to help you with this. As you program in
[Forth] you must keep careful track of what is supposed to be on the stack at every point. This is all
part of ChuckMoore's philosophy of brutal simplicity in software engineering, and the most indigestible aspect of
[Forth].
+Finally,
the input buffer
for the [Forth] parser forms an integral
part of a
[Forth] system
.
-Layers of
words on
the ''user dictionary''
stack are called ''vocabularies
''. The first vocabulary
is a tiny kernel of word definitions written in MachineCode
, then
there is a standard library vocabulary defined
in [Forth] ByteCode~s, then there
are optional vocabularies than define a tiny text editor, assembler and disk operating system
. (I guess a modern
[Forth] system would have a TCP/IP stack
on there somewhere too
.)
+[Forth] programs are written in ReversePolish notation. [Forth]
words access
the ''parameter
stack'' directly to fetch arguments and leave return values
. The stack
is also used for temporary storage
, as traditionally
there are no local variables
in [Forth]. There
are words for flipping around values on the top of the stacks to help you with this
. As you program in
[Forth] you must keep careful track of what is supposed to be
on the stack at every point. This is all part of ChuckMoore's philosophy of brutal simplicity in software engineering, and the most indigestible aspect of [Forth]
.
-There
is no syntax
in [Forth], just words for manipulating byte-codes
, input buffer
and the user dictionary
.
+The ''user dictionary'' looks a bit like a stack and
is organised in sets called ''vocabularies''. The first vocabulary is a tiny kernel of word definitions written in MachineCode, then there is a standard library vocabulary defined
in [Forth] (compiled to ByteCode)
, and then optional vocabularies that define a simple text editor
, assembler
and disk OperatingSystem. (A modern [Forth] system might have a [TCP/IP] stack on there somewhere too
.)
-The word <tt>:</tt> tells
[Forth] to begin compiling subsequent
words on
the input buffer.
+There is no syntax in
[Forth], just
words for manipulating other words,
the input buffer and the user dictionary
.
-Some words have flags that tell [Forth] to execute them immediately while compiling: these create control structures in the ByteCode. Ordinary words are compiled into <tt>call</tt> statements. Words that look like integers are compiled into <tt>push</tt> statements. The word <tt>;</tt> pushes the new defintion onto the dictionary and ends compilation. (It goes ''something'' like that anyway. I think I'm giving you
the gist.)
+The word <tt>:</tt> tells [Forth] to begin compiling the subsequent words found on the input buffer.
+
+
Some words have flags that tell [Forth] to execute them immediately while compiling: these create control structures in the ByteCode of a word
. Ordinary words are compiled into <tt>call</tt> statements. Words that look like integers are compiled into <tt>push</tt> statements. The word <tt>;</tt> pushes the new defintion onto the dictionary and ends compilation. (This is
the gist.)
You use <tt>:</tt> to add new words to the [Forth] system until you've created a high-level [Forth] vocabulary that you can easily express your problem in… then you just keep going until you've defined a single word that, when called, executes your entire program. [Forth] is very much a BottomUp language. :-)
-MachineCode statements can be used as [Forth] ByteCode~s so the machine can execute it
directly. The machine will mostly be executing call statements, but this does at least remove the need for an inner loop in the interpreter
. This is called ''subroutine threaded interpretation
''.
+MachineCode statements can be used as [Forth] ByteCode~s so the machine can execute them
directly. This is called ''subroutine threading
''. It is one of a number of approaches to reduce the overhead of interpretation (which spends a lot of time executing call statements)
.
Real [Forth] geeks write their own [Forth] kernels from the metal up. (I wrote my own, on paper, when I was 14. (I don't think I can do that anymore.) I was working from a [Forth] book and a Z80 opcode table; I didn't have a computer. I still have pieces of it. God knows if it would have worked.) ChuckMoore creates his own [Forth] machines from silicon. It's not ''very'' hard once you've absorbed the [Forth] philosophy. There is shockingly little holding [Forth] up.
!!! Examples
