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

Groups > comp.lang.forth > #35960

Re: Expected BASE-LINE for Embedded Controllers

Show all headers | View raw

Bernd Paysan <bernd.paysan@gmx.de> writes:
> Oh, come on.  Of course saving the registers means to emit code to save the 
> registers.  On most CPUs with a single core, that's necessary to switch 
> tasks.

The difference is that a general multitasker can save the registers any
way it wants, while SP@ (barring ugly hacks) has to save them on the
data stack.  That decreases flexibility, e.g. with cpus that can save a
set of registers in a single instruction.  For that matter, shuffling
the registers to the data stack apparently took considerable
implementation effort in VFX.  Easier to use a save/restore mechanism
that doesn't need such complexity.  That also makes it easier to
implement multitasking by running Forth under a non-Forth RTOS if that's
desired.  There are some very light and simple ones around.

> You might be thinking of a SPARC with its rotating register window,

I wasn't thinking of register windows particularly.  But some cpu's can
save the registers in one instruction or even (Parallax Propeller) have
built-in multitasking and multiprocessing.

As another example, I've mentioned the Beaglebone real-time coprocessor
as a promising Forth target in some other posts.  It has 32 registers so
a reasonable way to implement a two-task multitasker with very low
switching latency could be to just dedicate a dozen or so registers to
the background task, and put that task's stacks in those registers, with
the compiler knowing which task was which.  So there would be no need to
save the registers as they'd be left alone between switches.  Switching
at the Forth level would just be an F18-like coroutine jump that would
compile down to a simple jump in the case where the compiler tracked
the stack contents.

Come to think of it, for that very simple case, EX (coroutine jump in
Colorforth terminology, http://www.colorforth.com/inst.htm ) might be
enough by itself.  The background task would share the main stack with
the foreground, using a few ALLOTted cells or variables to remember what
it was doing between calls, so it would leave the main stack undisturbed
from the perspective of the foreground task.

> this doesn't imply that the standard has to add a layer of
> abstraction.

The idea of a standard is to abstract over implementations.  So in this
case it should look at the end goal (lightweight multitasking), consider
all the reasonable implementation techniques for that goal, and then
specify an interface that's consistent with existing Forth practice and
can be implemented with any of those techniques.

> I want to remind you that one essential design principle of Forth is
> to not abstract just for the sake of abstraction, and to speculate
> about things which you haven't yet seen in practice.  

I've certainly seen multitaskers in practice that don't rely on anything
as deeply tangled in the interpreter implementation as SP@.  Consider
your mention of Forth multitaskers using Posix threads.

Particularly, I've always found it useful when coding for an embedded
target to also be able to run it on a PC for development/debugging or
for when the target hardware isn't available.  The code can't always be
100% identical, but minimizing the difference between the embedded and
PC versions is worth some effort.  So the word sets should be similar or
identical if possible.

>> Why should the multitasking words for controllers not follow the same
>> standard?
> I've already written that: You don't want to have the full-blown
> thing, one task in the background, only switched to during KEY?
> usually does the job.

Yes, I saw that, but I didn't (and still don't) see why the multitasking
words can't be designed such that a minimal implementation handles the
two-task case perfectly well.  However, Elizabeth has since posted that
the reason it's not standardized is that implementers have never been
able to agree on what's the right set of words, which is something you
hadn't explained.  

So maybe there are serious technical dilemmas or maybe it's just the
usual bikeshedding paralysis.  Either way, it sounds like a reasonable
attempt was made and it failed.  That's a more useful explanation than
"you don't want to have the full-blown thing" and it shows that other
people had the same desire and (at least for a while) saw it as
practical.

> Ah, the "big end" of Forth multitasking certainly is using POSIX
> threads, so it at least has to take that into account.

It's fine to write the standard in a way that makes sure POSIX threads
are a usable implementation approach.  It would be un-Forthlike for the
standard to *require* Forth multitaskers to have anything like the
complexity that POSIX thread implementations need.

Back to comp.lang.forth | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Expected BASE-LINE for Embedded Controllers Paul E Bennett <Paul_E.Bennett@topmail.co.uk> - 2015-01-18 11:58 +0000
  Re: Expected BASE-LINE for Embedded Controllers Matthias Trute <matthias.trute@gmail.com> - 2015-01-18 04:55 -0800
    Re: Expected BASE-LINE for Embedded Controllers Mikael Nordman <oh2aun@gmail.com> - 2015-01-18 10:20 -0800
    Re: Expected BASE-LINE for Embedded Controllers visualforth@rocketmail.com - 2015-01-20 10:45 -0800
      Re: Expected BASE-LINE for Embedded Controllers "Elizabeth D. Rather" <erather@forth.com> - 2015-01-20 12:34 -1000
        Re: Expected BASE-LINE for Embedded Controllers visualforth@rocketmail.com - 2015-01-20 16:40 -0800
  Re: Expected BASE-LINE for Embedded Controllers Bernd Paysan <bernd.paysan@gmx.de> - 2015-01-18 22:27 +0100
    Re: Expected BASE-LINE for Embedded Controllers "Elizabeth D. Rather" <erather@forth.com> - 2015-01-18 13:45 -1000
      Re: Expected BASE-LINE for Embedded Controllers albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-01-19 18:22 +0000
    Re: Expected BASE-LINE for Embedded Controllers Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2015-01-19 12:06 +0100
      Re: Expected BASE-LINE for Embedded Controllers albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-01-19 18:47 +0000
        Re: Expected BASE-LINE for Embedded Controllers "Elizabeth D. Rather" <erather@forth.com> - 2015-01-19 11:22 -1000
          Re: Expected BASE-LINE for Embedded Controllers albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-01-20 11:54 +0000
        Re: Expected BASE-LINE for Embedded Controllers Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2015-01-20 09:49 +0100
      Re: Expected BASE-LINE for Embedded Controllers Bernd Paysan <bernd.paysan@gmx.de> - 2015-01-19 20:27 +0100
      Re: Expected BASE-LINE for Embedded Controllers Paul Rubin <no.email@nospam.invalid> - 2015-01-20 11:04 -0800
        Re: Expected BASE-LINE for Embedded Controllers Mark Wills <markwills1970@gmail.com> - 2015-01-20 11:33 -0800
        Re: Expected BASE-LINE for Embedded Controllers Bernd Paysan <bernd.paysan@gmx.de> - 2015-01-20 23:30 +0100
          Re: Expected BASE-LINE for Embedded Controllers Paul Rubin <no.email@nospam.invalid> - 2015-01-20 14:41 -0800
            Re: Expected BASE-LINE for Embedded Controllers Bernd Paysan <bernd.paysan@gmx.de> - 2015-01-21 00:40 +0100
              Re: Expected BASE-LINE for Embedded Controllers Paul Rubin <no.email@nospam.invalid> - 2015-01-20 15:53 -0800
                Re: Expected BASE-LINE for Embedded Controllers Bernd Paysan <bernd.paysan@gmx.de> - 2015-01-21 01:41 +0100
                Re: Expected BASE-LINE for Embedded Controllers "Elizabeth D. Rather" <erather@forth.com> - 2015-01-20 15:38 -1000
                Re: Expected BASE-LINE for Embedded Controllers Paul Rubin <no.email@nospam.invalid> - 2015-01-22 11:08 -0800
                Re: Expected BASE-LINE for Embedded Controllers albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-01-23 16:10 +0000
            Re: Expected BASE-LINE for Embedded Controllers "Elizabeth D. Rather" <erather@forth.com> - 2015-01-20 15:25 -1000
          Re: Expected BASE-LINE for Embedded Controllers albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-01-21 10:40 +0000
  Re: Expected BASE-LINE for Embedded Controllers Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2015-01-19 12:00 +0100
  Re: Expected BASE-LINE for Embedded Controllers Mikael Nordman <oh2aun@gmail.com> - 2015-01-21 00:04 -0800
    Re: Expected BASE-LINE for Embedded Controllers Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2015-01-21 11:53 +0100
    Re: Expected BASE-LINE for Embedded Controllers Mark Wills <markwills1970@gmail.com> - 2015-01-21 03:02 -0800
    Re: Expected BASE-LINE for Embedded Controllers Mark Wills <markwills1970@gmail.com> - 2015-01-21 03:07 -0800
      Re: Expected BASE-LINE for Embedded Controllers Bernd Paysan <bernd.paysan@gmx.de> - 2015-01-22 15:50 +0100
        Re: Expected BASE-LINE for Embedded Controllers anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-01-22 16:39 +0000
        Re: Expected BASE-LINE for Embedded Controllers Paul Rubin <no.email@nospam.invalid> - 2015-01-22 11:13 -0800
          Re: Expected BASE-LINE for Embedded Controllers stephen@mpeforth.com (Stephen Pelc) - 2015-01-23 11:19 +0000
            Re: Expected BASE-LINE for Embedded Controllers albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-01-23 16:12 +0000
          Re: Expected BASE-LINE for Embedded Controllers anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-01-23 16:42 +0000
            Re: Expected BASE-LINE for Embedded Controllers Paul Rubin <no.email@nospam.invalid> - 2015-01-24 01:53 -0800
              Re: Expected BASE-LINE for Embedded Controllers Bernd Paysan <bernd.paysan@gmx.de> - 2015-01-24 15:33 +0100
              Re: Expected BASE-LINE for Embedded Controllers anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-01-25 15:48 +0000

csiph-web