Paul Rubin <no.email@nospam.invalid> writes:
>Doug Hoffman <dhoffman888@gmail.com> writes:
>> This always reminds me of the old blocks vs text files debate.
>
>I wasn't around for that but I think blocks have mostly faded away by
>now. Did they really have staunch proponents?

The topic managed to get into the "Flame baits" category of the FAQ:

http://www.complang.tuwien.ac.at/forth/faq/faq-general-4.html#ss4.3

>Was there a similar
>debate over 3+length vs. storing the whole name in the dictionary?

Not on comp.lang.forth ever since I read it first in ~1988. There is
the article by Chuck Moore in Forth Dimensions where he argued for
3+length. In a way, you see a bit of that still in colorForth, which
stores only as much of a name as fits in a fixed number of bits (but
using a variable-length encoding for characters).

It seems to me that both topics have to do with the technological
environment (native vs. hosted systems for blocks vs. files; RAM size
for 3+length), and when that changed, the preferences changed, and the
discussions were the transition pains.

>I wonder if the
>absence of locals in early Forth was something like the 3+length
>dictionary, i.e. an artifact of memory being scarce in those days.

To some extent, it is. But the 3+length discussion has been over for
more than three decades, while the locals discussion is still alive.
I think the reason is that full-length names mainly cost RAM, which
has become cheaper over time, while locals also (or mainly?) cost
implementation effort and Forth system complexity, which does not
become cheaper over time.

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

On 9/3/21 6:05 AM, Anton Ertl wrote:
> Paul Rubin <no.email@nospam.invalid> writes:
>> Doug Hoffman <dhoffman888@gmail.com> writes:
>>> This always reminds me of the old blocks vs text files debate.
>>
>> I wasn't around for that but I think blocks have mostly faded away by
>> now. Did they really have staunch proponents?

Yes, and they still do. There is valid logic to using blocks files: They
discourage long definitions so short, well factored definitions tend to
get used. This is not a bad thing. My first Forth was blocks files only
and I found using blocks to be not a big problem though I switched to
text files when I could. I think today it's primarily a matter of
personal preference. But since this is on a FAQ "flame bait" list I have
already violated what that list tries to do. So I'll say no more.

> The topic managed to get into the "Flame baits" category of the FAQ:
>
> http://www.complang.tuwien.ac.at/forth/faq/faq-general-4.html#ss4.3

> ... while locals also (or mainly?) cost implementation effort and
> Forth system complexity, which does not become cheaper over time.
The implementation effort and complexity was and never will be an issue
for me since I don't implement a Forth and never will. The "flame bait"
FAQ lists the ordering as the reason for locals controversy. While
perhaps true at one time, I think the locals use controversy goes deeper
than that. I see locals as just another tool. Use them to solve certain
problems but don't over use them. Again, not wanting to be a flame
baiter I'll leave it at that.

-Doug

Doug Hoffman <dhoffman888@gmail.com> writes:
>The "flame bait"
>FAQ lists the ordering as the reason for locals controversy.

The ordering has been resolved with the acceptance of {: ... :}.
There are a few who use (prefer?) the LOCALS| ordering, but most
prefer the {: ordering, and there have not been flame wars about that
in recent years.

>While
>perhaps true at one time, I think the locals use controversy goes deeper
>than that.

Yes. It's interesting that it's not mentioned in the Flame baits part
of the FAQ. Apparently it was not a common flame bait topic when the
FAQ was written. Maybe I should update that part, but then, who reads
the FAQ these days?

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

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
> I think the reason is that full-length names mainly cost RAM, which
> has become cheaper over time, while locals also (or mainly?) cost
> implementation effort and Forth system complexity, which does not
> become cheaper over time.

I dunno, the big Forths like Swift don't particularly skimp to avoid
complexity per se, but their devs seem to frown on locals even though
the implementation supports them.

The sentiment I see (I don't understand it so may be describing it
wrong) is more like: the Forth with its dual stack model is a wonderful
discovery, so anything that makes the dual stack model look less
wonderful must be heresy.

I'm not sure I even see the dual stack model as essential to Forth.
Maybe it would be fine to get rid of >r and r> if there are locals.

Here is another awful possible syntax:

5 >: FOO

would be like 5 TO FOO except FOO would be a local, instantiated by >:
if it hadn't already been in that word. The : in >: denotes that it is
(temporarily) defining a word. That is more in the spirit of scripting
languages that let you create variables without having to declare them.

On 4/09/2021 04:09, Paul Rubin wrote:
>
> Maybe it would be fine to get rid of >r and r> if there are locals.

That's but one step short of asking why have stacks or Forth at all.
So let's ask it. What is your reason for wanting to know Forth - one
more language under the belt - or something else?

dxforth <dxforth@gmail.com> writes:
> That's but one step short of asking why have stacks or Forth at all.

It's reasonable to separate those two questions I think. Can we have
stacks without Forth? Yes, PostScript etc. Can we have Forth without
stacks? That I suppose depends on your notion of what Forth is.

I think it is ok to want Forth while questioning stacks, even though I
don't have the answers.

> So let's ask it. What is your reason for wanting to know Forth - one
> more language under the belt - or something else?

I like the sense of KISS in Forth. I'm unconvinced that locals
seriously interfere with it. They make the user code simpler, which
seems KISS to me. I've written functions with locals that I don't see a
clean way to write without them.

On 4/09/2021 16:08, Paul Rubin wrote:
> dxforth <dxforth@gmail.com> writes:
>> That's but one step short of asking why have stacks or Forth at all.
>
> It's reasonable to separate those two questions I think. Can we have
> stacks without Forth? Yes, PostScript etc. Can we have Forth without
> stacks? That I suppose depends on your notion of what Forth is.
>
> I think it is ok to want Forth while questioning stacks, even though I
> don't have the answers.
>
>> So let's ask it. What is your reason for wanting to know Forth - one
>> more language under the belt - or something else?
>
> I like the sense of KISS in Forth. I'm unconvinced that locals
> seriously interfere with it. They make the user code simpler, which
> seems KISS to me. I've written functions with locals that I don't see a
> clean way to write without them.
>

Then it's a different Forth and notion of KISS from Moore's who has
condemned locals. Far from bemoaning Forth's lack of locals, I find
it both interesting and challenging to find alternate ways of doing
things that make them redundant.

dxforth <dxforth@gmail.com> writes:
> Far from bemoaning Forth's lack of locals, I find it both interesting
> and challenging to find alternate ways of doing things that make them
> redundant.

But I thought the idea of a compiler was to simplify your coding task,
not make it more challenging. Doesn't designing a program present
enough high level challenges that we don't need the language's help in
making the low level parts challenging too?

I haven't understood Moore's objection to locals, but I gather he also
liked 3+length dictionary representation and maybe blocks.

I confess that I also find the idea of blocks pretty cool, maybe because
I've never actually used them.

On Saturday, September 4, 2021 at 8:08:15 AM UTC+2, Paul Rubin wrote:
Yes, locals interfere with Forth. So far, I only used them in ports and example code. They slow things down by extending function call overhead.

And get it in your head: a stack is NOT array. For that reason I don't like pick and roll either. And yes, functions with lots of parameters are hard to implement - but that's it - work harder to get it right.

If you don't like Forth - that's alright. Go Lua or Python. Lots of alternatives. But don't bother people who do know how to write Forth with ridiculous 'proposals'.

Hans Bezemer

> dxforth <dxf...@gmail.com> writes:
> > That's but one step short of asking why have stacks or Forth at all.
> It's reasonable to separate those two questions I think. Can we have
> stacks without Forth? Yes, PostScript etc. Can we have Forth without
> stacks? That I suppose depends on your notion of what Forth is.
>
> I think it is ok to want Forth while questioning stacks, even though I
> don't have the answers.
> > So let's ask it. What is your reason for wanting to know Forth - one
> > more language under the belt - or something else?
> I like the sense of KISS in Forth. I'm unconvinced that locals
> seriously interfere with it. They make the user code simpler, which
> seems KISS to me. I've written functions with locals that I don't see a
> clean way to write without them.

On Saturday, September 4, 2021 at 3:09:42 PM UTC-7, the.bee...@gmail.com wrote:
> On Saturday, September 4, 2021 at 8:08:15 AM UTC+2, Paul Rubin wrote:
> Yes, locals interfere with Forth. So far, I only used them in ports and example code.
> They slow things down by extending function call overhead.
>
> And get it in your head: a stack is NOT array. For that reason I don't like pick and roll either.
> And yes, functions with lots of parameters are hard to implement - but that's it - work harder to get it right.

Work harder, not smarter!

> If you don't like Forth - that's alright. Go Lua or Python. Lots of alternatives.
> But don't bother people who do know how to write Forth with ridiculous 'proposals'.

My rquotations assume the use of locals in the parent function, and that the rquotation
will communicate information back to the parent function in these locals, despite
the fact that the HOF that the parent function called and which is executing the rquotation
has locals of its own.

Do my rquotations prove that I don't know how to write Forth?

I have yet to find anybody on comp.lang.forth who understands the concept of
general-purpose data-structures. Do you? Can you explain this concept?

On 5/09/2021 08:40, Hugh Aguilar wrote:
>
> I have yet to find anybody on comp.lang.forth who understands the concept of
> general-purpose data-structures. Do you? Can you explain this concept?

General-purpose data-structures implies lots of parameter passing which
necessitates locals. Did I get it right?

Hans Bezemer <the.beez.speaks@gmail.com> writes:
> If you don't like Forth - that's alright. Go Lua or Python.

Processor is an ATTiny with maybe 1KB of available code memory and a few
hundred B of available ram. Forth seems about right for that.

In the early Forth era, ram and cpu cycles were both scarce, and
programs and data were both in ram (maybe loaded from blocks) so they
competed for space. Today, code is in flash so it doesn't exactly
compete with data, ram in small machines is maybe even more scarce than
before, flash tends to be less scarce than ram, and CPU cycles are
relatively plentiful (8 Mhz AVR is probably faster than most 1970s
minicomputers).

The drawback of locals that you mentioned (that they slow things down)
therefore now seems like a good trade, if they make the program smaller
and decrease ram use (program uses locals on R stack instead of more
VARIABLEs permanently occupying ram), at the cost of some CPU cycles.

On 5/09/2021 13:44, Paul Rubin wrote:
>
> The drawback of locals that you mentioned (that they slow things down)
> therefore now seems like a good trade, if they make the program smaller
> and decrease ram use (program uses locals on R stack instead of more
> VARIABLEs permanently occupying ram), at the cost of some CPU cycles.

But do they? Locals quickly chew up Rstack as one locals-based function
calls another. Even if temporary, locals are likely to use more memory
than corresponding stack operations. In an application whose source code
you have seen, I count:

153 colon definitions
19 constants
9 values
3 variables
0 locals

Of these, only two variables and one value might be considered 'temporary'.
If I used them, it's because they saved me bother and memory.

dxforth <dxforth@gmail.com> writes:
> In an application whose source code you have seen, I count: 153 colon
> definitions... only two variables and one value might be considered
> 'temporary'. If I used them, it's because they saved me bother and
> memory.

Hmm, which application is that? I guess that is fewer temp variables
than I would have expected. I think Chuck Moore's style was to use
variables rather freely, to avoid excessive stack juggling. Of course
it's sometimes possible to use the same variable for multiple purposes,
sort of like register allocation, but I figure that's asking for
trouble.

You may be onto something about R stack consumption. I was planning on
16 cells for each of D and R, but maybe I need more. I think it will be
ok though. Anyway, non-locals programs also save things in the R stack,
though maybe not as much.

On Saturday, September 4, 2021 at 8:08:15 AM UTC+2, Paul Rubin wrote:
> dxforth <dxf...@gmail.com> writes:
> > That's but one step short of asking why have stacks or Forth at all.
> It's reasonable to separate those two questions I think. Can we have
> stacks without Forth? Yes, PostScript etc. Can we have Forth without
> stacks? That I suppose depends on your notion of what Forth is.

The assertion is not correct. Could I turn Postscript into Forth (only
using Postscript)? No (because this is too vague). Could I add
stacks to a Forth without stacks? Of course, but here the problem
is to get that Forth to use these stack(s) where we expect a real Forth
to use them. In order to do that we need knowledge how that
'Forth' gets rid of the stack(s) in the first place. If it's mechanism
is " a @ b @ + c ! c@ " it should be relatively easy.

-marcel

On Saturday, September 4, 2021 at 8:08:15 AM UTC+2, Paul Rubin wrote:
> dxforth <dxf...@gmail.com> writes:
> > That's but one step short of asking why have stacks or Forth at all.
> It's reasonable to separate those two questions I think. Can we have
> stacks without Forth? Yes, PostScript etc. Can we have Forth without
> stacks? That I suppose depends on your notion of what Forth is.

The assertion is not correct. Could I turn Postscript into Forth (only
using Postscript)? No (because this is too vague). Could I add
stacks to a Forth without stacks? Of course, but here the problem
is to get that Forth to use these stack(s) where we expect a real Forth
to use them. In order to do that we need knowledge how that
'Forth' gets rid of the stack(s) in the first place. If its mechanism
is "a @ b @ + c ! c@" it should be relatively easy.

-marcel

On 5/09/2021 17:34, Paul Rubin wrote:
> dxforth <dxforth@gmail.com> writes:
>> In an application whose source code you have seen, I count: 153 colon
>> definitions... only two variables and one value might be considered
>> 'temporary'. If I used them, it's because they saved me bother and
>> memory.
>
> Hmm, which application is that?

https://pastebin.com/Uv2EE4sn

> I guess that is fewer temp variables
> than I would have expected.

The three I picked as being 'local' are #DIGIT LEN MAXCHR. Others may
categorize them differently.

Paul Rubin <no.email@nospam.invalid> writes:
>anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>> I think the reason is that full-length names mainly cost RAM, which
>> has become cheaper over time, while locals also (or mainly?) cost
>> implementation effort and Forth system complexity, which does not
>> become cheaper over time.
>
>I dunno, the big Forths like Swift don't particularly skimp to avoid
>complexity per se,

If you mean SwiftForth, that in particular seems to be designed more
than other big Forth systems for avoiding complexity.

>but their devs seem to frown on locals even though
>the implementation supports them.
>
>The sentiment I see (I don't understand it so may be describing it
>wrong) is more like: the Forth with its dual stack model is a wonderful
>discovery, so anything that makes the dual stack model look less
>wonderful must be heresy.

Yes, there could be something to that, too.

Speculation: They dug themselves into a position that locals are not
needed. Customer demand finally overran this position, but they are
still in its trenches.

>I'm not sure I even see the dual stack model as essential to Forth.
>Maybe it would be fine to get rid of >r and r> if there are locals.

The dual-stack model is essential. You cannot pass parameters and
return values on the data stack if the return address is on the data
stack. Well, ok, you could, but it would make Forth really cumbersome.

: 1+ swap 1 + swap ;

As for >R and R>, they certainly bring with themselves all the same
factoring restrictions as locals, so if locals are to be shunned
because of factoring, so should >R and R>. However, the data stack
alone is cumbersome if too many stack items are alive at the same
time, and >R and R> are an easily-implemented relief in that
situation.

Once you have locals and can define them anywhere in a definition (as
you can in Gforth), I see no benefit in using >R and R>.

>Here is another awful possible syntax:
>
> 5 >: FOO
>
>would be like 5 TO FOO except FOO would be a local, instantiated by >:
>if it hadn't already been in that word.

In Gforth you can define a local anywhere, with code like

5 {: foo :}

There have been suggestions that this should work like 5 TO FOO if FOO
has been defined already, but I like the static-single-assignment
behaviour of {: FOO :} (when you see a local, you just have to look
for its definition to know what value it has; at least as long as
nobody uses TO with that local), so I have no plans to go there. You
get a redefinition warning and another local if you define a local
with the same name as an existing local.

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

On Sunday, 5 September 2021 at 16:02:32 UTC+2, Anton Ertl wrote:
> Paul Rubin <no.e...@nospam.invalid> writes:
> >an...@mips.complang.tuwien.ac.at (Anton Ertl) writes:
> >> I think the reason is that full-length names mainly cost RAM, which
> >> has become cheaper over time, while locals also (or mainly?) cost
> >> implementation effort and Forth system complexity, which does not
> >> become cheaper over time.
> >
> >I dunno, the big Forths like Swift don't particularly skimp to avoid
> >complexity per se,
> If you mean SwiftForth, that in particular seems to be designed more
> than other big Forth systems for avoiding complexity.
> >but their devs seem to frown on locals even though
> >the implementation supports them.
> >
> >The sentiment I see (I don't understand it so may be describing it
> >wrong) is more like: the Forth with its dual stack model is a wonderful
> >discovery, so anything that makes the dual stack model look less
> >wonderful must be heresy.
> Yes, there could be something to that, too.
>
> Speculation: They dug themselves into a position that locals are not
> needed. Customer demand finally overran this position, but they are
> still in its trenches.
> >I'm not sure I even see the dual stack model as essential to Forth.
> >Maybe it would be fine to get rid of >r and r> if there are locals.
> The dual-stack model is essential. You cannot pass parameters and
> return values on the data stack if the return address is on the data
> stack. Well, ok, you could, but it would make Forth really cumbersome.
>
> : 1+ swap 1 + swap ;
>
> As for >R and R>, they certainly bring with themselves all the same
> factoring restrictions as locals, so if locals are to be shunned
> because of factoring, so should >R and R>. However, the data stack
> alone is cumbersome if too many stack items are alive at the same
> time, and >R and R> are an easily-implemented relief in that
> situation.
>
> Once you have locals and can define them anywhere in a definition (as
> you can in Gforth), I see no benefit in using >R and R>.
> >Here is another awful possible syntax:
> >
> > 5 >: FOO
> >
> >would be like 5 TO FOO except FOO would be a local, instantiated by >:
> >if it hadn't already been in that word.
> In Gforth you can define a local anywhere, with code like
>
> 5 {: foo :}
>
> There have been suggestions that this should work like 5 TO FOO if FOO
> has been defined already, but I like the static-single-assignment
> behaviour of {: FOO :} (when you see a local, you just have to look
> for its definition to know what value it has; at least as long as
> nobody uses TO with that local), so I have no plans to go there. You
> get a redefinition warning and another local if you define a local
> with the same name as an existing local.

How does it work at runtime when the definition is inside a loop?

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

P Falth <peter.m.falth@gmail.com> writes:
>On Sunday, 5 September 2021 at 16:02:32 UTC+2, Anton Ertl wrote:
>> In Gforth you can define a local anywhere, with code like
>>
>> 5 {: foo :}
>>
>> There have been suggestions that this should work like 5 TO FOO if FOO
>> has been defined already, but I like the static-single-assignment
>> behaviour of {: FOO :} (when you see a local, you just have to look
>> for its definition to know what value it has; at least as long as
>> nobody uses TO with that local), so I have no plans to go there. You
>> get a redefinition warning and another local if you define a local
>> with the same name as an existing local.
>
>How does it work at runtime when the definition is inside a loop?

Locals live in every place that can be reached by going through the
locals definition. This means that in

begin {: a :} while {: b :} repeat a . \ but b is is not visible

It also means that

do {: a :} loop a . \ this works

but

?do {: a :} loop \ a is not visible behind the loop

The compiler could reserve space for all the locals at the start of
the definition (and maybe update the reserved space by backpatching),
but in Gforth the locals definition pushes the locals it defines on
the locals stack; they are popped when they die.

: foo do i {: a :} loop a . ;

is compiled into

$7FD21C6BB030 (do)
$7FD21C6BB038 i
$7FD21C6BB040 >l
$7FD21C6BB048 (loop)-lp+!#
$7FD21C6BB050 <foo+$8>
$7FD21C6BB058 #8
$7FD21C6BB060 unloop
$7FD21C6BB068 @local0
$7FD21C6BB070 call
$7FD21C6BB078 <.>
$7FD21C6BB080 lp+
$7FD21C6BB088 ;s ok 4

The (loop)-lp+!# pops 8 bytes from the locals stack if the branch is
taken. For the fall-through case, the local is popped with the LP+
right before the ;S.

For more details, see:

@InProceedings{ertl94l,
author = "M. Anton Ertl",
title = "Automatic Scoping of Local Variables",
booktitle = "EuroForth~'94 Conference Proceedings",
year = "1994",
address = "Winchester, UK",
pages = "31--37",
url = "http://www.complang.tuwien.ac.at/papers/ertl94l.ps.gz",
abstract = "In the process of lifting the restrictions on using
locals in Forth, an interesting problem poses
itself: What does it mean if a local is defined in a
control structure? Where is the local visible? Since
the user can create every possible control structure
in ANS Forth, the answer is not as simple as it may
seem. Ideally, the local is visible at a place if
the control flow {\em must} pass through the
definition of the local to reach this place. This
paper discusses locals in general, the visibility
problem, its solution, the consequences and the
implementation as well as related programming style
questions."
}

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

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>>Maybe it would be fine to get rid of >r and r> if there are locals.
>
> The dual-stack model is essential. You cannot pass parameters and
> return values on the data stack if the return address is on the data
> stack.

I mean there would still be a return stack, just no >r and r> .

> Once you have locals and can define them anywhere in a definition (as
> you can in Gforth), I see no benefit in using >R and R>.

Yes, same idea.

On Saturday, September 4, 2021 at 8:35:03 PM UTC-7, dxforth wrote:
> On 5/09/2021 08:40, Hugh Aguilar wrote:
> >
> > I have yet to find anybody on comp.lang.forth who understands the concept of
> > general-purpose data-structures. Do you? Can you explain this concept?
> General-purpose data-structures implies lots of parameter passing which
> necessitates locals. Did I get it right?

No. You are not even close. You don't know what rquotations do,
and you don't know what a general-purpose data-structure is.

I haven't forgotten about how you mocked me by using the term "disambiguifier"
for some kindergarten-level code that you wrote.
You either don't know anything about that subject, or you were just acting stupid
for the purpose of annoying me.

Stop pestering me with idiotic nonsense --- I don't think that you know anything
about programming at all --- I don't want to hear anything further from you.

On Sunday, September 5, 2021 at 12:34:25 AM UTC-7, Paul Rubin wrote:
> I think Chuck Moore's style was to use
> variables rather freely, to avoid excessive stack juggling. Of course
> it's sometimes possible to use the same variable for multiple purposes,
> sort of like register allocation, but I figure that's asking for
> trouble.

Using global variables is ignorant programming. I don't do that.

Walter Banks has a C compiler that reuses local variables. He says that
he can prove that this takes the same memory as a local-stack would.
This is not difficult to implement. You have to compile an entire program
at once, and you keep track of which functions call which other functions,
and you make sure that a two functions in the same call-chain don't use
the same memory location for different local variables. A lot of compilers
do this. Turbo51 is an example, afaik. This is a good technique on a processor
such as the 8051 that has a direct addressing-mode but does not have an
indexed addressing-mode needed for a local-stack.

I was aware of this in 1994. When I hired on at Testra and was told that their
Dallas 80c320 motion-control program was too slow, I suggested that I write
a compiler for a Pascalish language that used this technique, so the direct
addressing-mode could be used rather than the Forth-style stack that is
grossly inefficient on the 8051. I was told that this wouldn't work because
most of the program had already been translated from Forth to assembly-language
and over 50% of the time was spent in ISRs, so the Forth stack was not
slowing the system down significantly. This could be done for Forth too,
using an analytic compiler, but it would kill interactive programming because
the entire program needs to be available for analysis, so not a good idea for Forth.

I wrote an assembler for the MSP430.
I could retarget this for the 8051 if there was a need for an 8051 program.
I would just stick with assembly-language on the 8051 though --- I wouldn't
use Forth --- on the MSP430 though, Forth should work well.

On 6/09/2021 09:47, Hugh Aguilar wrote:
> On Saturday, September 4, 2021 at 8:35:03 PM UTC-7, dxforth wrote:
>> On 5/09/2021 08:40, Hugh Aguilar wrote:
>> >
>> > I have yet to find anybody on comp.lang.forth who understands the concept of
>> > general-purpose data-structures. Do you? Can you explain this concept?
>> General-purpose data-structures implies lots of parameter passing which
>> necessitates locals. Did I get it right?
>
> No. You are not even close. You don't know what rquotations do,
> and you don't know what a general-purpose data-structure is.
>
> I haven't forgotten about how you mocked me by using the term "disambiguifier"
> for some kindergarten-level code that you wrote.
> You either don't know anything about that subject, or you were just acting stupid
> for the purpose of annoying me.

Disambiguifiers were aimed at kindergarten-level users to convince them
how broken was ANS, and by implication those behind it. So it's been
for your general-purpose code routines - thinly-veiled expositions on
how ANS got it wrong. In the meantime they do the opposite. One has
to travel a long way in Forth to get past the pro/anti-ANS lobby.

>
> Stop pestering me with idiotic nonsense --- I don't think that you know anything
> about programming at all --- I don't want to hear anything further from you.
>

On 5/09/2021 17:34, Paul Rubin wrote:
>
> I was planning on
> 16 cells for each of D and R, but maybe I need more. I think it will be
> ok though. Anyway, non-locals programs also save things in the R stack,
> though maybe not as much.

So you're creating a forth? Care to share some details - target cpu,
language used to implement etc.

Regarding stack sizes, Forth-83 nominated a minimum of 64/48 bytes (for 16b
system). When trying out a simple multi-tasking example on DX-Forth which
printed numbers to the screen, I assigned 128/64. Too much less and the
Rstack overflowed.

\\ Demo 1
variable SCREEN screen off #user dup user CNT 1 cells +
( u) dup 128 64 tcb DCOUNTING \ task1 control block
( u) 128 64 tcb HCOUNTING \ task2 control block

: DCOUNTER ( -- ) dcounting activate decimal 0 cnt !
begin screen get 0 2 at-xy cnt @ dup 0 10 d.r
1+ cnt ! screen release pause again ;

: HCOUNTER ( -- ) hcounting activate hex 0 cnt !
begin screen get 15 2 at-xy cnt @ dup 0 10 d.r
1- cnt ! screen release pause again ;

: RUN ( -- ) /tasker page ." 2 tasks counting:"
dcounter hcounter multi begin key? until key drop single ;
cr ." Save demo1? " y/n [if] turnkey run DEMO1 bye [then]