From: krishna.myneni@ccreweb.org   
      
   On 6/15/24 02:19, Anton Ertl wrote:   
   > Krishna Myneni  writes:   
   >> In particular, I don't like the necessity of two separate steps to fetch   
   >> a sign-extended word, preferring instead two separate words, one for   
   >> unsigned fetch and one for sign extended fetch.   
   >   
   > That used to be my position, too, but if we add the need to deal with   
   > different byte orders, this results in   
   >   
   > sw@ uw@ be-sw@ be-uw@ le-sw@ le-uw@   
   >   
   > and when you have the precomposed words for fetching, you also want   
   > them for storing:   
   >   
   > w! be-w! le-w!   
   >   
   > And another 9 words for l, and another 9 words for x.  And if you also   
   > add stuff like w, etc., precomposing leads to even more words.   
   >   
   > That is the memory access proposal from Federico de Ceballos, but the   
   > committe (in particular, Leon Wagner) has experimented with it and   
   > found that the number of words is too high.   
   >   
      
   IMO, when it comes to memory access, and arithmetic, demanding that one   
   say explicitly what one wants to do is preferable to reducing the word   
   count. The two step process for sign-extended fetches opens up room for   
   inadvertent programming mistakes, e.g.   
      
   sw@  versus w@ w>s   
      
   Also, when trying to debug code, one has to question whether or not the   
   programmer accidentally omitted the sign-extension part.   
      
   If you want to stick with the two step-process, I suggest renaming the   
   fetch words to explicitly state that the fetches are unsigned:   
      
   w@ --> uw@   
   l@ --> ul@   
   x@ --> ux@   
      
   and the sign-extension conversion words to   
      
   uw>s   
   ul>s   
   ux>s   
      
   This will force the programmer to explicitly state what he is doing. It   
   also maintains consistency with existing practice in Forths such as   
   Gforth and kForth, while allowing word count reduction.   
      
   The store words do not need a signed/unsigned prefix, so that's not   
   relevant.   
      
      
   > One idea have is to provide a library that defines the precomposed   
   > words in terms of the decomposed ones.   
   >   
   >> These words are indispensable for writing portable code between 32-bit   
   >> and 64-bit systems.   
   >   
   > I have good experiences with Forth's cell, char, float model for   
   > portability and bad experiences with the portability of C code, thanks   
   > to its large number of integer types: you can produce portable C code,   
   > but unless you test it on both 32-bit and 64-bit systems, I would not   
   > bet on its portability, while debugged Forth code often is also   
   > portable.   
   >   
      
   One of the reasons I'm a proponent of the explicit prefix fetch words is   
   that I have used them for working with structures provided by C   
   libraries, and they keep me from making mistakes. In 64-bit libraries,   
   structures often pack 32-bit fields contiguously to keep 64-bit   
   alignment with the 64-bit fields.   
      
   --   
   Krishna   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)