On 29/03/2024 12:38 am, Krishna Myneni wrote:
> On 3/28/24 06:29, dxf wrote:
>> On 28/03/2024 2:44 am, Krishna Myneni wrote:
>>> On 3/27/24 08:57, dxf wrote:
>>>> On 27/03/2024 10:26 pm, Ruvim wrote:
>>>>> On 2024-03-27 04:57, Krishna Myneni wrote:
>>>>> [...]
>>>>>> We shouldn't have an ambiguous condition here because of some idiosyncratic behavior of the SHL instruction!
>>>>>>
>>>>>> u 64 LSHIFT should be zero on all systems with cell sizes up to 64 bits.
>>>>>
>>>>> Ideally — yes.
>>>>>
>>>>> My rationale (see [1]) is that for any `x` and `u`, the result of a single shift of `x` by `u` bits should always be equivalent to `u` sequential shifts by 1 bit.
>>>>>
>>>>> But neither the standard nor implementations follow this idea.
>>>>
>>>> The same occurred with 2/ and 2 / .  Those who saw Forth as a language wanted
>>>> consistent results; whereas those who saw Forth as a toolkit said give us what
>>>> the hardware provides.
>>>>
>>>
>>> If one needs the machine shift instructions, they should be using the Forth assembler to write the word in which it is needed. The language specification has no justification (that I can see) for undefined behavior for the LSHIFT and RSHIFT instructions.
>>
>> Some 40 years ago Intel told their customers there's no justification for shifting
>> a full cell of bits.  ANS told the same thing to forthers.
>>
>>
>
> This really isn't an issue with the processor design -- they're under more severe constraints in what they can put in the hardware. The desired behavior can be achieved in software.

If it's an issue of algorithm design - how many shifts does it take before a programmer
realizes the result must be 0 - and should the language indulge him? If a forth programmer
is determined that any shift count should work then he won't mind the performance loss of
putting 2* or U2/ in a loop. Leave LSHIFT and RSHIFT to programmers whose goal is efficiency.

On 27-03-2024 01:57, Krishna Myneni wrote:
> On 3/26/24 17:01, Krishna Myneni wrote:
>> Standard source definitions of DLSHIFT and DRSHIFT (double number left
>> shift and right shift), over full shift range, per discussion in prior
>> thread.
>>
>> Tests needed.
>
> Just tested DLSHIFT and found weird things going on. Traced the problem
> to LSHIFT.

Yep. That's why I had to create this horrible code in order to force the
compiler to give me the behavior I want:

CODE (SHIFT) DSIZE (2); a = DPOP;
b = (sizeof (cell) * CHAR_BIT);
if ((a < b) && (a > -b))
{ /* within cell size? */
if (a < 0L)
{ /* force logical right shift */
DS (1) = (DS (1) >> 1L) & CELL_MAX;
a = -1L - a; DS (1) >>= a;
} /* shift one bit, clear it */
else DS (1) <<= a;
} /* we're in zero territory now */
else DS (1) = 0L;
NEXT;

Hans Bezemer

On 3/28/24 03:49, Anton Ertl wrote:
> Krishna Myneni <krishna.myneni@ccreweb.org> writes:
>> On 3/27/24 13:46, Anton Ertl wrote:
>>> You could point out that the extra cost of the check is only incurred
>>> for shifts with non-constant shift amounts, and if you could provide
>>> data on the frequency of constant and non-constant shift amounts, this
>>> might help convince system implementors.
>
> Here's some data about the occurences in the Gforth image:
>
> Non-constant shift amount:
> 2 lshift
> 1 rshift
> 0 arshift
>
> Constant shift amount:
> 18 lit lshift
> 41 lit rshift
> 0 lit arshift
>
....

Checking the Forth code base which I use, I find ~ 100:1 ratio between
uses of constant shift amount to non-constant shifts. The existing
instances of non-constant shifts are comparable to yours: two in number
theory programs e.g., finding an exact fraction for a floating point
number, and one use in the assembler.

I don't know what to conclude from this other than the kind of
application development I have been doing favors one over the other. The
large number of constant shifts have to do with defining constants,
largely for data acquisition interfaces.

--
Krishna

On 27-03-2024 20:49, Krishna Myneni wrote:
> On 3/27/24 11:36, Ruvim wrote:
>
>>>> === "double-shift.fth"
>>>>
>>>> :NONAME 0 -1 BEGIN DUP WHILE SWAP 1+ SWAP 1 RSHIFT REPEAT DROP ;
>>>> EXECUTE
>>>> CONSTANT BITS-PER-CELL
>>>>
>>>> BITS-PER-CELL 1-      CONSTANT MAX-FOR-SHIFT1
>>>> BITS-PER-CELL 2* 1-   CONSTANT MAX-FOR-SHIFT2
>>>>
>>>> : (DLSHIFT) ( xd1 u -- xd2 )
>>>>    ( x.lo x.hi  u )
>>>>    TUCK LSHIFT >R
>>>>    2DUP NEGATE BITS-PER-CELL + RSHIFT >R
>>>>    LSHIFT 2R> OR
>>>> ;
>>>> : DLSHIFT ( xd1 u -- xd2 )
>>>>    DUP 0= IF  DROP EXIT THEN
>>>>    DUP MAX-FOR-SHIFT2 U> IF  DROP 2DROP 0. EXIT THEN
>>>>    DUP MAX-FOR-SHIFT1 U> IF  NIP BITS-PER-CELL - LSHIFT 0 SWAP EXIT
>>>> THEN
>>>>    (DLSHIFT)
>>>> ;
>>>> : (DRSHIFT) ( xd1 u -- xd2 )
>>>>    ( x.lo x.hi  u )
>>>>    2DUP RSHIFT >R
>>>>    TUCK NEGATE BITS-PER-CELL + LSHIFT >R
>>>>    RSHIFT R> OR R>
>>>> ;
>>>> : DRSHIFT ( xd1 u -- xd2 )
>>>>    DUP 0= IF  DROP EXIT THEN
>>>>    DUP MAX-FOR-SHIFT2 U> IF  DROP 2DROP 0. EXIT THEN
>>>>    DUP MAX-FOR-SHIFT1 U> IF  >R NIP R> BITS-PER-CELL - RSHIFT 0 EXIT
>>>> THEN
>>>>    (DRSHIFT)
>>>> ;
>>>>
>>>> === End of "double-shift.fth"

Can't make it any shorter than this. And no idea what happens with less
robust LSHIFT or RSHIFT implementations. CELL-BITS should be most
obvious, : SPIN SWAP ROT ; should fix most porting issues, replace ;THEN
with EXIT THEN. It passes all tests.

: dlshift
dup 0> 0= if drop ;then
>r over 0 invert cell-bits r@ - dup >r lshift and r> rshift swap
r@ lshift or swap r> lshift swap
;

: drshift
dup 0> 0= if drop ;then
>r dup 0 invert cell-bits r@ - dup >r rshift and r> lshift swap
r@ rshift spin r> rshift or swap
;

Hans Bezemer

On 3/29/24 09:32, Hans Bezemer wrote:
> On 27-03-2024 20:49, Krishna Myneni wrote:
>> On 3/27/24 11:36, Ruvim wrote:
>>
>>>>> === "double-shift.fth"
>>>>>
>>>>> :NONAME 0 -1 BEGIN DUP WHILE SWAP 1+ SWAP 1 RSHIFT REPEAT DROP ;
>>>>> EXECUTE
>>>>> CONSTANT BITS-PER-CELL
>>>>>
>>>>> BITS-PER-CELL 1-      CONSTANT MAX-FOR-SHIFT1
>>>>> BITS-PER-CELL 2* 1-   CONSTANT MAX-FOR-SHIFT2
>>>>>
>>>>> : (DLSHIFT) ( xd1 u -- xd2 )
>>>>>    ( x.lo x.hi  u )
>>>>>    TUCK LSHIFT >R
>>>>>    2DUP NEGATE BITS-PER-CELL + RSHIFT >R
>>>>>    LSHIFT 2R> OR
>>>>> ;
>>>>> : DLSHIFT ( xd1 u -- xd2 )
>>>>>    DUP 0= IF  DROP EXIT THEN
>>>>>    DUP MAX-FOR-SHIFT2 U> IF  DROP 2DROP 0. EXIT THEN
>>>>>    DUP MAX-FOR-SHIFT1 U> IF  NIP BITS-PER-CELL - LSHIFT 0 SWAP EXIT
>>>>> THEN
>>>>>    (DLSHIFT)
>>>>> ;
>>>>> : (DRSHIFT) ( xd1 u -- xd2 )
>>>>>    ( x.lo x.hi  u )
>>>>>    2DUP RSHIFT >R
>>>>>    TUCK NEGATE BITS-PER-CELL + LSHIFT >R
>>>>>    RSHIFT R> OR R>
>>>>> ;
>>>>> : DRSHIFT ( xd1 u -- xd2 )
>>>>>    DUP 0= IF  DROP EXIT THEN
>>>>>    DUP MAX-FOR-SHIFT2 U> IF  DROP 2DROP 0. EXIT THEN
>>>>>    DUP MAX-FOR-SHIFT1 U> IF  >R NIP R> BITS-PER-CELL - RSHIFT 0
>>>>> EXIT THEN
>>>>>    (DRSHIFT)
>>>>> ;
>>>>>
>>>>> === End of "double-shift.fth"
>
> Can't make it any shorter than this. And no idea what happens with less
> robust LSHIFT or RSHIFT implementations. CELL-BITS should be most
> obvious, : SPIN SWAP ROT ; should fix most porting issues, replace ;THEN
> with EXIT THEN. It passes all tests.
>
> : dlshift
>   dup 0> 0= if drop ;then
>   >r over 0 invert cell-bits r@ - dup >r lshift and r> rshift swap
>   r@ lshift or swap r> lshift swap
> ;
>
> : drshift
>   dup 0> 0= if drop ;then
>   >r dup 0 invert cell-bits r@ - dup >r rshift and r> lshift swap
>   r@ rshift spin r> rshift or swap
> ;
>

Thanks! I have updated LSHIFT and RSHIFT in kForth-32 and kForth-64 to
handle shift count >= BITS_PER_CELL to give the expected answer (0).

--
Krishna

On 3/26/24 19:57, Krishna Myneni wrote:
> On 3/26/24 17:01, Krishna Myneni wrote:
>> Standard source definitions of DLSHIFT and DRSHIFT (double number left
>> shift and right shift), over full shift range, per discussion in prior
>> thread.
>>
>> Tests needed.
>
> Just tested DLSHIFT and found weird things going on. Traced the problem
> to LSHIFT.
>
>
> kforth64
>
> 1 64 LSHIFT .  \ expected to get zero
> 1              \ instead, got 1
>
> Then, I looked at the spec. for LSHIFT and, indeed, there is an
> ambiguous condition for u >= BITS_PER_CELL .
>
>
> 6.1.1805
> LSHIFT “l-shift”
> CORE
> ( x1 u – – x2 )
> Perform a logical left shift of u bit-places on x1, giving x2. Put
> zeroes into the least significant bits vacated by the shift. An
> ambiguous condition exists if u is greater than or equal to the number
> of bits in a cell.
>
> Gforth does the same thing
>
> 1 64 LSHIFT .  1
> 1 65 LSHIFT .  2
> etc.
>
>
> We shouldn't have an ambiguous condition here because of some
> idiosyncratic behavior of the SHL instruction!
>
> u 64 LSHIFT should be zero on all systems with cell sizes up to 64 bits.
>

I have revised LSHIFT and RSHIFT in kForth-32 and kForth-64 to give
expected results for shift count >= BITS_PER_CELL (still have to update
kForth-Win32). Some test code to check that these words behave as expected:

1 CELLS 8 * constant BITS_PER_CELL

: test-lshift ( -- )
BITS_PER_CELL 6 + 0 DO
I 2 .R 2 SPACES
1 I LSHIFT
BINARY BITS_PER_CELL U.R CR DECIMAL
LOOP ;

: test-rshift ( -- )
1 BITS_PER_CELL 1- LSHIFT
BITS_PER_CELL 6 + 0 DO
I 2 .R 2 SPACES
DUP I RSHIFT
BINARY BITS_PER_CELL U.R CR DECIMAL
LOOP DROP ;

TEST-LSHIFT ( on 32-bit system )
0 1
1 10
2 100
3 1000
4 10000
5 100000
6 1000000
7 10000000
8 100000000
9 1000000000
10 10000000000
11 100000000000
12 1000000000000
13 10000000000000
14 100000000000000
15 1000000000000000
16 10000000000000000
17 100000000000000000
18 1000000000000000000
19 10000000000000000000
20 100000000000000000000
21 1000000000000000000000
22 10000000000000000000000
23 100000000000000000000000
24 1000000000000000000000000
25 10000000000000000000000000
26 100000000000000000000000000
27 1000000000000000000000000000
28 10000000000000000000000000000
29 100000000000000000000000000000
30 1000000000000000000000000000000
31 10000000000000000000000000000000
32 0
33 0
34 0
35 0
36 0
37 0
ok
TEST-RSHIFT ( on 32-bit system )
0 10000000000000000000000000000000
1 1000000000000000000000000000000
2 100000000000000000000000000000
3 10000000000000000000000000000
4 1000000000000000000000000000
5 100000000000000000000000000
6 10000000000000000000000000
7 1000000000000000000000000
8 100000000000000000000000
9 10000000000000000000000
10 1000000000000000000000
11 100000000000000000000
12 10000000000000000000
13 1000000000000000000
14 100000000000000000
15 10000000000000000
16 1000000000000000
17 100000000000000
18 10000000000000
19 1000000000000
20 100000000000
21 10000000000
22 1000000000
23 100000000
24 10000000
25 1000000
26 100000
27 10000
28 1000
29 100
30 10
31 1
32 0
33 0
34 0
35 0
36 0
37 0
ok

Similar displays for 64-bit systems.

--
KM

Krishna Myneni <krishna.myneni@ccreweb.org> writes:
>On 3/28/24 03:49, Anton Ertl wrote:
>> Here's some data about the occurences in the Gforth image:
>>
>> Non-constant shift amount:
>> 2 lshift
>> 1 rshift
>> 0 arshift
>>
>> Constant shift amount:
>> 18 lit lshift
>> 41 lit rshift
>> 0 lit arshift
>>
>...
>
>Checking the Forth code base which I use, I find ~ 100:1 ratio between
>uses of constant shift amount to non-constant shifts. The existing
>instances of non-constant shifts are comparable to yours: two in number
>theory programs e.g., finding an exact fraction for a floating point
>number, and one use in the assembler.
>
>I don't know what to conclude from this other than the kind of
>application development I have been doing favors one over the other.

It shows that Forth systems that support special code generation for
operations with constants (probably all native-code systems, as well
as Gforth) would be able to generate the same code in the vast
majority of cases even with the change you propose. Only in the few
non-constant cases a few extra instructions would be needed.

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: https://forth-standard.org/
EuroForth 2023: https://euro.theforth.net/2023

On 28/03/2024 3:36 am, Ruvim wrote:
> On 2024-03-27 19:33, Krishna Myneni wrote:
>> ...
>> Does it succeed on all of the tests I gave?
>
> Of course, I checked — it succeed your tests.

VFX's implementations are simpler still and pass the tests with the
exception of 5 and 6 (same ambiguous conditions as ANS).

On 3/29/24 11:55, Anton Ertl wrote:
> Krishna Myneni <krishna.myneni@ccreweb.org> writes:
>> On 3/28/24 03:49, Anton Ertl wrote:
>>> Here's some data about the occurences in the Gforth image:
>>>
>>> Non-constant shift amount:
>>> 2 lshift
>>> 1 rshift
>>> 0 arshift
>>>
>>> Constant shift amount:
>>> 18 lit lshift
>>> 41 lit rshift
>>> 0 lit arshift
>>>
>> ...
>>
>> Checking the Forth code base which I use, I find ~ 100:1 ratio between
>> uses of constant shift amount to non-constant shifts. The existing
>> instances of non-constant shifts are comparable to yours: two in number
>> theory programs e.g., finding an exact fraction for a floating point
>> number, and one use in the assembler.
>>
>> I don't know what to conclude from this other than the kind of
>> application development I have been doing favors one over the other.
>
> It shows that Forth systems that support special code generation for
> operations with constants (probably all native-code systems, as well
> as Gforth) would be able to generate the same code in the vast
> majority of cases even with the change you propose. Only in the few
> non-constant cases a few extra instructions would be needed.
>

Ah, so optimizing Forth compilers can do a compile-time check for
literal shifts and not have to insert instructions for compare and
branch e.g., my new implementation of LSHIFT in kforth64

(from vm64-common.s)

..equ MAX_SHIFT_COUNT, WSIZE*8-1

L_lshift:
LDSP
DROP
mov (%rbx), %rcx
cmp $MAX_SHIFT_COUNT, %rcx
jbe lshift1
movq $0, WSIZE(%rbx)
NEXT
lshift1:
shlq %cl, WSIZE(%rbx)
NEXT

The older version was:

L_lshift:
LDSP
DROP
mov (%rbx), %rcx
shlq %cl, WSIZE(%rbx)
NEXT

Similarly for RSHIFT.

--
KM

Krishna Myneni <krishna.myneni@ccreweb.org> writes:
>Ah, so optimizing Forth compilers can do a compile-time check for
>literal shifts and not have to insert instructions for compare and
>branch

Yes.

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: https://forth-standard.org/
EuroForth 2023: https://euro.theforth.net/2023

On 30/03/2024 1:32 am, Hans Bezemer wrote:
> ...
> And no idea what happens with less robust LSHIFT or RSHIFT implementations.

Simply define:

: lshift dup cell-bits u< 0= abort" **shift-arg**" lshift ;
: rshift dup cell-bits u< 0= abort" **shift-arg**" rshift ;

It will reveal all the out-of-bounds cases in one's code that's been masked
by having LSHIFT and RSHIFT return zero.

On 30/03/2024 1:32 am, Hans Bezemer wrote:
> ...
> Can't make it any shorter than this. And no idea what happens with less robust LSHIFT or RSHIFT implementations. CELL-BITS should be most obvious, : SPIN SWAP ROT ; should fix most porting issues, replace ;THEN
> with EXIT THEN. It passes all tests.
>
> : dlshift
>   dup 0> 0= if drop ;then
>   >r over 0 invert cell-bits r@ - dup >r lshift and r> rshift swap
>   r@ lshift or swap r> lshift swap
> ;
>
> : drshift
>   dup 0> 0= if drop ;then
>   >r dup 0 invert cell-bits r@ - dup >r rshift and r> lshift swap
>   r@ rshift spin r> rshift or swap
> ;

The table below shows the arguments (number and shift) presented to each
RSHIFT/LSHIFT in your double-shift algorithm using the 9 tests Krishna provided.

I've used a 32-bit forth in which RSHIFT/LSHIFT have been modified such that
shifts greater than 31 bits will return 0 per the 'no ambiguous conditions'
recommendation.

-1 0 3 0 1 20 3 20 00 03

-1 0 FF 0 0 20 FF 20 00 FF

-1 0 1 0 1 20 0 20 01 00

-1 0 FF 0 FF 20 0 20 FF 00

-1 -20 0 -20 -1 40 -1 40 00 00

-1 -20 0 -20 -1 40 -1 40 00 00

-1 1 2 1 1 1F 3 1F

-1 1F -80000000 1F 2 1 -80000000 1

-1 1F 1 1F 3 1 7 1

While your double-shift algorithm produces the correct results (not shown here),
the intermediate values presented to each RSHIFT/LSHIFT can be quite out-of-bounds
e.g. a shift of 40 and -20 (actually FFFFFFE0) would concern me. That an 'unambiguous'
RSHIFT/LSHIFT will mask questionable parameters fed to it and return a result of 0,
I for one find problematic. IMO it were better that RSHIFT/LSHIFT should fail than
do this.

dxf wrote:

> While your double-shift algorithm produces the correct results (not shown here),
> the intermediate values presented to each RSHIFT/LSHIFT can be quite out-of-bounds
> e.g. a shift of 40 and -20 (actually FFFFFFE0) would concern me. That an 'unambiguous'
> RSHIFT/LSHIFT will mask questionable parameters fed to it and return a result of 0,
> I for one find problematic. IMO it were better that RSHIFT/LSHIFT should fail than
> do this.

Doesn't make sense during fp number addition/subtraction.

On 1/04/2024 7:03 pm, minforth wrote:
> dxf wrote:
>
>> While your double-shift algorithm produces the correct results (not shown here),
>> the intermediate values presented to each RSHIFT/LSHIFT can be quite out-of-bounds
>> e.g. a shift of 40 and -20 (actually FFFFFFE0) would concern me.  That an 'unambiguous'
>> RSHIFT/LSHIFT will mask questionable parameters fed to it and return a result of 0,
>> I for one find problematic.  IMO it were better that RSHIFT/LSHIFT should fail than
>> do this.
>
> Doesn't make sense during fp number addition/subtraction.

Example?

In article <uu1pmo$305br$1@dont-email.me>,
Bernd Linsel <bl1-thispartdoesnotbelonghere@gmx.com> wrote:
>On 27.03.2024 13:28, Krishna Myneni wrote:
>>
>> I really think it is a bad idea to have UB in the spec of LSHIFT and
>> RSHIFT due to the arbitrariness of low level shift operations at the
> > hardware level.
>
>It's not UB, it is IB and thus it should be required that an implementer
>documents the respective behaviour of their system.
>
> > Here we have a chance to remove that UB and guarantee that>
>> 1 BITS_PER_CELL LSHIFT  returns zero
>> and
>> 1 BITS_PER_CELL RSHIFT  returns zero
>>
>> so that the expected result for a shift operation on the cell operand
>> does not have UB.
>>
>> Efficiency because of extra instructions needed to implement this
>> guarantee are not even worth bothering about -- we are not C.
>
>Forth does care about efficiency. Otherwise you could eliminate over the
>half of the ambiguous conditions in the Forth standard that only arise
>from the fact that hardware platforms differ in their behaviour.
>
>[snip]
>
>For the rare situation that a variable shift count is needed, and is not
>per se restricted to 0..ADDRESS-UNIT-BITS - 1, you can always write either
>
>0 MAX S" ADDRESS-UNIT-BITS" 1- MIN LSHIFT ( or RSHIFT)
>
>or
>
>DUP 0< INVERT IF DUP S" ADDRESS-UNIT-BITS" < IF LSHIFT ( or RSHIFT)
>ELSE ( whatever to do if shift-amount < 0)
>ELSE ( whatever to do if shift-amount >= cell width)
>THEN THEN
>
>or simply
>
>DUP 0< ABORT" shift amount less than 0"
>DUP S" ADDRESS-UNIT-BITS" 1- > ABORT" shift amount greater/equal cell width)
>LSHIFT ( or RSHIFT)

I hate ABORT in this context. Are you sure that you want to shut down
the nuclear power plant in this situation?

>
>NB: The behaviour of most processors to only regard the 5 or 6 LSBs is
>useful for expressions like -1 64 <n> - LSHIFT to produce bit masks,
>these can simply be expressed as <n> NEGATE LSHIFT (with an
>environmental dependency on processors that behave this way).
>
>
>--
>Bernd Linsel
--
Don't praise the day before the evening. One swallow doesn't make spring.
You must not say "hey" before you have crossed the bridge. Don't sell the
hide of the bear until you shot it. Better one bird in the hand than ten in
the air. First gain is a cat purring. - the Wise from Antrim -

albert@spenarnc.xs4all.nl writes:
>In article <uu1pmo$305br$1@dont-email.me>,
>Bernd Linsel <bl1-thispartdoesnotbelonghere@gmx.com> wrote:
>>NB: The behaviour of most processors to only regard the 5 or 6 LSBs is
>>useful for expressions like -1 64 <n> - LSHIFT to produce bit masks,
>>these can simply be expressed as <n> NEGATE LSHIFT (with an
>>environmental dependency on processors that behave this way).

Let's see:

-1 64 2 - lshift hex. $C000000000000000 ok
-1 64 1 - lshift hex. $8000000000000000 ok
-1 64 0 - lshift hex. $FFFFFFFFFFFFFFFF ok

I have my doubts that somebody performing such a computation intends
to produce the last result. A result of 0 is more likely to be
intended. Of course, there is some chance that providing a zero <n>
for that computation is not intended, which may be a justification for
everybody involved to produce arbitrary results in that case.

Anyway, given 64-bt cells, the standard LSHIFT and twos-complement
arithmetic (which is assumed by the "-1" above already), one can
express the intention as follows:

: gen-mask1 ( n -- x )
\ produce -1 if <n>=0
negate 63 and -1 swap lshift ;

: gen-mask2 ( n -- x )
\ produce 0 if <n>=0
64 swap - dup 64 u< if
-1 swap lshift
else
drop 0
then ;

: gen-mask3 ( n -- x )
\ throw if <n>=0
64 swap - dup 64 u< 0= -24 and throw -1 swap lshift ;

And similarly for machine code. So, if GEN-MASK1 is intended, even an
LSHIFT that produces 0 for larger shift counts is only one instruction
away. So it is unlikely that the computer architects decided to look
at only the LSB bits for that purpose.

BTW, I ignore base64-encoded postings.

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: https://forth-standard.org/
EuroForth 2023: https://euro.theforth.net/2023

On 01-04-2024 03:22, dxf wrote:
> On 30/03/2024 1:32 am, Hans Bezemer wrote:
>> ...
>> Can't make it any shorter than this. And no idea what happens with less robust LSHIFT or RSHIFT implementations. CELL-BITS should be most obvious, : SPIN SWAP ROT ; should fix most porting issues, replace ;THEN
>> with EXIT THEN. It passes all tests.
>>
>> : dlshift
>>   dup 0> 0= if drop ;then
>>   >r over 0 invert cell-bits r@ - dup >r lshift and r> rshift swap
>>   r@ lshift or swap r> lshift swap
>> ;
>>
>> : drshift
>>   dup 0> 0= if drop ;then
>>   >r dup 0 invert cell-bits r@ - dup >r rshift and r> lshift swap
>>   r@ rshift spin r> rshift or swap
>> ;
>
> The table below shows the arguments (number and shift) presented to each
> RSHIFT/LSHIFT in your double-shift algorithm using the 9 tests Krishna provided.
>
> I've used a 32-bit forth in which RSHIFT/LSHIFT have been modified such that
> shifts greater than 31 bits will return 0 per the 'no ambiguous conditions'
> recommendation.
>
> -1 0 3 0 1 20 3 20 00 03
>
> -1 0 FF 0 0 20 FF 20 00 FF
>
> -1 0 1 0 1 20 0 20 01 00
>
> -1 0 FF 0 FF 20 0 20 FF 00
>
> -1 -20 0 -20 -1 40 -1 40 00 00
>
> -1 -20 0 -20 -1 40 -1 40 00 00
>
> -1 1 2 1 1 1F 3 1F
>
> -1 1F -80000000 1F 2 1 -80000000 1
>
> -1 1F 1 1F 3 1 7 1
>
> While your double-shift algorithm produces the correct results (not shown here),
> the intermediate values presented to each RSHIFT/LSHIFT can be quite out-of-bounds
> e.g. a shift of 40 and -20 (actually FFFFFFE0) would concern me. That an 'unambiguous'
> RSHIFT/LSHIFT will mask questionable parameters fed to it and return a result of 0,
> I for one find problematic. IMO it were better that RSHIFT/LSHIFT should fail than
> do this.
I see where you're going with this. I have two things to say about this:
1. If you're confronted with a LSHIFT/RSHIFT that's not reliable when
you exceed a CELL-BITS shift, the entire discussion is moot anyway;
2. 4tH's implementation does not have a separate LSHIFT/RSHIFT. It's the
same thing, so a negative shift works as expected.

That may seem a bit harsh, but it's the consequence of "An ambiguous
condition exists if u is greater than or equal to the number of bits in
a cell" and a separate LSHIFT and RSHIFT. I mean a MAX-U shift is
meaningless in every universe (spoiler alert: it's "ambiguous"), why not
make it "+/-n"?

The only viable alternative is:

: DLSHIFT ( xd1 n -- xd2) 0 ?do d2* loop ;
: DRSHIFT ( xd1 n -- xd2) 0 ?do d2/ loop ;

Which is okay in my book, but may be not fast enough for some.

One could save the routine by adding:
dup cell-bits - dup 0< 0= if abs >r >r swap dup xor r> r> swap then drop

Sure, it wont be any faster, but it'd avoid "ambiguous" LSHIFT/RSHIFT
issues.

Hans Bezemer

On 01-04-2024 03:22, dxf wrote:
> On 30/03/2024 1:32 am, Hans Bezemer wrote:
>> ...
>> Can't make it any shorter than this. And no idea what happens with less robust LSHIFT or RSHIFT implementations. CELL-BITS should be most obvious, : SPIN SWAP ROT ; should fix most porting issues, replace ;THEN
>> with EXIT THEN. It passes all tests.
>>
>> : dlshift
>>   dup 0> 0= if drop ;then
>>   >r over 0 invert cell-bits r@ - dup >r lshift and r> rshift swap
>>   r@ lshift or swap r> lshift swap
>> ;
>>
>> : drshift
>>   dup 0> 0= if drop ;then
>>   >r dup 0 invert cell-bits r@ - dup >r rshift and r> lshift swap
>>   r@ rshift spin r> rshift or swap
>> ;
>
> The table below shows the arguments (number and shift) presented to each
> RSHIFT/LSHIFT in your double-shift algorithm using the 9 tests Krishna provided.
>
> I've used a 32-bit forth in which RSHIFT/LSHIFT have been modified such that
> shifts greater than 31 bits will return 0 per the 'no ambiguous conditions'
> recommendation.
>
> -1 0 3 0 1 20 3 20 00 03
>
> -1 0 FF 0 0 20 FF 20 00 FF
>
> -1 0 1 0 1 20 0 20 01 00
>
> -1 0 FF 0 FF 20 0 20 FF 00
>
> -1 -20 0 -20 -1 40 -1 40 00 00
>
> -1 -20 0 -20 -1 40 -1 40 00 00
>
> -1 1 2 1 1 1F 3 1F
>
> -1 1F -80000000 1F 2 1 -80000000 1
>
> -1 1F 1 1F 3 1 7 1
>
> While your double-shift algorithm produces the correct results (not shown here),
> the intermediate values presented to each RSHIFT/LSHIFT can be quite out-of-bounds
> e.g. a shift of 40 and -20 (actually FFFFFFE0) would concern me. That an 'unambiguous'
> RSHIFT/LSHIFT will mask questionable parameters fed to it and return a result of 0,
> I for one find problematic. IMO it were better that RSHIFT/LSHIFT should fail than
> do this.

This should fix it with minimal overhead:

RSHIFT: dup cell-bits - dup 0< 0= if >r drop nip r> rshift 0 swap ;then drop
LSHIFT: dup cell-bits - dup 0< 0= if >r drop drop r> lshift 0 ;then drop

Moderately tested.

Hans Bezemer

On 01-04-2024 17:53, Hans Bezemer wrote:
> On 01-04-2024 03:22, dxf wrote:
>> On 30/03/2024 1:32 am, Hans Bezemer wrote:
>>> ...
>>> Can't make it any shorter than this. And no idea what happens with
>>> less robust LSHIFT or RSHIFT implementations. CELL-BITS should be
>>> most obvious, : SPIN SWAP ROT ; should fix most porting issues,
>>> replace ;THEN
>>> with EXIT THEN. It passes all tests.
>>>
>>> : dlshift
>>>    dup 0> 0= if drop ;then
>>>    >r over 0 invert cell-bits r@ - dup >r lshift and r> rshift swap
>>>    r@ lshift or swap r> lshift swap
>>> ;
>>>
>>> : drshift
>>>    dup 0> 0= if drop ;then
>>>    >r dup 0 invert cell-bits r@ - dup >r rshift and r> lshift swap
>>>    r@ rshift spin r> rshift or swap
>>> ;
>>
>> The table below shows the arguments (number and shift) presented to each
>> RSHIFT/LSHIFT in your double-shift algorithm using the 9 tests Krishna
>> provided.
>>
>> I've used a 32-bit forth in which RSHIFT/LSHIFT have been modified
>> such that
>> shifts greater than 31 bits will return 0 per the 'no ambiguous
>> conditions'
>> recommendation.
>>
>> -1 0   3 0   1 20   3 20   00 03
>>
>> -1 0   FF 0   0  20   FF 20   00 FF
>>
>> -1 0   1  0   1  20   0  20   01 00
>>
>> -1 0   FF 0   FF 20   0  20   FF 00
>>
>> -1 -20   0 -20   -1 40   -1 40   00 00
>>
>> -1 -20   0 -20   -1 40   -1 40   00 00
>>
>> -1 1   2 1   1 1F   3 1F
>>
>> -1 1F   -80000000 1F   2 1   -80000000 1
>>
>> -1 1F   1 1F   3 1   7 1
>>
>> While your double-shift algorithm produces the correct results (not
>> shown here),
>> the intermediate values presented to each RSHIFT/LSHIFT can be quite
>> out-of-bounds
>> e.g. a shift of 40 and -20 (actually FFFFFFE0) would concern me.  That
>> an 'unambiguous'
>> RSHIFT/LSHIFT will mask questionable parameters fed to it and return a
>> result of 0,
>> I for one find problematic.  IMO it were better that RSHIFT/LSHIFT
>> should fail than
>> do this.
>
> This should fix it with minimal overhead:
>
> RSHIFT: dup cell-bits - dup 0< 0= if >r drop nip r> rshift 0 swap ;then
> drop
> LSHIFT: dup cell-bits - dup 0< 0= if >r drop drop r> lshift 0 ;then drop
>
> Moderately tested.
>
> Hans Bezemer
>

Darn, scrap that:

RSHIFT: dup cell-bits - dup 0< 0= if >r drop nip r> rshift 0 ;then drop
LSHIFT: dup cell-bits - dup 0< 0= if >r drop drop r> lshift 0 swap ;then
drop

Hans Bezemer

On 4/1/24 10:18, Hans Bezemer wrote:
....
> The only viable alternative is:
>
> : DLSHIFT  ( xd1 n -- xd2)     0 ?do d2* loop ;
> : DRSHIFT  ( xd1 n -- xd2)     0 ?do d2/ loop ;
>

DRSHIFT cannot be coded with D2/ which is an arithmetic right shift,
i.e. it preserves the sign bit. DRSHIFT has to pad from the left with
zero bits.

--
Krishna

On 4/1/24 04:21, dxf wrote:
> On 1/04/2024 7:03 pm, minforth wrote:
>> dxf wrote:
>>
>>> While your double-shift algorithm produces the correct results (not shown here),
>>> the intermediate values presented to each RSHIFT/LSHIFT can be quite out-of-bounds
>>> e.g. a shift of 40 and -20 (actually FFFFFFE0) would concern me.  That an 'unambiguous'
>>> RSHIFT/LSHIFT will mask questionable parameters fed to it and return a result of 0,
>>> I for one find problematic.  IMO it were better that RSHIFT/LSHIFT should fail than
>>> do this.
>>
>> Doesn't make sense during fp number addition/subtraction.
>
> Example?
>

First, there is no negative shift count argument for LSHIFT RSHIFT
DLSHIFT or DRSHIFT . The arguments are unsigned.

For an ieee 754 double precision number, there is an effective distance
of 53 bits between the most significant bit and the least significant
bit. On a 32-bit system, consider adding 1.0e0 to the number 1.0e10.

The ieee-754 unbiased base 2 exponents for the two floating point
arguments are 0 (for 1.0e0) and 33 (for 1.0e10). This means that adding
the two 53-bit significands using two double numbers (two 64-bit numbers
on a 32 bit system) requires a relative right shift of 33 bits for the
argument 1.0e0.

Here are the bit patterns for the two significands, along with their
base 2 exponents:

21098765432109876543210987654321098765432109876543210
10010101000000101111100100000000000000000000000000000 33
10000000000000000000000000000000000000000000000000000 00

There are 53 bits in each significand, and the 53rd bit is always an
implied 1. To add these, we can use 33 DRSHIFT on the one argument to
align the significands and add the two double length numbers to obtain
the new significand.

For ieee 754 quad precision, there are 113 bits in the significand, so
relative shifts can be as large as 112 bits for addition and subtraction.

--
Krishna

On 02-04-2024 02:56, Krishna Myneni wrote:
> On 4/1/24 10:18, Hans Bezemer wrote:
> ...
>> The only viable alternative is:
>>
>> : DLSHIFT  ( xd1 n -- xd2)     0 ?do d2* loop ;
>> : DRSHIFT  ( xd1 n -- xd2)     0 ?do d2/ loop ;
>>
>
> DRSHIFT cannot be coded with D2/ which is an arithmetic right shift,
> i.e. it preserves the sign bit. DRSHIFT has to pad from the left with
> zero bits.

True, but if you know my coding style - this is not it. And it is
acknowledged as such in the source:

\ DXForth MISC.SCR, Copyright Ed, 2011-03-25
\ Albert van der Horst, Thursday 09 April 2015 19:57:13, c.l.f

So it's not uncommon to define it like this. Apart from that - "D2/" is
not a standardized word - so it can mean anything. Although I do agree
with you that your definition is the most likely one.

Hans Bezemer

On 4/2/24 03:56, Hans Bezemer wrote:
> On 02-04-2024 02:56, Krishna Myneni wrote:
>> On 4/1/24 10:18, Hans Bezemer wrote:
>> ...
>>> The only viable alternative is:
>>>
>>> : DLSHIFT  ( xd1 n -- xd2)     0 ?do d2* loop ;
>>> : DRSHIFT  ( xd1 n -- xd2)     0 ?do d2/ loop ;
>>>
>>
>> DRSHIFT cannot be coded with D2/ which is an arithmetic right shift,
>> i.e. it preserves the sign bit. DRSHIFT has to pad from the left with
>> zero bits.
>
> True, but if you know my coding style - this is not it. And it is
> acknowledged as such in the source:
>
> \ DXForth MISC.SCR, Copyright Ed, 2011-03-25
> \ Albert van der Horst, Thursday 09 April 2015 19:57:13, c.l.f
>
> So it's not uncommon to define it like this. Apart from that - "D2/" is
> not a standardized word - so it can mean anything. Although I do agree
> with you that your definition is the most likely one.
>
> Hans Bezemer

D2/ is a standardized word, since ANS Forth:

8.6.1.1100
D2/
“d-two-slash”
DOUBLE
( xd1 – – xd2 )
xd2 is the result of shifting xd1 one bit toward the least-significant
bit, leaving the most-significant bit unchanged.

--
KM

On 02-04-2024 13:33, Krishna Myneni wrote:
> On 4/2/24 03:56, Hans Bezemer wrote:
>> On 02-04-2024 02:56, Krishna Myneni wrote:
>>> On 4/1/24 10:18, Hans Bezemer wrote:
>>> ...
>>>> The only viable alternative is:
>>>>
>>>> : DLSHIFT  ( xd1 n -- xd2)     0 ?do d2* loop ;
>>>> : DRSHIFT  ( xd1 n -- xd2)     0 ?do d2/ loop ;
>>>>
>>>
>>> DRSHIFT cannot be coded with D2/ which is an arithmetic right shift,
>>> i.e. it preserves the sign bit. DRSHIFT has to pad from the left with
>>> zero bits.
>>
>> True, but if you know my coding style - this is not it. And it is
>> acknowledged as such in the source:
>>
>> \ DXForth MISC.SCR, Copyright Ed, 2011-03-25
>> \ Albert van der Horst, Thursday 09 April 2015 19:57:13, c.l.f
>>
>> So it's not uncommon to define it like this. Apart from that - "D2/"
>> is not a standardized word - so it can mean anything. Although I do
>> agree with you that your definition is the most likely one.
>>
>> Hans Bezemer
>
> D2/ is a standardized word, since ANS Forth:
>
> 8.6.1.1100
> D2/
> “d-two-slash”
> DOUBLE
> ( xd1 – – xd2 )
> xd2 is the result of shifting xd1 one bit toward the least-significant
> bit, leaving the most-significant bit unchanged.

I stand corrected, sir. ;-)

Hans Bezemer

On 2/04/2024 2:02 pm, dxf wrote:
> ...
> LSHIFT/RSHIFT was intended to support the corresponding machine-code primitives available on
> modern architectures.

Not a bad guess as it turns out.

Digging further I found this from ANS 'BASIS17' June 1991:

8.1.2205 SHIFT

( x1 n -- x2 )

Perform a logical shift of n bit-places on x1, giving x2. If n is
positive, shift the bits n places toward the most significant bit. If n is
negative, shift them toward the least significant bits. Put zero into
the places "uncovered" by the shift.

That led to this Jan 1992 message:

https://groups.google.com/g/comp.lang.forth/c/DqrKMIiyLWc/m/1XUyYBaHyfYJ