ANS Forth: Cell Size vs. Address Size 
Author Message
 ANS Forth: Cell Size vs. Address Size

DPANS-94 Draft specification for implementation of FORTH
states that the size of ADDRESS operands on the stack must
be equal to ONE CELL size.

This means you have a choice.  You can use 16-bit operands,
or 32-bit operands.  The latter method is often called a
"32-bit FORTH."

Since certain CPUs have 24-bit addresses, it would seem
advantageous to use 3 bytes for the cell size, thus
conveniently utilizing all possible addressing space, and
the Dictionary becomes seamless, unbounded, and no funny
"banking" routines would be required.

The standard says ADDRESS SIZE = CELL SIZE -- I assume that
is an ultimatum.

What are your thoughts on this?

Doug.

-----------------------------------------------
Douglas Beattie Jr.
Student of Computer Science
Student of Electronics Engineering Technology
Skagit Valley College, Whidbey Branch
Whidbey Island, Washington State, U.S.A.



Sat, 23 Dec 2000 03:00:00 GMT  
 ANS Forth: Cell Size vs. Address Size

Quote:

> Since certain CPUs have 24-bit addresses, it would seem
> advantageous to use 3 bytes for the cell size, thus
> conveniently utilizing all possible addressing space, and
> the Dictionary becomes seamless, unbounded, and no funny
> "banking" routines would be required.

Don't even think of doing that. Yes, the 68000 has 24 bit adresses, but
the 68010 and all above already had 32 bit addresses, so you shoot
yourself into the foot. Also, addressing 3 byte entries isn't a native
operation in any byte-addressed CPU I know (there are some 24 bit word
addressed DSPs, but that's an entirely different topic).

--
Bernd Paysan
"Late answers are wrong answers!"
http://www.jwdt.com/~paysan/



Sat, 23 Dec 2000 03:00:00 GMT  
 ANS Forth: Cell Size vs. Address Size

Quote:

>Don't even think of doing that. Yes, the 68000 has 24 bit adresses, but
>the 68010 and all above already had 32 bit addresses, so you shoot
>yourself into the foot. Also, addressing 3 byte entries isn't a native
>operation in any byte-addressed CPU I know (there are some 24 bit word
>addressed DSPs, but that's an entirely different topic).

All the Cray machines that I ever worked on had 24-bit addresses
and each memory location held a 64-bit word.  I am sure there are
other machines like these where the hardware architecture of the
machine will lead the Forth implementor to the natural conclusion
that addresses should be one size and cells should be a different
size.

I think that Douglas' original question deserves consideration: Can we
and should we create Forths where addresses and cells are different
sizes.

dawa



Sat, 23 Dec 2000 03:00:00 GMT  
 ANS Forth: Cell Size vs. Address Size

: DPANS-94 Draft specification for implementation of FORTH
: states that the size of ADDRESS operands on the stack must
: be equal to ONE CELL size.

: This means you have a choice.  You can use 16-bit operands,
: or 32-bit operands.

Or 64.

: Since certain CPUs have 24-bit addresses, it would seem
: advantageous to use 3 bytes for the cell size, thus
: conveniently utilizing all possible addressing space, and
: the Dictionary becomes seamless, unbounded, and no funny
: "banking" routines would be required.

"banking"?

: The standard says ADDRESS SIZE = CELL SIZE -- I assume that
: is an ultimatum.

: What are your thoughts on this?


cell.  It would be hellish to have them different sizes.

The only machine where there is a real problem with the ANS rules is
the HP Saturn, where an address is 20 bits and an address unit is 4
bits.  I believe that it's impossible to run ANS Forth on that.

Andrew.



Sat, 23 Dec 2000 03:00:00 GMT  
 ANS Forth: Cell Size vs. Address Size
Quote:


> >Don't even think of doing that. Yes, the 68000 has 24 bit adresses, but
> >the 68010 and all above already had 32 bit addresses, so you shoot
> >yourself into the foot. Also, addressing 3 byte entries isn't a native
> >operation in any byte-addressed CPU I know (there are some 24 bit word
> >addressed DSPs, but that's an entirely different topic).

> All the Cray machines that I ever worked on had 24-bit addresses
> and each memory location held a 64-bit word.  I am sure there are
> other machines like these where the hardware architecture of the
> machine will lead the Forth implementor to the natural conclusion
> that addresses should be one size and cells should be a different
> size.

> I think that Douglas' original question deserves consideration: Can we
> and should we create Forths where addresses and cells are different
> sizes.

> dawa

I often treat addresses as constants. Would I need to write
           ADDRESS  <address>     insted of
           CONSTANT <address>     ?
How would I do address arithmetic?

Jerry
--
If my address has "x" or "z" in it, remove them to reply.

"I view the progress of science as ... the slow erosion of the
 tendency to dichotomize."                    Barbara {*filter*}s, U. Mich.
---------------------------------------------------------------------



Sat, 23 Dec 2000 03:00:00 GMT  
 ANS Forth: Cell Size vs. Address Size

Quote:

> All the Cray machines that I ever worked on had 24-bit addresses
> and each memory location held a 64-bit word.  I am sure there are
> other machines like these where the hardware architecture of the
> machine will lead the Forth implementor to the natural conclusion
> that addresses should be one size and cells should be a different
> size.

Crays were definitely word-addressed machines. Even if you want not to
waste the bits, it's quite expensive. You can only load and store 64 bit
entities, to extract 24 or 32 bit sub-words, you have to shift the
result around. And later Cray machines definitely had more than 16
Mwords.

--
Bernd Paysan
"Late answers are wrong answers!"
http://www.jwdt.com/~paysan/



Sun, 24 Dec 2000 03:00:00 GMT  
 ANS Forth: Cell Size vs. Address Size

Quote:

>I think that Douglas' original question deserves consideration: Can we
>and should we create Forths where addresses and cells are different
>sizes.

Some FORTH's do that.

The problem is that you need a lot more stack manipulation words. e.g.
NASWAP to swap a number and an address, ANSWAP to do the reverse, ASWAP
to swap two addresses... And that is just for SWAP.

As second problem, in particular on Intel CPU's, is that changing a
segment register is sloooow. Most of the time it's not necessary, in
particular if the accessed addresses are  close together.

        Bart.



Sun, 24 Dec 2000 03:00:00 GMT  
 ANS Forth: Cell Size vs. Address Size


Quote:
> DPANS-94 Draft specification for implementation of FORTH
> states that the size of ADDRESS operands on the stack must
> be equal to ONE CELL size.
...
> Since certain CPUs have 24-bit addresses, it would seem
> advantageous to use 3 bytes for the cell size, thus
> conveniently utilizing all possible addressing space, and
> the Dictionary becomes seamless, unbounded, and no funny
> "banking" routines would be required.

You can also use longer cells to give you all these advantages.

Quote:
> The standard says ADDRESS SIZE = CELL SIZE -- I assume that
> is an ultimatum.

Yes, in the sense that on a Forth system with 16-bit cells you cannot
address more than 64K aus (au=address unit).

Of course, it is still possible that not all addresses representable
in a cell are valid. E.g., on the Alpha under Linux and Digital Unix
Gforth has 64-bit cells, but present-day Alphas only support 43 bits
for addresses, and usually only a small fraction of this address space
is actually used.

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

http://www.complang.tuwien.ac.at/anton/home.html



Sun, 24 Dec 2000 03:00:00 GMT  
 ANS Forth: Cell Size vs. Address Size


Quote:
> The only machine where there is a real problem with the ANS rules is
> the HP Saturn, where an address is 20 bits and an address unit is 4
> bits.  I believe that it's impossible to run ANS Forth on that.

Why?

How about a Forth with 4-bit aus, 20-bit chars, and 20-bit cells
(CHARS and CELLS would be expensive, but so what)?

Or a Forth with 20-bit aus (you would have to do the translation
between Forth aus and native aus at every memory reference), 20-bit
chars, and 20-bit cells.

Or a Forth with 4-bit aus, 8-bit chars, and 16-bit cells (limiting
address space to 32KB).

Or ...

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

http://www.complang.tuwien.ac.at/anton/home.html



Sun, 24 Dec 2000 03:00:00 GMT  
 ANS Forth: Cell Size vs. Address Size

Quote:


> > I think that Douglas' original question deserves consideration: Can we
> > and should we create Forths where addresses and cells are different
> > sizes.
> I often treat addresses as constants. Would I need to write
>            ADDRESS  <address>        insted of
>            CONSTANT <address>        ?
> How would I do address arithmetic?

        I think that this is running away with a problem that can be
solved much more simply.  Simply define addresses on the stack as 32-bit
unsigned values with the top eight bits "0".  For one, that exceeds the
minimum range for unsigned cell values on the stack in ANS of 16 bits, and
even more important, nowhere does the ANS stanard say that you have to be
able to map *every* possible value to an address.  What about when you are
working with hardware security that doesn't permit a particular range of
values to be accessed?  As long as that range of values is never used by
the ALLOT/HERE or the ALLOCATE systems, you really ought to be OK.
Similarly, as long as a 24-bit system never hands the stack an
out-of-range address value, there ought not be any problem.

Virtually,

Bruce R. McFarling, Newcastle, NSW



Mon, 25 Dec 2000 03:00:00 GMT  
 ANS Forth: Cell Size vs. Address Size


Quote:
>DPANS-94 Draft specification for implementation of FORTH
>states that the size of ADDRESS operands on the stack must
>be equal to ONE CELL size.

...
>The standard says ADDRESS SIZE = CELL SIZE -- I assume that
>is an ultimatum.

>What are your thoughts on this?

>Doug.

In 1994 I have created a 32-bit Forth for i8086, on which physical addresses
are of only 20 bits. The Forth did not translate all addresses from linear
to segment:offset form; instead, it assumed that if the low byte of the
higher part is 0, no conversion is needed; and the cases where it was not 0
were very rare. The formula was rather complex, but even for that Forth I
found no contradictions to the standard.

So: let the addresses be 32-bit and ignore the higher byte. If there will be
any problems (comparison, etc.), they are not yours, but the standard's.



Mon, 25 Dec 2000 03:00:00 GMT  
 ANS Forth: Cell Size vs. Address Size
Quote:



> > > I think that Douglas' original question deserves consideration: Can we
> > > and should we create Forths where addresses and cells are different
> > > sizes.

> > I often treat addresses as constants. Would I need to write
> >            ADDRESS  <address> insted of
> >            CONSTANT <address> ?
> > How would I do address arithmetic?

>         I think that this is running away with a problem that can be
> solved much more simply.  Simply define addresses on the stack as 32-bit
> unsigned values with the top eight bits "0".  For one, that exceeds the
> minimum range for unsigned cell values on the stack in ANS of 16 bits, and
> even more important, nowhere does the ANS stanard say that you have to be
> able to map *every* possible value to an address.  What about when you are
> working with hardware security that doesn't permit a particular range of
> values to be accessed?  As long as that range of values is never used by
> the ALLOT/HERE or the ALLOCATE systems, you really ought to be OK.
> Similarly, as long as a 24-bit system never hands the stack an
> out-of-range address value, there ought not be any problem.

> Virtually,

> Bruce R. McFarling, Newcastle, NSW


Bruce,

It seems to me that if your approach is implemented, the problem
dissolves to an argument about definitions. The address, on the stack
and presumably in the dictionary, occupies 32 bits. Does the fact that
some of these bits are irrelevant mean that it is not a cell? The
original post had to do with cells and addresses containing different
numbers of bits.

Jerry
--
If my address has "x" or "z" in it, remove them to reply.

"I view the progress of science as ... the slow erosion of the
 tendency to dichotomize."                    Barbara {*filter*}s, U. Mich.
---------------------------------------------------------------------



Mon, 25 Dec 2000 03:00:00 GMT  
 ANS Forth: Cell Size vs. Address Size

Quote:

> It seems to me that if your approach is implemented, the problem
> dissolves to an argument about definitions. The address, on the stack
> and presumably in the dictionary, occupies 32 bits. Does the fact that
> some of these bits are irrelevant mean that it is not a cell? The
> original post had to do with cells and addresses containing different
> numbers of bits.

        As far as I am concerned, the fact that some of the bits are
irrelevant has nothing to do with whether it is a cell or not.  For
example, on a word-aligned machine that uses executable pointers for
xt's, the bottom most bit is redundant.  Further, there may be limitations
on memory locations that are executable by user programs.  "Is a cell"
means that words that take generic cells as stack arguments work on the
data in question.  So a 32-bit forth that is using 24 bit memory addresses


bytes to store and fetch addresses might be useful, especially for address

stack would be a cell.

Virtually,

Bruce R. McFarling, Newcastle, NSW



Sun, 31 Dec 2000 03:00:00 GMT  
 ANS Forth: Cell Size vs. Address Size
OK, got it: an address is cell on the stack, but less than that

the price of RAM nowadays, is the light worth the candle? In 8- and
16-bit embedded systems, where memory may still be precious, the
consideration isn't likely to arise.

Jerry
--
If my address has "x" or "z" in it, remove them to reply.

"I view the progress of science as ... the slow erosion of the
 tendency to dichotomize."                    Barbara {*filter*}s, U. Mich.
---------------------------------------------------------------------

Quote:


> > It seems to me that if your approach is implemented, the problem
> > dissolves to an argument about definitions. The address, on the stack
> > and presumably in the dictionary, occupies 32 bits. Does the fact that
> > some of these bits are irrelevant mean that it is not a cell? The
> > original post had to do with cells and addresses containing different
> > numbers of bits.

>         As far as I am concerned, the fact that some of the bits are
> irrelevant has nothing to do with whether it is a cell or not.  For
> example, on a word-aligned machine that uses executable pointers for
> xt's, the bottom most bit is redundant.  Further, there may be limitations
> on memory locations that are executable by user programs.  "Is a cell"
> means that words that take generic cells as stack arguments work on the
> data in question.  So a 32-bit forth that is using 24 bit memory addresses


> bytes to store and fetch addresses might be useful, especially for address

> stack would be a cell.

> Virtually,

> Bruce R. McFarling, Newcastle, NSW




Sun, 31 Dec 2000 03:00:00 GMT  
 ANS Forth: Cell Size vs. Address Size

Quote:

> OK, got it: an address is cell on the stack, but less than that

> the price of RAM nowadays, is the light worth the candle? In 8- and
> 16-bit embedded systems, where memory may still be precious, the
> consideration isn't likely to arise.

        If you'r going to have 8K long address vetcors, mebbe.  Myself,
I'd just leave it at a four-byte wide cell and ignore the top byte, until

worthwhile.

Virtually,

Bruce R. McFarling, Newcastle, NSW



Mon, 01 Jan 2001 03:00:00 GMT  
 
 [ 15 post ] 

 Relevant Pages 

1. Operand-size and Address-size prefix bytes

2. ANS Forth, Word Size Independence etc...

3. ADIR() Size vs Calculated Size

4. Direct Access Record Size vs. Disk Sector Size

5. size of libtk.a vs size of wishx

6. Executable code size: Forth vs C

7. Double cell multiply in ANS Forth? D*

8. Machine Forth vs ANS : 20 bits vs 32 bits

9. ANS-4th, size of a BLOCK/screen

10. ANS Forth in ANS Forth?

11. File Size, Volume Size

12. Maximum size of unnamed pipe size in ruby

 

 
Powered by phpBB® Forum Software