From: the.beez.speaks@gmail.com   
      
   On 01-04-2024 17:53, Hans Bezemer wrote:   
   > 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   
   >   
      
   Darn, scrap that:   
      
   RSHIFT: dup cell-bits - dup 0< 0= if >r drop nip r> rshift 0 ;then drop   
   LSHIFT: dup cell-bits - dup 0< 0= if >r drop drop r> lshift 0 swap ;then   
   drop   
      
   Hans Bezemer   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)