dxforth <dxforth@gmail.com> writes:
>Both F83 and Fig-Forth were ITC. Their speeds would have been comparable.

IIRC we looked at the NEXT for the 8086 versions some time ago.
fig-Forth's 8086 NEXT used 8080-based register assignments, whereas
F83's NEXT made much better use of the 8086 instruction set.

- 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

Paul Rubin <no.email@nospam.invalid> writes:
[feedback on the Gforth multi-tasking docs]

Thanks for the feedback. I have forwarded it to Bernd Paysan, who
hopefully will improve the documentation.

- 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 25/02/2023 10:11 am, Anton Ertl wrote:
> dxforth <dxforth@gmail.com> writes:
>> Both F83 and Fig-Forth were ITC. Their speeds would have been comparable.
>
> IIRC we looked at the NEXT for the 8086 versions some time ago.
> fig-Forth's 8086 NEXT used 8080-based register assignments, whereas
> F83's NEXT made much better use of the 8086 instruction set.

True. ISTR Zbig was going to fix that :)

> It's a rare person that turns down 'more' especially when it's free.
> Both F83 and Fig-Forth were ITC. Their speeds would have been comparable.

Oh, not really — example: FPC. I recall how overwhelming it seemed I tried
it first time…
It all depends on what one needs.

In article <878rgmuaz8.fsf@nightsong.com>,
Paul Rubin <no.email@nospam.invalid> wrote:
>anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>> https://gforth.org/manual/Multitasker.html
>> Note that this documents the development version.
>
>Oh, neat! But the doc doesn't seem to describe the cooperative
>multitasker. 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?

The most sensible approach is :
A defining word that creates a data structure e.g. THREAD-something
It takes a size upon creation.

<size> THREAD-something my-music

Then you may run an xt in this space
' score my-music

If score exits, my-music becomes free again.
There can be communication using semaphores to signal score to terminate.

This is almost identical to MPE-Forth I think, but it is parallel
development and the names are not standardised of course.

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 <87zg92ssj8.fsf@nightsong.com>,
Paul Rubin <no.email@nospam.invalid> wrote:
>Paul Rubin <no.email@nospam.invalid> writes:
>> Oh, neat! But the doc doesn't seem to describe the cooperative
>> multitasker.
>
>On reading the doc, it looks like the same words can control both
>multitaskers, though some of them are only important for the preemptive
>case.
>
>The "Special User Variables" section has the confusing paragraph
>
> Define a per-thread deferred word wait for all spawned tasks to
> complete wait for a worker to become free, and spawn xt there wait
> for a worker to become free, and spawn xt there, with one argument
> wait for a worker to become free, and spawn xt there, with two
> arguments
>
>It looks there are some word headings missing from the middle of that by
>accident. They seem to be for dealing with worker thread pools. Should
>those really be primitives?
>
>Are there parameters for the size of the event queue per task? What
>happens if a queue fills up? Is the event queue system as described in
>the doc part of a standardization proposal?
>
>I find the event queue doc a bit confusing. Does event: let you give
>arbitrary Forth code that is supposed to be executed in the receiving
>task, i.e. something like an xt gets passed through the queue? If yes,
>the doc should say so, and say how to pass an xt. Or is the definition
>just supposed to be the events like elit, and friends? Do you use elit,
>if you want to send an xt?
>
>I expect it is the latter, and a typical event sequence would pass some
>args and an event type. The receiving task would CASE on the event type
>where each branch of the CASE would use the args for that type of event.
>Does that sound right? But in that case why does EVENT: exist, instead
>of using an ordinary colon definition? Why is there a maximum of 256
>named events?
>
>And if it is the former, how does one send a named event to another
>task?
>
>There are various defining words like event: which take names and create
>objects with those names. Do they have factors that let you create the
>objects anonymously?
>
>It sounds like the event queue stuff might be gforth-specific, rather
>than proposed or contemplated for standardization. That's fine, but it
>would be nice if the doc identified words whose semantics might become
>part of the standard.
>
>I'm still interested in using this stuff on small MCU's (16KB program
>flash, 1KB or 2KB ram), so I'm trying to figure out the resource
>requirements of this multitasking scheme.

It seems a monumental design error to conflate threads and queues.
They are separate issues and can be designed separately.

In the manx program I have separate queues for each instrument.
I have separate tasks for each part of a score, conceptually,
and a higher priority task that inspect instruments queues in real time.
Actually I handle the score sequentially, generating events for the
first bar of the first part, then the first part of the second part,
and so on , then continuing with the second bar of the first part.

I have a cooperative multitasking in ciforth but I don't use it.

On the subject of multi-tasking on a flash based CPU.
There are c-based soc's intended for smart devices.
2 K flash and 16 K ram is more Forth-like.
They are ram starved. A task will have separate tib, data stack
and return stack. You probably could bastle something together,
but forget about general tools gforth can provide.
There is no reward in this except the challenge.

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 <3ce3a9d3-3776-497e-8e87-f4cd9de90508n@googlegroups.com>,
Zbig <zbigniew2011@gmail.com> wrote:
>> Folks loved F83 because it was everything Fig-Forth was not.
>
>What you mean, in particular?
>
>BTW I acquired a taste for that „outdated” fig-Forth because of its
>simplicity. :) It may even be perhaps slowest of them all, but nowadays
>(contrary to the 70s/80s) it's not that serious disadvantage on modern
>CPUs, unless one „really really” needs the speed (like 3D-graphics?).

Probably you would like ciforth. There is an MSDOS version ...

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 -

On 25/02/2023 8:53 pm, Zbig wrote:
>> It's a rare person that turns down 'more' especially when it's free.
>> Both F83 and Fig-Forth were ITC. Their speeds would have been comparable.
>
> Oh, not really — example: FPC. I recall how overwhelming it seemed I tried
> it first time…
> It all depends on what one needs.

Sure, but how many didn't need a ready-to-run forth with editor, assembler,
OS file-system support etc comparable in quality to systems LMI was selling?
The Forth world including FIG had moved on with Forth-79 and then Forth-83.
If there were vendors still offering systems based on Fig-Forth, it was
because Laxen & Perry had threatened to go after anyone profiteering from
their work. FWIW I thought F83 was over-bloated too.

> Sure, but how many didn't need a ready-to-run forth with editor, assembler,
> OS file-system support etc comparable in quality to systems LMI was selling?
> The Forth world including FIG had moved on with Forth-79 and then Forth-83.
> If there were vendors still offering systems based on Fig-Forth, it was
> because Laxen & Perry had threatened to go after anyone profiteering from
> their work. FWIW I thought F83 was over-bloated too.

Maybe indeed I look at this from today's perspective, when everything I need
(including tips, tricks and other kind of help/support) I can have „on a click”…
it wasn't that easy accessible in „diskette-based” times back in the day.

> If there were vendors still offering systems based on Fig-Forth, it was
> because Laxen & Perry had threatened to go after anyone profiteering from
> their work.

On a second thought: wouldn't it be actually better solution for both them and
the Forth world simply to offer kind of agreement in case anyone would like to
use their work commercially?
They would have additional income — and their Forth would gain even more users.

On Friday, February 24, 2023 at 5:07:08 PM UTC-5, dxforth wrote:

> Both F83 and Fig-Forth were ITC. Their speeds would have been comparable.

F83 compile times were much faster due to the hashed dictionary.

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.

I guess the documentation you are seeing is what we have from Bernd
Paysan, but he will propose only a part of that for standardization.

- 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

albert@cherry.(none) (albert) writes:
> On the subject of multi-tasking on a flash based CPU.
> There are c-based soc's intended for smart devices.
> 2 K flash and 16 K ram is more Forth-like.
> They are ram starved. A task will have separate tib, data stack
> and return stack.

The 16k flash and 2k ram seemed ok to me, since the flash would in both
cases be mostly used for code. With 16 bit cells if you have 16 cells
for each stack, that's 64 bytes of stack per task. Plus you'd have a
few user variables and a TCB. There wouldn't be a TIB in an embedded
application, but even if there was, why have a separate one per task?

A Forth version of the Anduril app (flashlight controller written in C)
might have about 5 or so tasks, so a few hundred bytes of ram would
suffice. It originally ran on the ATTiny85 which iirc has 8KB of flash
and 512B of ram, but it has reached the limit of code space on that
part, and new lights have been using the ATTiny1616 (16KB flash, 2KB
ram) which is nicer in other ways too.

I guess the ram requirement would increase if the app migrated to a 32
bit cpu and the Forth had 32 bit cells. Also, 16 cells per stack might
sometimes be too few. I guess that could be controlled at task
creation. Some tasks are more complicated than others.

I also wonder how interrupt handlers would fit into this.

On 2/25/23 1:33 PM, Paul Rubin wrote:> I guess the ram requirement would
increase if the app migrated to a 32
> bit cpu and the Forth had 32 bit cells. Also, 16 cells per stack might
> sometimes be too few. I guess that could be controlled at task
> creation. Some tasks are more complicated than others.
>
> I also wonder how interrupt handlers would fit into this.

Digging out my ARM eForth code I see:

; FORK ( u r s -- tid )
; Create and start a new task
; Parameters are the size of the user area, return stack, and
; parameter stack in cells. Return value to the parent is
; the task ID of the child.
; Minimum size for the user area is 7 which is added to the
; value on the stack.

This is based on the old Forth Dimensions article by Laxen but with the
task creation combined into a single word.

And an example of its use:

: BUFFER-TASK ( -- tid )
DMAC-INIT
0 16 24 FORK DBUFFER BEGIN CHECK-BUFFER AGAIN ;

( Begin task to write full buffers to the SD card )

Interrupts fit into the ARM system pretty easily so ISRs were high level
Forth rather than assembly. The ARM stack is used to save state and that
is a separate stack distinct from the Forth data and parameter stacks.
It is nice having plenty of memory. And registers.

--
http://davesrocketworks.com
David Schultz

> The Forth world including FIG had moved on with Forth-79 and then Forth-83.

One more: are you sure really many „moved on with Forth-79”? Longer time
I was searching for any Forth-79 for DOS — actually just out of curiosity, to
take a look at it — it can nowhere be found, not present even on forth.org pages
(neither at Taygeta).

If I'm correct even for my C-64 I haven't got any Forth-79; several fig-s, two F83
(Blazin' Forth and UltraForth/VolksForth), one MVP Forth (Super Forth), one trying
to be ANS-compliant (Durex Forth, but this of course rather recent implementation)
— and that's about it. I've found that C64-Forth from Performance Micro has
79-STANDARD word present in its vocabulary, but anyway it uses, for example,
fig-Forth's VARIABLE.

So even if I find one (or maybe, who knows, even two) in the future, it doesn't seem
that Forth-79 was that popular in the past. No trace!

On 26/02/2023 4:01 am, Brian Fox wrote:
> On Friday, February 24, 2023 at 5:07:08 PM UTC-5, dxforth wrote:
>
>> Both F83 and Fig-Forth were ITC. Their speeds would have been comparable.
>
> F83 compile times were much faster due to the hashed dictionary.

I'd forgotten F83 had that. Can't say I ever measured or noticed
the difference even back in the day (of floppies).

On 25/02/2023 11:27 pm, Zbig wrote:
>> If there were vendors still offering systems based on Fig-Forth, it was
>> because Laxen & Perry had threatened to go after anyone profiteering from
>> their work.
>
> On a second thought: wouldn't it be actually better solution for both them and
> the Forth world simply to offer kind of agreement in case anyone would like to
> use their work commercially?
> They would have additional income — and their Forth would gain even more users.

Perhaps they did. I once came across some utilities bundled with (IIRC) a
Paradise EGA/VGA card. It included what appeared to be an updated version
of F83. I believe Laxen worked for the company that produced the card.
I can understand the restriction on profiteering if one was in the business
of making a living from the product but in all other circumstances all it
does is restrict development.

On 26/02/2023 10:38 am, Zbig wrote:
>> The Forth world including FIG had moved on with Forth-79 and then Forth-83.
>
> One more: are you sure really many „moved on with Forth-79”? Longer time
> I was searching for any Forth-79 for DOS — actually just out of curiosity, to
> take a look at it — it can nowhere be found, not present even on forth.org pages
> (neither at Taygeta).
>
> If I'm correct even for my C-64 I haven't got any Forth-79; several fig-s, two F83
> (Blazin' Forth and UltraForth/VolksForth), one MVP Forth (Super Forth), one trying
> to be ANS-compliant (Durex Forth, but this of course rather recent implementation)
> — and that's about it. I've found that C64-Forth from Performance Micro has
> 79-STANDARD word present in its vocabulary, but anyway it uses, for example,
> fig-Forth's VARIABLE.
>
> So even if I find one (or maybe, who knows, even two) in the future, it doesn't seem
> that Forth-79 was that popular in the past. No trace!

I believe MVP updated to Forth-79. I found a Micromotion Forth-79 system
for CP/M dated 1982. Forth Dimensions had adverts for Forth-79 systems.
Commercial support for Forth-79 was there, it's just that there was little
available in the public domain. The second factor was it was short-lived.
Almost immediately after Forth-79 hit the streets, implementers found
problems with the spec. That gave FIG the impetus/excuse to start working
on a new Standard.

> I believe MVP updated to Forth-79.

MVP is actually a „mix” of fig and F79, trying to get the best of both worlds.

In article <87r0udsfph.fsf@nightsong.com>,
Paul Rubin <no.email@nospam.invalid> wrote:
>albert@cherry.(none) (albert) writes:
>> On the subject of multi-tasking on a flash based CPU.
>> There are c-based soc's intended for smart devices.
>> 2 K flash and 16 K ram is more Forth-like.
>> They are ram starved. A task will have separate tib, data stack
>> and return stack.
>
>The 16k flash and 2k ram seemed ok to me, since the flash would in both
>cases be mostly used for code. With 16 bit cells if you have 16 cells
>for each stack, that's 64 bytes of stack per task. Plus you'd have a
>few user variables and a TCB. There wouldn't be a TIB in an embedded
>application, but even if there was, why have a separate one per task?
>
>A Forth version of the Anduril app (flashlight controller written in C)
>might have about 5 or so tasks, so a few hundred bytes of ram would
>suffice. It originally ran on the ATTiny85 which iirc has 8KB of flash
>and 512B of ram, but it has reached the limit of code space on that
>part, and new lights have been using the ATTiny1616 (16KB flash, 2KB
>ram) which is nicer in other ways too.
>
>I guess the ram requirement would increase if the app migrated to a 32
>bit cpu and the Forth had 32 bit cells. Also, 16 cells per stack might
>sometimes be too few. I guess that could be controlled at task
>creation. Some tasks are more complicated than others.
>
>I also wonder how interrupt handlers would fit into this.

I can't wait to see a sensible application of multi-tasking on
a 2k RAM sbc. So I suspend disbelief till then.

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 -

> I can't wait to see a sensible application of multi-tasking on
> a 2k RAM sbc. So I suspend disbelief till then.

If the code of the application is going to reside in flash, and to use
the RAM just for its data — why not?

In article <1bf203c1-1937-4d7b-8ec2-565a47b01030n@googlegroups.com>,
Zbig <zbigniew2011@gmail.com> wrote:
>> I can't wait to see a sensible application of multi-tasking on
>> a 2k RAM sbc. So I suspend disbelief till then.
>
>If the code of the application is going to reside in flash, and to use
>the RAM just for its data — why not?

I can't wait to see it.

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 -

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.

Paul Rubin <no.email@nospam.invalid> writes:
>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.

If it does not have separate stacks, it's not coroutining. But in the
Forth tradition of selling some deficient solution as the genuine
article (and sometimes the deficient solution is good enough, and the
additional cost of the genuine article too expensive), you can look at
Albert van der Horst's CO.

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

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

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

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