On 27/02/2023 5:40 am, Paul Rubin wrote:
> albert@cherry.(none) (albert) writes:
>> I can't wait to see a sensible application of multi-tasking on
>> a 2k RAM sbc. So I suspend disbelief till then.
>
> I thought it had already been done in 8051 class mcu's, e.g. with
> Chipforth. Maybe I'm wrong though.
>
> I know that eForth on the STM8 (1k of ram) supports multitasking because
> I played with it, but it only handles two tasks iirc.

There's a SwiftX for the Arduino. That's 32K flash and 2K ram.
SwiftX has an application stripper that weeds out unused code.
That should be enough flash for a serious application?

dxforth <dxforth@gmail.com> writes:
> There's a SwiftX for the Arduino. That's 32K flash and 2K ram.
> SwiftX has an application stripper that weeds out unused code.
> That should be enough flash for a serious application?

16K flash is enough, really. That's what newer lights that run this app
are using. I don't pick the cpus. But, I think the ATMega parts with
32K flash only come in larger packages. The 1616 is chosen because it
is available in a 3x3mm QFN if I have the terminology right.

On 27/02/2023 4:37 pm, Paul Rubin wrote:
> dxforth <dxforth@gmail.com> writes:
>> There's a SwiftX for the Arduino. That's 32K flash and 2K ram.
>> SwiftX has an application stripper that weeds out unused code.
>> That should be enough flash for a serious application?
>
> 16K flash is enough, really. That's what newer lights that run this app
> are using. I don't pick the cpus. But, I think the ATMega parts with
> 32K flash only come in larger packages. The 1616 is chosen because it
> is available in a 3x3mm QFN if I have the terminology right.

SwiftX-AVR supports a bunch of parts out of the box. Each comes with
its own config files and folder. I think (but not sure) users can
create a custom config for their particular part.

Elsewhere you mention ChipForth. Can't say I know anything about it.
Wasn't it a precursor to SwiftX ?

Paul Rubin <no.email@nospam.invalid> writes:
>anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>> If it does not have separate stacks, it's not coroutining.
>
>I thought so too, but the C++20 has taken issue with that, saying that
>if C++20 coroutines had separate stacks, they would be called fibers.
>That is apparently Microsoft-speak though.

C++20 is not the first programming-language standard that deviates
from established terminology and won't be the last. I have read
"fiber" rarely, IIRC with the meaning of user-level (aka green)
threads, and indeed,
<https://en.wikipedia.org/wiki/Fiber_(computer_science)> confirms my
memory.

The difference between user-level threads and coroutines is that
coroutines cooperate intimately, passing data from one to the other,
and calling each other directly (I see that
<https://en.wikipedia.org/wiki/Coroutine#Definition_and_Types> calls
this "symmetric coroutine"), while threads work mostly independently.

>> Albert van der Horst's CO.
>
>I'll see if I can find that. I have a copy of 4th downloaded, if that's
>the right place.

Unlikely. 4th is from Hans Bezemer.

>I mean the F18A (individual core of the GA144) has its own coroutine
>jump instruction. It swaps the top of the R stack with the current PC.
>CO is probably similar. In a threaded Forth, it can be done with
>R-stack manipulation, I suppose.

Yes, IIRC that's what CO does. So it would be something like

: CO 2r> swap 2>r ;

- 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:
> C++20 is not the first programming-language standard that deviates
> from established terminology and won't be the last.

There is a good paper about coroutines in Lua that classifies different
versions of coroutines and includes the stackless type under the
umbrella, but reserves the term "full" coroutines for stackful
coroutines that can be passed around as first class objects:

http://www.inf.puc-rio.br/~roberto/docs/MCC15-04.pdf

> Unlikely. 4th is from Hans Bezemer.

Oops, I got 4th confused with another implementation.

> Yes, IIRC that's what CO does. So it would be something like
> : CO 2r> swap 2>r ;

Yes that looks right, or pretty close.

dxforth <dxforth@gmail.com> writes:
> Elsewhere you mention ChipForth. Can't say I know anything about it.
> Wasn't it a precursor to SwiftX ?

I have also been looking for info but it looks like most is gone from
the web. Forth Inc. sold it for a while but I don't think it was
related to SwiftX. It was a tethered Forth for 8051 and comparable
MCU's whether the text interpreter was entirely on a host PC.

It came from this company in England, which is now closed down. Its web
site is partly online but much of the interesting stuff is 404:

https://www.computer-solutions.co.uk/chipdev/cf-space.htm

If anyone else has info I'd be interested to see it.

In article <871qmcs216.fsf@nightsong.com>,
Paul Rubin <no.email@nospam.invalid> wrote:
>albert@cherry.(none) (albert) writes:
>> I can't wait to see a sensible application of multi-tasking on
>> a 2k RAM sbc. So I suspend disbelief till then.
>
>I thought it had already been done in 8051 class mcu's, e.g. with
>Chipforth. Maybe I'm wrong though.
>
>I know that eForth on the STM8 (1k of ram) supports multitasking because
>I played with it, but it only handles two tasks iirc.
>
>I wonder if it is feasible to standardize a coroutine switch operation,
>or at least add it to gforth. So that gives very minimal multitasking,
>i.e. without separate stacks per task. Tiny processors like the GA144
>nodes implement it it in hardware. C++20 has something like it now, and
>there are some C header libraries like protothreads that implement it
>through preprocessor hacks. But it's not so easy to do in traditional
>Forth.

Coroutine words abound. I have dubbed it CO. Chuck Moore uses ;: .
In noforth (Ouwerkerk & Nijhof) it is called DIVE .

It is as simple as exchanging the current interpreter pointer
with the address to return to.

CODE CO
XCHG ESI,[EBP] ; xchg HIP,[RSP]
NEXT

This is useful (e.g. to use in combination with decorators) but
it doesn't amount to multi-tasking.

Groetjes Albert
--
Don't praise the day before the evening. One swallow doesn't make spring.
You must not say "hey" before you have crossed the bridge. Don't sell the
hide of the bear until you shot it. Better one bird in the hand than ten in
the air. First gain is a cat spinning. - the Wise from Antrim -

In article <87o7pgq7at.fsf@nightsong.com>,
Paul Rubin <no.email@nospam.invalid> wrote:
>anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>> If it does not have separate stacks, it's not coroutining.
>
>I thought so too, but the C++20 has taken issue with that, saying that
>if C++20 coroutines had separate stacks, they would be called fibers.
>That is apparently Microsoft-speak though.

Anton Ertl has the tendency to accept only meanings of terms
customary in his environment. I tend to accept the interpretation
of Microsoft, of Knuth.

>
>> Albert van der Horst's CO.
>
>I'll see if I can find that. I have a copy of 4th downloaded, if that's
>the right place.

The right place to look is
https://forth.hcc.nl/producten/ciforth.html
It makes no difference what you download. Each archive comes with full
assembler source (and documentation of the kernel, and a source
library.) CO is defined in assembly, so pick a processor where you're
familiar with.

>
>>>Tiny processors like the GA144 nodes implement it it in hardware.
>> The cores of the GA144 have separate stacks, and they actually
>> genuinely run in parallel, unlike coroutines.
>
>I mean the F18A (individual core of the GA144) has its own coroutine
>jump instruction. It swaps the top of the R stack with the current PC.
>CO is probably similar. In a threaded Forth, it can be done with
>R-stack manipulation, I suppose.

You're so right. It is R-stack manipulation.
You can look at another article of this thread to find the code
of CO (spoiler alert, it is one instruction.)

Groetjes Albert

P.S.
I have had it with the GA144.
Leon and I had to change the tools in order to run a non-trivial
program. Then with the next release the tools had to changed
in the same fashion, but we had to gave up.
I have 10 GA144 chips. I keep one of them, the rest is available
to the highest bidder.
--
Don't praise the day before the evening. One swallow doesn't make spring.
You must not say "hey" before you have crossed the bridge. Don't sell the
hide of the bear until you shot it. Better one bird in the hand than ten in
the air. First gain is a cat spinning. - the Wise from Antrim -

On Mon, 27 Feb 2023 17:53:10 +1100
dxforth <dxforth@gmail.com> wrote:

> Elsewhere you mention ChipForth. Can't say I know anything about it.
> Wasn't it a precursor to SwiftX ?

chipFORTH networks 7,000 micros
https://www.computer-solutions.co.uk/chipdev/lighting.htm

Jan Coombs
--

On Monday, February 27, 2023 at 9:47:11 AM UTC+1, Paul Rubin wrote:
> > Unlikely. 4th is from Hans Bezemer.
> Oops, I got 4th confused with another implementation.
That's unfair! I have some simple co-routines as well:

: yield r> r> swap >r >r ;
synonym grab rdrop

As is shown here:

: payload 10000000 0 do loop dup 1+ swap 100 < ;
\ dummy task
: test
." Wait for it.. " spinner 0 \ start coroutine
begin payload while yield repeat \ show spinner while doing it
drop grab bl spin cr \ grab control, finish spinner
." Done!" cr \ all done
;

test

True, it can't do much, but it works. ;-)

Hans Bezemer

On 27/02/2023 11:33 pm, Jan Coombs wrote:
> On Mon, 27 Feb 2023 17:53:10 +1100
> dxforth <dxforth@gmail.com> wrote:
>
>> Elsewhere you mention ChipForth. Can't say I know anything about it.
>> Wasn't it a precursor to SwiftX ?
>
> chipFORTH networks 7,000 micros
> https://www.computer-solutions.co.uk/chipdev/lighting.htm

Thanks for that. A COMSOL product that appears to have targetted older chips.

Links to missing pages
https://web.archive.org/web/20151103000711/https://www.computer-solutions.co.uk/chipdev/cf.htm#cF%20Intro
https://web.archive.org/web/20151103000848/http://www.computer-solutions.co.uk/chipdev/cfworks.htm

dxforth <dxforth@gmail.com> writes:
> Links to missing pages
> https://web.archive.org...

Thanks for finding those, they help. They explain that ChipForth is a
Polyforth derivative, and supports multitasking on the target with
overhead of 48 bytes of ram per task. That sounds like two 16-level
stacks plus a few registers and a TCB. It also mentions that the host
communication module is < 256 bytes of code and doesn't have to be
included in a final build.

It would be great to have an actual manual, as I don't see one there,
but it's ok.

On 28/02/2023 7:53 am, Paul Rubin wrote:
> dxforth <dxforth@gmail.com> writes:
>> Links to missing pages
>> https://web.archive.org...
>
> Thanks for finding those, they help. They explain that ChipForth is a
> Polyforth derivative, and supports multitasking on the target with
> overhead of 48 bytes of ram per task. That sounds like two 16-level
> stacks plus a few registers and a TCB. It also mentions that the host
> communication module is < 256 bytes of code and doesn't have to be
> included in a final build.

The SwiftX doc describes a multitasking example as having:

"32 bytes of user area, 128 bytes of data stack, and 64 bytes of return stack"

These aren't necessarily minimums. In Forth the programmer is very much
in charge. Since everything is exposed he can calculate resources used
down to the last byte. That's in contrast to black box systems that supply
an API and specs because there's stuff going on underneath the programmer
'need not be concerned with'. I note the team behind Arduino is looking
into multitasking and asking for input...

https://blog.arduino.cc/2022/08/02/introducing-multitasking-to-arduino/

albert@cherry.(none) (albert) writes:
> I can't wait to see a sensible application of multi-tasking on
> a 2k RAM sbc. So I suspend disbelief till then.

You could allocate a task to each HW source (button, touch screen, timer, ...)
and just have them cooperatively take turns checking their hardware. Or you
could have a service loop that checked each sequentially. With lightweight
Forth tasks, it's really a "I saw poe-tay-toe, you say poe-tah-toe" kind of
thing. In 2k I _might_ use tasks, in 8k I'd _probably_ use them.

I find that if you can avoid interrupts (poll instead), it streamlines the
software considerably. At least SMALL software; you get to a megabyte and
the infrastructure for interrupts is in the noise.

Andy Valencia
Home page: https://www.vsta.org/andy/
To contact me: https://www.vsta.org/contact/andy.html

On 26/02/2023 4:23 am, Anton Ertl wrote:
> Paul Rubin <no.email@nospam.invalid> writes:
>> It mentions the possibility of multitasking being
>> standardized. That is interesting too. Is it actually likely, in the
>> sense of progress being made? Are there any proposed standardization
>> specs around?
>
> Andrew Haley worked on it before he dropped out of the standardization
> effort. Now we have tasked Bernd Paysan with that, but I think he
> wants to wrap up recognizers before taking this task on.
>
> IIRC Andrew Haley produced some slides, not sure if there is something
> available online.
> ...

Googling forth multitaskers turned up this reference:

https://theforth.net/package/multi-tasking

On 27/02/2023 7:50 pm, Paul Rubin wrote:
> dxforth <dxforth@gmail.com> writes:
>> Elsewhere you mention ChipForth. Can't say I know anything about it.
>> Wasn't it a precursor to SwiftX ?
>
> I have also been looking for info but it looks like most is gone from
> the web. Forth Inc. sold it for a while but I don't think it was
> related to SwiftX. It was a tethered Forth for 8051 and comparable
> MCU's whether the text interpreter was entirely on a host PC.

I just noticed this tethered forth for Arduino:

https://github.com/CharleyShattuck/myforth-arduino

In true forth style, docs are minimal to non-existent. However there's
an intro here:

http://www.forth.org/svfig/kk/02-2011-Shattuck.pdf