[Top][All Lists]

[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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]