PRC: double number cell order 
Author Message
 PRC: double number cell order

SUMMARY: The storage order in a double number's cell pair shall not be fixed.
-----------------------------------------------------------------------------

Reading carefully the dpANS Forth document, I fully agree with the spirit of
minimizing restrictions to the implementor of a small required core word set
while allowing a wide range of hardware, architectures and perhaps host OSs.

In fact, as an example, I had stalled my attemps to implement Forth83 on
VAX/VMS because of too stringent requirements defeating efficient usage
of the powerful orthogonal VAX instruction set. (No flames, please!)

But there remains still one IMHO unnecessary hurdle, namely double cell order.

-----------------------------------------------------------------------------

PROPOSAL:
The draft document specifies that the more significant cell of a double
number must be on top of stack or at the lower memory address.

The storage order of the cell pair in which either signed or unsigned double
numbers reside on a stack or in memory shall not be fixed by the standard.

The implementation shall document the choosen cell order.

A standard program relying on the storage order shall declare an environmental
dependecy on "double number cell order".

I do not recommend any new words, as it is possible for a standard program to
figure out portably what the double number cell order is, see below.

However, it may be convenient to have U>UD standardized in the CORE words set,
because some words from CORE use unsigned double numbers, e.g. # .
For completeness, UD>U may be in the DOUBLE word set.
Few programs might need 2X:XD so it could be in DOUBLE EXT .
The standard committee might consider an appropriate ?ENVIRONMENT query string.
-----------------------------------------------------------------------------

REASON:
Many CPUs have builtin arithmetic instructions even for longer operands, and
some machines are big endian, the others little endian, so one class is always
penalized if the order of cells within double numbers is fixed.
The same applies for either 16bit cells or 32bit cells and may be others.

It is generally bad programming practice to assume knowledge of storage order.
Therefore a portable mechanism of accessing one of the double cells is needed.
This is now possible for signed numbers using S>D and D>S but not for unsigned.
A portable solution would be using words similar to S>D D>S CELL+ and ALIGN.

-----------------------------------------------------------------------------

WORDS AFFECTED:
Those with implicit or explicit conversions between single and double numbers

-----------------------------------------------------------------------------

IMPACT:
For historical continuity a standard program could declare an environmental
dependency on "historical double number cell order". As nobody should write
a new program assuming "reversed double number cell order", the former could
be shortened to just "double number cell order".

-----------------------------------------------------------------------------

TRANSITION/CONVERSION:
I figured out a portable solution. There may be others as well.
The only machine specific word would be 2X:XD . It is symmetric in the sense
that conversions in both directions are possible with the same word.
It is either a SWAP or a NOOP, but assuming this without some conditional test
in a standard program would be an environmental dependency.
I have choosen this name because it deals with two unspecified single cell
numbers (2X) versus (:) one unspecified double cell number (XD). Because of
the symmetry and shortness, I prefer : over > or <> or >< or the like.

2X:XD could be in the CORE or CORE EXT word set, because there is already
e.g. M* in CORE. U>UD might be in the CORE word set as convenience.

The following are example definitions. They may not be well optimized, but
it's to the implementor knowing the details and writing native code.

: 2X:XD ( x1 x2 | xd -- xd | x1 x2 ) [ 1 S>D NIP ] [IF] SWAP [THEN] ; IMMEDIATE
\ where x1 is the more significant cell, x2 is the less significant cell.
: 2X:XD ( x1 x2 | xd -- xd | x1 x2 ) [ 1 S>D NIP ] LITERAL ROLL ; IMMEDIATE
\ this version uses only CORE and CORE EXT words!

: U>UD       ( u  -- ud )    0 2X:XD ;       \ similar to S>D
: UD>U       ( ud -- u  )    2X:XD DROP ;    \ returns less significant cell
: UD>UH      ( ud -- u  )    2X:XD NIP ;     \ returns more significant cell

: U.    ( u -- )        U>UD D. ;    \ using U>UD instead of 0 is portable
\ probably most common usage!
: U.    ( u -- )        U>UD <# #S #> TYPE ; \ the latter are all CORE words

: UPPER-CELL+   ( a-addr1 -- a-addr2 ) [ 1 S>D NIP  CELLS ] LITERAL + ;
: LOWER-CELL+   ( a-addr1 -- a-addr2 ) [ 1 S>D DROP CELLS ] LITERAL + ;
\ convert the aligned address of a double number a-addr1 to the aligned address
\ a-addr2 of the cell containing the more/less significant cell of the double
\ number. Using may imply an environmental dependency on the cell size (bits).

-----------------------------------------------------------------------------

(If you have questions, please note that I'm in holidays from May 8 to 29.)




Fri, 20 Oct 1995 04:03:23 GMT  
 PRC: double number cell order
: SUMMARY: The storage order in a double number's cell pair shall not be fixed.
: -----------------------------------------------------------------------------

[ ... ]

: But there remains still one IMHO unnecessary hurdle, namely double cell order.

: -----------------------------------------------------------------------------

: PROPOSAL:
: The draft document specifies that the more significant cell of a double
: number must be on top of stack or at the lower memory address.

: The storage order of the cell pair in which either signed or unsigned double
: numbers reside on a stack or in memory shall not be fixed by the standard.

: The implementation shall document the choosen cell order.

: A standard program relying on the storage order shall declare an environmental
: dependecy on "double number cell order".

[ ... lots deleted ... ]

This is a very well thought out and documented proposal, but:

1.  It's much too late to be making proposals which have this much
impact, and:

2.  There is very little experience of Forths which behave in this
way.  It is likely that this change will break most code which uses
double numbers, and as such is very unlikely to get the suport of the
TC.

Whatever the merits of this change, it is a goal of the TC to avoid
breaking exisiting code where possible.

Andrew.



Sat, 21 Oct 1995 18:20:52 GMT  
 PRC: double number cell order


: : SUMMARY: The storage order in a double number's cell pair shall not be fixed.
[...]
:
: This is a very well thought out and documented proposal, but:
:
: 1.  It's much too late to be making proposals which have this much
: impact, and:

That's the risc of testing public network review as I have my first access now.
I spent about 2 weeks reading very carefully and I'll send a lot of more info.
:
: 2.  There is very little experience of Forths which behave in this
: way.  It is likely that this change will break most code which uses
: double numbers, and as such is very unlikely to get the suport of the
: TC.

What experience do you need to replace phrases as
        0 D.
with
        U>UD D.
which should be obvious and more readable to everyone?
The other way around, wether using UD>U or the historical DROP *has* an
environmental dependency on the cell size in bits (16, 32 or whatever) because
truncation may occur (if you don't know that the more significant cell *is*
zero).
:
: Whatever the merits of this change, it is a goal of the TC to avoid
: breaking exisiting code where possible.

Most existing FIG or Forth83 code is broken anyway, as ALIGNs and so on have to
be added. You have to look at the code before claiming portability, so trivial
source fixes can be applied easily that time.
:
: Andrew.




Sun, 22 Oct 1995 00:37:47 GMT  
 PRC: double number cell order

|> SUMMARY: The storage order in a double number's cell pair shall not be fixed.

There was a less radical proposal in the draft (I think up to
dpANS-3), but it did not make it. I guess your proposal has no chance,
Heribert.

BTW, if you want the storage order on the stack in a specific way,
just let the stack grow in the appropriate direction! The storage


thrown out, but to make sense they would have required the addition of
DALIGN etc.

- anton
--
M. Anton Ertl                    Some things have to be seen to be believed



Tue, 24 Oct 1995 19:47:53 GMT  
 PRC: double number cell order


: |> SUMMARY: The storage order in a double number's cell pair shall not be fixed.
:
: There was a less radical proposal in the draft (I think up to
: dpANS-3), but it did not make it. I guess your proposal has no chance,
: Heribert.
They will be alerted at least. Perhaps they put a note in an addendum.
:
: BTW, if you want the storage order on the stack in a specific way,
: just let the stack grow in the appropriate direction! The storage


: thrown out, but to make sense they would have required the addition of
: DALIGN etc.

I knew about the possibility of negating or complementing addresses, I
considered this when I got Forth83 Std. a few years ago. But it is not worth
when you have to hack every address first, even for the single number words.
Then I prefer doing doubles with 3 instructions, for VAX e.g.

DPLUS:  ADDL2   B^4(SP),B^12(SP)        ! 12 instruction bytes total w/o next
        ADWC    (SP),B^8(SP)
        ADDL2   S^#8,SP                 ! Byte addressing
        next
versus (not dpANS compliant)
        ADDL2   (SP)+,B^4(SP)           ! 8 instruction bytes total w/o next
        ADWC    (SP)+,B^4(SP)
        next
the difference is not so great, because the VAX has no ADDQ instruction
(quadword=64bit, not quick as 68xxx), also I have no timing/speed info yet.

There are also some VAX instructions which can handle 64bit at a time, e.g.
MOVQ, ASHQ, EDIV, EMUL where the instruction saving might be greater.

I'll think again about that in holidays, I'm just starting, and back May 29.




Wed, 25 Oct 1995 01:13:17 GMT  
 
 [ 5 post ] 

 Relevant Pages 

1. Order of storage of cell pairs & doubles

2. How to know wich cell was double-clicked?

3. Double cell multiply in ANS Forth? D*

4. 12TET Musical 3-Interval-String/6-Interval Cell/Set Non-Redundancy Permutation Ordering Problem:

5. Number of free colormap cells

6. Writing double word binary numbers on screen

7. gawk: numbers not double-precision?

8. Double auto-number keys !

9. ANSForth A0004 re double number punctuation

10. Double precision -> number

11. EKEY and double numbers

12. Double Number Word Set

 

 
Powered by phpBB® Forum Software