[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: lshift bug
From: |
Anton Ertl |
Subject: |
Re: lshift bug |
Date: |
Mon, 18 May 2020 08:45:39 +0200 |
User-agent: |
NeoMutt/20170113 (1.7.2) |
On Sun, May 17, 2020 at 10:22:03PM +0200, Klaus Schleisiek wrote:
> Am 17.05.2020 um 18:10 schrieb Anton Ertl:
>
> > and this should work as you expect. But I would not call a result 0
> > "mathematically correct".
>
> Aber ja doch! Lshift ist doch so definiert, dass die niederwrtigen Bits mit
> Nullen gefüllt werden.
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.
> > : 2** 1 over lshift swap 8 cells < and ;
>
> Das funktioniert dann aber nur bei 64 Bit.
This works on every system with 8-bit address units (and Bernd
discussed how to eliminate that dependency), except for very large
numbers. Fix:
: 2** ( u1 -- u2 ) 1 over lshift swap 8 cells u< and ;
> Und bedenke bitte, das ich bei uCore auch mit 16, 18, 24, 27 und 32 Bits
> Datenwortbreite arbeite und keine "Bytes" habe.
Ok, for systems with arbitrary address units, use:
s" address-unit-bits" environment? [if]
constant address-unit-bits [then]
: 2** ( u1 -- u2 ) 1 over lshift swap address-unit-bits cells u< and ;
- anton