From: anton@mips.complang.tuwien.ac.at   
      
   Ruvim  writes:   
   >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.   
      
   It leads to bugs where the wrong kind of address is provided or   
   expected.  It leads to complications in designing the words where you   
   now have to deal with two kinds of addresses and design your words to   
   expect or provide the right one.  And in cases where the usage of the   
   word includes both kinds of addresses, perform the conversion before   
   and/or after the call, or have two functionally parallel words, one   
   for each kind of address; or maybe more, if you want to support   
   various combinations for the different parameters and return values.   
      
   Actually, it's worse than the BCPL approach: On the Amiga in BCPL the   
   two kinds of addresses were clearly distinct, i.e., the conversion   
   were not nops, and any mistakes in usage would be found quickly in   
   testing.   
      
   In the suggested approach, on the widely-used byte-addressed Forth   
   systems the conversion words would be nops, and having one too many,   
   too few, or in the wrong direction or in the wrong place would not   
   become apparent in testing.  You would have to test on a system where   
   the address unit >8 bits to find the mistake, and it's likely that the   
   program won't test there for other reasons (e.g., because it uses   
   OPEN-FILE).  We have seen with CHARS how well that has worked.  Even   
   those who wanted to write Forth-94 standard programs could not test   
   that their programs actually complied.  We finally accepted reality   
   and standardized 1 chars = 1.   
      
   My preferred alternative of reading and writing the data in a   
   byte-per-address-unit format (or maybe converting between a packed and   
   a byte-per-address-unit format) has the same problem, of course, but   
   at a smaller scale: if we standardize words for doing this reading and   
   writing, or this conversion, on a byte-addressed machine you cannot   
   determine by testing that you did the OPEN-FILE without a BYTEWISE   
   fam, where it would be appropriate.  However, the places where   
   BYTEWISE would have to be inserted are far fewer, making it much easer   
   to get right without testing, or to insert missing instances of   
   BYTEWISE.   
      
   For the variant where there is a conversion between packed and   
   bytewise representations in memory the number of places to consider is   
   between the fam approach and the two-kinds-of-address approach, so I   
   would rather recommend the fam approach.   
      
   If we do not standardize words for systems with address units >8 bits   
   (and I currently don't plan to propose such words, because I would   
   like to see some existing practice before proposing such words), the   
   situation is actually not that much difference from if we standardize   
   them: many programs will not use these words either way, and it's best   
   to go for the variant that requires the least changes.   
      
   [two kinds of addresses]   
   >> 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.   
      
   That's also the case for jsforth.  jsforth can address 16GB (4G   
   cells), but 32-bit byte addresses can only address 4GB.   
      
   >The only way that I can see is to use double-cell size addresses to   
   >refer individual bytes (or even bits).   
      
   On one hand, requiring double-cell addresses for W@ etc. will   
   certainly ensure that most or all mistakes in converting between the   
   address types will be found in testing.   
      
   On the other hand, double-cell addresses for W@ etc. conflicts with   
   existing practice and is very likely to lead to a proposal that   
   proposes it being rejected.  I also doubt that the that the users of   
   systems with address units >8 bits would prefer it over the fam   
   approach, and that the implementors of such systems would implement   
   such words.   
      
   - anton   
   --   
   M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html   
   comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html   
        New standard: https://forth-standard.org/   
      EuroForth 2024: https://euro.theforth.net   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)