On 04-04-2024 09:42, dxf wrote:
> 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
>
Fun part - 4tH still has SHIFT, performing exactly as indicated. LSHIFT
is exactly like SHIFT, while RSHIFT is expanded to NEGATE SHIFT.

It's been like that for the last 30 years. Can't remember whether I
nicked the word from Forth-79, but if it was there I can't rule it out.

The word has been changed several times. First to force a logical RSHIFT
and second to properly handle shifts exceeding CELL-BITS bits.

It's also exposed in uBasic/4tH with the SHL() function (which also
accepts negative shifts).

Hans Bezemer

dxf <dxforth@gmail.com> writes:
>That led to this Jan 1992 message:
>
>https://groups.google.com/g/comp.lang.forth/c/DqrKMIiyLWc/m/1XUyYBaHyfYJ

I found the last posting in this thread most fitting:

|Andrew Scott
|Jan 13, 1992, 9:32:24 PM
| |John Hayes writes:
|>The bidirectional shift operator is probably a result of the parsimony
|>of Forth philosophy; why have two operators when one will do.
| |I thought part of the Forth philosophy was exactly the *opposite*. We
|wouldn't have words like 1+ or 0< if efficiency wasn't regarded as more
|important than a small set of consistent words.

- 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 5/04/2024 2:34 am, Hans Bezemer wrote:
> On 04-04-2024 09:42, dxf wrote:
>> 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
>>
> Fun part - 4tH still has SHIFT, performing exactly as indicated. LSHIFT is exactly like SHIFT, while RSHIFT is expanded to NEGATE SHIFT.
>
> It's been like that for the last 30 years. Can't remember whether I nicked the word from Forth-79, but if it was there I can't rule it out.

Didn't think to look but yes - it is from Forth-79 'Reference Word Set' (Kitt Peak Forth
words that didn't make it into the standard proper).

ASHIFT n1 n2 -- n3
Shift the value n1 arithemetically n2 bits left if n2 is
positive, shifting zeros into the least-significant bit
positions. If n2 is negative, n1 is shifted right. Sign
extension is to be consistent with the processor's arithmetic
shift.
> The word has been changed several times. First to force a logical RSHIFT and second to properly handle shifts exceeding CELL-BITS bits.
>
> It's also exposed in uBasic/4tH with the SHL() function (which also accepts negative shifts).
>
> Hans Bezemer

On 04-04-2024 18:27, Anton Ertl wrote:
> dxf <dxforth@gmail.com> writes:
> I found the last posting in this thread most fitting:
>
> |Andrew Scott
> |Jan 13, 1992, 9:32:24 PM
> |
> |John Hayes writes:
> |>The bidirectional shift operator is probably a result of the parsimony
> |>of Forth philosophy; why have two operators when one will do.
> |
> |I thought part of the Forth philosophy was exactly the *opposite*. We
> |wouldn't have words like 1+ or 0< if efficiency wasn't regarded as more
> |important than a small set of consistent words.

So true - which is fun when you're implementing Forth in bytecode. Since
bytecodes are limited, you want to restrict the number of words, while
Forth tends to expand its vocabulary. The most common ones have their
own bytecode in 4tH, while the less frequently used are often
composites. 4tH got about 100 bytecodes, but almost three times the
number of builtin words.

Hans Bezemer

On 5/04/2024 3:27 am, Anton Ertl wrote:
> ...
> I found the last posting in this thread most fitting:
>
> |Andrew Scott
> |Jan 13, 1992, 9:32:24 PM
> |
> |John Hayes writes:
> |>The bidirectional shift operator is probably a result of the parsimony
> |>of Forth philosophy; why have two operators when one will do.
> |
> |I thought part of the Forth philosophy was exactly the *opposite*. We
> |wouldn't have words like 1+ or 0< if efficiency wasn't regarded as more
> |important than a small set of consistent words.

ALLOT is a good example of the 'parsimony' rule. Unlike bidirectional
shift, co-habitation is cheap and easy. Issues created by a bidirectional
ALLOT mostly affects 16-bit users. As I could afford to be single, I have
ALLOT and RECOVER.

On 01-04-2024 03:22, 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.

For those interested in the entire fixed routine, here it is:

: dlshift
dup 0> 0= if drop ;then
dup cell-bits - dup 0< 0= if >r drop drop r> lshift 0 swap ;then drop
>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
dup cell-bits - dup 0< 0= if >r drop nip r> rshift 0 ;then drop
>r dup 0 invert cell-bits r@ - dup >r rshift and r> lshift swap
r@ rshift spin r> rshift or swap
;

: SPIN SWAP ROT ;
: ;THEN POSTPONE EXIT POSTPONE THEN ; IMMEDIATE

"cell-bits" should be obvious.

Hans Bezemer

On 7/04/2024 10:53 pm, Hans Bezemer wrote:
> On 01-04-2024 03:22, 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.
>
> For those interested in the entire fixed routine, here it is:
>
> : dlshift
>   dup 0> 0= if drop ;then
>   dup cell-bits - dup 0< 0= if >r drop drop r> lshift 0 swap ;then drop
>   >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
>   dup cell-bits - dup 0< 0= if >r drop nip r> rshift 0 ;then drop
>   >r dup 0 invert cell-bits r@ - dup >r rshift and r> lshift swap
>   r@ rshift spin r> rshift or swap
> ;
>
> : SPIN SWAP ROT ;
> : ;THEN POSTPONE EXIT POSTPONE THEN ; IMMEDIATE
>
> "cell-bits" should be obvious.

'8 cells' should work for most users.

Here's a hack (fix?) of the routines from CForth:
https://github.com/MitchBradley/cforth/blob/master/src/cforth/double.fth

Seems to pass Krishna's tests (other than full double cell shift) but no
warranty :)

: DLSHIFT ( xd u -- xd2 )
dup cell-bits u< not if nip cell-bits - lshift 0 swap exit then
tuck lshift >r 2dup cell-bits swap - rshift r> or >r lshift r> ;

: DRSHIFT ( xd u -- xd2 )
dup cell-bits u< not if cell-bits - rshift nip 0 exit then
2dup rshift >r tuck cell-bits swap - lshift -rot rshift or r> ;

On 8/04/2024 9:14 pm, dxf wrote:
> ...
> Here's a hack (fix?) of the routines from CForth:
> https://github.com/MitchBradley/cforth/blob/master/src/cforth/double.fth
>
> Seems to pass Krishna's tests (other than full double cell shift) but no
> warranty :)
> ...

It appears the original also has a problem when shift is zero. A quick fix is:

: DLSHIFT ( xd u -- xd2 )
?dup if
dup cell-bits u< not if nip cell-bits - lshift 0 swap exit then
tuck lshift >r 2dup cell-bits swap - rshift r> or >r lshift r>
then ;
: DRSHIFT ( xd u -- xd2 )
?dup if
dup cell-bits u< not if cell-bits - rshift nip 0 exit then
2dup rshift >r tuck cell-bits swap - lshift -rot rshift or r>
then ;

A test using random numbers and shifts suggests it now works. Reference definitions
used were:

: UD2/ ( xd1 -- xd2 ) d2/ [ 0 invert 1 rshift ] literal and ;
: DRSHIFT2 ( xd1 n -- xd2 ) 0 ?do ud2/ loop ;
: DLSHIFT2 ( xd1 n -- xd2 ) 0 ?do d2* loop ;

On 12/04/2024 1:11 am, albert@spenarnc.xs4all.nl wrote:
>
> While others indulge in endless discussions about DRSHIFT
> I thought to attempt some literate programming.

It didn't prompt you to test your own implementation?

( D0= D0<> D0< D= D< D- M+ DRSHIFT DLSHIFT DU< ) \ AvdH B6Mar22

: DLSHIFT >R SWAP DUP R@ LSHIFT SWAP 8 CELLS R@ - RSHIFT ROT R>
LSHIFT OR ;

: DRSHIFT >R DUP R@ RSHIFT SWAP 8 CELLS R@ - LSHIFT ROT R>
RSHIFT OR SWAP ;

0 4 d. 17179869184 ok
0 4 0 drshift d. 17179869188 ok

4 0 d. 4 ok
4 0 0 dlshift d. 17179869188 ok

In article <66188ab1$1@news.ausics.net>, dxf <dxforth@gmail.com> wrote:
>On 12/04/2024 1:11 am, albert@spenarnc.xs4all.nl wrote:
>>
>> While others indulge in endless discussions about DRSHIFT
>> I thought to attempt some literate programming.
>
>It didn't prompt you to test your own implementation?
>
> ( D0= D0<> D0< D= D< D- M+ DRSHIFT DLSHIFT DU< ) \ AvdH B6Mar22
>
> : DLSHIFT >R SWAP DUP R@ LSHIFT SWAP 8 CELLS R@ - RSHIFT ROT R>
> LSHIFT OR ;
>
> : DRSHIFT >R DUP R@ RSHIFT SWAP 8 CELLS R@ - LSHIFT ROT R>
> RSHIFT OR SWAP ;
>
>0 4 d. 17179869184 ok
>0 4 0 drshift d. 17179869188 ok
>
>4 0 d. 4 ok
>4 0 0 dlshift d. 17179869188 ok
>

Good catch! Shifting over 8 CELLS is an ambiguous condition.
insert
DUP 0= IF EXIT THEN
in front of the code.
--
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 -

On 12/04/2024 6:27 pm, albert@spenarnc.xs4all.nl wrote:
> In article <66188ab1$1@news.ausics.net>, dxf <dxforth@gmail.com> wrote:
>> On 12/04/2024 1:11 am, albert@spenarnc.xs4all.nl wrote:
>>>
>>> While others indulge in endless discussions about DRSHIFT
>>> I thought to attempt some literate programming.
>>
>> It didn't prompt you to test your own implementation?
>>
>> ( D0= D0<> D0< D= D< D- M+ DRSHIFT DLSHIFT DU< ) \ AvdH B6Mar22
>>
>> : DLSHIFT >R SWAP DUP R@ LSHIFT SWAP 8 CELLS R@ - RSHIFT ROT R>
>> LSHIFT OR ;
>>
>> : DRSHIFT >R DUP R@ RSHIFT SWAP 8 CELLS R@ - LSHIFT ROT R>
>> RSHIFT OR SWAP ;
>>
>> 0 4 d. 17179869184 ok
>> 0 4 0 drshift d. 17179869188 ok
>>
>> 4 0 d. 4 ok
>> 4 0 0 dlshift d. 17179869188 ok
>>
>
> Good catch! Shifting over 8 CELLS is an ambiguous condition.
> insert
> DUP 0= IF EXIT THEN
> in front of the code.

That handles the specific case '0 shift' but the ambiguous condition
you mention arises again here:

HEX
03 01 8 cells dlshift .( Expected: 00 03 Got: ) swap u. u. cr
FF 00 8 cells dlshift .( Expected: 00 FF Got: ) swap u. u. cr
00 01 8 cells drshift .( Expected: 01 00 Got: ) swap u. u. cr
00 FF 8 cells drshift .( Expected: FF 00 Got: ) swap u. u. cr
DECIMAL

Krishna Myneni wrote:
[..]
> Just tested DLSHIFT and found weird things going on. Traced the problem
> to LSHIFT.
[..]
> 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.

Interesting. Apparently this was changed somewhere in
the course of time, as my local version of the spec. says:

LSHIFT CORE
( u1 u -- u2 )
Perform a logical shift of u bit-places on u1, giving u2. Shift the bits
n places toward the most significant bit. Put zero into the places
"uncovered" by the shift. When u is greater than or equal to the number
of bits in a cell, u2 wraps around.

Fortunately, this is exactly what AMD/Intel hardware does, and leads to

FORTH> 1 64 lshift . 1 ok

-marcel

On 4/13/24 08:54, mhx wrote:
> Krishna Myneni wrote:
> [..]
>> Just tested DLSHIFT and found weird things going on. Traced the
>> problem to LSHIFT.
> [..]
>> 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.
>
> Interesting. Apparently this was changed somewhere in
> the course of time, as my local version of the spec. says:
>
> LSHIFT                                                                 CORE
>     ( u1 u -- u2 )
>     Perform a logical shift of u bit-places on u1, giving u2. Shift the
> bits
>     n places toward the most significant bit. Put zero into the places
>     "uncovered" by the shift. When u is greater than or equal to the
> number
>     of bits in a cell, u2 wraps around.
>
> Fortunately, this is exactly what AMD/Intel hardware does, and leads to
>
> FORTH> 1 64 lshift . 1  ok
>
> -marcel

The spec for LSHIFT which I posted is the same as the one in Forth-94
(ANS Forth), so yours must have come from an earlier standard, or it
just mirrors the SHL instruction spec for x86/x86_64. IMO the language
spec shouldn't be tied to the behavior of a processor machine level
instruction on a specific processor family.

Also, I don't see what good a wrap-around shift is when u is greater
than or equal to the bits in a cell. In what algorithm would you use
such an operation? Bit operations such as a linear shift register where
the bits drop off in the direction of the shift, or a bit rotation
within a cell with an arbitrary number seem to be more useful.

--
Krishna

On 13/04/2024 11:54 pm, mhx wrote:
> Krishna Myneni wrote:
> [..]
>> Just tested DLSHIFT and found weird things going on. Traced the problem to LSHIFT.
> [..]
>> 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.
>
> Interesting. Apparently this was changed somewhere in
> the course of time, as my local version of the spec. says:
>
> LSHIFT                                                                 CORE
>     ( u1 u -- u2 )
>     Perform a logical shift of u bit-places on u1, giving u2. Shift the bits
>     n places toward the most significant bit. Put zero into the places
>     "uncovered" by the shift. When u is greater than or equal to the number
>     of bits in a cell, u2 wraps around.
>
> Fortunately, this is exactly what AMD/Intel hardware does, and leads to
>
> FORTH> 1 64 lshift . 1  ok

Unfortunate for the Intel 8086 and folks who expected a 0 result.

In article <661a5369$1@news.ausics.net>, dxf <dxforth@gmail.com> wrote:
>On 12/04/2024 6:27 pm, albert@spenarnc.xs4all.nl wrote:
>> In article <66188ab1$1@news.ausics.net>, dxf <dxforth@gmail.com> wrote:
>>> On 12/04/2024 1:11 am, albert@spenarnc.xs4all.nl wrote:
>>>>
>>>> While others indulge in endless discussions about DRSHIFT
>>>> I thought to attempt some literate programming.
>>>
>>> It didn't prompt you to test your own implementation?
>>>
>>> ( D0= D0<> D0< D= D< D- M+ DRSHIFT DLSHIFT DU< ) \ AvdH B6Mar22
>>>
>>> : DLSHIFT >R SWAP DUP R@ LSHIFT SWAP 8 CELLS R@ - RSHIFT ROT R>
>>> LSHIFT OR ;
>>>
>>> : DRSHIFT >R DUP R@ RSHIFT SWAP 8 CELLS R@ - LSHIFT ROT R>
>>> RSHIFT OR SWAP ;
>>>
>>> 0 4 d. 17179869184 ok
>>> 0 4 0 drshift d. 17179869188 ok
>>>
>>> 4 0 d. 4 ok
>>> 4 0 0 dlshift d. 17179869188 ok
>>>
>>
>> Good catch! Shifting over 8 CELLS is an ambiguous condition.
>> insert
>> DUP 0= IF EXIT THEN
>> in front of the code.
>
>That handles the specific case '0 shift' but the ambiguous condition
>you mention arises again here:
>
>HEX
>03 01 8 cells dlshift .( Expected: 00 03 Got: ) swap u. u. cr
>FF 00 8 cells dlshift .( Expected: 00 FF Got: ) swap u. u. cr
>00 01 8 cells drshift .( Expected: 01 00 Got: ) swap u. u. cr
>00 FF 8 cells drshift .( Expected: FF 00 Got: ) swap u. u. cr
>DECIMAL

You are right. Totally annoyed with this. Changed the library to

: DLSHIFT 0 ?DO 2DUP D+ LOOP ;

: DRSHIFT 0 ?DO 2 UDM/MOD ROT DROP LOOP ;

Groetjes Albert
--
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 -

On 14-04-2024 13:06, albert@spenarnc.xs4all.nl wrote:
> In article <661a5369$1@news.ausics.net>, dxf <dxforth@gmail.com> wrote:
>> On 12/04/2024 6:27 pm, albert@spenarnc.xs4all.nl wrote:
>>> In article <66188ab1$1@news.ausics.net>, dxf <dxforth@gmail.com> wrote:
>>>> On 12/04/2024 1:11 am, albert@spenarnc.xs4all.nl wrote:
>>>>>
>>>>> While others indulge in endless discussions about DRSHIFT
>>>>> I thought to attempt some literate programming.
>>>>
>>>> It didn't prompt you to test your own implementation?
>>>>
>>>> ( D0= D0<> D0< D= D< D- M+ DRSHIFT DLSHIFT DU< ) \ AvdH B6Mar22
>>>>
>>>> : DLSHIFT >R SWAP DUP R@ LSHIFT SWAP 8 CELLS R@ - RSHIFT ROT R>
>>>> LSHIFT OR ;
>>>>
>>>> : DRSHIFT >R DUP R@ RSHIFT SWAP 8 CELLS R@ - LSHIFT ROT R>
>>>> RSHIFT OR SWAP ;
>>>>
>>>> 0 4 d. 17179869184 ok
>>>> 0 4 0 drshift d. 17179869188 ok
>>>>
>>>> 4 0 d. 4 ok
>>>> 4 0 0 dlshift d. 17179869188 ok
>>>>
>>>
>>> Good catch! Shifting over 8 CELLS is an ambiguous condition.
>>> insert
>>> DUP 0= IF EXIT THEN
>>> in front of the code.
>>
>> That handles the specific case '0 shift' but the ambiguous condition
>> you mention arises again here:
>>
>> HEX
>> 03 01 8 cells dlshift .( Expected: 00 03 Got: ) swap u. u. cr
>> FF 00 8 cells dlshift .( Expected: 00 FF Got: ) swap u. u. cr
>> 00 01 8 cells drshift .( Expected: 01 00 Got: ) swap u. u. cr
>> 00 FF 8 cells drshift .( Expected: FF 00 Got: ) swap u. u. cr
>> DECIMAL

Sure, I had to adapt it a bit: 4tH is segmented, so 1 CELLS renders 1.
[HEX] only works at compile time, so HEX is added to allow for runtime
behavior. And sure, not all of this stuff is core, so some libs are
added as well.

include lib/dbldot.4th \ if you insist..
include lib/dshift.4th \ identical to routine posted on c.l.f.

[HEX] HEX
03 01 8 /cell * dlshift .( Expected: 00 03 Got: ) swap u. u. cr
FF 00 8 /cell * dlshift .( Expected: 00 FF Got: ) swap u. u. cr
00 01 8 /cell * drshift .( Expected: 01 00 Got: ) swap u. u. cr
00 FF 8 /cell * drshift .( Expected: FF 00 Got: ) swap u. u. cr
[DECIMAL] DECIMAL

But it's rock solid:

$ pp4th -x clfdrshift.4th
Expected: 00 03 Got: 0 3
Expected: 00 FF Got: 0 FF
Expected: 01 00 Got: 1 0
Expected: FF 00 Got: FF 0

Hans Bezemer