Ruvim <ruvim.pinka@gmail.com> writes:
>The names "2*" and "2/" fall out of this series, since they were not
>equivalent to "2 *" and "2 /" correspondingly.
>
>"2/" is not equivalent to "2 /" even after accepting of the
>2s-complement representation for negative integer numbers.

2s-complement is universal. That it was not standardized in Forth-94
was a mistake that will finally be corrected in the upcoming standard.

So, 2* is equivalent to 2 *.

In Forth-83, which introduced 2/, 2/ is equivalent to 2 /. Forth-94
dropped the requirement for floored division, but defined 2/ to be an
arithmetic shift right, so in Forth-94 they are no longer equivalent
in general (in Gforth >=0.7, they are).

- 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: http://www.forth200x.org/forth200x.html
EuroForth 2021: https://euro.theforth.net/2021

On 14/08/2021 15:19, Anton Ertl wrote:
> Ruvim <ruvim.pinka@gmail.com> writes:
>>The names "2*" and "2/" fall out of this series, since they were not
>>equivalent to "2 *" and "2 /" correspondingly.
>>
>>"2/" is not equivalent to "2 /" even after accepting of the
>>2s-complement representation for negative integer numbers.
>
> 2s-complement is universal. That it was not standardized in Forth-94
> was a mistake that will finally be corrected in the upcoming standard.
>
> So, 2* is equivalent to 2 *.
>
> In Forth-83, which introduced 2/, 2/ is equivalent to 2 /. Forth-94
> dropped the requirement for floored division, but defined 2/ to be an
> arithmetic shift right, so in Forth-94 they are no longer equivalent
> in general (in Gforth >=0.7, they are).

2* 2/ appear to have been around forever. ANS states these were
historically implemented on 2's comp machines as arithmetic shifts.
It's unclear what was the intended behaviour under Forth-77 and 79
due to notoriously weak descriptions (mostly lifted from the Kitt
Peak Forth manual). Assuming Kitt Peak Forth ran on 2's comp
machines, it's fair to say 2* 2/ operated as ANS stated irrespective
of the description in the manual:

2* <VALUE> 2* <RESULT>
EQUIVALENT TO THE SEQUENCE "2 *".

2/ <VALUE> 2/ <RESULT>
EQUIVALENT TO THE SEQUENCE "2 /".

What implementers of Forth-77/79 may have done with 2* 2/, unaware of
the history, is anyone's guess. Fig-Forth had neither 2* nor 2/ .

dxforth <dxforth@gmail.com> writes:
>2* 2/ appear to have been around forever. ANS states these were
>historically implemented on 2's comp machines as arithmetic shifts.
>It's unclear what was the intended behaviour under Forth-77 and 79
>due to notoriously weak descriptions (mostly lifted from the Kitt
>Peak Forth manual).

Earlier I looked only at the overview of required Forth-79 words,
which do not include 2/. But I find that it is documented as an
uncontrolled word. Forth-79 says:

|No restrictions are placed on the definition or usage of uncontrolled
|words. However, use of these names for procedures differing from the
|given definitions is discouraged.

And it specifies 2/ as follows:

|2/ n1 -- n2 "two-divide"
| Leave (n1)/2.

In the required wordset, Forth-79 specifies:

|/ n1 n2 -- n3 178 "divide"
| Divide n1 by n2 and leave the quotient n3. n3 is rounded
| toward zero.

Source: http://www.complang.tuwien.ac.at/forth/fth79std/FORTH-79.TXT

>Assuming Kitt Peak Forth ran on 2's comp
>machines

They used a H316 and its predecessor DDP-116 there. According to
<https://en.wikipedia.org/wiki/Honeywell_316>:

|The computer was a bitwise-parallel 2's complement system with 16-bit
|word length.

>it's fair to say 2* 2/ operated as ANS stated irrespective
>of the description in the manual:
>
>2* <VALUE> 2* <RESULT>
> EQUIVALENT TO THE SEQUENCE "2 *".
>
>2/ <VALUE> 2/ <RESULT>
> EQUIVALENT TO THE SEQUENCE "2 /".

The question is what kind of division Kitt Peak Forth implemented.

Unsigned? Then maybe 2/ is a logical shift right.

Floored? Then 2/ is an arithmetic shift right.

Symmetric? Then 2/ would have to do correction for odd negative
input to satisfy the specification above.

Floored would fit telescope control applications better than
symmetric.

- 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: http://www.forth200x.org/forth200x.html
EuroForth 2021: https://euro.theforth.net/2021

Paul Rubin <no.email@nospam.invalid> wrote:
> Ruvim <ruvim.pinka@gmail.com> writes:
>> The following names fall out of the series too:
>>> 2swap 2drop 2nip 2>r 2r> ...
>
> Also 1+ and 1- which I think go back to early LISP.

Not very early, they were called ADD1 and SUB1 initially
and these names survived for a while.

--
Nils M Holm < n m h @ t 3 x . o r g > www.t3x.org

On 14/08/2021 21:02, Anton Ertl wrote:
> dxforth <dxforth@gmail.com> writes:
>>2* 2/ appear to have been around forever. ANS states these were
>>historically implemented on 2's comp machines as arithmetic shifts.
>>It's unclear what was the intended behaviour under Forth-77 and 79
>>due to notoriously weak descriptions (mostly lifted from the Kitt
>>Peak Forth manual).
>
> Earlier I looked only at the overview of required Forth-79 words,
> which do not include 2/. But I find that it is documented as an
> uncontrolled word. Forth-79 says:
>
> |No restrictions are placed on the definition or usage of uncontrolled
> |words. However, use of these names for procedures differing from the
> |given definitions is discouraged.
>
> And it specifies 2/ as follows:
>
> |2/ n1 -- n2 "two-divide"
> | Leave (n1)/2.
>
> In the required wordset, Forth-79 specifies:
>
> |/ n1 n2 -- n3 178 "divide"
> | Divide n1 by n2 and leave the quotient n3. n3 is rounded
> | toward zero.
>
> Source: http://www.complang.tuwien.ac.at/forth/fth79std/FORTH-79.TXT

Yes. 2/ was defined in the Forth-77 eXtension word set. In Forth-79
it's located in the Reference word set. In light of subsequent standards,
one can only conclude their description and that of KPF to have been
wanting.

FWIW, MICROMOTION FORTH-79 VER 2.0 FOR CP/M dated 1981 implemented the
functions as follows and which accords with ANS' commentary:

CODE 2*
POP HL
ADD HL,HL
JP HPUSH

CODE 2/
POP HL
SRA H
RR L
JP HPUSH

-7 2 / . -3 OK
-7 2/ . -4 OK

>
>>Assuming Kitt Peak Forth ran on 2's comp
>>machines
>
> They used a H316 and its predecessor DDP-116 there. According to
> <https://en.wikipedia.org/wiki/Honeywell_316>:
>
> |The computer was a bitwise-parallel 2's complement system with 16-bit
> |word length.
>
>>it's fair to say 2* 2/ operated as ANS stated irrespective
>>of the description in the manual:
>>
>>2* <VALUE> 2* <RESULT>
>> EQUIVALENT TO THE SEQUENCE "2 *".
>>
>>2/ <VALUE> 2/ <RESULT>
>> EQUIVALENT TO THE SEQUENCE "2 /".
>
> The question is what kind of division Kitt Peak Forth implemented.
>
> Unsigned? Then maybe 2/ is a logical shift right.
>
> Floored? Then 2/ is an arithmetic shift right.
>
> Symmetric? Then 2/ would have to do correction for odd negative
> input to satisfy the specification above.
>
> Floored would fit telescope control applications better than
> symmetric.
>
> - anton
>

On 8/13/21 7:35 AM, Krishna Myneni wrote:
> On 8/13/21 7:04 AM, minf...@arcor.de wrote:
....
> I haven't checked yet, but I believe the frequent use of "2 PICK" within
> the FSL code existed in the original modules. If this proves to be the
> case, THIRD has the potential to improve the efficiency of the FSL
> routines. Most of its use appears to be in indexing for FSL matrices, so
> optimizing 2 PICK in the indexing has a big impact.

I downloaded a current copy of the FSL from

https://www.taygeta.com/fsl/scilib.html

and checked the use of "2 PICK". My recollection was correct. The
sequence "2 PICK" is used widely within the FSL code. I was also
surprised to find the extensive use of "3 PICK".

--
Krishna

------
$ grep -i "2 pick" *.*
backsub.seq: a{{ I 2 PICK }} F@ b{ I } F@ F* F+
backsub.seq: 2 PICK J I }} F@ F!
big.fth: 2 PICK
complex4.seq: zs{ 2 PICK } .re F@
complex4.seq: zs{ 2 PICK 1- } .re F@ zs{ 2 PICK } .re F!
complex4.seq: zs{ 2 PICK 1- } .re F!
complex4.seq: zs{ 2 PICK } .im F@
complex4.seq: zs{ 2 PICK 1- } .im F@ zs{ 2 PICK } .im F!
complex4.seq: zs{ 2 PICK } .re F@ zs{ 2 PICK 1- } .re F@ F*
complex4.seq: zs{ 2 PICK } .im F@ zs{ 2 PICK 1- } .im F@ F* F-
complex4.seq: zs{ 2 PICK } .im F@ zs{ 2 PICK 1- } .re F@ F*
complex4.seq: zs{ 2 PICK } .re F@ zs{ ROT 1- } .im F@ F* F+
dates.seq:\ 2 PICK * >R UM* R> + ;
dets.seq: lmat 2 PICK LU-MALLOC
dynmem.seq: WHILE DUP @ CELL+ @ 2 PICK U<
dynmem.seq: ELSE DUP @ CELL+ @ 2 PICK - 2 CELLS MAX
DUP 2 CELLS =
dynmem.seq: IF DUP CELL+ @ 4 PICK + 3 PICK CELL+ ! @ 2 PICK !
dynmem.seq: DUP CELL+ @ OVER + 2 PICK =
dynmem.seq: 2 PICK cell_size DUP
factorl.seq:\ 2 PICK * >R UM* R> +
ffourier.seq: 2 PICK 0 DO
ffourier.seq: 2 PICK OVER /
ffourier.seq: 2 PICK OVER /
ffourier.seq: 2 PICK OVER /
fileio.fth: FDUP F0= IF FDROP S" 0.0" SWAP 2 PICK 2 PICK CMOVE EXIT
THEN
fsl_util.f: 2 PICK >BODY @ IF ." Warning: matrix is already allocated"
THEN [THEN]
fsl_util.f: 2 PICK }}FREE ( deallocate the array to prevent memory leaks )
fsl_util.f: 2 PICK >BODY CELL+ @ ( get the element size )
fsl_util.f: R> R> 2 PICK 2! ( store the element size and row length )
fsl_util.f: 2 PICK J I }} F@
fsl-util.fo: 2 PICK I + C!
fsl-util.fo: 2 PICK I + C!
fsl-util.fo: 2 PICK * >R UM* R> +
fsl-util.fo: 2 PICK J I }} F@
fsl-util.fs: 2 PICK * >R UM* R> + ; \ single *
double = double
fsl-util.fs: SWAP 0 DO DUP 0 DO 2 PICK J I }} F@
fsl-utilg.fth: 2 PICK * >R UM* R> + ; \ single
* double = double
fsl-utilg.fth: SWAP 0 DO DUP 0 DO 2 PICK J I }} F@
fsl_util.seq: 2 PICK * >R UM* R> +
fsl_util.seq: 2 PICK J I }} F@
hartley.seq: 2 PICK I + DUP TO pbc OVER + TO pbd
isaac.fth: 5 ROLL XOR 2 PICK @ + ( b m m2 r a' )
lufact.seq: 2 PICK 0 DO
lufact.seq: matrix{{ 2 PICK I }} DUP F@
lufact.seq: matrix{{ 2 PICK I }} DUP F@
lufact.seq: matrix{{ I 2 PICK }} DUP F@ FOVER F*
lufact.seq: 2 PICK 0 DO
lufact.seq: 2 PICK I } @ I OVER OVER =
structs.seq: 2 PICK , 3 PICK ,
structs.seq: 2 PICK , 3 PICK ,
structs.seq: 2 PICK , 3 PICK ,
structs.seq: 2 PICK , 3 PICK ,
umd.fo: 2 PICK OVER UM* 2>R ( ul uh vl vh R: x3 .)
vulgar.fth:: um** ( u1 u2--ud) 1. ROT 0 ?DO 2 PICK mu* LOOP ROT DROP ;
$ $ grep -i "3 pick" *.*
dynmem.seq: DUP 3 PICK U< AND
dynmem.seq: DUP @ DUP 3 PICK ! ?DUP
dynmem.seq: IF DUP 3 PICK 5 PICK + =
dynmem.seq: IF DUP CELL+ @ 4 PICK + 3 PICK CELL+ ! @ 2 PICK !
ffourier.seq: 3 PICK SWAP DO
ffourier.seq: 3 PICK SWAP DO
ffourier.seq: 3 PICK 0 DO
ffourier.seq: 3 PICK 1 DO
ffourier.seq: 3 PICK 1 DO
find.seq: p{ 3 PICK } F@
hartley.seq: 3 PICK SWAP DO
isaac.fth: 3 PICK @ SWAP 5 ROLL ( m m2 r x a' b )
lufact.seq: 3 PICK 3 PICK -> ->PIVOT{ ->! \ store pointer
to pivot array
lufact.seq: 3 PICK SWAP DO
lufact.seq: matrix{{ I 3 PICK }} F@ FABS
lufact.seq: 3 PICK I 3 PICK }} DUP F@
lufact.seq: 4 PICK I 3 PICK }} DUP F@
polrat.seq: OVER 2* 3 PICK ROT - 3 - < IF c{ OVER 1+ } F@
randdist.fth: DUP 3 PICK U> WHILE
shanks.fth: DUP 3 PICK - >R \ save new array upper bound
shanks.fth: DUP 3 PICK > IF DROP OVER THEN
structs.seq: SWAP 3 PICK
structs.seq: 2 PICK , 3 PICK ,
structs.seq: 2 PICK , 3 PICK ,
structs.seq: 2 PICK , 3 PICK ,
structs.seq: 2 PICK , 3 PICK ,
umd.fo: 3 PICK * >R TUCK * >R UM* R> + R> +
umd.fo: 3 PICK UM* 2>R ( ul uh vl R: x3 . x2 .)
$ ------

dxforth <dxforth@gmail.com> writes:
>Yes. 2/ was defined in the Forth-77 eXtension word set. In Forth-79
>it's located in the Reference word set. In light of subsequent standards,
>one can only conclude their description and that of KPF to have been
>wanting.

You mean, they should have specified the rounding?

At first blush I would go for the rounding given by /. And the Kitt
Peak description you cited was very clear.

As for the following standards, Forth-83 specified floored division,
and 2/ as an arithmetic shift right matches nicely.

Forth-94 ff. allowed floored or symmetric /, but requires 2/ as
arithmetic shift right (floored division on 2s-complement, symmetric
on 1s-complement, makes no sense on sign-magnitude). Alternatives
would have been to require the same rounding for 2/ as for /, or to
let the rounding of 2/ be independent of the rounding of /. The
latter could be the outcome of this train of thought: "In most cases,
the difference between floored and symmetric does not matter (and we
have SM/REM and FM/MOD when it does), so let the implementor choose
the cheaper; given that it does not matter, there is no point in
prescribing the same rounding mode for 2/.

And if you then have the following additional thoughts:

1) The most efficient way to implement an arbitrary-rounding 2/ on
every hardware (not thinking about sign-magnitude systems; but
maybe sign-magnitude was not in when they standardized 2/) is
arithmetic shift right.

2) It would be good to standardize arithmetic shift right.

.... then the result is that you standardize 2/ as arithmetic shift
right.

- 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: http://www.forth200x.org/forth200x.html
EuroForth 2021: https://euro.theforth.net/2021

On 15/08/2021 01:01, Anton Ertl wrote:
> dxforth <dxforth@gmail.com> writes:
>>Yes. 2/ was defined in the Forth-77 eXtension word set. In Forth-79
>>it's located in the Reference word set. In light of subsequent standards,
>>one can only conclude their description and that of KPF to have been
>>wanting.
>
> You mean, they should have specified the rounding?

They should have specified these were bit shifting operations - a critical
omission which '83 and ANS went on to correct.

>
> At first blush I would go for the rounding given by /. And the Kitt
> Peak description you cited was very clear.

Precisely what was wrong with it. 2* 2/ were intended to be fast
operations. Following the behaviour of / wasn't the objective.

>
> As for the following standards, Forth-83 specified floored division,
> and 2/ as an arithmetic shift right matches nicely.

Duncan mentioned that too. After a revolution, the justifications come
thick and fast.

>
> Forth-94 ff. allowed floored or symmetric /, but requires 2/ as
> arithmetic shift right (floored division on 2s-complement, symmetric
> on 1s-complement, makes no sense on sign-magnitude). Alternatives
> would have been to require the same rounding for 2/ as for /, or to
> let the rounding of 2/ be independent of the rounding of /. The
> latter could be the outcome of this train of thought: "In most cases,
> the difference between floored and symmetric does not matter (and we
> have SM/REM and FM/MOD when it does), so let the implementor choose
> the cheaper; given that it does not matter, there is no point in
> prescribing the same rounding mode for 2/.
>
> And if you then have the following additional thoughts:
>
> 1) The most efficient way to implement an arbitrary-rounding 2/ on
> every hardware (not thinking about sign-magnitude systems; but
> maybe sign-magnitude was not in when they standardized 2/) is
> arithmetic shift right.
>
> 2) It would be good to standardize arithmetic shift right.
>
> ... then the result is that you standardize 2/ as arithmetic shift
> right.

2* 2/ are historic operators. If one can use them to advantage, fine.
They've been overtaken somewhat by LSHIFT RSHIFT. In my case I went on
to define U2/ .

On 15/08/2021 13:22, dxforth wrote:
> On 15/08/2021 01:01, Anton Ertl wrote:
>> ...
>> As for the following standards, Forth-83 specified floored division,
>> and 2/ as an arithmetic shift right matches nicely.
>
> Duncan mentioned that too. After a revolution, the justifications come
> thick and fast.

Correction - it was Robert Berkey - one of the architects behind the
switch to floored division.

https://groups.google.com/g/comp.lang.forth/c/nrbvdlwV_Tc/m/htgFz6ZMf1UJ

dxforth <dxforth@gmail.com> writes:
>On 15/08/2021 01:01, Anton Ertl wrote:
>> dxforth <dxforth@gmail.com> writes:
>>>Yes. 2/ was defined in the Forth-77 eXtension word set. In Forth-79
>>>it's located in the Reference word set. In light of subsequent standards,
>>>one can only conclude their description and that of KPF to have been
>>>wanting.
>>
>> You mean, they should have specified the rounding?
>
>They should have specified these were bit shifting operations

Why?

And why call a bit-shifting operator 2/ if it's different from 2 /?

>- a critical
>omission which '83 and ANS went on to correct.

For Forth-83 2/ serves both as 2 / and as an arithmetic shift right.

For Forth-94 things are more complex, as discussed already.

>> At first blush I would go for the rounding given by /. And the Kitt
>> Peak description you cited was very clear.
>
>Precisely what was wrong with it. 2* 2/ were intended to be fast
>operations. Following the behaviour of / wasn't the objective.

Do you mean to say that / was symmetric in Kitt Peak Forth and 2/ was
floored?

If / was floored, a floored 2/ would match nicely, as in Forth-83.

But even if / was symmetric, a symmetric 2/ is much faster than 2 / on
most machines (especially in those times).

- 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: http://www.forth200x.org/forth200x.html
EuroForth 2021: https://euro.theforth.net/2021

On 15/08/2021 23:30, Anton Ertl wrote:
> dxforth <dxforth@gmail.com> writes:
>>On 15/08/2021 01:01, Anton Ertl wrote:
>>> dxforth <dxforth@gmail.com> writes:
>>>>Yes. 2/ was defined in the Forth-77 eXtension word set. In Forth-79
>>>>it's located in the Reference word set. In light of subsequent standards,
>>>>one can only conclude their description and that of KPF to have been
>>>>wanting.
>>>
>>> You mean, they should have specified the rounding?
>>
>>They should have specified these were bit shifting operations
>
> Why?

What they are.

>
> And why call a bit-shifting operator 2/ if it's different from 2 /?

Difference is the only reason by which 2* 2/ can be justified.

>
>>- a critical
>>omission which '83 and ANS went on to correct.
>
> For Forth-83 2/ serves both as 2 / and as an arithmetic shift right.
>
> For Forth-94 things are more complex, as discussed already.

Because of 94's support for 1's comp and signed-magnitude? I'm sure
the latter were grateful for what they got. I understand 200x intends
to give them the boot.

>
>>> At first blush I would go for the rounding given by /. And the Kitt
>>> Peak description you cited was very clear.
>>
>>Precisely what was wrong with it. 2* 2/ were intended to be fast
>>operations. Following the behaviour of / wasn't the objective.
>
> Do you mean to say that / was symmetric in Kitt Peak Forth and 2/ was
> floored?

That's my interpretation. From the Kitt Peak manual:

/MOD <VALUE1> <VALUE2> /MOD <REMAINDER> <QUOTIENT>
16-BIT SIGNED INTEGER DIVIDE. THE QUOTIENT FROM THE DIVISION,
<VALUE1> / <VALUE2>, IS LEFT ON TOP OF THE STACK AND THE
REMAINDER IS LEFT BELOW. THE REMAINDER HAS THE SIGN OF THE
DIVIDEND.

>
> If / was floored, a floored 2/ would match nicely, as in Forth-83.

Better for / to match the hardware and 2/ to match arithmetic bit shift.

>
> But even if / was symmetric, a symmetric 2/ is much faster than 2 / on
> most machines (especially in those times).
>
> - anton
>

On Saturday, August 14, 2021 at 3:58:31 AM UTC+2, Paul Rubin wrote:
> > Namewise I reluctantly prefer PLUCK over THIRD.
> How about OOVER? Like OVER with one extra.
OOVER is not even a decent word. STOW is a word. STASH Is a word. PLUCK is a word. OOVER is not.
Don't be lazy.

Hans Bezemer

All of the Forth-200x committee, including Stephen Pelc and Anton Ertl,
have failed badly at writing synonym and early-binding macro in
ANS-Forth due to Elizabeth Rather disallowing the use of disambiguifiers.

Here we see Stephen Pelc, the chair-person of Forth-200x, falling back
on what he does best, which is teach kindergarten:

On Friday, August 13, 2021 at 6:03:37 AM UTC-7, Stephen Pelc wrote:
> From a code readability perspective, having THIRD and FOURTH implies that
> there should be FIRST and SECOND. Nah! Let's just stick with PICK.

On Friday, August 13, 2021 at 6:58:31 PM UTC-7, Paul Rubin wrote:
> Hans Bezemer <the.bee...@gmail.com> writes:
> > Namewise I reluctantly prefer PLUCK over THIRD.
> How about OOVER? Like OVER with one extra.

That is hilarious!
Should we have OOOVER for 3 PICK and 0000VER for 4 PICK etc.?

I use ROVER for 2 PICK (it is OVER for the datum accessible by ROT).
I don't recall ever needing 3 PICK etc. --- I would just use locals.
ROVER gets used often enough to deserve a readable name.

Here is some example code:
----------------------------------------------------------
SwiftForth? [if] \ SwiftForth's optimization is so bad that no Forth version is any good

icode exchange ( adrX adrY size -- ) \ the size of the record must be a multiple of W
0 [ebp] edx mov w [ebp] ecx mov \ EDX<>ECX, with EBX being the size
begin non-zero? while
0 [ecx] eax mov
0 [edx] eax xor eax 0 [edx] xor 0 [edx] eax xor
eax 0 [ecx] mov
w # edx add w # ecx add
w # ebx sub repeat
w 2 * [ebp] ebx mov
w 3 * # ebp add ret end-code

[else]

macro: exchange ( adrX adrY size -- ) \ the size of the record must be a non-zero multiple of W
begin
-rot \ -- remaining adrX adrY
dup @ rover @ \ -- remaining adrX adrY Y X
rover ! rover ! \ -- remaining adrX adrY
w + swap w + rot w - \ -- adrY adrX remaining \ adrY and adrX change places
dup 0= until
3drop ;

[then]
----------------------------------------------------------

I had to hand-write EXCHANGE for SwiftForth because SwiftForth code generation
is so awful as to be unacceptable for something like EXCHANGE that needs to be
fast (EXCHANGE is used in SORT).

On Thursday, July 22, 2021 at 6:55:03 PM UTC-7, daru...@gmail.com wrote:
> On Thursday, July 22, 2021 at 1:00:25 AM UTC-7, jpit...@gmail.com wrote:
> > On Thursday, 22 July 2021 at 07:59:58 UTC+1, Hugh Aguilar wrote:
> > > PolyForth was worthless crap. After Charles Moore got kicked out of Forth Inc.
> > > there were no more programmers at Forth Inc. but only sales clowns and
> > > maintenance programmers who lived off of the "Forth Inc." name that made it
> > > seem as if they owned Forth despite the fact that the inventor of Forth was gone.
> > > ...
> > He must be really disturbed.
> > Is there no help?
> There is no help for Hugh. Why even bother trying?

Dennis Ruffer has admitted in public that he worked for Forth Inc.!!! That is disgraceful!
Here is the code generated by SwiftForth for the Forth version of EXCHANGE
so perhaps Dennis Ruffer can explain why it is so awful:
----------------------------------------------------------
see SwiftForth-exchange
48804F EBX ECX MOV 8BCB
488051 4 [EBP] EAX MOV 8B4504
488054 0 [EBP] EBX MOV 8B5D00
488057 EAX 0 [EBP] MOV 894500
48805A ECX 4 [EBP] MOV 894D04
48805D 4 # EBP SUB 83ED04
488060 EBX 0 [EBP] MOV 895D00
488063 0 [EBX] EBX MOV 8B1B
488065 4 # EBP SUB 83ED04
488068 EBX 0 [EBP] MOV 895D00
48806B 8 [EBP] EBX MOV 8B5D08
48806E 0 [EBX] EBX MOV 8B1B
488070 4 # EBP SUB 83ED04
488073 EBX 0 [EBP] MOV 895D00
488076 8 [EBP] EBX MOV 8B5D08
488079 0 [EBP] EAX MOV 8B4500
48807C EAX 0 [EBX] MOV 8903
48807E 4 [EBP] EBX MOV 8B5D04
488081 8 # EBP ADD 83C508
488084 4 # EBP SUB 83ED04
488087 EBX 0 [EBP] MOV 895D00
48808A 8 [EBP] EBX MOV 8B5D08
48808D 0 [EBP] EAX MOV 8B4500
488090 EAX 0 [EBX] MOV 8903
488092 4 [EBP] EBX MOV 8B5D04
488095 8 # EBP ADD 83C508
488098 4 # EBX ADD 83C304
48809B 0 [EBP] EAX MOV 8B4500
48809E EBX 0 [EBP] MOV 895D00
4880A1 EAX EBX MOV 8BD8
4880A3 4 # EBX ADD 83C304
4880A6 EBX ECX MOV 8BCB
4880A8 4 [EBP] EBX MOV 8B5D04
4880AB 0 [EBP] EAX MOV 8B4500
4880AE EAX 4 [EBP] MOV 894504
4880B1 ECX 0 [EBP] MOV 894D00
4880B4 4 # EBX SUB 83EB04
4880B7 EBX EBX OR 09DB
4880B9 48804F JNZ 0F8590FFFFFF
4880BF 48036F ( 3drop ) JMP E9AB82FFFF ok
ok
see 3drop
48036F 8 [EBP] EBX MOV 8B5D08
480372 C # EBP ADD 83C50C
480375 RET C3 ok
----------------------------------------------------------

On 18/08/2021 08:56, Hugh Aguilar wrote:
>
> I use ROVER for 2 PICK (it is OVER for the datum accessible by ROT).

Always wondered about that - thought perhaps it was Rover doing a fetch.

On 18/08/2021 08:41, Hans Bezemer wrote:
> On Saturday, August 14, 2021 at 3:58:31 AM UTC+2, Paul Rubin wrote:
>> > Namewise I reluctantly prefer PLUCK over THIRD.
>> How about OOVER? Like OVER with one extra.
> OOVER is not even a decent word. STOW is a word. STASH Is a word.

And subject of early 70's song ...

https://youtu.be/BdBOmkWkESQ

> PLUCK is a word. OOVER is not.
> Don't be lazy.
>
> Hans Bezemer
>

On Tuesday, August 17, 2021 at 5:41:34 PM UTC-5, the.bee...@gmail.com wrote:
> OOVER is not even a decent word. STOW is a word. STASH Is a word. PLUCK is a word. OOVER is not.

Words are just symbols; any symbol can be a word if someone says so. Here are some
words I use:
MWW for dup
WMW for tuck
MWM for over
SWM for swap
MWS for rot
WSM for -rot
SMX for drop
SXW for NIP
2MWW for 2DUP
and so on for all stack operators.
These words are short and uniform in size; makes for pleasant display.
--
me

S Jack <sdwjack69@gmail.com> writes:
> SMX for drop
> SXW for NIP

Should these two be XSM and XSW? The rest seem to be the top 3 stack
elements after doing the operation, where the top 4 elements before the
operation were XSMW. Can I ask where if the letters XSMW mean anything?
I had been thinking of something similar, starting with e.g. ABCD.

I don't think it helps to have them all 3 letters. It's easier if they
show the picture getting shorter when you delete stuff and longer when
you add stuff. ABCD gives ABCDD=dup, ABDCD=tuck, ABC=drop and so on.

Looking at this a little more, I guess they are all terrible, heh.

On Wednesday, August 18, 2021 at 1:07:00 PM UTC-5, Paul Rubin wrote:
> operation were XSMW. Can I ask where if the letters XSMW mean anything?

The reference is SMW , no such word, just reference to top three data stack elements.
The letters themselves mean nothing; chosen for their symmetrical looks. The name
of the stack operation is the arrangement of the top three elements after the operation,
hence, DUP is MWW. The DROP and NIP are a little bit of an exception. The X stands
for the position that got dropped, SMX drop top item, SXW drop next to top item.
--
me

On 19/08/2021 04:06, Paul Rubin wrote:
> S Jack <sdwjack69@gmail.com> writes:
>> SMX for drop
>> SXW for NIP
>
> Should these two be XSM and XSW? The rest seem to be the top 3 stack
> elements after doing the operation, where the top 4 elements before the
> operation were XSMW. Can I ask where if the letters XSMW mean anything?
> I had been thinking of something similar, starting with e.g. ABCD.
>
> I don't think it helps to have them all 3 letters. It's easier if they
> show the picture getting shorter when you delete stuff and longer when
> you add stuff. ABCD gives ABCDD=dup, ABDCD=tuck, ABC=drop and so on.
>
> Looking at this a little more, I guess they are all terrible, heh.
>

LFA CFA NFA were a horror. Perhaps the assumption was they wouldn't
be used in everyday programming. Who still remembers what they _did_ ?

On 8/18/21 2:06 PM, Paul Rubin wrote:
> S Jack <sdwjack69@gmail.com> writes:
>> SMX for drop
>> SXW for NIP
>
> Should these two be XSM and XSW? The rest seem to be the top 3 stack
> elements after doing the operation, where the top 4 elements before the
> operation were XSMW.

> I don't think it helps to have them all 3 letters. It's easier if they
> show the picture getting shorter when you delete stuff and longer when
> you add stuff. ABCD gives ABCDD=dup, ABDCD=tuck, ABC=drop and so on.

Interesting thought. There is historical precedent for naming stack
items with letters. The Hewlett-Packard RPN calculators use(d) TZYX with
X being the top of the stack.

newname oldname ( stack effect )
------- -------- ----------------
xx dup ( x -- x x )
xyx tuck ( y x -- x y x )
yxy over ( y x -- y x y )
xy swap ( y x -- x y )
yxz rot ( z y x -- y x z )
xzy -rot ( z y x -- x z y )
y drop ( y x -- y )
x nip ( y x -- x )
yxyx 2dup ( y x -- y x y x )
tz 2drop ( t z y x -- t z )
zyxz 2 pick ( z y x -- z y x z )
tzyxt 3 pick ( t z y x -- t z y x t )
|x| abs ( x -- |x| )
-x negate ( x -- -x )
y^x f** ( F: y x -- y^x )

In all cases newname has less characters to type than oldname,
except three have the same.

Precede newname with 'F' for FP words? Fxx = fdup

-Doug

On 2021-08-18 8:33 PM, dxforth wrote:
>
> LFA CFA NFA were a horror. Perhaps the assumption was they wouldn't
> be used in everyday programming. Who still remembers what they _did_ ?

I always thought these were mis-named or perhaps "over" named.
After all they are just fields in the header record.

It's clearer to me to simply say the header has the follow fields:
- link
- name
- code ( albeit XT is more accurate in the general sense)

This seems related to the history of Forth not exposing the dictionary
nicely to the programmer, as a linked list tool, for purposes other than
making Forth words.

I added the word

: HEADER, ( caddr c -- ) ...

to my Camel Forth so I can use the dictionary for other purposes.

On 20/08/2021 00:41, Brian Fox wrote:
> On 2021-08-18 8:33 PM, dxforth wrote:
>>
>> LFA CFA NFA were a horror. Perhaps the assumption was they wouldn't
>> be used in everyday programming. Who still remembers what they _did_ ?
>
> I always thought these were mis-named or perhaps "over" named.
> After all they are just fields in the header record.
>
> It's clearer to me to simply say the header has the follow fields:
> - link
> - name
> - code ( albeit XT is more accurate in the general sense)

I'd probably have objected less had they been called

>LFA >PFA >NFA ( these revolved around PFA rather than CFA)

>
> This seems related to the history of Forth not exposing the dictionary
> nicely to the programmer, as a linked list tool, for purposes other than
> making Forth words.
>
> I added the word
>
> : HEADER, ( caddr c -- ) ...
>
> to my Camel Forth so I can use the dictionary for other purposes.

It's been suggested several times. Systems with separated headers
would probably need the addition of an xt|0 parameter.