From: the.beez.speaks@gmail.com   
      
   On 01-04-2024 03:22, dxf wrote:   
   > On 30/03/2024 1:32 am, Hans Bezemer wrote:   
   >> ...   
   >> Can't make it any shorter than this. And no idea what happens with less   
   robust LSHIFT or RSHIFT implementations. CELL-BITS should be most obvious, :   
   SPIN SWAP ROT ; should fix most porting issues, replace ;THEN   
   >> with EXIT THEN. It passes all tests.   
   >>   
   >> : dlshift   
   >>    dup 0> 0= if drop ;then   
   >>    >r over 0 invert cell-bits r@ - dup >r lshift and r> rshift swap   
   >>    r@ lshift or swap r> lshift swap   
   >> ;   
   >>   
   >> : drshift   
   >>    dup 0> 0= if drop ;then   
   >>    >r dup 0 invert cell-bits r@ - dup >r rshift and r> lshift swap   
   >>    r@ rshift spin r> rshift or swap   
   >> ;   
   >   
   > The table below shows the arguments (number and shift) presented to each   
   > RSHIFT/LSHIFT in your double-shift algorithm using the 9 tests Krishna   
   provided.   
   >   
   > I've used a 32-bit forth in which RSHIFT/LSHIFT have been modified such that   
   > shifts greater than 31 bits will return 0 per the 'no ambiguous conditions'   
   > recommendation.   
   >   
   > -1 0   3 0   1 20   3 20   00 03   
   >   
   > -1 0   FF 0   0  20   FF 20   00 FF   
   >   
   > -1 0   1  0   1  20   0  20   01 00   
   >   
   > -1 0   FF 0   FF 20   0  20   FF 00   
   >   
   > -1 -20   0 -20   -1 40   -1 40   00 00   
   >   
   > -1 -20   0 -20   -1 40   -1 40   00 00   
   >   
   > -1 1   2 1   1 1F   3 1F   
   >   
   > -1 1F   -80000000 1F   2 1   -80000000 1   
   >   
   > -1 1F   1 1F   3 1   7 1   
   >   
   > While your double-shift algorithm produces the correct results (not shown   
   here),   
   > the intermediate values presented to each RSHIFT/LSHIFT can be quite   
   out-of-bounds   
   > e.g. a shift of 40 and -20 (actually FFFFFFE0) would concern me.  That an   
   'unambiguous'   
   > RSHIFT/LSHIFT will mask questionable parameters fed to it and return a   
   result of 0,   
   > I for one find problematic.  IMO it were better that RSHIFT/LSHIFT should   
   fail than   
   > do this.   
      
   This should fix it with minimal overhead:   
      
   RSHIFT: dup cell-bits - dup 0< 0= if >r drop nip r> rshift 0 swap ;then drop   
   LSHIFT: dup cell-bits - dup 0< 0= if >r drop drop r> lshift 0 ;then drop   
      
   Moderately tested.   
      
   Hans Bezemer   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)