Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #134100 > unrolled thread

multitasking vs multiple interpreters

Back to article view | Back to comp.lang.forth

Contents

  multitasking vs multiple interpreters Paul Rubin <no.email@nospam.invalid> - 2025-07-28 11:36 -0700
    Re: multitasking vs multiple interpreters albert@spenarnc.xs4all.nl - 2025-07-28 23:09 +0200
      Re: multitasking vs multiple interpreters Paul Rubin <no.email@nospam.invalid> - 2025-07-28 20:32 -0700
        Re: multitasking vs multiple interpreters minforth <minforth@gmx.net> - 2025-07-29 06:03 +0200
        Re: multitasking vs multiple interpreters Ivan Shmakov <ivan@siamics.netREMOVE.invalid> - 2025-08-09 14:37 +0000
    Re: multitasking vs multiple interpreters anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-07-29 07:49 +0000
      Re: multitasking vs multiple interpreters albert@spenarnc.xs4all.nl - 2025-07-29 11:06 +0200
      Re: multitasking vs multiple interpreters Paul Rubin <no.email@nospam.invalid> - 2025-07-29 15:06 -0700
      Re: multitasking vs multiple interpreters Buzz McCool <buzz_mccool@yahoo.com> - 2025-08-11 10:12 -0700
        Re: multitasking vs multiple interpreters anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-08-11 17:49 +0000
          Re: multitasking vs multiple interpreters albert@spenarnc.xs4all.nl - 2025-08-12 13:14 +0200
            Re: multitasking vs multiple interpreters Paul Rubin <no.email@nospam.invalid> - 2025-08-12 09:45 -0700
              Re: multitasking vs multiple interpreters albert@spenarnc.xs4all.nl - 2025-08-13 11:23 +0200
                Re: multitasking vs multiple interpreters Paul Rubin <no.email@nospam.invalid> - 2025-08-13 09:12 -0700
            Re: multitasking vs multiple interpreters minforth <minforth@gmx.net> - 2025-08-13 13:55 +0200
            Re: multitasking vs multiple interpreters Stephen Pelc <stephen@vfxforth.com> - 2025-08-14 09:43 +0000

#134100 — multitasking vs multiple interpreters

Question is how to multitask on a small embedded target.  One way is the
traditional cooperative multitasker with a shared dictionary plus task
variables.

Another way is time slicing multiple interpreters, each with its own
data dictionary (all variables are task variables).  There would be a
shared read-only dictionary for code and constants, and a mailbox scheme
for IPC.

This question is more about shared vs non-shared than cooperative vs
preemptive.  The latter would be Erlang-style preemptive, i.e. avoiding
most locking hazards by using mailboxes instead of memory sharing.

Does anyone do it this way?  Is the overhead substantial?

[toc] | [next] | [standalone]

#134101

In article <871pq0uppw.fsf@nightsong.com>,
Paul Rubin  <no.email@nospam.invalid> wrote:
>Question is how to multitask on a small embedded target.  One way is the
>traditional cooperative multitasker with a shared dictionary plus task
>variables.
>
>Another way is time slicing multiple interpreters, each with its own
>data dictionary (all variables are task variables).  There would be a
>shared read-only dictionary for code and constants, and a mailbox scheme
>for IPC.
>
>This question is more about shared vs non-shared than cooperative vs
>preemptive.  The latter would be Erlang-style preemptive, i.e. avoiding
>most locking hazards by using mailboxes instead of memory sharing.
>
>Does anyone do it this way?  Is the overhead substantial?

Interpreting a musical score with multiple instruments
and several polyphonic parts:
If I look at the manx program, I have 2 levels of multitasking.
The low level for the instruments (microseconds precision and busy
waiting) and the high level , interpreting a measure of a part of a
musical score than the same measure of other parts.
Once the low level queues are full, and the next event is -- say --
15 mS away, I give time back to the OS (linux) by a wait, such that
the process can be run in the background and the terminal is still
responsive.
Without waiting this can be run on a small system, memory may
restrict the size of the musical score.

This suggests that a Forther would design the multitasking fit
for the application,

The other situation is that you take advantage of multiple cores
to speed up the calculation. There you use the fork system call.

Groetjes Albert
-- 
The Chinese government is satisfied with its military superiority over USA.
The next 5 year plan has as primary goal to advance life expectancy
over 80 years, like Western Europe.

[toc] | [prev] | [next] | [standalone]

#134102

albert@spenarnc.xs4all.nl writes:
> The other situation is that you take advantage of multiple cores
> to speed up the calculation. There you use the fork system call.

The idea here is to multitask on an MCU with around 2kB of memory, so no
OS.  Just a few tasks to monitor a pushbutton, control a LED, and some
similar things.

[toc] | [prev] | [next] | [standalone]

#134103

Am 29.07.2025 um 05:32 schrieb Paul Rubin:
> albert@spenarnc.xs4all.nl writes:
>> The other situation is that you take advantage of multiple cores
>> to speed up the calculation. There you use the fork system call.
> 
> The idea here is to multitask on an MCU with around 2kB of memory, so no
> OS.  Just a few tasks to monitor a pushbutton, control a LED, and some
> similar things.

The scheduler will require a base clock interrrupt, say every
10 millisecs. Other interrupts can fill a request queue which is
handled by the scheduler. Details are VERY hardware specific.

You may be interested in:
https://codeberg.org/clausecker/mecrisp-stellaris

[toc] | [prev] | [next] | [standalone]

#134112

>>>>> On 2025-07-29, Paul Rubin wrote:
>>>>> albert@spenarnc.xs4all.nl writes:

 >> The other situation is that you take advantage of multiple cores
 >> to speed up the calculation.  There you use the fork system call.

 > The idea here is to multitask on an MCU with around 2kB of memory,
 > so no OS.

	That depends on the OS definition in use.  Contiki (say, [1])
	positioned itself as an OS, and it /did/ run on AVR MCUs.
	(Though I only have experience with it on STM32F4 myself.)

[1] http://en.wikipedia.org/wiki/Contiki

 > Just a few tasks to monitor a pushbutton, control a LED, and some
 > similar things.

	My /guess/ is that time-slicing multiple interpreters will
	result in higher "save state / restore state" overhead overall.

	In any case, Contiki's cooperative multitasking / scheduling
	might be worth taking a look at.

	HTH.

[toc] | [prev] | [next] | [standalone]

#134104

Paul Rubin <no.email@nospam.invalid> writes:
>Question is how to multitask on a small embedded target.  One way is the
>traditional cooperative multitasker with a shared dictionary plus task
>variables.
>
>Another way is time slicing multiple interpreters, each with its own
>data dictionary (all variables are task variables).  There would be a
>shared read-only dictionary for code and constants, and a mailbox scheme
>for IPC.
>
>This question is more about shared vs non-shared than cooperative vs
>preemptive.  The latter would be Erlang-style preemptive, i.e. avoiding
>most locking hazards by using mailboxes instead of memory sharing.
>
>Does anyone do it this way?  Is the overhead substantial?

Gforth is not for small embedded systems, but anyway, the development
version does multi-tasking by mapping each task to a POSIX thread
(within one process), with the classical USER variable mechanism for
task-local variables, multiprocessing/preemption (coming from POSIX
threads), and an actor-like mechanism for communicating between tasks
and for synchronizing them (there are also other synchronizing
mechanisms).  The messages that the actor-like mechanism delivers to
the mailbox of a task are xts that the receiving task executes.  You
can read about that in https://net2o.de/gforth/Multitasker.html.

Concerning the idea of replicating all variables and buffers in each
task, that seemed too expensive in memory for Gforth, and I expect
that it is considered too expensive all the more for small embedded
targets.  For Gforth we want to be able to support a huge number of
tasks (although the current implementation with one pthread per task
is probably too expensive for that, too, but a future implementation
can fix that), for a small embedded system you may only want to have a
few tasks, but even then you don't want to waste memory on replicating
buffers that are only used in one task.  There is a reason why Forth
has both VARIABLE and USER.

- 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 2025 CFP: http://www.euroforth.org/ef25/cfp.html

[toc] | [prev] | [next] | [standalone]

#134105

In article <2025Jul29.094901@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>Paul Rubin <no.email@nospam.invalid> writes:
>>Question is how to multitask on a small embedded target.  One way is the
>>traditional cooperative multitasker with a shared dictionary plus task
>>variables.
>>
>>Another way is time slicing multiple interpreters, each with its own
>>data dictionary (all variables are task variables).  There would be a
>>shared read-only dictionary for code and constants, and a mailbox scheme
>>for IPC.
>>
>>This question is more about shared vs non-shared than cooperative vs
>>preemptive.  The latter would be Erlang-style preemptive, i.e. avoiding
>>most locking hazards by using mailboxes instead of memory sharing.
>>
>>Does anyone do it this way?  Is the overhead substantial?
>
>Gforth is not for small embedded systems, but anyway, the development
>version does multi-tasking by mapping each task to a POSIX thread
>(within one process), with the classical USER variable mechanism for
>task-local variables, multiprocessing/preemption (coming from POSIX
>threads), and an actor-like mechanism for communicating between tasks
>and for synchronizing them (there are also other synchronizing
>mechanisms).  The messages that the actor-like mechanism delivers to
>the mailbox of a task are xts that the receiving task executes.  You
>can read about that in https://net2o.de/gforth/Multitasker.html.
>
>Concerning the idea of replicating all variables and buffers in each
>task, that seemed too expensive in memory for Gforth, and I expect
>that it is considered too expensive all the more for small embedded
>targets.  For Gforth we want to be able to support a huge number of
>tasks (although the current implementation with one pthread per task
>is probably too expensive for that, too, but a future implementation
>can fix that), for a small embedded system you may only want to have a
>few tasks, but even then you don't want to waste memory on replicating
>buffers that are only used in one task.  There is a reason why Forth
>has both VARIABLE and USER.

I use fork in ciforth but I use shared memory. The main task is
controlling the memory, and forking amounts to running an execution
token in a memory structure (featuring stacks and user variables, and
a dictionary part, used for pad, numeric output, and maybe per task
definitions.) . All tasks can access all memory, e.g. a task can
monitor an other task.
If you kill all tasks except the original Forth, you can FORGET
all memory used for multi tasking.
This is feasible in limited memory, but of course implementing
forking under msdos, even if 8 cores are available is tricky.

Creating a memory structure : 1 screen
Pre-emptive multitasking , linux : 1 screen.

Creating a memory structure : 1 screen
Cooperative multitasking: 2 screens

(memory structure is common.)

>- anton
-- 
The Chinese government is satisfied with its military superiority over USA.
The next 5 year plan has as primary goal to advance life expectancy
over 80 years, like Western Europe.

[toc] | [prev] | [next] | [standalone]

#134109

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
> Concerning the idea of replicating all variables and buffers in each
> task, that seemed too expensive in memory for Gforth

No no, they wouldn't be replicated.  Each task would have its very own
data dictionary with its own variables.  Immutable data like code and
constants could be shared, but even then, that sharing wouldn't be
apparent to the application code.

There are actually a couple of applications I'm considering this for.
One is a flashlight (toykeeper.net/anduril) using a small MCU.  The
other is a battery controller, whose CPU is probably larger, but I don't
know at the moment what it is.  Both applications are written in C (not
by me) and the idea is to extend them with a small Forth.

[toc] | [prev] | [next] | [standalone]

#134115

On 7/29/2025 12:49 AM, Anton Ertl wrote:
...
> 
> Gforth is not for small embedded systems, but anyway, the development
> version does multi-tasking by mapping each task to a POSIX thread
> (within one process), with the classical USER variable mechanism for
> task-local variables, multiprocessing/preemption (coming from POSIX
> threads), and an actor-like mechanism for communicating between tasks
> and for synchronizing them (there are also other synchronizing
> mechanisms).  The messages that the actor-like mechanism delivers to
> the mailbox of a task are xts that the receiving task executes.  You
> can read about that in https://net2o.de/gforth/Multitasker.html.
> 
The link above says "Gforth offers two multitaskers: a traditional, cooperative round-robin multitasker, and a pthread-based multitasker ... " then has additional links to Pthreads and Cilk. Is the traditional multitasker at the Cilk link?

[toc] | [prev] | [next] | [standalone]

#134116

Buzz McCool <buzz_mccool@yahoo.com> writes:
>On 7/29/2025 12:49 AM, Anton Ertl wrote:
>> The messages that the actor-like mechanism delivers to
>> the mailbox of a task are xts that the receiving task executes.  You
>> can read about that in https://net2o.de/gforth/Multitasker.html.
>> 
>The link above says "Gforth offers two multitaskers: a traditional, cooperative round-robin multitasker, and a pthread-based multitasker ... " then has additional links to Pthreads and Cilk. Is the traditional multitasker at the Cilk link?

No.  The Cilk stuff is based on the pthreads stuff.  The traditional
multitasker is undocumented, unfortunately.  Maybe we should not
mention it.  Those who like to use it will find it and will know how
to use it.

- 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 2025 CFP: http://www.euroforth.org/ef25/cfp.html
EuroForth 2025 registration: https://euro.theforth.net/

[toc] | [prev] | [next] | [standalone]

#134119

In article <2025Aug11.194958@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>Buzz McCool <buzz_mccool@yahoo.com> writes:
>>On 7/29/2025 12:49 AM, Anton Ertl wrote:
>>> The messages that the actor-like mechanism delivers to
>>> the mailbox of a task are xts that the receiving task executes.  You
>>> can read about that in https://net2o.de/gforth/Multitasker.html.
>>>
>>The link above says "Gforth offers two multitaskers: a traditional,
>cooperative round-robin multitasker, and a pthread-based multitasker ...
>" then has additional links to Pthreads and Cilk. Is the traditional
>multitasker at the Cilk link?
>
>No.  The Cilk stuff is based on the pthreads stuff.  The traditional
>multitasker is undocumented, unfortunately.  Maybe we should not
>mention it.  Those who like to use it will find it and will know how
>to use it.

The important properties of multi taskers are
 - can you do io from all tasks
 - can you compile in any task
 - must you do PAUSE at certain interval's

The only essential difference between COT and PRE is that you must
do PAUSE in COT. The other differences can be anything.
In ciforth the only difference between COT and PRE is that you
must do PAUSE. And of course PRE can take advantage of multi cores.
All tasks can compile and do i/o.

Classical multitasking was geared towards multiple users, hence
USER variables. This requires multiple keyboards and screens,
e.g. a couple of VT100's. This is an interesting experiments,
but otherwise makes no sense.
i/o is mostly tied up with PAD and BASE, so if you use COT for
control, you probably must use the USER mechanism.

I don't think it makes sense to talk about COT in general, because
the most important use case has disappeared, and there are no
canonical examples any more.

An example is manx (control of musical instruments). The instruments
are controlled within uS. This is possible with a busy wait on the
high priorities parallel tasks. Each high priority parallel task runs
to completion, no PAUSE there.
The PAUSE is only executed from low priority tasks, the meaning is
run all scheduled high priority tasks.
I expect that for an application specific solutions are found,
and that general frameworks are for illustration only.
E.g. the COT in ciforth is use nowhere as far as I can tell.

>
>- anton

Groetjes Albert
-- 
The Chinese government is satisfied with its military superiority over USA.
The next 5 year plan has as primary goal to advance life expectancy
over 80 years, like Western Europe.

[toc] | [prev] | [next] | [standalone]

#134120

albert@spenarnc.xs4all.nl writes:
> The only essential difference between COT and PRE is that you must
> do PAUSE in COT. The other differences can be anything.

COT and PRE = cooperative and preemptive, idk if those are standard
abbreviations but ok.  One advantage of COT is that you don't have to
worry about critical sectons.  I think COT tends to get displaced by PRE
as systems get more complicated though.  COT is too easy to wedge if
some task blocks indefinitely.

> I don't think it makes sense to talk about COT in general, because
> the most important use case has disappeared, and there are no
> canonical examples any more.

What was the most important use case?

[toc] | [prev] | [next] | [standalone]

#134121

In article <87pld01obw.fsf@nightsong.com>,
Paul Rubin  <no.email@nospam.invalid> wrote:
>albert@spenarnc.xs4all.nl writes:
<SNIP>
>
>> I don't think it makes sense to talk about COT in general, because
>> the most important use case has disappeared, and there are no
>> canonical examples any more.
>
>What was the most important use case?

Have multiple users connected to one cpu, e.g. onve upon a time with
vt100's connected to a PDP11.

Groetjes Albert
-- 
The Chinese government is satisfied with its military superiority over USA.
The next 5 year plan has as primary goal to advance life expectancy
over 80 years, like Western Europe.

[toc] | [prev] | [next] | [standalone]

#134123

albert@spenarnc.xs4all.nl writes:
> Have multiple users connected to one cpu, e.g. onve upon a time with
> vt100's connected to a PDP11.

COT = cooperative multitasking?  The above could also have been
preemptive, I'd expect?

[toc] | [prev] | [next] | [standalone]

#134122

Le 12.08.2025 à 13:14 albert@spenarnc.xs4all.nl écrit:
 > I don't think it makes sense to talk about COT in general, because
 > the most important use case has disappeared, and there are no
 > canonical examples any more.

Because it makes no sense to put the cart before the horse and ask:
what does Forth need?

MT and RT requirements are primarily determined by the hardware and
the response time requirements. Just as an example: for a time-slicing
system with fixed cycles in a PLC, the software requirements are
different than for a desktop Forth running on Linux. Standardization
makes little sense here. And there are also hybrids: interrupts for
Task0 (scheduler) that controls cooperative subtasks 1..N, but can
also interrupt them preemptively eg. on detected cycle overload.

[toc] | [prev] | [next] | [standalone]

#134127

On 12 Aug 2025 at 13:14:20 CEST, "albert@spenarnc.xs4all.nl"
<albert@spenarnc.xs4all.nl> wrote:

> I don't think it makes sense to talk about COT in general, because
> the most important use case has disappeared, and there are no
> canonical examples any more.

There are many, many embedded apps that use COT of one form or another. The
traditional Forth cooperative tasker is supported by all our cross-compilers -
even
for 8031.

Now that silicon has more features per unit cost. In many cases, the
cooperative
tasker has features to reduce power consumption. Allied with efficient
high-level
Interrupt handling, a modern Forth cooperative scheduler can have much more
to offer than the traditional scheduler.

Stephen 
-- 
Stephen Pelc, stephen@vfxforth.com
Wodni & Pelc GmbH
Vienna, Austria
Tel: +44 (0)7803 903612, +34 649 662 974
http://www.vfxforth.com/downloads/VfxCommunity/
  free VFX Forth downloads

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.forth

csiph-web