In article <87a65c66u4.fsf@nightsong.com>,
Paul Rubin <no.email@nospam.invalid> wrote:
>Doug Hoffman <dhoffman888@gmail.com> writes:
>>> I also don't see how to implement 2SWAP with just DUP, DROP, OVER.
>> Use the return stack as a "local variable holder"
>> and use ROT and SWAP.
>
>I'm doing by the quote from Chuck Moore about DUP, DROP, and OVER (and
>maybe SWAP) being the only legit stack primitives, so no ROT. He does
>use the return stack in his own code though.

Once strings are introduced as a proper pair (not zero-ended)
you need SPSWAP and PSSWAP for swapping a single and a double.
I can't see Chuck Moore object to that.
I use these preferably, because I (like Chuck) have difficulty
remembering the stack diagram of ROT.
>
>> Truthfully, I don't see much difference between conventional locals
>> and using the return stack for same.
>
>There is no RPICK in standard Forth, so you can't get at the internal
>slots. Moore even frowns on regular PICK. Also, you have to be able to
>pop the locals if the word exits through an exception. (LOCAL) had to
>be added to the standard to allow that, since the VM has to handle the
>unwinding in that situation.

PICK is no use. It does something right though, it leaves parameters
on the data stack instead of copying to un undisclosed location.
I experimented with a frame pointer that marks
a position on the stack and names data items from there with an offset.
This works but I was not convinced to show it here on comp.lang.forth.
(but a one-screener and not invasive.)

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

On 31/10/2022 7:41 pm, Hans Bezemer wrote:
> On Monday, October 31, 2022 at 3:05:16 AM UTC+1, Paul Rubin wrote:
>>
>> Yes, idiot proofing is always a good goal when programming ;).
> According to both Moore and Dijkstra, idiots shouldn't be programming.

I felt the same way after quashing a bug that randomly deleted files :)

On 31 Oct 2022 at 00:48:55 CET, "Paul Rubin" <no.email@nospam.invalid> wrote:

> In Forth, there are only 3 or so
> "registers" (T, N, and R), and each is special. Why be so vehement that
> a human rather than a machine should be juggling them?

If you consider the whole Forth VM there are rather more:
TOS, NOS, PSP \ T, N, data stack pointer
TOR, RSP \ R, return stack pointer
TOF, FSP \ top of floats, float stack pointer
LP \ local pointer
UP \ user area pointer
For stack underflow checking you need three more. On a modern optimising
Forth.
it's easy to find oneself using six to eight CPU registers for the VM and the
same
again for code generation, and a couple of special purpose registers.

Stephen
--
Stephen Pelc, stephen@vfxforth.com
MicroProcessor Engineering, Ltd. - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, +44 (0)78 0390 3612,
+34 649 662 974
http://www.mpeforth.com - free VFX Forth downloads

On Monday, October 31, 2022 at 4:40:09 AM UTC-4, the.bee...@gmail.com wrote:

> > : 2swap ( x1 x2 x3 x4 -- x3 x4 x1 x2 )
> > >r rot rot r> swap rot swap ;
> Really?! Even my computer can do better!
> rot >r rot r>

Thanks for pointing that out Hans.
VFX's optimizer lulled me into thinking that
what I showed was efficient. My bad!

-Doug

On Sunday, October 30, 2022 at 10:54:29 PM UTC-4, Paul Rubin wrote:
> Doug Hoffman <dhoff...@gmail.com> writes:
> >> I also don't see how to implement 2SWAP with just DUP, DROP, OVER.
> > Use the return stack as a "local variable holder"
> > and use ROT and SWAP.
> I'm doing by the quote from Chuck Moore about DUP, DROP, and OVER (and
> maybe SWAP) being the only legit stack primitives, so no ROT. He does
> use the return stack in his own code though.
> > Truthfully, I don't see much difference between conventional locals
> > and using the return stack for same.
> There is no RPICK in standard Forth, so you can't get at the internal
> slots. Moore even frowns on regular PICK. Also, you have to be able to
> pop the locals if the word exits through an exception. (LOCAL) had to
> be added to the standard to allow that, since the VM has to handle the
> unwinding in that situation.

Meh. What Moore has stated in recent decades also has little to do with
standard Forth.

My point, which I should have stated explicitly, is that detractors of locals
generally say that their use impedes factoring because items are
not on the data stack. But often these same people have no issue
with putting items on the return stack, which must also impede factoring
for the same reason. Though I really don't subscribe to the impede
factoring issue in either case.

Frequently-used core-type words like 2swap should not use locals.
In higher level problem specific words locals have a place in the code I write.

That was fun. What next, a debate about blocks vs text files?

-Doug

On Sunday, October 30, 2022 at 4:30:16 PM UTC+1, Gerry Jackson wrote:
> Sorry about that, I wasn't aware that 4th used zero terminated strings
> and just assumed that standard counted strings were used. So presumably
> your version of COUNT does it by actually counting the characters.
Yes - found out pretty quickly that abstracting STRING words worked in most
situations - so I rarely have problems porting stuff with "cooked" strings.
Unless someone uses COUNT as C@+ equivalent :-(

Note that the overhead of "counting strings" is negligible, since 4tH promotes
the addr/count representation - just like ANS Forth. Only when getting stuff
from string variables or ," compiled strings or +PLACE counting strings is
required.

> It's fortuitous that a 0 byte means an empty string for both ways of
> representing a string.
Yeah - I thought so too! I'm so used to ASCIIZ strings it didn't dawn upon me
this might have been written for COUNTed strings. There I got the idea about
the stack item!

Hans Bezemer

Doug Hoffman schrieb am Montag, 31. Oktober 2022 um 16:30:33 UTC+1:
> On Sunday, October 30, 2022 at 10:54:29 PM UTC-4, Paul Rubin wrote:
> > Doug Hoffman <dhoff...@gmail.com> writes:
> > >> I also don't see how to implement 2SWAP with just DUP, DROP, OVER.
> > > Use the return stack as a "local variable holder"
> > > and use ROT and SWAP.
> > I'm doing by the quote from Chuck Moore about DUP, DROP, and OVER (and
> > maybe SWAP) being the only legit stack primitives, so no ROT. He does
> > use the return stack in his own code though.
> > > Truthfully, I don't see much difference between conventional locals
> > > and using the return stack for same.
> > There is no RPICK in standard Forth, so you can't get at the internal
> > slots. Moore even frowns on regular PICK. Also, you have to be able to
> > pop the locals if the word exits through an exception. (LOCAL) had to
> > be added to the standard to allow that, since the VM has to handle the
> > unwinding in that situation.
> Meh. What Moore has stated in recent decades also has little to do with
> standard Forth.
>
> My point, which I should have stated explicitly, is that detractors of locals
> generally say that their use impedes factoring because items are
> not on the data stack. But often these same people have no issue
> with putting items on the return stack, which must also impede factoring
> for the same reason. Though I really don't subscribe to the impede
> factoring issue in either case.
>
> Frequently-used core-type words like 2swap should not use locals.
> In higher level problem specific words locals have a place in the code I write.
>
> That was fun. What next, a debate about blocks vs text files?

I'd suggest state-smartness. Seems to attract flies too.

Doug Hoffman <dhoffman888@gmail.com> writes:
>On Monday, October 31, 2022 at 4:40:09 AM UTC-4, the.bee...@gmail.com wrote:
>
>> > : 2swap ( x1 x2 x3 x4 -- x3 x4 x1 x2 )
>> > >r rot rot r> swap rot swap ;
>> Really?! Even my computer can do better!
>> rot >r rot r>
>
>Thanks for pointing that out Hans.
>VFX's optimizer lulled me into thinking that
>what I showed was efficient. My bad!

Let's see how VFX64 fares:

>r rot rot r> swap rot swap rot >r rot r> 2swap
PUSH RBX PUSH QWORD [RBP+08] MOV RDX, RBX
POP RDX POP RDX MOV RBX, [RBP+08]
MOV RBX, [RBP+08] MOV RCX, [RBP+10] MOV [RBP+08], RDX
MOV [RBP+08], RDX MOV RAX, [RBP] MOV RDX, [RBP+10]
MOV RDX, [RBP+10] MOV [RBP], RCX MOV RCX, [RBP]
MOV RCX, [RBP] MOV [RBP+10], RAX MOV [RBP], RDX
MOV [RBP], RDX MOV [RBP+08], RBX MOV [RBP+10], RCX
MOV [RBP+10], RCX MOV RBX, RDX RET/NEXT
RET/NEXT RET/NEXT 28 Bytes
27 bytes 29 Bytes

For comparison, lxf is analytical about the return stack and compiles
them all to the same code (21 bytes, but 32-bit code rather than
64-bit code):

>r rot rot r> swap rot swap rot >r rot r> 2swap
mov eax , [ebp+4h] mov eax , [ebp+4h] mov eax , [ebp+4h]
mov [ebp+4h] , ebx mov [ebp+4h] , ebx mov [ebp+4h] , ebx
mov ebx , eax mov ebx , eax mov ebx , eax
mov eax , [ebp+8h] mov eax , [ebp+8h] mov eax , [ebp+8h]
mov ecx , [ebp] mov ecx , [ebp] mov ecx , [ebp]
mov [ebp+8h] , ecx mov [ebp+8h] , ecx mov [ebp+8h] , ecx
mov [ebp] , eax mov [ebp] , eax mov [ebp] , eax
ret near ret near ret near

- 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 Monday, October 31, 2022 at 6:20:55 PM UTC+1, Anton Ertl wrote:
[..]
> Let's see how VFX64 fares:
>
> >r rot rot r> swap rot swap rot >r rot r> 2swap
[..]
> For comparison, lxf is analytical about the return stack and compiles
> them all to the same code (21 bytes, but 32-bit code rather than
> 64-bit code):
[..]
FORTH> : tt >r rot rot r> swap rot swap rot >r rot r> 2swap ; ok
FORTH> ' tt idis
$0133DC40 : tt
$0133DC4A pop rbx
$0133DC4B pop rdi
$0133DC4C pop rax
$0133DC4D pop rdx
$0133DC4E push rdi
$0133DC4F push rbx
$0133DC50 push rdx
$0133DC51 push rax
$0133DC52 ;
FORTH> : tt2 tt 2swap 2swap 2swap .S ; ok
FORTH> see tt2
Flags: ANSI
$0133DCC0 : tt2
$0133DCCA pop rbx
$0133DCCB pop rdi
$0133DCCC pop rax
$0133DCCD mov rdx, [rsp] qword
$0133DCD1 push rax
$0133DCD2 push rdi
$0133DCD3 push rbx
$0133DCD4 jmp .S+10 ( $012BEA0A ) offset NEAR
$0133DCD9 ;
FORTH> : tt3 1. 2. tt tt tt .S ; ok
FORTH> see tt3
Flags: ANSI
$0133DCC0 : tt3
$0133DCCA push 2 b#
$0133DCCC push 0 b#
$0133DCCE push 1 b#
$0133DCD0 push 0 b#
$0133DCD2 jmp .S+10 ( $012BEA0A ) offset NEAR
$0133DCD7 ;

-marcel

On Monday, 31 October 2022 at 18:20:55 UTC+1, Anton Ertl wrote:
> Doug Hoffman <dhoff...@gmail.com> writes:
> >On Monday, October 31, 2022 at 4:40:09 AM UTC-4, the.bee...@gmail.com wrote:
> >
> >> > : 2swap ( x1 x2 x3 x4 -- x3 x4 x1 x2 )
> >> > >r rot rot r> swap rot swap ;
> >> Really?! Even my computer can do better!
> >> rot >r rot r>
> >
> >Thanks for pointing that out Hans.
> >VFX's optimizer lulled me into thinking that
> >what I showed was efficient. My bad!
> Let's see how VFX64 fares:
>
> >r rot rot r> swap rot swap rot >r rot r> 2swap
> PUSH RBX PUSH QWORD [RBP+08] MOV RDX, RBX
> POP RDX POP RDX MOV RBX, [RBP+08]
> MOV RBX, [RBP+08] MOV RCX, [RBP+10] MOV [RBP+08], RDX
> MOV [RBP+08], RDX MOV RAX, [RBP] MOV RDX, [RBP+10]
> MOV RDX, [RBP+10] MOV [RBP], RCX MOV RCX, [RBP]
> MOV RCX, [RBP] MOV [RBP+10], RAX MOV [RBP], RDX
> MOV [RBP], RDX MOV [RBP+08], RBX MOV [RBP+10], RCX
> MOV [RBP+10], RCX MOV RBX, RDX RET/NEXT
> RET/NEXT RET/NEXT 28 Bytes
> 27 bytes 29 Bytes
>
> For comparison, lxf is analytical about the return stack and compiles
> them all to the same code (21 bytes, but 32-bit code rather than
> 64-bit code):
>
> >r rot rot r> swap rot swap rot >r rot r> 2swap
> mov eax , [ebp+4h] mov eax , [ebp+4h] mov eax , [ebp+4h]
> mov [ebp+4h] , ebx mov [ebp+4h] , ebx mov [ebp+4h] , ebx
> mov ebx , eax mov ebx , eax mov ebx , eax
> mov eax , [ebp+8h] mov eax , [ebp+8h] mov eax , [ebp+8h]
> mov ecx , [ebp] mov ecx , [ebp] mov ecx , [ebp]
> mov [ebp+8h] , ecx mov [ebp+8h] , ecx mov [ebp+8h] , ecx
> mov [ebp] , eax mov [ebp] , eax mov [ebp] , eax
> ret near ret near ret near

Also the locals version will produce the same code!

: s2 {: a b c d -- c d a b :} c d a b ; ok
see s2
A4A5D4 409CB2 21 C80000 5 normal S2

409CB2 8B4504 mov eax , [ebp+4h]
409CB5 895D04 mov [ebp+4h] , ebx
409CB8 8BD8 mov ebx , eax
409CBA 8B4508 mov eax , [ebp+8h]
409CBD 8B4D00 mov ecx , [ebp]
409CC0 894D08 mov [ebp+8h] , ecx
409CC3 894500 mov [ebp] , eax
409CC6 C3 ret near
ok

Peter

> - 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 Monday, October 31, 2022 at 6:45:25 PM UTC+1, P Falth wrote:
[..]
> Also the locals version will produce the same code!
>
> : s2 {: a b c d -- c d a b :} c d a b ; ok
> see s2
> A4A5D4 409CB2 21 C80000 5 normal S2
>
> 409CB2 8B4504 mov eax , [ebp+4h]
> 409CB5 895D04 mov [ebp+4h] , ebx
> 409CB8 8BD8 mov ebx , eax
> 409CBA 8B4508 mov eax , [ebp+8h]
> 409CBD 8B4D00 mov ecx , [ebp]
> 409CC0 894D08 mov [ebp+8h] , ecx
> 409CC3 894500 mov [ebp] , eax
> 409CC6 C3 ret near

In this particular case I can match that (but not in general).

FORTH> : s2 params| a b c d | c d a b ; ok
FORTH> see s2
Flags: TOKENIZE, ANSI
: s2 (4)PARAMS %c %d %a %b ; ok
FORTH> ' s2 idis
$0133E080 : s2
$0133E08A pop rbx
$0133E08B pop rdi
$0133E08C pop rax
$0133E08D pop rdx
$0133E08E push rdi
$0133E08F push rbx
$0133E090 push rdx
$0133E091 push rax
$0133E092 ;
FORTH> : test 1 2 3 4 s2 .S ; ok
FORTH> see test
Flags: ANSI
$0133E100 : test
$0133E10A push 3 b#
$0133E10C push 4 b#
$0133E10E push 1 b#
$0133E110 push 2 b#
$0133E112 jmp .S+10 ( $012BEA0A ) offset NEAR

-marcel

On 1/11/2022 2:30 am, Doug Hoffman wrote:
>
> What Moore has stated in recent decades also has little to do with
> standard Forth.

He did say the latter "did not describe Forth, but a language with the
same name"! Not sure 'language' is even appropriate - 'unrealized ideal'
would be closer. One would be hard pressed to find a language as drawn-out
and divisive as 'Standard Forth' (any incarnation). If anyone is writing
applications 'in Forth', it's because they've stopped pursuing 'the vision
splendid', accepted what they have, and the short time in which they have
to do it.

On 1/11/2022 2:30 am, Doug Hoffman wrote:
>
> My point, which I should have stated explicitly, is that detractors of locals
> generally say that their use impedes factoring because items are
> not on the data stack. But often these same people have no issue
> with putting items on the return stack, which must also impede factoring
> for the same reason.

'These same people' are judicious in their use of return stack. They don't
have so many items that they need to name them, or require the system to
manage it for them :)

On Monday, October 31, 2022 at 11:46:55 PM UTC-4, dxforth wrote:

> 'These same people' are judicious in their use of return stack. They don't
> have so many items that they need to name them, or require the system to
> manage it for them :)

Yes. As it should be. I'm a habitual user of the return stack when it is all
I need (as opposed to resorting to locals). Very handy and efficient.

-Doug

Paul Rubin <no.email@nospam.invalid> wrote:
> dxforth <dxforth@gmail.com> writes:
> > It appears he [Moore] found them superfluous:
> > "The words that manipulate that stack are DUP, DROP and OVER
> > period. There's no ..., well SWAP is very convenient and you want it,
> > but it isn't a machine instruction. But no PICK no ROLL, none of the
> > complex operators to let you index down into the stack."
>
> PICK and ROLL have to have come from somewhere: if it wasn't Moore, then
> who? And what about ROT, -ROT, >R, and R>?
>
> I get that Moore used VARIABLEs for everything that I'd use locals for.
> He also used CODE when Forth got in the way too much.
>
> Back in the 1970s, computers were limited, programs were necessarily
> small, and Moore espoused rewriting programs from the ground up instead
> of maintaining them. The main problem facing programmers was how to
> make their program implement behaviour X, for whatever X happened to be
> that day. They'd put a lot of effort into coding and testing X, and
> then they were done.
>
> Today, the main problem facing programmers is ensuring the absence of
> behaviours rather than their presence. Writing code is way easier than
> it used to be, because tools are better and computers are faster. But
> maintaining is harder since programs are bigger and have more people
> hacking at them. If you use a VARIABLE to save a temporary value used
> by a word, then anyone modifying that word, when they see that variable,
> now has to check that no other word uses the variable and depends on it
> for communication. Or worse, communicates through the memory cell
> occupied by that variable but through some sneaky alias. VALUE avoids
> aliasing (no idea whether Moore used them), but locals make both issues
> go away.
>
> Finally, while I can't doubt Moore's genius, I've never understood the
> vision that says the pure stack VM fits every programming problem.
> Register allocation and spilling is one of the messier parts of
> traditional compilers even when there are plenty of registers that don't
> have weird special purposes. In Forth, there are only 3 or so
> "registers" (T, N, and R), and each is special. Why be so vehement that
> a human rather than a machine should be juggling them? I can understand
> taht locals (if supported) complicate the traditional threaded Forth
> interpreter,

I think thatsome voices here vastly overestimate extra complexity.
AFAICS at runtime it is enough to have bunch of extra primitives:
add and subtract from return stack pointer (could be single primitive)
and two primitives fpr each local, one for reading, the other for
storing. If one sticks to standard limit of 16 locals that is 33
primitives. And they are very simple, one or two machine instructions
for real work (plus whatever boilerplate is needed for dispatch).

At compile time main effort is to add new transient part to dictionary.
One needs to decide where to put it. With standard restriction
of local declarations fitting on single line one could use a fixed
size area of order 120-200 bytes. One needs to modify search for
words to look there before main dictionary. And of course one needs
parsing word to recognize locals.

Together that adds some bulk, probably around 500-1000 bytes to
code space and say extra 200 bytes during compile, but I do not
think it is really complication.

> but I don't know how much Moore valued that. I know he did
> like stack hardware (his many Forth chips) but that came later.
>
> So the pure "stack plus VARIABLEs" seems "not even wrong" to me. I
> don't understand the motivation behind it well enough to disagree per
> se. And I've never seen an explanation that made sense. They have all
> seemed like grasping at straws.
>

--
Waldek Hebisch

On 1/11/2022 10:44 pm, Doug Hoffman wrote:
> On Monday, October 31, 2022 at 11:46:55 PM UTC-4, dxforth wrote:
>
>> 'These same people' are judicious in their use of return stack. They don't
>> have so many items that they need to name them, or require the system to
>> manage it for them :)
>
> Yes. As it should be. I'm a habitual user of the return stack when it is all
> I need (as opposed to resorting to locals). Very handy and efficient.

Are you saying Forth is inadequate - or that it's your choice to extend it
with locals? If Forth is inadequate it would mean I've wasted 40 years on
a bum steer. Locals users too.

On Tuesday, November 1, 2022 at 2:19:21 PM UTC+1, anti...@math.uni.wroc.pl wrote:
[..]
> I think thatsome voices here vastly overestimate extra complexity.
> AFAICS at runtime it is enough to have bunch of extra primitives:
> add and subtract from return stack pointer (could be single primitive)
> and two primitives fpr each local, one for reading, the other for
> storing. If one sticks to standard limit of 16 locals that is 33
> primitives. And they are very simple, one or two machine instructions
> for real work (plus whatever boilerplate is needed for dispatch).

Aren't you forgetting what happens when you call a word that also
uses locals? What about recursion? What happens when bot locals
and the R-stack are used?
>
> At compile time main effort is to add new transient part to dictionary.
[..]

Complexity depends on simply *implementing* locals versus *optimizing* them.
The former is indeed trivially simple.

Another problem: what to do with SEE ?

-marcel

Marcel Hendrix <mhx@iae.nl> writes:
>On Tuesday, November 1, 2022 at 2:19:21 PM UTC+1, anti...@math.uni.wroc.pl wrote:
>[..]
>> I think thatsome voices here vastly overestimate extra complexity.
>> AFAICS at runtime it is enough to have bunch of extra primitives:
>> add and subtract from return stack pointer (could be single primitive)
>> and two primitives fpr each local, one for reading, the other for
>> storing. If one sticks to standard limit of 16 locals that is 33
>> primitives. And they are very simple, one or two machine instructions
>> for real work (plus whatever boilerplate is needed for dispatch).

Actually, you need only one primitive with an immediate argument N for
reading local N and one primitive with an immediate argument M for
writing local M.

>Aren't you forgetting what happens when you call a word that also
>uses locals? What about recursion?

The locals are on the return stack in his model (like in many
systems), so calls to other words with locals are covered, including
recursion.

>What happens when bot locals
>and the R-stack are used?

The standard has restrictions on mixing that. I think if he wants
minimal complexity, he will also impose these restrictions in programs
on his system (like many systems with locals on the return stack do).

>Another problem: what to do with SEE ?

Most native-code systems show the native code in disassembled form, so
apparently it's not that important that the result of SEE is similar
to the source code. If you want to see that source code, use LOCATE.
In Gforth, SEE shows you the primitives for code generated for locals.
E.g.:

: my2swap {: a b c d :} c d a b ; ok
see my2swap
: my2swap
>l >l >l >l @local2 @local3 @local0 @local1 lp+!# 32 ; ok

- 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

anti...@math.uni.wroc.pl schrieb am Dienstag, 1. November 2022 um 14:19:21 UTC+1:
> Paul Rubin <no.e...@nospam.invalid> wrote:
> > dxforth <dxf...@gmail.com> writes:
> > > It appears he [Moore] found them superfluous:
> > > "The words that manipulate that stack are DUP, DROP and OVER
> > > period. There's no ..., well SWAP is very convenient and you want it,
> > > but it isn't a machine instruction. But no PICK no ROLL, none of the
> > > complex operators to let you index down into the stack."
> >
> > PICK and ROLL have to have come from somewhere: if it wasn't Moore, then
> > who? And what about ROT, -ROT, >R, and R>?
> >
> > I get that Moore used VARIABLEs for everything that I'd use locals for.
> > He also used CODE when Forth got in the way too much.
> >
> > Back in the 1970s, computers were limited, programs were necessarily
> > small, and Moore espoused rewriting programs from the ground up instead
> > of maintaining them. The main problem facing programmers was how to
> > make their program implement behaviour X, for whatever X happened to be
> > that day. They'd put a lot of effort into coding and testing X, and
> > then they were done.
> >
> > Today, the main problem facing programmers is ensuring the absence of
> > behaviours rather than their presence. Writing code is way easier than
> > it used to be, because tools are better and computers are faster. But
> > maintaining is harder since programs are bigger and have more people
> > hacking at them. If you use a VARIABLE to save a temporary value used
> > by a word, then anyone modifying that word, when they see that variable,
> > now has to check that no other word uses the variable and depends on it
> > for communication. Or worse, communicates through the memory cell
> > occupied by that variable but through some sneaky alias. VALUE avoids
> > aliasing (no idea whether Moore used them), but locals make both issues
> > go away.
> >
> > Finally, while I can't doubt Moore's genius, I've never understood the
> > vision that says the pure stack VM fits every programming problem.
> > Register allocation and spilling is one of the messier parts of
> > traditional compilers even when there are plenty of registers that don't
> > have weird special purposes. In Forth, there are only 3 or so
> > "registers" (T, N, and R), and each is special. Why be so vehement that
> > a human rather than a machine should be juggling them? I can understand
> > taht locals (if supported) complicate the traditional threaded Forth
> > interpreter,
> I think thatsome voices here vastly overestimate extra complexity.
> AFAICS at runtime it is enough to have bunch of extra primitives:
> add and subtract from return stack pointer (could be single primitive)
> and two primitives fpr each local, one for reading, the other for
> storing. If one sticks to standard limit of 16 locals that is 33
> primitives. And they are very simple, one or two machine instructions
> for real work (plus whatever boilerplate is needed for dispatch).
>
> At compile time main effort is to add new transient part to dictionary.
> One needs to decide where to put it. With standard restriction
> of local declarations fitting on single line one could use a fixed
> size area of order 120-200 bytes.

With locals declarations in one line you can parse the declarations twice
by resetting >in to {: after first encounter of :}. It makes the locals compiler
only slightly more complex.

Use the the first parsing stage to calculate the required locals frame size
in the return stack. Advantage: the next step for fp, buffer/strings, structure
locals is well prepared.

Locals are seldom worth the effort when one deals only with integers.

FWIW I found string locals very helpful in the past. Very often they can
release you from explicit buffer management or setting up a string stack.

On Tuesday, November 1, 2022 at 2:19:21 PM UTC+1, anti...@math.uni.wroc.pl wrote:
> I think that some voices here vastly overestimate extra complexity.
I did locals in my uBASIC interpreter - because it's BASIC - a Fortran
derivative - it's fitting. But it requires setting up and releasing a stack frame,
copying values there - that's a whole lot of overhead. For some ugly C-ism.
As if we didn't have enough of those in ANS Forth.

> AFAICS at runtime it is enough to have bunch of extra primitives:
> add and subtract from return stack pointer (could be single primitive)
> and two primitives fpr each local, one for reading, the other for
> storing. If one sticks to standard limit of 16 locals that is 33
> primitives. And they are very simple, one or two machine instructions
> for real work (plus whatever boilerplate is needed for dispatch).
33 primitives? And you call that "minor overhead"? My entire VM has about
100 primitives.

Hans Bezemer

On Tuesday, November 1, 2022 at 3:23:07 PM UTC+1, dxforth wrote:
> Are you saying Forth is inadequate - or that it's your choice to extend it
> with locals? If Forth is inadequate it would mean I've wasted 40 years on
> a bum steer. Locals users too.
True. Thinking about programming in a Forth way has significantly influenced my
C style. Now I need to go the opposite way: translating C to Forth, so I can
have loads of local variables - and write functions (not words) of five pages
without ever posing the question: "Do I really need those - or can I do something
clever to eradicate them?"

See: https://sourceforge.net/p/forth-4th/wiki/This%20is%20Forth/ and
https://sourceforge.net/p/forth-4th/wiki/Understand%20your%20algorithm/

Hans Bezemer

On Wednesday, November 2, 2022 at 7:04:58 AM UTC-4, the.bee...@gmail.com wrote:
> On Tuesday, November 1, 2022 at 3:23:07 PM UTC+1, dxforth wrote:
> > Are you saying Forth is inadequate - or that it's your choice to extend it
> > with locals? If Forth is inadequate it would mean I've wasted 40 years on
> > a bum steer. Locals users too.
> True. Thinking about programming in a Forth way has significantly influenced my
> C style. Now I need to go the opposite way: translating C to Forth, so I can
> have loads of local variables - and write functions (not words) of five pages
> without ever posing the question: "Do I really need those - or can I do something
> clever to eradicate them?"
>
> See: https://sourceforge.net/p/forth-4th/wiki/This%20is%20Forth/ and
> https://sourceforge.net/p/forth-4th/wiki/Understand%20your%20algorithm/
>
> Hans Bezemer

Off topic but ever since you started making videos I can't read your
written stuff without hearing your voice in my head. :-)))
(with the interesting "Nederlandse" accent of course)

dxforth <dxforth@gmail.com> writes:
> Oh, I'm not advocating variables - locals or otherwise. What I see is a lot
> of promiscuous use of the former as if there were no cost. Here's an example
> of using extra locals - not out of necessity - but 'style':
>
> https://gforth.org/manual/Locals-programming-style.html

In that example, there is some stuff in locals, but getting rid of the
locals would mean keeping the same stuff on the data stack (and maybe
partly the return stack). The total memory used is the same. In some
systems the return (or locals) stack might be too small, but if you're
going to use locals (or anything else) at all, obviously you want to
size the stacks to accomodate your usage.

> If anyone is writing applications 'in Forth', it's because they've
> stopped pursuing 'the vision splendid' ...

Heh, I like that expression. I had to look up its origin, a book from
1913 about some faction in the Anglican church. I will have to look at
the book one of these days. It's the vision itself that I've never
completely understood. I ought to read more of Dr. Ting's "Zen of
Forth" books, I suppose.

On 3/11/2022 9:26 am, Paul Rubin wrote:
> dxforth <dxforth@gmail.com> writes:
>> Oh, I'm not advocating variables - locals or otherwise. What I see is a lot
>> of promiscuous use of the former as if there were no cost. Here's an example
>> of using extra locals - not out of necessity - but 'style':
>>
>> https://gforth.org/manual/Locals-programming-style.html
>
> In that example, there is some stuff in locals, but getting rid of the
> locals would mean keeping the same stuff on the data stack (and maybe
> partly the return stack). The total memory used is the same. In some
> systems the return (or locals) stack might be too small, but if you're
> going to use locals (or anything else) at all, obviously you want to
> size the stacks to accomodate your usage.

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) but I doubt it's
Moore's. But back to your comment. You argue the same resources are
being spent (albeit differently apportioned) so it really doesn't matter
whether one is using locals or stack operators. I suspect you are not
alone. But what are implications of using locals in Forth? It's this:
A stack-based language that cannot exist without the help of locals has
failed and therefore does not deserve to exist.

Marcel Hendrix <mhx@iae.nl> wrote:
> On Tuesday, November 1, 2022 at 2:19:21 PM UTC+1, anti...@math.uni.wroc.pl wrote:
> [..]
> > I think thatsome voices here vastly overestimate extra complexity.
> > AFAICS at runtime it is enough to have bunch of extra primitives:
> > add and subtract from return stack pointer (could be single primitive)
> > and two primitives fpr each local, one for reading, the other for
> > storing. If one sticks to standard limit of 16 locals that is 33
> > primitives. And they are very simple, one or two machine instructions
> > for real work (plus whatever boilerplate is needed for dispatch).
>
> Aren't you forgetting what happens when you call a word that also
> uses locals? What about recursion? What happens when bot locals
> and the R-stack are used?

Anton answered this.

> >
> > At compile time main effort is to add new transient part to dictionary.
> [..]
>
> Complexity depends on simply *implementing* locals versus *optimizing* them.
> The former is indeed trivially simple.

I have spent some time working on "optimizing" codegen for two stack
VM with locals. I mean input was sequence of Forth-like operations
and codegen produced machine code. AFAICS result was worse than
your Forth. But offender were not locals. In fact, careful
use of local gave best code. One trouble was insufficient stack
tracking, sometimes items were forced on data stack not because
they had to be there, but only because codegen was unable to
track them. Another trouble was too naive register allocator, which
did not do well with temporaries. But if you had small number
of locals it would put them all in registers. And if all temporaries
were immediately put into locals, then computation could do work
in registers and you would get resonably good code. In other
words, one could use locals to tell compiler which things should
go into registers.

If you say that optimizing locals in _your_ Forth takes substantial
effort, then I belive. I know in principle how to write better
register allocator and do not think it is very hard. But existing
code was micro-optimized in many places and is hard to modify.

So, this is not absolute difficulty of solving problem, but rather
trouble with modifying existing program (plus limited time that
I could spent on this). But with different compiler structure
or when starting anew I could do better. And I _know_ that one
can generate pretty efficient code for locals in rather simple
compiler.

--
Waldek Hebisch