dgary@ecsvax.UUCP (07/09/84)
<>
The referenced article notes that FORTH is often not efficient when
compared to compiled languages, giving as an example the phrase
A @ B @ + C !
and its FORTRAN equivalent C=A+B. Two comments:
First, FORTH is properly advertised as a fast, space-efficient interactive
development language. The operative word is 'interactive' which almost
(obviously, not quite) implies 'interpretive'. FORTH is rather speedy as
interpretive languages go. Furthermore, all 'real' FORTHs include an
assembler so that time-critical routines (typically a small part of
most applications) can be coded in assembler and then tested interactively.
FORTH is often best used as an interactive assembler.
A few ridiculous claims have been made for FORTH speed. The most ludicrous
is the assertion that FORTH code often executes faster than the equivalent
assembler program (!!!) an outrageous claim from no less than a FORTH
Interest Group (fig) brochure.
As for the example given, it is possible to speed it up by using constants
instead of variables, and writing a FORTH word that stores a new value in
a constant. That would make the phrase something like:
A B + := C
(The := word has to be IMMEDIATE and is best done in assembler, but
: := ['] ! ; IMMEDIATE
would probably work (haven't tried it), although you may need to
get rid of the brackets.)
D Gary Grady
Duke University Computation Center, Durham, NC 27706
(919) 684-4146
USENET: {decvax,ihnp4,akgua,etc.}!mcnc!ecsvax!dgarywmb@sun.uucp (Mitch Bradley) (07/13/84)
Gary Grady suggested using constants in place of variables to improve FORTH execution speed. The following syntax is suggested: A B + := C along with the implementation: : := ['] ! ; IMMEDIATE This implementation doesn't quite work; ['] is itself immediate, so this implementation of := actually just leaves the address of the word "!". One correct implementation is: : := ( value --name ) ( store into the constant whose name follows ) ' >body state @ if [compile] literal compile ! else ! then ; immediate This version works either in interpret mode or compile mode. The ">body" word is for Forth-83, in which "'" leaves the "compilation address" (cfa) of the word, instead of the "parameter field address" (pfa) of the word as in Forth-79 and FIG-Forth. ">body" should be omitted for Forth-79 or FIG-Forth systems. Historical perspective: An idea similar to this was suggested a couple of years ago in Forth Dimensions. Sorry, I don't have the reference handy. The name of the word was "TO" instead of ":=", so this concept has become known as "TO VARIABLES". They were used as: A B + TO C The implementation suggested in the article made such variables "smart" at execution time. The word "TO" set a global flag, and whenever a to-variable executed, it decided to fetch or store based on the value of the flag. This clearly had some bad features in terms of execution speed and the existence of the global state variable. Lately the idea has resurfaced in the form of so-called "QUAN"s. A QUAN is a variable that has three separate behaviors: 1) The default behavior is to fetch, that is to leave its value on the stack. 2) The secondary behavior is to store the value on the stack into the variable. 3) The tertiary behavior is to leave the address of the variable on the stack. Normally, QUAN variables behave as in 1). If the QUAN is preceded by the word "TO" (I think this is the correct word, but I may be wrong), behavior 2) is chosen, and if preceded by the word "ADDR", behavior 3 is chosen. The QUAN words themselves have 3 code fields, one for each of the behaviors, and the appropriate code field address is selected at compile time, thus eliminating the run-time speed penalty. The QUAN concept in various forms is getting a lot of attention. In particular, the last issue of the Journal of Forth Application and Research had two articles proposing a defining syntax for words with multiple code fields. Philosophically, such a word is an "object", in the sense that it defines a data structure and a set of operations which may be performed on that data. The concept is a useful one, and may usher in a whole new style of programming in Forth. If anyone is interested, drop me a line and I'll dig up the references and post them. Thanks to Gary Grady for bringing up the issue. Mitch Bradley decvax!decwrl!sun!wmb