Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!samsung!uunet!zephyr.ens.tek.com!tekcrl!tekgvs!toma
From: toma@tekgvs.LABS.TEK.COM (Tom Almy)
Newsgroups: comp.lang.forth
Subject: Re: Some Code
Message-ID: <6396@tekgvs.LABS.TEK.COM>
Date: 20 Nov 89 20:37:28 GMT
References: <5187@sdcc6.ucsd.edu>
Reply-To: toma@tekgvs.LABS.TEK.COM (Tom Almy)
Organization: Tektronix, Inc., Beaverton,  OR.
Lines: 49

In article <5187@sdcc6.ucsd.edu> ir230@sdcc6.ucsd.edu (john wavrik) writes:
...
>This solution is for F-83:
>VARIABLE OSTATE      ' : @ CONSTANT DOCOL                 
... (lots of code)
>These words are interesting because they bring up a point: they do not involve 
>assembly language, but they involve a knowledge of how traditional Forth is 
>implemented. They involve knowing what is put in the return stack, how a 
>dictionary entry is compiled, what a dictionary entry looks like, etc. (The 
>amazing thing is that the definitions above will work on any traditionally 
>implemented Forth regardless of processor! 

Which brings up a sore point about any of these. This code, and most of
the "interesting" stuff that gets published, is very non-portable. What
is a "traditionally implemented Forth" anyway? And how many implementations
are traditional?

The 83 standard specifically says you cannot use tick to reference any
data that you didn't explicitly compile. This example fetches from the
compilation address of a word. I use a number of different Forth 
implementations, but *none* of the ones I use will this work as intended.

That's not to say that this posting is "bad". Far from it. The problem, if
indeed there is one, is that this sort of program plays around with the
internals of Forth, and the internals are decidedly non-standard. 
Unfortunately, if these details were to become part of the standard then
it would inhibit better implementations. I've been running direct threaded
Forths for about seven years, and woundn't want to be forced back to
indirect threaded to get this code to work!

It's sad but true -- to get the best results with Forth you have to
throw portability out the window. I keep the implementation dependent code
in my programs localized (even at the expense of performance) so I minimize
my porting struggles. But it would be nice if I could assume running on the
same machine/environment forever!

>It's like having a totally portable 
>assembly language.)  An aspect of Forth which hasn't been touched on is a 
>Forth programmer's ability to use his or her knowledge of the implementation. 
>(Which, again, accounts for a small fraction of code but some of the most 
>powerful results.) 

Its more like being a C programmer and having sources to your compiler. You
can add features to make your C better, but no one else can use your code
unless they have the same compiler sources.

Tom Almy
toma@tekgvs.labs.tek.com
Standard Disclaimers Apply