Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!ucsd!sdcc6!ir230
From: ir230@sdcc6.ucsd.EDU (john wavrik)
Newsgroups: comp.lang.forth
Subject: Re: Random comments
Summary: double length and implementation
Message-ID: <4605@sdcc6.ucsd.EDU>
Date: 6 Aug 89 06:42:33 GMT
References: <10425@dasys1.UUCP> <5693@tekgvs.LABS.TEK.COM>
Organization: University of California, San Diego
Lines: 73



    Tom Almy (toma@tekgvs.labs.tek.com) writes:
> The prefix "D" refers to double integer (typically 32 bit in a 16 bit FORTH 
> implementation), while the prefix "2" refers to a pair of integers.  A 
> double integer is a subclass of a pair of integers ...
 
> There is a practical reason to have both D@ and 2@ (etc).  LMI UR/FORTH 386 
> implements both operations, and they are not the same!  The 83 standard 
> defines 2@ such that the lower address integer becomes top of stack, and the 
> next integer becomes second on stack.  In the 80386 (and other Intel 
> architectures), the most significant portions of numbers are stored at the 
> highest addresses.  This means that using double integers will store into 
> memory wrong, causing problems with the OS interface or interfacing with 
> other language programs.
-----------------------------------------------------------------------------
                        IMPLEMENTATION DEPENDENCE
 
    There is at least a conceptual difference between a double-precision 
number and an ordered pair of single-precision numbers. The number pair 
operations (with prefix 2) should, as Tom Almy points out, always refer to 
ordered pairs of integers of whatever size. On the other hand, 32-bits seems 
to be the current standard (among other languages) for "long" integers. If 
this were to be the accepted definition of the Forth double-numbers then "D" 
and "2" operations would be different on 32-bit machines.  The ANSI standards 
team, however, seems to lean toward making D-numbers twice the cell size. 
Their BASIS document says:
      "The order in memory of ordered pairs, being structured data, 
      must be predictable. On the other hand experience has 
      indicated that there may be significant advantages to choosing 
      a hardware compatible representation of double numbers in 
      memory". 
An argument could be made for the reverse: As long as 2@ and 2! are 
compatible, the order in memory doesn't matter. On the other hand, the 
component words of a double precision number have arithmetic significance. 
[When used as the basis of multi-precision arithmetic, for example, the high 
word is the "carry" to the next position -- and it must be in a predictable 
place.]
 
   In any case, when dealing with compound data, one can either provide a 
programmer with information about how the data is represented, or one can 
provide selector and manipulator functions to deal with an unknown 
representation. (It is interesting that the ANSI team is proposing that the 
representation of double numbers be implementation-dependent but has not 
suggested selectors for the high and low words!) 
 
    Almy's also gives justification for making data representations 
implementation-dependent. The fact that the Intel chips (as well as others) 
store an integer with the low BYTE lower in memory has no bearing on 2@ vs D@. 
On the Intel 80286, 8086, 8088 there is no architecture-preferred order for 
the 16-bit words of a 32-bit number. 32-bit arithmetic operations on the 80286 
use pairs of registers and these can be pushed or popped in any order. Either 
order is equally fast and neither is "wrong". When a 16-bit Forth is 
implemented on a machine with 32-bit registers there is a machine preferred 
order -- but, in this case, it seems best to use a 32-bit Forth stack. No 
problems have been found with OS interfacing on an 80286-based system (and 
double-precision numbers are not needed for such interfacing!). 
 
   Forth lacks the ability of compiled languages to trap illegal operations on 
mixed data. Some of its amazing robustness and portability are due to an 
historical consistency in implementation: sequences like 2! followed by an 
eventual @ lead to predictable results (counter-intuitive, but predictable!). 
If I were on the Standards team, I'd think long and hard before giving up 
consistency in implementation. Not only will it mean an increase in 
complexity, but also an increase in subtle bugs when applications are 
transported. 
 
 
                                                  John J Wavrik
             jjwavrik@ucsd.edu                    Dept of Math  C-012
                                                  Univ of Calif - San Diego
                                                  La Jolla, CA  92093