From: krishna.myneni@ccreweb.org   
      
   On 3/27/24 02:53, Anton Ertl wrote:   
   > Krishna Myneni  writes:   
   >> 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.   
   >>   
   ...   
   >   
   > One interesting case is Java, which specifies the language pretty   
   > completely in order to make Java write-once-run-everywhere.  Java's   
   > designers chose to go along with the common practice in computer   
   > architecture   
   > :   
   >   
   > |If the promoted type of the left-hand operand is int, then only the   
   > |five lowest-order bits of the right-hand operand are used as the shift   
   > |distance.   
   >   
   > |If the promoted type of the left-hand operand is long, then only the   
   > |six lowest-order bits of the right-hand operand are used as the shift   
   > |distance.   
   >   
      
   For Forth, it would seem reasonable and natural to guarantee that the   
   number of bits in the shift count which are honored are enough to   
   represent the data stack width in bits. This would ensure that   
      
     1 u LSHIFT   
      
   and   
      
   -1 u RSHIFT   
      
   would be zero for u >= BITS_PER_CELL.   
      
   --   
   Krishna   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)