>R R@ and DUP >R both do the same. Which one to use and why?

Until yesterday, looking in the Gforth sources produced the following
results:

rg -i --multiline --stats 'dup(\n|[[:blank:]])+>r'
....
249 matches
247 matched lines
....

This includes 6 occurences of 2DUP >R.

rg -i --multiline --stats '>r(\n|[[:blank:]])+r@'
....
127 matches
188 matched lines
....

This includes 5 occurences of 2>R R@.

One interesting result is that the occurences of >R R@ are more
frequently split across lines. This comes from idioms like:

... >r
r@ ...
r@ ...
r@ ...
r> ...

Gforth-fast used to compile DUP >R into

$7F7DF4EF9E00 dup
7F7DF4BC0EB8: mov $00[r13],r8
7F7DF4BC0EBC: sub r13,$08
7F7DF4BC0EC0: add r15,$08
$7F7DF4EF9E08 >r
7F7DF4BC0EC4: add r13,$08
7F7DF4BC0EC8: mov -$08[rbx],r8
7F7DF4BC0ECC: sub rbx,$08
7F7DF4BC0ED0: add r15,$08
7F7DF4BC0ED4: mov r8,$00[r13]

(assuming start and end in the canonical stack state). Yesterday we
added a superinstruction for DUP >R, so it now compiles to:

$7F054AFE6E00 dup
$7F054AFE6E08 >r
7F054ACADAE8: mov -$08[rbx],r8
7F054ACADAEC: sub rbx,$08
7F054ACADAF0: add r15,$10

We replaced nearly all occurences of >R R@ with DUP >R so this
superinstruction is used, resulting in 365 matches for DUP >R (still 6
being for 2DUP >R).

The AMD64 gforth image now contains 61 occurences of DUP >R (with 2DUP
>r filtered away); for comparison, there are 65 occurences of TUCK,
115 of NIP, and 41 of -ROT.

Using this superinstruction now results in a reduction of the native
code size from 523960 Bytes to 522984 Bytes.

- 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 Sat, 12 Mar 2022 12:04:00 GMT
anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:

> >R R@ and DUP >R both do the same. Which one to use and why?
>
> Until yesterday, looking in the Gforth sources produced the following
> results:
>
> rg -i --multiline --stats 'dup(\n|[[:blank:]])+>r'
> ...
> 249 matches
> 247 matched lines
> ...
>
> This includes 6 occurences of 2DUP >R.
>
> rg -i --multiline --stats '>r(\n|[[:blank:]])+r@'
> ...
> 127 matches
> 188 matched lines
> ...
>
> This includes 5 occurences of 2>R R@.
>
> One interesting result is that the occurences of >R R@ are more
> frequently split across lines. This comes from idioms like:
>
> ... >r
> r@ ...
> r@ ...
> r@ ...
> r> ...
>
> Gforth-fast used to compile DUP >R into
>
> $7F7DF4EF9E00 dup
> 7F7DF4BC0EB8: mov $00[r13],r8

Assuming, TOS in r8, and SP in r13.

"PUSH" TOS value to stack.

> 7F7DF4BC0EBC: sub r13,$08

Adjust SP for "PUSH".

> 7F7DF4BC0EC0: add r15,$08

What is in r15?

> $7F7DF4EF9E08 >r
> 7F7DF4BC0EC4: add r13,$08

Adjust SP for "POP".

> 7F7DF4BC0EC8: mov -$08[rbx],r8

Assuming RP in rbx.

"PUSH" TOS in r8 to return stack.

> 7F7DF4BC0ECC: sub rbx,$08

Adjust RP for "PUSH".

> 7F7DF4BC0ED0: add r15,$08

What is in r15?

> 7F7DF4BC0ED4: mov r8,$00[r13]

"POP" new TOS into r8.

> (assuming start and end in the canonical stack state). Yesterday we
> added a superinstruction for DUP >R, so it now compiles to:
>
> $7F054AFE6E00 dup
> $7F054AFE6E08 >r
> 7F054ACADAE8: mov -$08[rbx],r8

"PUSH" TOS in r8 to return stack.

> 7F054ACADAEC: sub rbx,$08

Adjust RP for "PUSH".

> 7F054ACADAF0: add r15,$10

What is r15?

> We replaced nearly all occurences of >R R@ with DUP >R so this
> superinstruction is used, resulting in 365 matches for DUP >R (still 6
> being for 2DUP >R).
>
> The AMD64 gforth image now contains 61 occurences of DUP >R (with 2DUP
> >r filtered away); for comparison, there are 65 occurences of TUCK,
> 115 of NIP, and 41 of -ROT.

Did you mean that 2DUP 2>R is filtered away?

> Using this superinstruction now results in a reduction of the native
> code size from 523960 Bytes to 522984 Bytes.
>

In summary,

a) I'm not sure what r15 is. It seems to be some sort of
stack pointer working in reverse. Perhaps, this is for PAD? ...

In other words, could constantly adjusting r15 be doing unnecessary
work? r15 doesn't seem to be needed for DUP for >R nor for your
super-instruction. I.e., maybe whatever is located at r15 needs to be
relocated away from SP to eliminate constant adjustment of r15?

b) Also, why are you using MOV + SUB/ADD instead of using PUSH or POP?

There might be situations where splitting PUSH/POP into two
instructions - MOV plus stack adjustment - reduces overhead code, but I
only see once instance of that here, in the older, eliminated code.

--

Rod Pemberton <noemail@basdxcqvbe.com> writes:
>On Sat, 12 Mar 2022 12:04:00 GMT
>anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:
>> Gforth-fast used to compile DUP >R into
>>
>> $7F7DF4EF9E00 dup
>> 7F7DF4BC0EB8: mov $00[r13],r8
>
>Assuming, TOS in r8, and SP in r13.
>
>"PUSH" TOS value to stack.
>
>> 7F7DF4BC0EBC: sub r13,$08
>
>Adjust SP for "PUSH".
>
>> 7F7DF4BC0EC0: add r15,$08
>
>What is in r15?

IP (the threaded-code instruction pointer); remember that Gforth is
based on direct-threaded code.

>> The AMD64 gforth image now contains 61 occurences of DUP >R (with 2DUP
>> >r filtered away); for comparison, there are 65 occurences of TUCK,
>> 115 of NIP, and 41 of -ROT.
>
>Did you mean that 2DUP 2>R is filtered away?

No. What I mean is: If I grep for "dup >r", I also get results for
"2dup >r". In some cases I counted those, and mentioned their number
(so you can do the subtraction), in others I filtered them away before
counting.

>In other words, could constantly adjusting r15 be doing unnecessary
>work?

The IP (r15) is necessary for accessing literal values, for control
flow, and for executing non-relocateble primitives. I have thought
about an optimization that combines the IP updates of several
primitives, but have not found the time to implement it.

>b) Also, why are you using MOV + SUB/ADD instead of using PUSH or POP?

That's what's coming out of gcc. Why is gcc using those instead of
PUSH and POP? Because PUSH and POP use RSP as stack pointer, not R13.
Why is gcc not using RSP as data stack pointer? Because it uses RSP
for the C stack.

- 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