Re: lshift bug

[Klaus Schleisiek]

Am 18.05.2020 um 08:45 schrieb Anton Ertl:

> For lshift the shift count results in an ambuguous condition.
> 
> For 2**, 0 is just as wrong as any other number that fits into a cell.

Lets look at it from a mathematical point of view. (For a 16 bit machine for the
sake of argument.)

&15 2** = $8000.

&16 2** = $1.0000. This would be correct but not representable. (One could set a
carry bit though.) If we now do $1.0000 mod(2^16) = 0.

Therefore, I consider 0 as mathematically correct, whereas 1 is just wrong.

This is how I bumped into it:

I have a cross-compiler/debugger running on a 32 bit system. When I pass numbers
to the target system, I have to take care of the data width difference between
host (32) and target (12..32). Constant data_width is the targets data width.
This is done by

: u>target ( u1 -- u2 )  #datamask and ;

And this is how I compute #datamask:

: 2**   1 swap lshift ;
data_width 2** 1- Constant #datamask

Most of the time I had a target data width of 18 or 27 bits. Fine, that works
with gforth's lshift. But three days ago I tried to compile code for a 32 bit
target. Using lshift, #datamask was 0 all of a sudden and it took a while until
I found lshift to be the culprit.
-- 
Klaus Schleisiek
Am Elbufer 8
29478 Höhbeck-Vietze
05846 9804008