From: krishna.myneni@ccreweb.org   
      
   On 3/27/24 06:26, Ruvim wrote:   
   > On 2024-03-27 04:57, Krishna Myneni wrote:   
   >> On 3/26/24 17:01, Krishna Myneni wrote:   
   >>> Standard source definitions of DLSHIFT and DRSHIFT (double number   
   >>> left shift and right shift), over full shift range, per discussion in   
   >>> prior thread.   
   >>>   
   >>> Tests needed.   
   >>   
   >> Just tested DLSHIFT and found weird things going on. Traced the   
   >> problem to LSHIFT.   
   >>   
   >>   
   >> kforth64   
   >>   
   >> 1 64 LSHIFT .  \ expected to get zero   
   >> 1              \ instead, got 1   
   >>   
   >> Then, I looked at the spec. for LSHIFT and, indeed, there is an   
   >> ambiguous condition for u >= BITS_PER_CELL .   
   >>   
   >>   
   >> 6.1.1805   
   >> LSHIFT “l-shift”   
   >> CORE   
   >> ( x1 u – – x2 )   
   >> Perform a logical left shift of u bit-places on x1, giving x2. Put   
   >> zeroes into the least significant bits vacated by the shift. An   
   >> ambiguous condition exists if u is greater than or equal to the number   
   >> of bits in a cell.   
   >>   
   > [...]   
   >> We shouldn't have an ambiguous condition here because of some   
   >> idiosyncratic behavior of the SHL instruction!   
   >>   
   >> u 64 LSHIFT should be zero on all systems with cell sizes up to 64 bits.   
   >   
   > Ideally — yes.   
   >   
   > My rationale (see [1]) is that for any `x` and `u`, the result of a   
   > single shift of `x` by `u` bits should always be equivalent to `u`   
   > sequential shifts by 1 bit.   
   >   
      
   I really think it is a bad idea to have UB in the spec of LSHIFT and   
   RSHIFT due to the arbitrariness of low level shift operations at the   
   hardware level. Here we have a chance to remove that UB and guarantee that   
      
   1 BITS_PER_CELL LSHIFT  returns zero   
   and   
   1 BITS_PER_CELL RSHIFT  returns zero   
      
   so that the expected result for a shift operation on the cell operand   
   does not have UB.   
      
   Efficiency because of extra instructions needed to implement this   
   guarantee are not even worth bothering about -- we are not C.   
      
   One would also expect the following two expressions to be consistent   
      
   1 64 LSHIFT .   
      
   and   
      
   : TEST2* 1  64 0 DO 2* LOOP . ;   
   TEST2*   
      
   Currently, on some systems (kForth and Gforth), we get,   
      
   1 64 LSHIFT .  \ gives 1   
   TEST2*         \ gives 0   
      
   For system implementers to ensure LSHIFT uses 6 bits of the shift count   
   would be trivial and should not break past code provided that code did   
   not use specific behavior which was called out as undefined behavior in   
   the standard.   
      
   If we get enough common practice in systems to have LSHIFT and RSHIFT   
   behave in a consistent and expected manner, then it can be standardized.   
   The important thing is to avoid nonsense in the language spec because of   
   low-level hardware choices.   
      
   --   
   Krishna   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)