anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
> Chuck Moore's work on Forth is an example that is not only
> comprehensible to others, but has inspired many others to use it,
> adapt it to their needs, extend it, and do their own things with it.
> And it scaled quite well. Thousands of people have used Forth.

Forth itself is useful and inspiring, but when I look at actual Forth
code written by Chuck Moore, maybe it's just me, but I have found it
quite incomprehensible. That basically means cmForth and some of his
GA144 code, so far. I don't know what else is out there.

> It helps to keep both the implementation and the interface simple, it
> does not help to keep the implementation simple at the cost of
> interface complexity.

The Jeff Fox article calls rather for keeping the implementation simple
at all costs. For example, having OKAD work in 6400/4096ths of a
millivolt (or maybe the reciprocal of that) instead of directly in
millivolts. It seems almost like an extreme caricature of what Dick
Gabriel called the New Jersey approach in "Worse Is Better" (
https://www.dreamsongs.com/RiseOfWorseIsBetter.html ). And Gabriel's
description of the New Jersey approach was itself already a caricature.

Anton Ertl schrieb am Montag, 7. November 2022 um 23:29:52 UTC+1:
> "minf...@arcor.de" <minf...@arcor.de> writes:
> >Modern 64-bit C passes most arguments through CPU registers.
> >Times are a-changing ...
> C calling conventions on 32-bit architectures such as ARM (1985), MIPS
> (1986), SPARC (1986) etc. all pass parameters through registers.
> Given the age and current status of these architectures, I hesitate to
> call them modern.

Yes, the fastcall calling convention offers itself for CPUs having sufficient
numbers of registers.

I wonder if Forth performance could be improved by keeping a larger stack
segment in CPU registers, than by meanwhile classic TOS-only-caching.
AFAIU the bottleneck is bringing the stack to its canonical state, but this
could be reduced by keeping some registers in reserve (top stack segment
"floating" in CPU registers).

In the end, passing top stack segments already through registers would
about eliminate the difference to using locals.

"minf...@arcor.de" <minforth@arcor.de> writes:
> I wonder if Forth performance could be improved by keeping a larger
> stack segment in CPU registers, than by meanwhile classic
> TOS-only-caching.

TOS+NOS is also a thing. Mecrisp keeps more stack slots in registers
but has an actual register allocator, so maybe you meant something
simpler.

> AFAIU the bottleneck is bringing the stack to its canonical state, but
> this could be reduced by keeping some registers in reserve (top stack
> segment "floating" in CPU registers).

Mecrisp has some code for tidying the stack like that, but I thought it
was because the word being compiled didn't know where it was being
called from, so it had to present a consistent stack picture wherever
the caller was.

In the case where the compiler knows there is only one call site, the
word can be inlined. If there is more than one call site, but they are
known (say there are 3 of them), I wonder if it's feasible to allocate
the registers so that the shared stack slots all end up in the same
registers.

> In the end, passing top stack segments already through registers would
> about eliminate the difference to using locals.

Once the compiler is that fancy, putting locals in registers seems
natural.

Ditzel's original CRISP cpu had a stack cache that may have been almost
as good as registers. I wonder if something that could come back someday.

On 8/11/2022 4:06 am, minf...@arcor.de wrote:
> the.bee...@gmail.com schrieb am Montag, 7. November 2022 um 17:01:21 UTC+1:
>> However, it's alien to the very concept of C, which uses stack frames
>> as its primary data flow mechanism.
>
> Modern 64-bit C passes most arguments through CPU registers.
> Times are a-changing ...

Forth and C VM's know nothing about that. See MPE's 'Programming Forth'.

Jeff remarked locals-in-Forth users would come up with all sorts of
rationalizations for doing so, and that's certainly been true.

"Don't use local variables. Don't come up with new syntaxs for describing
them and new schemes for implementing them. You can make local variables
very efficient especially if you have local registers to store them in,
but don't. It's bad. It's wrong." - C.M.

On 8/11/2022 10:06 am, Paul Rubin wrote:
> anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>> Chuck Moore's work on Forth is an example that is not only
>> comprehensible to others, but has inspired many others to use it,
>> adapt it to their needs, extend it, and do their own things with it.
>> And it scaled quite well. Thousands of people have used Forth.
>
> Forth itself is useful and inspiring, but when I look at actual Forth
> code written by Chuck Moore, maybe it's just me, but I have found it
> quite incomprehensible. That basically means cmForth and some of his
> GA144 code, so far.

Perhaps because you haven't worked your way up to it. Well, neither have
I - mainly due to lack of motivation.

> I don't know what else is out there.

There's plenty of forth code about which demonstrates locals are rarely,
if ever, needed - and it didn't require a Moore or Fox to do it. If
dismissing all and focussing on the exceptions that is the game, then who
is the one being pure and perfect?

On Monday, November 7, 2022 at 11:24:53 PM UTC+1, Anton Ertl wrote:
> Marcel Hendrix <m...@iae.nl> writes:
[..]
> Chuck Moore's work on Forth is an example that is not
> only comprehensible to others, but has inspired many others to use it,
> adapt it to their needs, extend it, and do their own things with it.
> And it scaled quite well. Thousands of people have used Forth.
That is meta-true for Forth as a language concept. But how many
engineers use CM's tools as-is in their daily work?

-marcel

dxforth <dxforth@gmail.com> writes:
> There's plenty of forth code about which demonstrates locals are
> rarely, if ever, needed

Yes, that code shows that stuff can usually or always be done without
locals. I don't doubt that. What I don't understand is what makes a
without-locals version superior to a locals version.

> "Don't use local variables. Don't come up with new syntaxs for
> describing them and new schemes for implementing them. You can make
> local variables very efficient especially if you have local registers
> to store them in, but don't. It's bad. It's wrong." - C.M.

I doubt C.M. was one for faith in authority, and I haven't yet figured
out what is in his mind when he says things like that. Ideas that have
been mentioned:

1. Locals complicate the compiler. Jeff Fox's essay mentions C.M.'s
compiler uses just 1K of code. Adding locals would make it bigger.

2. Locals are less efficient at runtime. They take more cpu cycles.

3. They use more memory, return stack cells or whatever.

4.. Locals interfere with some kind of Forth spirituality at which I
have currently not reached enlightenment. The one true way is
through commune with the Cosmic Stack Machine.

My reactions:

1. Most of us are using bigger compilers already, even non-ANS. For
example, Mecrisp is around 12K. Gforth is bigger still, but it is ANS,
so it has already left the path and doesn't count.

2. Jeff's article is emphatic, it is ok for the code to be slow, or else
he wouldn't disapprove of optimizing compilers so much. Anyway, this is
a trade-off that can be visited on a per-word basis.

3. Ok, running out of memory is a thing in small processors, but it's
best to get something working and then worry about squeezing stack cells
if you have to. Premature optimization and all that.

4. This I have no idea about, but I had thought early on that C.M. saw
Forth as a spiritual relation of Lisp, even though its formalism is
completely different. I see that as being mostly about interactive
development, code executed at compile time, and simple, user-redefinable
syntax, rather than the stack VM per se. So again I don't understand
the issue with locals. There have even been parsing words for infix
syntax written for Forth. Locals have to be pretty minor compared to
that.

Jeff Fox's essay also said to avoid over-abstraction, but then talks
about the pure stack VM, which is itself an abstraction inversion when
run on a register machine.

On 8/11/2022 6:22 pm, Paul Rubin wrote:
> dxforth <dxforth@gmail.com> writes:
>> There's plenty of forth code about which demonstrates locals are
>> rarely, if ever, needed
>
> Yes, that code shows that stuff can usually or always be done without
> locals. I don't doubt that. What I don't understand is what makes a
> without-locals version superior to a locals version.

For the same reason forth texts and teachers encourage you not to use
variables - it stunts your growth as a forth programmer.

Paul Rubin schrieb am Dienstag, 8. November 2022 um 01:01:29 UTC+1:
> "minf...@arcor.de" <minf...@arcor.de> writes:
> > I wonder if Forth performance could be improved by keeping a larger
> > stack segment in CPU registers, than by meanwhile classic
> > TOS-only-caching.
> TOS+NOS is also a thing. Mecrisp keeps more stack slots in registers
> but has an actual register allocator, so maybe you meant something
> simpler.
> > AFAIU the bottleneck is bringing the stack to its canonical state, but
> > this could be reduced by keeping some registers in reserve (top stack
> > segment "floating" in CPU registers).
> Mecrisp has some code for tidying the stack like that, but I thought it
> was because the word being compiled didn't know where it was being
> called from, so it had to present a consistent stack picture wherever
> the caller was.

Indeed, too many stack states would increase code size and might even
prevent inlining. It seems more a feasible technique for VMs with a limited
number of primitives. During runtime the stack would probably reside
in a CPU cache anyway for fast access.

And, not to forget, the Standard prohibits this kind of optimization, aka
named stack elements. Instead it stipulates that locals must not use the
data stack as storage resource. Seems to have become a bit backwoodish
today.

Paul Rubin <no.email@nospam.invalid> writes:
>anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>> Chuck Moore's work on Forth is an example that is not only
>> comprehensible to others, but has inspired many others to use it,
>> adapt it to their needs, extend it, and do their own things with it.
>> And it scaled quite well. Thousands of people have used Forth.
>
>Forth itself is useful and inspiring, but when I look at actual Forth
>code written by Chuck Moore, maybe it's just me, but I have found it
>quite incomprehensible. That basically means cmForth and some of his
>GA144 code, so far.

I find the cmForth code that includes the shadow screens
<https://github.com/ForthHub/cmFORTH/blob/combined/cmforth.fth> mostly
comprehensible. Of course when he deals with the machine code of his
architecture and uses octal numbers for the instructions without
giving them names first, it's hard to follow, but the shadow screens
allow you to get the gist of it. E.g., (reformatted for fitting in
70-char lines):

\ PACK sets the return bit, if an instruction does not reference
\ the Return stack. Otherwise it compiles a return. It exits
\ from EXIT with POP DROP .
FORTH : PACK ( a n - a) 160257 AND 140201 XOR IF
40 SWAP +! ELSE DROP 100040 , THEN POP DROP ;

>The Jeff Fox article calls rather for keeping the implementation simple
>at all costs. For example, having OKAD work in 6400/4096ths of a
>millivolt (or maybe the reciprocal of that) instead of directly in
>millivolts.

That's a common technique with fixed-point, and to some extent even
with FP. In TeX Knuth uses lengths in terms of 1/65536ths of a point
IIRC.

>It seems almost like an extreme caricature of what Dick
>Gabriel called the New Jersey approach in "Worse Is Better" (
>https://www.dreamsongs.com/RiseOfWorseIsBetter.html ).

Well, of course what Jeff Fox (or dxforth) wrote may misrepresent the
positions of Chuck Moore, although we also get some of his own
writings.

But anyway, in 1971 Chuck Moore and Ken Thompson (Mr. New Jersey
approach) were both working on minicomputers of the time, and Moore
created Forth, and Thompson created Unix. Both Forth and Unix became
successful, with Forth switching to micros when they became powerful
enough, and Unix growing with the minis and switching to micros only
later in the 1980s. This already shows a difference.

When micros grew beyond the size of the minis Forth was originally
designed for, Chuck Moore refused to take advantage of that (in
particular, he advocated 3 chars+length even when memory was no longer
so tight that we could not afford the full length; most of the Forth
community did not follow him in that instance).

Competition sprung up (e.g., Turbo Pascal) that made use of the
additional opportunities to provide a more comfortable experience to
many programmers than Forth. Some of the Forth community jumped over
to using these things, some tried to make good use of the additional
memory (but failed in the Valdocs case), some insisted on the
superiority of the old ways (screens etc.).

Moore went on to design Forth hardware, OKad, Machine Forth, and
ColorForth, all of which were less successful than Forth.

Thompson continued with further research OSs (Plan 9, Inferno), which
did not become products, and the Go language, which is a product, and
seems to be quite successful (certainly more successful than Forth is
these days, and, coming back to Gabriel's paper, probably also more
successful than Common Lisp).

- 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: https://euro.theforth.net

"minf...@arcor.de" <minforth@arcor.de> writes:
>I wonder if Forth performance could be improved by keeping a larger stack
>segment in CPU registers, than by meanwhile classic TOS-only-caching.

When I last measured it (Figure 7-9 of [ertl&gregg05]), keeping only
one stack item in a register was better than two for single-state
stack caching (the line labeled "n"), and using the state with one
stack item in a register as canonical state was not worse then keeping
more items in a register as canonical state even for multi-state stack
caching (with the reset to the canonical state happening at basic
block boundaries). Of course, things may have changed now: With Intel
and AMD CPUs making register-register moves cost almost nothing, the
additional moves of using a canonical state with more stack items in
registers may cost less than the benefit we get from the possible
reduction in loads and stores.

>AFAIU the bottleneck is bringing the stack to its canonical state, but this
>could be reduced by keeping some registers in reserve (top stack segment
>"floating" in CPU registers).

That's multi-state stack caching, and Gforth has used this for a while
on architectures with enough registers. It does not reset to the
canonical state between primitives in a basic block.

>In the end, passing top stack segments already through registers would
>about eliminate the difference to using locals.

Given a compiler that is analytical about stack items of all stacks
and about locals, and works at the colon definition level (rather than
the basic block level), I expect essentially the same code from
keeping data on the stack or keeping it in locals: they all are mapped
to registers. Now I only have to write such a compiler:-).

@InProceedings{ertl&gregg05,
author = {M. Anton Ertl and David Gregg},
title = {Stack Caching in {Forth}},
crossref = {euroforth05},
pages = {6--15},
url = {http://www.complang.tuwien.ac.at/papers/ertl%26gregg05.ps.gz},
pdfurl = {http://www.complang.tuwien.ac.at/anton/euroforth2005/papers/ertl%26gregg05.pdf},
OPTnote = {not refereed},
abstract = {Stack caching speeds Forth up by keeping stack items
in registers, reducing the number of memory accesses
for stack items. This paper describes our work on
extending Gforth's stack caching implementation to
support more than one register in the canonical
state, and presents timing results for the resulting
Forth system. For single-representation stack
caches, keeping just one stack item in registers is
usually best, and provides speedups up to a factor
of 2.84 over the straight-forward stack
representation. For stack caches with multiple stack
representations, using the one-register
representation as canonical representation is
usually optimal, resulting in an overall speedup of
up to a factor of 3.80 (and up to a factor of 1.53
over single-representation stack caching).}
} @Proceedings{euroforth05,
title = {21st EuroForth Conference},
booktitle = {21st EuroForth Conference},
year = {2005},
key = {EuroForth'05},
editor = {M. Anton Ertl},
url = {http://www.complang.tuwien.ac.at/anton/euroforth2005/papers/proceedings.pdf}
}

- 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: https://euro.theforth.net

Anton Ertl schrieb am Dienstag, 8. November 2022 um 11:44:57 UTC+1:
> Given a compiler that is analytical about stack items of all stacks
> and about locals, and works at the colon definition level (rather than
> the basic block level), I expect essentially the same code from
> keeping data on the stack or keeping it in locals: they all are mapped
> to registers. Now I only have to write such a compiler:-).

:o) this smells a bit of a stack-state dependent JIT colon def. compiler.
Piece of cake.

Peter Fälth demonstrated his system generating the same code with or
without locals using CPU registers. I am not into wild guessing how, or
whether some stack caching is involved or not, but it was impressive.

On 8/11/2022 8:39 pm, Anton Ertl wrote:
>
> Well, of course what Jeff Fox (or dxforth) wrote may misrepresent the
> positions of Chuck Moore, although we also get some of his own
> writings.

'You can't trust those two, but you can trust the person who sells them
down the river.' Did I interpret that correctly? I wouldn't want to be
accused of misrepresenting you.

Paul Rubin <no.email@nospam.invalid> writes:
>Mecrisp has some code for tidying the stack like that, but I thought it
>was because the word being compiled didn't know where it was being
>called from, so it had to present a consistent stack picture wherever
>the caller was.

That's a reason for C with its separate compilation or Lisp with its
dynamic binding, but it's no reason for direct calls in Forth. In
Forth the direct caller always knows what it calls. So the compiler
could compile a word such that it expects its inputs in arbitrary
registers, and puts its output in arbitrary registers, with arbitrary
registers destroyed by the word. And it can then compile almost all
direct callers to deal with that interface.

The exception is direct recursion, where the call typically has to be
compiled before the word is compllete and you know the individual
interface. A (not very efficient) way to deal with that is to treat a
recursive call like an indirect call; or you compile the paths with
the recursive calls only after compiling the base case path, then you
fix the interface, then you compile the remaining paths.

For indirect calls (EXECUTE, DEFER), a fixed calling convention is
needed; that can be achieved by providing a wrapper around the
individual interface.

>Ditzel's original CRISP cpu had a stack cache that may have been almost
>as good as registers. I wonder if something that could come back someday.

No. There's a reason why nobody imitated CRISP. Although nowadays we
have hardware that can bypass the actual store->load latency in some
cases when loading from a recently-stored address, reducing the
latency from 5 or so to 1 cycle. Still, this does not happen reliably
enough and it uses load/store unit resources (2 loads and 1 store per
cycle or somesuch vs. 10 register reads and 5 register writes or
somesuch), so using registers is still the way to go.

- 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: https://euro.theforth.net

dxforth <dxforth@gmail.com> writes:
>"Don't use local variables. Don't come up with new syntaxs for describing
> them and new schemes for implementing them. You can make local variables
> very efficient especially if you have local registers to store them in,
> but don't. It's bad. It's wrong." - C.M.

Reference needed.

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

Marcel Hendrix <mhx@iae.nl> writes:
>On Monday, November 7, 2022 at 11:24:53 PM UTC+1, Anton Ertl wrote:
>> Marcel Hendrix <m...@iae.nl> writes:
>[..]
>> Chuck Moore's work on Forth is an example that is not
>> only comprehensible to others, but has inspired many others to use it,
>> adapt it to their needs, extend it, and do their own things with it.
>> And it scaled quite well. Thousands of people have used Forth.
>
>That is meta-true for Forth as a language concept. But how many
>engineers use CM's tools as-is in their daily work?

These days, probably not that many. It seems that his Forth systems
after 1978 (cmForth and ColorForth are known to me, are there others)
were not very popular. But in any case, if his old (1971-1978) Forth
had been incomprehensible, Forth would not have seen the takeup it has
seen. Dean Sanderson would have been unable to design microForth,
Seltzer and Ragsdale would have been unable to do fig-Forth, and so
on.

And I think that given Chuck Moores stance on on rewriting code and
adapting it for the purpose at hand, he considers the concepts more
valuable than the code.

- 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: https://euro.theforth.net

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
> if [C.M.'s] old (1971-1978) Forth had been incomprehensible, Forth
> would not have seen the takeup it has seen. Dean Sanderson would have
> been unable to design microForth, Seltzer and Ragsdale would have been
> unable to do fig-Forth, and so on... And I think ... [C.M.]
> considers the concepts more valuable than the code.

Did Sanderson etc. do their implementations by studying C.M.'s source
code, or did they simply reimplement its behaviour? I find Forth's
concepts to be mostly understandable. What I found hard to understand
was the actual Forth code written by C.M. that I looked at. I also
found fig-Forth to be hard to understand, if that matters. I'm
unfamiliar with microForth.

On 9/11/2022 5:34 am, Anton Ertl wrote:
> dxforth <dxforth@gmail.com> writes:
>> "Don't use local variables. Don't come up with new syntaxs for describing
>> them and new schemes for implementing them. You can make local variables
>> very efficient especially if you have local registers to store them in,
>> but don't. It's bad. It's wrong." - C.M.
>
> Reference needed.

According to Google the source of the quote has been mentioned on c.l.f. on
at least 38 occasions over the years, most recently:

https://groups.google.com/g/comp.lang.forth/c/Wcn1OXpDSzI/m/dEyaxHSKAQAJ

https://groups.google.com/g/comp.lang.forth/c/Wcn1OXpDSzI/m/Q1fWbUCPAQAJ

The quote from Moore himself:

https://youtu.be/pSnNy7IpVMg?t=3192

On Tuesday, November 8, 2022 at 11:25:56 AM UTC+1, Anton Ertl wrote:
> But anyway, in 1971 Chuck Moore and Ken Thompson (Mr. New Jersey
> approach) were both working on minicomputers of the time, and Moore
> created Forth, and Thompson created Unix. Both Forth and Unix became
> successful, with Forth switching to micros when they became powerful
> enough, and Unix growing with the minis and switching to micros only
> later in the 1980s. This already shows a difference.
There are, however, remarkable similarities between the Forth and Unix design.
First, in Forth everything is a word. In Unix, everything is a file. Second, in Forth,
data is passed transparently and implicitly by the stack. In Unix, data can be
passed transparently and implicitly by pipes.

Hans Bezemer

In article <87o7th2qyc.fsf@nightsong.com>,
Paul Rubin <no.email@nospam.invalid> wrote:
>anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>> if [C.M.'s] old (1971-1978) Forth had been incomprehensible, Forth
>> would not have seen the takeup it has seen. Dean Sanderson would have
>> been unable to design microForth, Seltzer and Ragsdale would have been
>> unable to do fig-Forth, and so on... And I think ... [C.M.]
>> considers the concepts more valuable than the code.
>
>Did Sanderson etc. do their implementations by studying C.M.'s source
>code, or did they simply reimplement its behaviour? I find Forth's
>concepts to be mostly understandable. What I found hard to understand
>was the actual Forth code written by C.M. that I looked at. I also
>found fig-Forth to be hard to understand, if that matters. I'm
>unfamiliar with microForth.

ciforth is actually fig-Forth 5.4.0.
The cvs archive version 1.0 is a copy of a 8086 fig-Forth.
I changed it gradually to 32 bits and replacing BUILD> DOES> with
create/does.
There was no point in time the code was hard to modify or understand.
There was an insight that create-words have actually two data field,
(one data pointer) that can independantly be modified. 1]
There was an insight that literals can be handled by modular,
all but regular words.
These required thinking hard to be implemented
but the fig-Forth code was no hurdle at all.

1] Ting came to the same insight with C++ implementation.

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 9/11/2022 5:34 am, Anton Ertl wrote:
>> dxforth <dxforth@gmail.com> writes:
>>> "Don't use local variables. Don't come up with new syntaxs for describing
>>> them and new schemes for implementing them. You can make local variables
>>> very efficient especially if you have local registers to store them in,
>>> but don't. It's bad. It's wrong." - C.M.
>>
>> Reference needed.
>
>According to Google the source of the quote has been mentioned on c.l.f. on
>at least 38 occasions over the years, most recently:
>
>https://groups.google.com/g/comp.lang.forth/c/Wcn1OXpDSzI/m/dEyaxHSKAQAJ
>
>https://groups.google.com/g/comp.lang.forth/c/Wcn1OXpDSzI/m/Q1fWbUCPAQAJ

More directly, you mean

http://www.ultratechnology.com/1xforth.htm

>The quote from Moore himself:
>
>https://youtu.be/pSnNy7IpVMg?t=3192

Thanks.

Looking at it again, it's an interesting juxtaposition: First Chuck
Moore talks about the registers A and R in i21 (and I think he has
kept them in his more recent cores), which are useful for MOVE, and he
says that A acts much like a local variable. This leads him to talk
about locals, which he rejects without giving a reason, and then he
goes on to talk about variables, which he considers necessary.
This ties in with some things we have discussed repeatedly over the
years. One reason for having locals was for implementing words that
have so many items in constant use that a pure-stack variant is
cumbersome. An example is MOVE (or, for additional difficulty,
consider a FAXPY-like[1] word on a system with floats on the data stack).
The answer of Elizabeth Rather (IIRC) has been that for
performance-critical words like MOVE, one would write them in assembly
language. For me that's an admission that her kind of Forth is
insufficient for writing these words.

With Forth in hardware, Chuck Moore could not cop out to a more
capable assembler, but he still had a need to write MOVE (probably not
FAXPY), and because traditional Forth was not adequate for that, he
added A and enhanced the capabilities of R. This inspired some people
to think about adding registers to Forth (I dimly remember a talk by
Stephen Pelc), but it seems the idea eventually has not caught on.

I understand why Moore did these additions, and I can see why he did
not want to add locals to his system (especially with both stacks only
6 items deep), but for Forth on general-purpose machines, locals are
superior to these registers: you can have more of them if needed
(e.g., for FAXPY), can name them as appropriate, and don't need to
worry about them being destroyed by a word you call.

There is one property of A (but not R) and (global) variables that
locals and the return stack don't have: you can split a word (as far
as control structures permit) into two parts and data flows through A
and variables automatically between these parts; with locals you have
to arrange explicit passing of these values through the stack. One
can see this as an advantage of A and variables in making factoring
easy, or one can see this as an advantage of locals in forcing to make
the data flow explicit and therefore easier to follow. The latter
advantage is more important for me.

In any case, in classic Forth Moore had provided two stacks instead of
registers despite running on machines that had registers. Why not
expose some of those registers under names like A and R in classic
Forth, and why has A and R not caught on in other Forth systems after
Chuck Moore added them to machine Forth (as the buzz at the time
shows, people were open to this idea)?

The stack provides a nice and convenient interfaces between words,
while register-based interfaces tend to be messy: In any case, you
have to write code for saving and restoring some registers, which is
handled automatically in a stack-based interface; moreover, if each
word has its individual interface for optimum performance, it's hard
to remember, and if you use a common calling convention, you have to
write code for complying with it even though you see how you could do
better by using an individual interface. Better avoid these problems
and stick to the stack.

[1] FAXPY ( ra f-x nstridex f-y nstridey ucount -- ) multiplies ra
with f-x and adds the result to f-y, where f-x and f-y are arrays and
ucount elements are accessed with strides nstridex and nstridey,
respectively. This is the Forth float variant of BLAS's SAXPY,
DAXPY, CAXPY and ZAXPY routines.

- 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: https://euro.theforth.net

Hans Bezemer <the.beez.speaks@gmail.com> writes:
>There are, however, remarkable similarities between the Forth and Unix design.
>First, in Forth everything is a word. In Unix, everything is a file. Second, in Forth,
>data is passed transparently and implicitly by the stack. In Unix, data can be
>passed transparently and implicitly by pipes.

So yes, both systems centered around a few common abstractions, but
these abstractions were far enough from each other that they show more
difference than commonality.

Comonalities are that they were on small machines, and they were
somewhat comprehensive systems, while these days we tend to think of
Unix as OS, and of Forth as a programming language. Both had no
memory protection (Unix acquired virtual memory only with 3BSD in
1979), both acquired multi-tasking (and multi-user) pretty soon.

But the OS/language difference has been there from the start, only
deepened later; as I wrote in
<2007Dec2.152201@mips.complang.tuwien.ac.at>:

|One difference between Forth and Unix from the start was that Unix had
|files and executables, thus supporting a hard compilation/run-time
|boundary in programming language implementations (and making
|programming languages without that restrictions less favoured), having
|several programming languages, and requiring an additional interpreter
|(the shell) for executing programs.

- 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: https://euro.theforth.net

On 9/11/2022 8:33 pm, Anton Ertl wrote:
> ...
> One reason for having locals was for implementing words that
> have so many items in constant use that a pure-stack variant is
> cumbersome.

Both are complicated solutions AFAICS. One has lots of stack
operations and the other has lots of variables. They're as bad
as each other. Were folks to see that, they might look for
another solution.

In article <2022Nov9.103332@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
<SNIP>
>
>[1] FAXPY ( ra f-x nstridex f-y nstridey ucount -- ) multiplies ra
>with f-x and adds the result to f-y, where f-x and f-y are arrays and
>ucount elements are accessed with strides nstridex and nstridey,
>respectively. This is the Forth float variant of BLAS's SAXPY,
>DAXPY, CAXPY and ZAXPY routines.

This can be done with nested loops: I and J
Rejecting local variables and then using I and J
(actually similar to adding a special A registers.)
that are a sort of register variables with a special purpose?
I have to admit that feels like cheating.
It makes the case for locals stronger, but local
TO-VALUEs have the same cludgy feeling as I and J.

I feels like you are not going to be able to program, beyond a
certain level of complexity.

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

Paul Rubin <no.email@nospam.invalid> wrote:
> dxforth <dxforth@gmail.com> writes:
> > My point was it went from 4 locals to 6 for reasons of style. It may be
> > C-style to expend resources this way (I wouldn't know)
>
> In C these days, the extra locals wouldn't expend any resources in most
> cases, since the compiler would optimize them away.
>
> > but I doubt it's Moore's.
>
> This I don't know. A traditional thread Forth interpreter (Moore's
> invention) is probably 10x slower than CODE doing the same thing, but
> Moore only used CODE when he had to. If 9x extra compute cycles is
> fine, why are a few memory cells a big deal?

I think origin of Forth explain this. In his book "PROGRAMMING
A PROBLEM-ORIENTED-LANGUAGE" Moore write about "programs with
input". In more clear language he wanted to have interactive
command processor. For processing user commands even minis
from 1970 and early micros have enough speed that you can lose
some (not too much, but factor of 10 is acceptable). OTOH
some minis were quite small. More writes about 4kB RAM, but
I think that he could put only very stripped down system on
such machine, full system that he outlines probably need
something between 8 and 16 kB RAM (FIG Forth executable is
slightly bigger than 6kB, but needs extra memory for block
buffers and for words defined in Forth).

--
Waldek Hebisch