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
