Path: utzoo!attcan!uunet!tut.cis.ohio-state.edu!network!ucsd!sdcc6!ir230
From: ir230@sdcc6.ucsd.EDU (john wavrik)
Newsgroups: comp.lang.forth
Subject: Implementation dependence
Keywords: swizzling implementation
Message-ID: <4617@sdcc6.ucsd.EDU>
Date: 12 Aug 89 07:28:44 GMT
Organization: University of California, San Diego
Lines: 90


       Tom Almy  writes:
 
> Not necessarily so, and the reason LMI added D@ and D!, was that they 
> changed 2@ and 2! from an earlier version so as to match the Intel preferred 
> order (oposite from the Forth standard).  This broke my code.  I have a 
> *large* application which used 2VARIABLEs, and 2@ and @!, to hold x,y 
> coordinate points.  I rely on "@" getting the Y value and "WSIZE + @" 
> getting the X value.  So the order is important! 
 
> Good point.  My problem would have been solved had there been something like 
> 2A@ and 2B@ for the "A" and "B" elements of the pair! 
 
> Of course you are right from an architectural point of view.  The preferred 
> order must be inferred from the "little-endian" architecture.  But when 
> interfacing with other languages, 32 bit numbers had better be stored with 
> least significance in the lower addresses.  This is also important if you 
> intend to access the data in the 80386 -- I have been "burned" by several 
> Forth programs that 32 bit data via 2!, and then my 80386 native program has 
> to swizzle the data to read it.  Ugh! 
 
--------------------------------------------------------------------------
                       IMPLEMENTATION DEPENDENCE
 
  When someone posts a message it is not only a reply to a specific prior 
message, but also to all the other sources (comments, articles, conversations, 
etc.) which have impinged on the sender. This message may, therefore, not 
really be a response to Tom Almy's.
 
There have numerous such "sources" in the Forth community whose input can be 
summarized by "If X and Y are two processors and something can be done a bit 
faster in one way on X and in another way on Y, we should make the thing 
'implementation dependent' and not specify how it is done in the Standards". 
 
If someone stores a pair of coordinates by    POINT 2!, one can always
define selector functions x-coord and y-coord by
 
       :  x-coord  2@ drop  ;
       :  y-coord  2@ swap drop ;
 
(Thus  POINT x-coord  will retrieve the x-coordinate no matter what order the
pair is stored in memory). For double precision numbers there is, 
unfortunately, no simple way to write selectors for the high and low word 
without knowing the order in which the component words occur on the stack or 
in memory.
 
The point is that if the order for 2@ and 2! are "implementation dependent", 
the programmer can write selectors (albeit slower than those if the order was 
known). In the case of double precision numbers, however, if the order is 
declared to be "implementation dependent", there MUST be selector functions 
provided. 
 
Some people go for a lifetime without needing to know the order in which pairs 
of numbers are stored in memory, or how double precision numbers are stored. 
But others write "*large*" applications in which this information is used. 
There is a lesson to be learned here: many Forth programmers use their 
knowledge of how Forth is implemented in their work. They get "burned" when 
someone later decides that the memory representation of a data object should 
be different, TRUE should be -1 instead of 1, EXPECT should no longer leave a 
0 at the end of input, ' should refer to the CFA instead of the PFA, etc. They 
get cremated when an important aspect of implementation becomes 
"implementation dependent". 
 
In the past we enjoyed total knowledge of how Forth works -- and achieved 
powerful (and portable) results by exploiting this knowledge. Every time a 
feature of implementation is removed from the Standard it must (to retain 
power) be replaced by words to replace the missing knowledge. Of course no one 
can really anticipate the implementation features that others will find 
useful.  The real question is whether anyone really wants a collection of 
auxilliary words to replace some simple information about the implementation. 
Charles Moore supplied a model of a (virtual) computer that can be implemented 
on ANY real machine. The Forth language is (semantically) an extensible 
assembly language for this virtual machine. Some would like this virtual 
machine, as the Cheshire Cat, to fade away -- leaving only its Reverse Polish 
smile. 
 
There is more to power in a computer language than the execution speed of its 
code. There may be merit in suggesting that a bit of "swizzling" on the part 
of the implementation is a worthy tradeoff for preserving a simple and uniform 
structure. 
 
 
                                                  John J Wavrik 
             jjwavrik@ucsd.edu                    Dept of Math  C-012 
                                                  Univ of Calif - San Diego 
                                                  La Jolla, CA  92093