[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
## Re: lshift bug

**From**: |
Klaus Schleisiek |

**Subject**: |
Re: lshift bug |

**Date**: |
Mon, 18 May 2020 12:11:19 +0200 |

**User-agent**: |
Mozilla/5.0 (Windows NT 5.1; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 |

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