From: ruvim.pinka@gmail.com   
      
   On 2024-06-23 21:10, Anton Ertl wrote:   
   > Ruvim  writes:   
      
   >> It seems, in almost any system we can have a separate byte-based address   
   >> space. For an address in this space, 1+ produces the address of the next   
   >> consecutive byte.   
   >>   
   >>   
   >> For example, let's consider a cell-addressed, little-endian   
   >> Forth-system, where one cell is 32 bits, and several most significant   
   >> bits of addresses are always 0.   
   >>   
   >>   
   >> : byte-address ( addr -- b-addr ) #2 lshift ;   
   >   
   > The BCPL approach in reverse.  Just say No!   
   >   
   > Having two incompatible address types was bad in BCPL (and AmigaDOS   
   > programmers can show you their scars from this mistake), and it would   
   > be bad in Forth.   
      
      
   Well, it's not obvious to me why this is bad. But, I trust your   
   expertise :-)   
      
      
      
   > Fortunately, Forth has found a better way to deal   
   > with byte-addressed machines, and AFAICT, Forth is more popular than   
   > BCPL despite BCPL having an Algol syntax and Forth not; I think the   
   > BCPL approach to dealing with bytes has had much to do with that.  I   
   > won't go there.   
      
      
   >   
   > If systems like jsforth want to go there, they should implement it and   
   > establish common practice about such things.  It will be interesting   
   > to see how this approach works out with, e.g., 20-bit cells.   
      
      
   It will not work if addresses use all bits in a cell.   
      
   The only way that I can see is to use double-cell size addresses to   
   refer individual bytes (or even bits).   
      
      
   --   
   Ruvim   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)