It's here - https://www.youtube.com/watch?v=hpw__rmBisU

The last one was so much fun to make, I decided to do a few
other ones. Consider this one to be some foundation I can
build on - without having to repeat myself too much in future
videos.

Hans Bezemer

> It's here - https://www.youtube.com/watch?v=hpw__rmBisU

01:45 -- but you know: Forth's stack works on the rule „last in — first out”, not „first in, first out”. Or am I wrong?

On Tuesday, May 31, 2022 at 6:35:56 PM UTC+2, Zbig wrote:
> > It's here - https://www.youtube.com/watch?v=hpw__rmBisU
> 01:45 -- but you know: Forth's stack works on the rule „last in — first out”, not „first in, first out”. Or am I wrong?
No, you're not. I pulled it and I'm uploading an updated version.

Hans Bezemer

On Tuesday, May 31, 2022 at 7:06:16 PM UTC+2, Hans Bezemer wrote:
> On Tuesday, May 31, 2022 at 6:35:56 PM UTC+2, Zbig wrote:
> > 01:45 -- but you know: Forth's stack works on the rule „last in — first out”, not „first in, first out”. Or am I wrong?
> No, you're not. I pulled it and I'm uploading an updated version.
Second attempt: https://www.youtube.com/watch?v=pnOhRPgFZDI

Hans Bezemer

On 1/06/2022 03:36, Hans Bezemer wrote:
>
> Second attempt: https://www.youtube.com/watch?v=pnOhRPgFZDI

The section on return stack was unexpected - especially for an intro.
Found myself stopping, reversing and going through it again bit by bit.
It's detail I rarely consider; wonder what a beginner would make of it.
Not saying RS function shouldn't be mentioned (SF did IIRC) but wishing
it were paced slower. But then antipodeans prefer everything slower...

On Friday, June 3, 2022 at 2:56:32 AM UTC+2, dxforth wrote:
> The section on return stack was unexpected - especially for an intro.
> Found myself stopping, reversing and going through it again bit by bit.
It's a stack as well - and I find its mechanism both simple and effective.
That's why I included it.

> It's detail I rarely consider; wonder what a beginner would make of it.
> Not saying RS function shouldn't be mentioned (SF did IIRC) but wishing
> it were paced slower. But then antipodeans prefer everything slower...
As a matter of fact, SF did in great length. It even went so far to do quite
tricky manipulations with it to change program flow. I refrained from that for
two reasons. First its a "new" concept to those watching it and second,
the implications of return stack manipulations are quite mind boggling
for newbies. Heck, when I did my co-routine stuff, I found it quite mind
boggling.

Hans Bezemer

On 3/06/2022 19:16, Hans Bezemer wrote:
> On Friday, June 3, 2022 at 2:56:32 AM UTC+2, dxforth wrote:
>> The section on return stack was unexpected - especially for an intro.
>> Found myself stopping, reversing and going through it again bit by bit.
> It's a stack as well - and I find its mechanism both simple and effective.
> That's why I included it.
>
>> It's detail I rarely consider; wonder what a beginner would make of it.
>> Not saying RS function shouldn't be mentioned (SF did IIRC) but wishing
>> it were paced slower. But then antipodeans prefer everything slower...
> As a matter of fact, SF did in great length. It even went so far to do quite
> tricky manipulations with it to change program flow. I refrained from that for
> two reasons. First its a "new" concept to those watching it and second,
> the implications of return stack manipulations are quite mind boggling
> for newbies. Heck, when I did my co-routine stuff, I found it quite mind
> boggling.

What was in SF was probably tricky (or long-winded) enough that I skipped
over it :) OTOH it makes little sense to tell newcomers forth has a
'return stack' without explaining what it's for. That you did caught me
by surprise as so few intros do.

Is return stack a "new" concept? I've no idea when I first heard about
subroutine calls and stacks but I'm sure it was long before I'd heard of
forth. Perhaps it's different for newcomers today (much like their music).

On Saturday, June 4, 2022 at 4:34:39 AM UTC+2, dxforth wrote:
[..]
> Is return stack a "new" concept? I've no idea when I first heard about
> subroutine calls and stacks but I'm sure it was long before I'd heard of
> forth. Perhaps it's different for newcomers today (much like their music).

I vividly remember that Forth's implementation techniques were
making understanding it very difficult for me. That was mainly
because it was not explained clearly (or not in a way I could easily
understand). Authors used non-portable aspects of the language
all the time, and it was never explained in depth what the actual
technical advantages of all these different and mind-boggling
tricks (threading methods) were. (At that time it was not yet
possible to Google your way to the heart of even the most esoteric
and difficult concepts.)

At that time I was mainly fascinated by the possibility to use
assembly language from within Forth, and the light came on
(slowly) when I realized that the language essentially boiled
down to generating call-return pairs. It is, for instance, very
easy to explain CREATE DOES> in terms of a call to a
subroutine that uses the return stack pointer to subsequently
load data from the caller's code segment.

-marcel

On 4/06/2022 14:22, Marcel Hendrix wrote:
> On Saturday, June 4, 2022 at 4:34:39 AM UTC+2, dxforth wrote:
> [..]
>> Is return stack a "new" concept? I've no idea when I first heard about
>> subroutine calls and stacks but I'm sure it was long before I'd heard of
>> forth. Perhaps it's different for newcomers today (much like their music).
>
> I vividly remember that Forth's implementation techniques were
> making understanding it very difficult for me. That was mainly
> because it was not explained clearly (or not in a way I could easily
> understand). Authors used non-portable aspects of the language
> all the time, and it was never explained in depth what the actual
> technical advantages of all these different and mind-boggling
> tricks (threading methods) were. (At that time it was not yet
> possible to Google your way to the heart of even the most esoteric
> and difficult concepts.)
>
> At that time I was mainly fascinated by the possibility to use
> assembly language from within Forth, and the light came on
> (slowly) when I realized that the language essentially boiled
> down to generating call-return pairs. It is, for instance, very
> easy to explain CREATE DOES> in terms of a call to a
> subroutine that uses the return stack pointer to subsequently
> load data from the caller's code segment.

I was thinking more fundamentally i.e. forth has a return stack
for the same reason CPUs typically had one. The latter also had
the equivalent of >R ... R> for storing temps! I gather early
processors didn't have a return stack - which may have made it
"new" at the time.

On Saturday, June 4, 2022 at 7:36:39 AM UTC+2, dxforth wrote:
> On 4/06/2022 14:22, Marcel Hendrix wrote:
> > On Saturday, June 4, 2022 at 4:34:39 AM UTC+2, dxforth wrote:
> > [..]
> >> Is return stack a "new" concept? I've no idea when I first heard about
> >> subroutine calls and stacks but I'm sure it was long before I'd heard of
> >> forth. Perhaps it's different for newcomers today (much like their music).
[..]
> > At that time I was mainly fascinated by the possibility to use
> > assembly language from within Forth, and the light came on
> > (slowly) when I realized that the language essentially boiled
> > down to generating call-return pairs. It is, for instance, very
> > easy to explain CREATE DOES> in terms of a call to a
> > subroutine that uses the return stack pointer to subsequently
> > load data from the caller's code segment.
> I was thinking more fundamentally i.e. forth has a return stack
> for the same reason CPUs typically had one. The latter also had
> the equivalent of >R ... R> for storing temps! I gather early
> processors didn't have a return stack - which may have made it
> "new" at the time.

I am not sure what you mean. Are you hinting that classic Forth
emulated something like the 'link register' the 68000 (and Knuth's
MIX) had?
In iForth I could, instead of CALL-ing primitive A, load the target
return address in register x and then JMP to A. Primitive A simply
jumps to (x) instead of doing a RET. Maybe I should try that...

-marcel

Marcel Hendrix <mhx@iae.nl> writes:
>Are you hinting that classic Forth
>emulated something like the 'link register' the 68000 (and Knuth's
>MIX) had?

The 68000 has no link register. It's JSR instruction writes the
return address to memory, and the RTS instruction reads the return
address from memory. The memory is pointed to by the hardware stack
pointer (IIRC A7). Just like on the 8086.

RISC architectures have link registers, either one of the GPRs
(Aarch64, ARM, MIPS, Alpha, SPARC, RISC-V), or a special-purpose
register (PowerPC). For the GPRs-using architectures, in indirect
call instructions, you can choose which GPR to store the return
address to, but for direct calls the register is a specific one (in
order to leave more room in the instruction for the target address).

AFAIK the IBM S/360 also has a link register.

>In iForth I could, instead of CALL-ing primitive A, load the target
>return address in register x and then JMP to A. Primitive A simply
>jumps to (x) instead of doing a RET. Maybe I should try that...

You do that already for calling colon definitions, so if you think
that's the way to go, you might just as well use it for primitives.

But which primitives do you have in mind? I looked at some candidates
(+, MOVE), and they look like they follow the same calling-convention
as colon definitions.

- 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 2022: http://www.euroforth.org/ef22/cfp.html

On Saturday, June 4, 2022 at 11:06:51 AM UTC+2, Anton Ertl wrote:
> Marcel Hendrix <m...@iae.nl> writes:
> >Are you hinting that classic Forth
> >emulated something like the 'link register' the 68000 (and Knuth's
> >MIX) had?
> The 68000 has no link register. It's JSR instruction writes the
> return address to memory, and the RTS instruction reads the return
> address from memory. The memory is pointed to by the hardware stack
> pointer (IIRC A7). Just like on the 8086.
>
> RISC architectures have link registers, either one of the GPRs
> (Aarch64, ARM, MIPS, Alpha, SPARC, RISC-V), or a special-purpose
> register (PowerPC). For the GPRs-using architectures, in indirect
> call instructions, you can choose which GPR to store the return
> address to, but for direct calls the register is a specific one (in
> order to leave more room in the instruction for the target address).
>
> AFAIK the IBM S/360 also has a link register.
> >In iForth I could, instead of CALL-ing primitive A, load the target
> >return address in register x and then JMP to A. Primitive A simply
> >jumps to (x) instead of doing a RET. Maybe I should try that...
> You do that already for calling colon definitions, so if you think
> that's the way to go, you might just as well use it for primitives.
>
> But which primitives do you have in mind? I looked at some candidates

Personally, I've always treated 4tHs return stack in the way I knew
from the Z80 - which I was quite familiar with back in the days. And that
concept fitted SF quite nicely.

https://riptutorial.com/assembly/example/17507/zilog-z80-stack

HB

> (+, MOVE), and they look like they follow the same calling-convention
> as colon definitions.
>
> - 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 2022: http://www.euroforth.org/ef22/cfp.html

On Saturday, June 4, 2022 at 11:06:51 AM UTC+2, Anton Ertl wrote:
> Marcel Hendrix <m...@iae.nl> writes:
> >Are you hinting that classic Forth
> >emulated something like the 'link register' the 68000 (and Knuth's
> >MIX) had?
> The 68000 has no link register. It's JSR instruction writes the
> return address to memory, and the RTS instruction reads the return
> address from memory. The memory is pointed to by the hardware stack
> pointer (IIRC A7). Just like on the 8086.

Indeed, 68k has a link instruction, not a link register.

> >In iForth I could, instead of CALL-ing primitive A, load the target
> >return address in register x and then JMP to A. Primitive A simply
> >jumps to (x) instead of doing a RET. Maybe I should try that...
> You do that already for calling colon definitions, so if you think
> that's the way to go, you might just as well use it for primitives.
>
> But which primitives do you have in mind? I looked at some candidates
> (+, MOVE), and they look like they follow the same calling-convention
> as colon definitions.

The problem is that iForth uses the machine stack as the Forth data stack.
Therefore the CALL instruction can't be used without saving RTOS first,
and restoring RTOS before a return. That overhead (for non-inlined words)
goes away with a dedicated link register, but then famous control-flow
modifying tricks like R> DROP would stop working. I assume that these
archaic techniques will be made non-standard at some time, but probably
mxForth (iForth with R-D stacks switched) arrives sooner than that.

-marcel

On Saturday, June 4, 2022 at 12:38:28 PM UTC+2, Marcel Hendrix wrote:
> The problem is that iForth uses the machine stack as the Forth data stack.
> Therefore the CALL instruction can't be used without saving RTOS first,
> and restoring RTOS before a return. That overhead (for non-inlined words)
> goes away with a dedicated link register, but then famous control-flow
> modifying tricks like R> DROP would stop working. I assume that these
> archaic techniques will be made non-standard at some time, but probably
> mxForth (iForth with R-D stacks switched) arrives sooner than that.

It's quite courageous to use the machine stack - but I can understand why
you did that and kudos for pulling it off!

I agree that the "old techniques" are dirty and its use should be discouraged.
Although you can pull them off in 4tH, it might pose problems if you don't
know exactly what you're doing because tail call optimization can come in
the way.

On the other hand, some things (like coroutines) can't be done (at least in 4tH)
without it. Still, if I have to weigh them both in, I prefer the clean approach much
more than some fancy thingies.

Hans Bezemer

Marcel Hendrix <mhx@iae.nl> writes:
>Indeed, 68k has a link instruction, not a link register.

IIRC LINK and UNLK deal with stack frames (but are not quite as
complicated as 8086's ENTER and LEAVE).

>The problem is that iForth uses the machine stack as the Forth data stack.
>Therefore the CALL instruction can't be used without saving RTOS first,
>and restoring RTOS before a return. That overhead (for non-inlined words)
>goes away with a dedicated link register, but then famous control-flow
>modifying tricks like R> DROP would stop working. I assume that these
>archaic techniques will be made non-standard at some time

If you mean the Forth standards (Forth-79 etc.), I don't know if they
ever were standard, but they certainly were not in Forth-94. Already
before Forth-94 there were systems such as F-PC where these techniques
didn't work (at least not with "r> drop exit" to return to the
caller's caller), and it does not work in general in SwiftForth
(thanks to tail-call optimization) and in VFX (thanks to inlining):

VFX Forth for Linux IA32 Version: 4.72 [build 0555]
: foo r> drop ; ok
: bar foo ; ok
: flip bar ." end flip." ; ok
: flop flip ." end flop." ; ok
flop end flop. ok

SwiftForth i386-Linux 3.11.0 23-Feb-2021
: foo r> drop ; ok
: bar foo ; ok
: flip bar ." end flip." ; ok
: flop flip ." end flop." ; ok
flop end flop. ok

iforth-5.1-mini:
FORTH> : foo r> drop ; ok
FORTH> : bar foo ; ok
FORTH> : flip bar ." end flip." ; ok
FORTH> : flop flip ." end flop." ; ok
FORTH> flop end flip. ok

That's surprising; so it already does not work in the classical way in
iForth.

Gforth performs no inlining and no tail-call optimization (yet):
: foo r> drop ; ok
: bar foo ; ok
: flip bar ." end flip." ; ok
: flop flip ." end flop." ; ok
flop end flip.end flop. ok

There have been efforts by Gordon Charlton and Michael Gassanenko to
standardize return-address manipulation, but nothing ended up in
Forth-2012. If you are interested in this functionality, they made
some proposals (not formal Forth-200x proposals, though).

>mxForth (iForth with R-D stacks switched)

Given that you tried both, why did you decide to use RSP as data stack
pointer for iForth. Everybody else used RSP for the return stack, and
it looks like the better choice to me, especially because it results
in a better branch prediction for EXIT.

- 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 2022: http://www.euroforth.org/ef22/cfp.html

On Saturday, June 4, 2022 at 6:03:43 PM UTC+2, Anton Ertl wrote:
> There have been efforts by Gordon Charlton and Michael Gassanenko to
> standardize return-address manipulation, but nothing ended up in
> Forth-2012. If you are interested in this functionality, they made
> some proposals (not formal Forth-200x proposals, though).
I remember this guy! His original paper was
http://www.forth.org.ru/~mlg/ef94/ef94-2-paper.txt

I found this quite compelling, but never fully grasped his concept.
It was remarkable similar to my YIELD library:

\ The implementation of backtracking may be briefly described as following:

\ 1) the residue of the caller procedure threaded code is called continuation;
\ 2) a success is a call of the continuation;
\ 3) a failure is a return from the continuation. (To perform failure a
\ procedure compiled into the continuation should exit both its threaded
\ code and the continuation threaded code).

\ To call the residue of the caller threaded code the callee may execute
\ the code SUCCESS. To perform failure, i.e. exit the code fragment
\ which called the procedure, the callee may perform the code FAIL.
\ Note that since the top return stack item contains the address of
\ continuation, exiting to this address is scarcely meaningful.

\ For example:

\ : 1-10
\ 1
\ BEGIN
\ DUP SUCCESS
\ 1+
\ DUP 11 =
\ UNTIL
\ DROP FAIL
\ ;

\ : X 1-10 . ;

\ Execution of the word X will print numbers from 1 to 10.

\ The technique described above cannot work if we use the return stack to hold
\ temporary data!!

Hans Bezemer

On Saturday, June 4, 2022 at 6:03:43 PM UTC+2, Anton Ertl wrote:
> Marcel Hendrix <m...@iae.nl> writes:
[..]
> Gforth performs no inlining and no tail-call optimization (yet):
> : foo r> drop ; ok
> : bar foo ; ok
> : flip bar ." end flip." ; ok
> : flop flip ." end flop." ; ok
> flop end flip.end flop. ok

In iForth one has to suppress both inlining and tail-call optimizations:
FORTH> : foo r> drop [ -OPT ] ; ok
FORTH> : bar foo [ -OPT ] ; ok
FORTH> : flip bar ." end flip." ; ok
FORTH> : flop flip ." end flop." ; ok
FORTH> flop end flip.end flop. ok

> >mxForth (iForth with R-D stacks switched)
> Given that you tried both, why did you decide to use RSP as data stack
> pointer for iForth. Everybody else used RSP for the return stack, and
> it looks like the better choice to me, especially because it results
> in a better branch prediction for EXIT.

Initially (32-bit era), I was struggling for free registers and didn't want
to give one up for TOS. Also, I didn't like the looks of that optimization.
By the time I started to measure performance in earnest, the code
generator had become so complex that I couldn't change it easily
without years of re-testing. Instead, I invested the time in writing the
64bit version of iForth, with mxForth as a prototype. mxForth was
much faster than iForth64, but the latter could be ported
extremely quickly from iForth32 while the former would have been
a complete rewrite (there were also metacompiler issues). I chose
to get on and concentrate on actually using iForth for my other interests.
As I seem to get closer and closer to the physical limits with circuit
simulation, I may want to pick up mxForth again at some point.

-marcel

On 5/06/2022 01:31, Anton Ertl wrote:
> ...
> If you mean the Forth standards (Forth-79 etc.), I don't know if they
> ever were standard, but they certainly were not in Forth-94. Already
> before Forth-94 there were systems such as F-PC where these techniques
> didn't work (at least not with "r> drop exit" to return to the
> caller's caller), and it does not work in general in SwiftForth
> (thanks to tail-call optimization) and in VFX (thanks to inlining):

Did they try? It's not clear to me Forth-94 TC ever considered it -
unless a reader wishes to read it into their statement:

'A program shall not access values on the return stack that it did
not place there'

It's almost biblical.

"The tree of knowledge of good and evil, thou shalt not eat of it."

R> DROP EXIT may not qualify as a beginner's technique, nor easy to debug,
nor frequently used etc but apparently it was known and applied:

From: fish@ecst.csuchico.edu (Kevin Haddock)
Subject: Re: More Forth-in-C opinions...
Date: 18 Jun 1993 15:38:45 GMT
NNTP-Posting-Host: cscihp.ecst.csuchico.edu

In article <1vs5iv$sto@nz12.rz.uni-karlsruhe.de> DAHMS@ifk20.mach.uni-karlsruhe.de (Heribert Dahms) writes:
>In <1vpg81INNe16@charnel.ecst.csuchico.edu> fish@ecst.csuchico.edu writes:
>
>: [...]
>R> DROP EXIT is explicitely forbidden by dpANS Forth !

[...]
R> DROP EXIT in most of the polyFORTH code I've seen is about as common
as the 'break' statement in C (and is roughly the equivalent).

Don't flame me, I'm just making an observation!

-Kevin

If Forth is about getting results using the simplest possible means then IMO
it should have been included. I came upon it unwittingly when coding the
example I describe here:

http://dxforth.mirrors.minimaltype.com/unnest.html

In article <2022Jun4.173139@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
<SNIP>
>
>Given that you tried both, why did you decide to use RSP as data stack
>pointer for iForth. Everybody else used RSP for the return stack, and
>it looks like the better choice to me, especially because it results
>in a better branch prediction for EXIT.

8086 fig-Forth and all their derivatives uses the real data stack.
16 bit models fig-Forth uses segments to their advantage to break
the 64 kbyte limit. That is not easily changed.
iForth and for that matter ciforth never changed that.

I have found an effective DLL activation on MS-Windows in
32/64 ciforth. I'm not sure how good this works if EXSP is not the
real data stack.

>
>- anton

Groetjes Albert
--
"in our communism country Viet Nam, people are forced to be
alive and in the western country like US, people are free to
die from Covid 19 lol" duc ha
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

dxforth <dxforth@gmail.com> writes:
>On 5/06/2022 01:31, Anton Ertl wrote:
>> ...
>> If you mean the Forth standards (Forth-79 etc.), I don't know if they
>> ever were standard, but they certainly were not in Forth-94. Already
>> before Forth-94 there were systems such as F-PC where these techniques
>> didn't work (at least not with "r> drop exit" to return to the
>> caller's caller), and it does not work in general in SwiftForth
>> (thanks to tail-call optimization) and in VFX (thanks to inlining):
>
>Did they try?

Did who try?

>It's not clear to me Forth-94 TC ever considered it -

Given that return-address manipulation is a well-known technique and
not extremely rare (as can also be seen by the repeated discussions
about the topic here, and by Marcel Hendrix' assumption that it is
standardized), I expect that they considered it, and decided against
standardizing it.

>unless a reader wishes to read it into their statement:
>
> 'A program shall not access values on the return stack that it did
> not place there'

More exactly (from 3.2.3.3):

|A program shall not access values on the return stack (using R@, R>,
|2R@, 2R> or NR>) that it did not place there using >R, 2>R or N>R;

>It's almost biblical.

The use of "shall" is normal standards language. Forth-94 usually
uses a different style: It describes how a standard system behaves
when processing a standard program; and basically anything outside
this description is non-standard: If a program relies on a behaviour
that's not guaranteed in the standard, it is non-standard; and if a
system behaves in a way incompatible with the requirements of the
standard, it is non-standard. I usually prefer that style.

All the restrictions spelled out explicitly with "shall not" and
"shall" in 3.2.3.3 are consequences of (from 3.1.5.2 System-execution
types):

|These data types denote zero or more items on the return stack.

Apparently the Forth-94 committee felt it necessary to spell out these
consequences explicitly in the face of well-known return-address
manipulation (and maybe also loop-control parameter manipulation,
although that seems to be much less popular) techniques.

>If Forth is about getting results using the simplest possible means then IMO
>it should have been included.

Somehow people manage to get results without return-address
manipulation (or are happy enough with system-specific ways to perform
them) or F-PC, iForth, SwiftForth, VFX, cmForth, machineForth, and
colorForth would have supported R> DROP EXIT by default; they don't
(at least not with the same results as you see on, say fig-Forth).
Given the lack of common practice these days, I expect that that ship
has sailed, but if you feel like it, you can try proposing support for
that feature.

Alternatively, you can implement that feature in your system (it
probably is already there) and document it as a feature.

- 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 2022: http://www.euroforth.org/ef22/cfp.html

albert@cherry.(none) (albert) writes:
>8086 fig-Forth and all their derivatives uses the real data stack.

You mean they use SP as the data stack pointer.

>16 bit models fig-Forth uses segments to their advantage to break
>the 64 kbyte limit.

I don't see that in the fig-Forth listing, and I doubt that played a
role for that question. If they had used SP for the return stack
instead of the data stack, they would have broken the limit, too, and
by a similar (small) amount (typical data and return stack depths are <30).

I expect that the much more relevant issue for 8086 fig-Forth is that
there are many more data-stack accesses than return-stack accesses,
and thus making use of POP and PUSH saved code space and (on the 8086
and 8088) execution time.

>I have found an effective DLL activation on MS-Windows in
>32/64 ciforth. I'm not sure how good this works if EXSP is not the
>real data stack.

VFX and SwiftForth seem to have no problems.

- 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 2022: http://www.euroforth.org/ef22/cfp.html

Marcel Hendrix <mhx@iae.nl> writes:
>Initially (32-bit era), I was struggling for free registers and didn't want
>to give one up for TOS.

We also have this problem on the 386 (as has everybody else).
However, after many years I noticed that keeping the TOS in a register
does not really increase register pressure. The reason is that you
keep the TOS in a register between the end of one word and the start
of the next; there are a few cases to consider:

* for data-stack words, the TOS can be

- alive throughout the a data-stack word (e.g., +), so if you do not
keep it in a register, you memory-pop it at the start of the word and
memory-push it at the end. Keeping it alive across words does not
increase register pressure.

- dead at the start of a data-stack word (e.g., R@). So if you keep the
TOS in a register, you memory-push it at the start, and are in the
same situation wrt. register pressure as if you had not kept the
TOS in a register.

- dead at the end of a data-stack word (e.g., !). If you keep the
TOS in a register, you have to memory-pop it at the end, but
before that, you are in the same situation wrt. register pressure
as if you had not kept the TOS in a register.

* So the only words where keeping the TOS in a register makes a real
difference to register pressure are those that don't access the data
stack at all, such as ;S/EXIT or F+. However, for these words
general-purpose register pressure tends not to be a problem.

This is from the perspective of a simple Forth system, but even with
an analytic compiler (like iForth, lxf and VFX), the reasoning is
similar, only at the level of colon definitions rather than
primitives.

>Also, I didn't like the looks of that optimization.
>By the time I started to measure performance in earnest, the code
>generator had become so complex that I couldn't change it easily
>without years of re-testing. Instead, I invested the time in writing the
>64bit version of iForth, with mxForth as a prototype. mxForth was
>much faster than iForth64, but the latter could be ported
>extremely quickly from iForth32 while the former would have been
>a complete rewrite (there were also metacompiler issues). I chose
>to get on and concentrate on actually using iForth for my other interests.
>As I seem to get closer and closer to the physical limits with circuit
>simulation, I may want to pick up mxForth again at some point.

Interesting, thanks. I guess that, with aggressive inlining, returns
are rare enough that the misprediction disadvantage plays a small
role.

- 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 2022: http://www.euroforth.org/ef22/cfp.html

On 5/06/2022 19:14, Anton Ertl wrote:
> Marcel Hendrix <mhx@iae.nl> writes:
>>Initially (32-bit era), I was struggling for free registers and didn't want
>>to give one up for TOS.
>
> We also have this problem on the 386 (as has everybody else).
> However, after many years I noticed that keeping the TOS in a register
> does not really increase register pressure. The reason is that you
> keep the TOS in a register between the end of one word and the start
> of the next; there are a few cases to consider:
>
> * for data-stack words, the TOS can be
>
> - alive throughout the a data-stack word (e.g., +), so if you do not
> keep it in a register, you memory-pop it at the start of the word and
> memory-push it at the end. Keeping it alive across words does not
> increase register pressure.
>
> - dead at the start of a data-stack word (e.g., R@). So if you keep the
> TOS in a register, you memory-push it at the start, and are in the
> same situation wrt. register pressure as if you had not kept the
> TOS in a register.
>
> - dead at the end of a data-stack word (e.g., !). If you keep the
> TOS in a register, you have to memory-pop it at the end, but
> before that, you are in the same situation wrt. register pressure
> as if you had not kept the TOS in a register.
>
> * So the only words where keeping the TOS in a register makes a real
> difference to register pressure are those that don't access the data
> stack at all, such as ;S/EXIT or F+. However, for these words
> general-purpose register pressure tends not to be a problem.
>
> This is from the perspective of a simple Forth system, but even with
> an analytic compiler (like iForth, lxf and VFX), the reasoning is
> similar, only at the level of colon definitions rather than
> primitives.

An 8080 has three 16-bit registers and 8-bit accumulator. An ITC
NEXT will use all of them:

NEXT LDAX B
INX B
MOV L,A
LDAX B
INX B
MOV H,A
MOV E,M
INX H
MOV D,M
XCHG
PCHL

It might be possible to keep IP in memory but that will only slow down
NEXT. ISTM keeping TOS in a register is predicated on having enough free
ones to begin with. IOW TOS in register is not the highest priority.

dxforth <dxforth@gmail.com> writes:
>An 8080 has three 16-bit registers and 8-bit accumulator. An ITC
>NEXT will use all of them:
>
>NEXT LDAX B
> INX B
> MOV L,A
> LDAX B
> INX B
> MOV H,A
> MOV E,M
> INX H
> MOV D,M
> XCHG
> PCHL
>
>It might be possible to keep IP in memory but that will only slow down
>NEXT. ISTM keeping TOS in a register is predicated on having enough free
>ones to begin with. IOW TOS in register is not the highest priority.

IP certainly has a higher priority, and if all the registers you have
are needed in NEXT, then obviously the considerations above don't
apply, because they are predicated on being able to keep the TOS in a
register without slowing down NEXT.

Anyway, we were discussing the 80386, not the 8080. Even if we take
the in-between 8086, I see in "Inside F83" the following register
allocation:

BX=W
SP=SP
BP=RP
SI=IP

AX, CX, DX, and DI are scratch registers

NEXT destroys AX, so let's leave that alone.

One might use DI as TOS, allowing to replace F83's

CODE @ ( addr -- n )
BX POP
0 [BX] PUSH
NEXT
END-CODE

by

CODE @ ( addr -- n )
DI 0 [DI] MOV
NEXT
END-CODE

and (I expanded the 1PUSH makro to make the cost of 1PUSH obvious):

CODE + (S n1 n2 -- sum )
BX POP AX POP BX AX ADD AX PUSH NEXT END-CODE
CODE NEGATE (S n -- n' )
AX POP AX NEG AX PUSH NEXT END-CODE

by

CODE + (S n1 n2 -- sum )
AX POP AX DI ADD NEXT END-CODE
CODE NEGATE (S n -- n' )
DI NEG NEXT END-CODE

Shorter and faster.

However, I have to admit that my argument why keeping the TOS in a
register does not increase register pressure does not hold in these
cases, because in these cases only registers AX and BX are used within
a word that NEXT uses anyway.

However, if you consider the direct-threaded NEXT of gforth-fast 0.6.2
(compiled with gcc-2.95), the only register involved is IP (in ebx):

add ebx , # 4
jmp dword ptr -4 [ebx]

(This is in a setup (primitive-centric hybrid direct/indirect threaded
code) where words called with NEXT don't need W. In this setup the
argument certainly is true.

- 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 2022: http://www.euroforth.org/ef22/cfp.html

On 5/06/2022 23:33, Anton Ertl wrote:
> ...
> Anyway, we were discussing the 80386, not the 8080. Even if we take
> the in-between 8086, I see in "Inside F83" the following register
> allocation:
>
> BX=W
> SP=SP
> BP=RP
> SI=IP
>
> AX, CX, DX, and DI are scratch registers
>
> NEXT destroys AX, so let's leave that alone.
>
> One might use DI as TOS, allowing to replace F83's
> ...

I could have gone with TOS in register when DX-Forth moved from
8080 to 8086 but it was never a serious consideration - perhaps
because I'd be looking at 15% speed improvement max and I was
already using an inline NEXT. Some years later I did create a
kernel with TOS in BX just to see what it would take. I recall
it wasn't particularly hard. However to make the change at that
point in time, invalidating anything that used assembler, I felt
was more trouble than worth. I'd only do it were I starting a
new forth and even then the gain would be marginal.