Path: utzoo!utgpu!watmath!att!dptg!rutgers!cs.utexas.edu!uunet!zephyr.ens.tek.com!tekcrl!tekgvs!toma
From: toma@tekgvs.LABS.TEK.COM (Tom Almy)
Newsgroups: comp.lang.forth
Subject: Re: Random comments
Message-ID: <5708@tekgvs.LABS.TEK.COM>
Date: 7 Aug 89 15:04:46 GMT
References: <10425@dasys1.UUCP> <5693@tekgvs.LABS.TEK.COM> <4605@sdcc6.ucsd.EDU>
Reply-To: toma@tekgvs.LABS.TEK.COM (Tom Almy)
Organization: Tektronix, Inc., Beaverton,  OR.
Lines: 51

In article <4605@sdcc6.ucsd.EDU> ir230@sdcc6.ucsd.EDU (john wavrik) writes:
[concerning my previous comment about D@ and D! being machine dependent and
 2@ and 2! memory order being a language standard]
>An argument could be made for the reverse: As long as 2@ and 2! are 
>compatible, the order in memory doesn't matter. 

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!

>   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!) 

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!

> 
>    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". 

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!

>No
>problems have been found with OS interfacing on an 80286-based system (and 
>double-precision numbers are not needed for such interfacing!). 

You are absolutely correct.  But there is confusion over ordering of 
segment/offset pairs, if you consider the segment to be of greater numeric
significance.
 
Tom Almy
toma@tekgvs.labs.tek.com
Standard Disclaimers Apply