Forth and RTOS, second posting
Mattias Waldau
I got no respons at all to my previous posting, thus I am posting it
again. If there are still no reponses I assume that no one is doing
embedded systems using Forth :-)
Do people that do embedded systems using forth use anything more than
1. Multitasking, and
2. The ability to put forth-code in an interrupt handler.
Is there a RTOS-package?
Typical RTOS features
1. I do not need/want pre-emptive tasking
2. I want to pass data using messaging
3. I want semaphore
4. I want syncronious and asyncronious communication
5. Time management, i.e. delay for 100 msec
Andrew McKewan
Mattias Waldau wrote:
>
> I got no respons at all to my previous posting, thus I am posting it
> again. If there are still no reponses I assume that no one is doing
> embedded systems using Forth :-)
>
> Do people that do embedded systems using forth use anything more than
> 1. Multitasking, and
> 2. The ability to put forth-code in an interrupt handler.
>
> Is there a RTOS-package?
What bothers me with the RTOS concept, is that there is something else
other than my program in control of the system. We use a version of pSOS
(with C) at Finnigan and I heard one of the engineers grumbling the
other day that he couldn't find out where pSOS put the stacks for his
tasks!
> Typical RTOS features
> 1. I do not need/want pre-emptive tasking
> 2. I want to pass data using messaging
> 3. I want semaphore
> 4. I want syncronious and asyncronious communication
> 5. Time management, i.e. delay for 100 msec
Most commercial Forth packages (and some free ones) come with a
multitasking toolkit. They include some or all of the features above.
You can find links at the FIG home page:
The only thing I would add to your list are queues (which might be
covered by message passing). I won't argue cooperative vs. prioritized
pre-emptive multitasking (both have pros and cons).
The real challenge in multitasking programming is correctly defining the
tasks and synchronization methods. A poor design can lead to a real mess
(I've seen some!).
--
Andrew McKewan
mck...@austin.finnigan.com
Elizabeth Rather
Andrew McKewan <mck...@austin.finnigan.com> wrote:
>What bothers me with the RTOS concept, is that there is something else
>other than my program in control of the system. We use a version of pSOS
>(with C) at Finnigan and I heard one of the engineers grumbling the
>other day that he couldn't find out where pSOS put the stacks for his
>tasks!
Last year an old customer of ours, a Very Large Company, told us that the corp.
suits had decided the next generation device would be programmed in pSOS & C
because that's how everybody else does it. 9 mos. later they called in a tearing
panic, because the C team barely had pSOS working on the device & they needed to
ship in 3 mos. We were busy, but agreed to help on a part time basis. We
delivered a kernel the following week, and drivers about 1/wk, while their Forth
team ported the application. Not only was our code (1) working; (2) smaller; (3)
faster, it also (4) used 0.1 x the power, which was important since it's a
battery-powered hand-held device. The key to the latter was that we could jigger
our multitasker to shut down the device when no tasks were running, which is in
fact most of the time, only frequently in small intervals. pSOS, on the other
hand, needed a fairly long time-out to shut down -- and, of course, it's a black
box that the VLC couldn't modify.
The s/w is now complete, all working, in final validation process, and will be
released on schedule. The C team did end up writing some diagnostics which will
be used, but the Forth guys didn't want to do that anyway ;-)
>Most commercial Forth packages (and some free ones) come with a
>multitasking toolkit. They include some or all of the features above.
>You can find links at the FIG home page:
>
> http://www.forth.org/fig.html
You might also check http://websites.earthlink.net/~forth (our site!)
>The real challenge in multitasking programming is correctly defining the
>tasks and synchronization methods. A poor design can lead to a real mess
>(I've seen some!).
Truer words are rarely emailed.
Elizabeth D. Rather
FORTH, Inc. Products and services for
111 N. Sepulveda Blvd. professional Forth programmers
Manhattan Beach, CA 90266 since 1973. See us at:
310-372-8493/fax 318-7130 http://websites.earthlink.net/~forth/
Ewald Pfau
Mattias Waldau <mattias...@abc.se> wrote:
MW> Do people that do embedded systems using forth use anything
MW> more than 1. Multitasking, and
MW> 2. The ability to put forth-code in an interrupt handler.
MW> Is there a RTOS-package?
MW> Typical RTOS features
MW> 1. I do not need/want pre-emptive tasking
MW> 2. I want to pass data using messaging
MW> 3. I want semaphore
MW> 4. I want syncronious and asyncronious communication
MW> 5. Time management, i.e. delay for 100 msec
Generally: 1. .. 5. yes, why not.
Forth gives the tool. Merely a promise spelled as solution. The rest is coding
waiting to be done.
1. Tasking in Forth didn't make it into the ANS language specification. You may
expect 'round-robin' tasking, as far as re-entrance in Forth is given at
selected entrance levels for task switching.
What remains of your questions deals with common coding practise.
2. Why not? Strings and numbers are just similar when encoded in bits'n
bytes...
3. To ask for semaphores is asking for common variables. Yes, Forth has common
variables :)
4. Look around for UART interfacing.
5. Look around for access to 'ticker' routines at the machine you deal with. At
DOS machines, there is either the 2^16/1.193.800 sec ticker, or a
non-re-entrant INT-call for better timing resolution down to microseconds (if a
WIN- or OS/2-box preserves it; in Windox start with unknown, in OS/2 reduce to
30 msec slots).
Ewald
Brad Rodriguez
Mattias Waldau wrote:
> I got no respons at all to my previous posting, thus I am posting it
> again. If there are still no reponses I assume that no one is doing
> embedded systems using Forth :-)
Sorry, I thought there would be a flood of replies so I kept quiet.
> Do people that do embedded systems using forth use anything more than
> 1. Multitasking, and
> 2. The ability to put forth-code in an interrupt handler.
>
> Is there a RTOS-package?
>
> Typical RTOS features
> 1. I do not need/want pre-emptive tasking
> 2. I want to pass data using messaging
> 3. I want semaphore
> 4. I want syncronious and asyncronious communication
> 5. Time management, i.e. delay for 100 msec
Briefly: there is not a standard RTOS package. Most Forth vendors offer
them for embedded controllers, e.g., Forth Inc. and MPE. I've used MPE's
multitasking package which is not pre-emptive, does allow message
passing, does (as I recall) allow semaphores, does include some time
management functions (e.g. delay), and does allow interrupt routines
written in high-level Forth. I'm not sure what you mean by synchronous
and asynchronous communication here; could you clarify?
I have written several preemptive and non-preemptive multitaskers in
Forth for embedded applications. Some have been quite simple and some
rather sophisticated. I invariably include semaphores, as I find them
quite useful; likewise, I rarely include message passing, since I haven't
adopted that paradigm yet. This will change: my recent work has been
with distributed OSs, for which message passing is a superior model.
--
Brad Rodriguez b...@headwaters.com Computers on the Small Scale
Contributing Editor, The Computer Journal... http://www.psyber.com/~tcj
Director, Forth Interest Group........... http://www.forth.org/fig.html
1996 Rochester Forth Conference: June 19-22 in Toronto, Ontario
http://maccs.dcss.mcmaster.ca/~ns/96roch.html
Andrew Haley
Zsoter Andras (h929...@hkuxa.hku.hk) wrote:
: Ewald Pfau (e...@ear.co.at) wrote:
: >1. Tasking in Forth didn't make it into the ANS language specification. You may
: ^^^^^^^^^^^^^^^^^^^^^^^^^
: >expect 'round-robin' tasking, as far as re-entrance in Forth is given at
: >selected entrance levels for task switching.
: Thanks God! Tasking is an *OS* concept not a language concept.
That's nonsense! Many programming languages over the years have had
concurrency as a built in language structure rather than as an OS
feature. Burroughs Algol, Concurrent Pascal, Occam, Ada, and
(classical) Forth are examples. It's a very useful feature that is
sadly lacking in Standard C.
Andrew.
Zsoter Andras
Ewald Pfau (e...@ear.co.at) wrote:
>1. Tasking in Forth didn't make it into the ANS language specification. You may
^^^^^^^^^^^^^^^^^^^^^^^^^
>expect 'round-robin' tasking, as far as re-entrance in Forth is given at
>selected entrance levels for task switching.
Thanks God! Tasking is an *OS* concept not a language concept.
It is just that many Forth-es happen to be OS-es on some embedded
device.
Andras
xian the desk lisard
thus spake Zsoter Andras in comp.lang.forth...
. Ewald Pfau (e...@ear.co.at) wrote:
. >1. Tasking in Forth didn't make it into the ANS language specification. You may
. ^^^^^^^^^^^^^^^^^^^^^^^^^
. >expect 'round-robin' tasking, as far as re-entrance in Forth is given at
. >selected entrance levels for task switching.
. Thanks God! Tasking is an *OS* concept not a language concept.
tell that to the ada folk...
--
xian the desk lisard -- cdah...@comp.brad.ac.uk
[ red, pink and blue, but mainly purple ribbons ]
we both know it was a girl back in bethlehem
you know soft spoken changes nothing view so cruel
Paul E. Bennett
> I got no respons at all to my previous posting, thus I am posting it
> again. If there are still no reponses I assume that no one is doing
> embedded systems using Forth :-)
Busy last time you posted this but I'll respond now.
> Do people that do embedded systems using forth use anything more than
> 1. Multitasking, and
> 2. The ability to put forth-code in an interrupt handler.
For a lot of systems I have had a hand in, interrupts were a problematic risk
area that was best disabled and rendered harmless for the processor concerned.
Limiting what you do in one processor does have some benefits and if the
processor is cheap enough then more can often be a help in getting a system up
and running. Many of the embedded systems have between 3 and 6 task threads on
a round robin.
> Is there a RTOS-package?
Forth.
> Typical RTOS features
> 1. I do not need/want pre-emptive tasking
> 2. I want to pass data using messaging
> 3. I want semaphore
> 4. I want syncronious and asyncronious communication
> 5. Time management, i.e. delay for 100 msec
With the right simple hardware selection all of 2 to 5 are relatively easy. For
item 1, round robin scheduling is quite robust and fair. Just remember to put
some pauses in the compute intensive tasks.
Time delays are best run from a simple long counter chain (with reads of time
rendering a natural binary representation of the 24 hour clock [32 bits]) and
fairly fine granularity of ticks. Multi-tasked delays need local storage space
to save the initial or limit time for the check. This is quite easy to provide.
For communications facilities, if the processor is slow add the hardware, if
the processor is ultra-fast and efficient at running Forth and has suitable
interface logic you may have the option to do software comms if you want to.
--
Paul E. Bennett <p...@transcontech.co.uk>
Transport Control Technology Ltd.
Tel: +44 (0)117-9499861
Going Forth Safely
Skip Carter
In article <4neo2n$r...@hkusuc.hku.hk>, h929...@hkuxa.hku.hk (Zsoter Andras) writes:
|> Ewald Pfau (e...@ear.co.at) wrote:
|>
|> >1. Tasking in Forth didn't make it into the ANS language specification. You may
|> >expect 'round-robin' tasking, as far as re-entrance in Forth is given at
|>
Right! We wouldn't want Forth to follow the example of Ada and partition
applications so that the tasker was part of the language spec.
|> It is just that many Forth-es happen to be OS-es on some embedded
|> device.
And so Forth should be "tasking friendly". For OS level multi-tasking there
is nothing to do, but for multi-threading where more than one task is running within
the same process image it would be nice to be able to handle synchonization and visibility
in some way that is standard (approximately anyway).
--
Everett (Skip) Carter Phone: 408-641-0645 FAX: 408-394-5561
Taygeta Scientific Inc. INTERNET: sk...@taygeta.com
1340 Munras Ave., Suite 223 UUCP: ...!uunet!taygeta!skip
Monterey, CA. 93940 WWW: http://www.taygeta.com/skip.html
Skip Carter
Zsoter Andras
Skip Carter (sk...@taygeta.com) wrote:
> And so Forth should be "tasking friendly". For OS level multi-tasking there
> is nothing to do, but for multi-threading where more than one task is running within
> the same process image it would be nice to be able to handle synchonization and visibility
> in some way that is standard (approximately anyway).
I think what should be in the standard is an optional wordset for IPC.
Words for Semaphores, Mutexes, File/Record-locking and the like.
I don't mean that the standard should suggest to implement such words
on a system which does not multitask but better be a standard name
for those things so that IF they are implemented they should be called
as so and so.
(This idea does not address the issue whetther or not multitasking should
be inside the language or in the underlying OS. The above tools would
merely provide a way for processes to communicate regardless whether
those processes are inside Forth or forked (spawned) by the OS.)
Andras
Jeff Fox
In article <3198CE...@abc.se> Mattias Waldau
<mattias...@abc.se> writes:
>Do people that do embedded systems using forth use anything more than
>1. Multitasking, and
>2. The ability to put forth-code in an interrupt handler.
>
>Is there a RTOS-package?
>
>Typical RTOS features
>1. I do not need/want pre-emptive tasking
>2. I want to pass data using messaging
>3. I want semaphore
>4. I want syncronious and asyncronious communication
>5. Time management, i.e. delay for 100 msec
I would recommend that you look at the FD article "Parallel Channels"
by Dr. Michael Montvelishsky in last year's FD or at my web site. I
an email you an ascii copy if you want.
He showed that a page of high level code can give you a pretty
portable package with in addition to traditional Forth PAUSE syntax
you get semaphores as well as syncronous and asyncronous data
channels between tasks. The syntax could also be adopted for
pre-emptive and iterrupt based code.
One big advantage that I see is that while this syntax can compile
to multitasking code on a uniprocessor it can also easily compile
to parallel execution on a multiprocessor. It gives you some nice
syntactic features from Linda and OCCAM with only a little code
on top of Forth.
Jeff Fox
Marty McGowan
h929...@hkuxa.hku.hk (Zsoter Andras) wrote:
>Skip Carter (sk...@taygeta.com) wrote:
>> And so Forth should be "tasking friendly". For OS level multi-tasking there
>> is nothing to do, but for multi-threading where more than one task is running within
>> the same process image it would be nice to be able to handle synchonization and visibility
>> in some way that is standard (approximately anyway).
>I think what should be in the standard is an optional wordset for IPC.
>Words for Semaphores, Mutexes, File/Record-locking and the like.
at the risk of beating my own drum, i'm talking about a general
C-Interface at "Rochester '96", where grafting Forth onto existing
standard, commercial and home-grown C interfaces becomes possible.
many interfaces are specified in C, let's use them. (PSOS, VRTX,
POSIX, ... )
>I don't mean that the standard should suggest to implement such words
>on a system which does not multitask but better be a standard name
>for those things so that IF they are implemented they should be called
>as so and so.
Call them whatever the implementation calls them; if your
applicaiont can use portabiility, then build bridges up or down from
Forth to C, or vice versa.
>(This idea does not address the issue whetther or not multitasking should
>be inside the language or in the underlying OS. The above tools would
>merely provide a way for processes to communicate regardless whether
>those processes are inside Forth or forked (spawned) by the OS.)
agreed. Nerhain Gehani invented Concurrent C about the time Bjarne
Stroustrup invented C++. For a time there was an attempt to maintain
a "Concurrent C++!" The verdict is in. Languages (incl Ada) don't
need mulit-/concurrency features.
>Andras
Ewald Pfau
sk...@taygeta.com (Skip Carter) wrote:
SC> And so Forth should be "tasking friendly". For OS level
SC> multi-tasking there is nothing to do, but for
SC> multi-threading where more than one task is running within
SC> the same process image it would be nice to be able to
SC> handle synchonization and visibility
SC> in some way that is standard (approximately anyway).
For a scheme as a rough proposal see below.
A debate about Forth tasking vs. OS tasking comes to my mind, held some good
time ago in a QL conference (the OS of that machine, QDOS, is a pre-emptive
tasking one, invented in 1984 by Tony Tebby).
There where strictly refusing arguments against asynchronous processes inside
of applications, coming from the ones who use syntax based compiler languages
(only knowing that scheme: here _the_ source, there _the_ program), demanding
for an OS, to be at any time in 'full control' of a machine for running _the_
programs.
Tasking has two sides: the one is allowing for different applications at the
same time. Pre-emptive tasking is just fine for this. As a burden for real time
applications, time slices come along, switching off CPU use in more or less
fixed intervals.
The other side is, to allow for 'factorizing' problems into quasi
simultaneously running logical layers. OS/2 uses the name 'threads' for this
and offers OS support. The burden remains here as well, that some generalized
assumptions are introcuded by the OS manufacturer, how a 'normal application'
may be expected to eat up CPU time. The administration overhead is the one for
bad behaving code which is supposed being tameable only by a strictly imposed
'divide et impera'.
Mostly, for Forth running asynchronous layers, those assumptions are simply
wrong, no matter how famous the name of the OS provider. The assumption is
based on linearly built code architectures. Since of now, such assumptions seem
to be based on the fixed idea, programming only is done in BASIC style (of
which, say PASCAL or 'C' from this view are just dialects) - applications, if
compiled, logically just consist of long linear series of GOTOs with myriads of
side-effects preventing re-entrancy.
Coming from Forth, you may introduce a different style - introduce quasi
asynchronous logical layers.
If some noise should be output from a speaker, in parallel while calculating
prime numbers and indexing some lot of filed data, so most tasking OS's just
turn this into a debugging session at OS level (how to install the OS-tasker).
Say, if one of the assumptions about linear (GOTO-) programming is one about
keyboard input handling, you will hear the speaker noise being frozen any time
you do not press a key. A lot of stupid things else happen like this.
If an OS just offers re-entrant ressources management (regarding CPU time just
to manage this), the benefit of a wizzard-fast Forth 'round-robin' may play a
fine role. There will be no other multitasker around, which will switch tasks
at a similar speed (re-entrant Forth coding being part of this issue).
But only the most dumb (straight-on) pre-emptive OS tasking schemes will
harmonize with this. The paradox might be encountered, to own a machine in
front of oneself, but not any more its CPU time. Just a case of based
assumptions.
*****
To offer, in spite of all this, a set of Forth tasking words as I have them in
regular use:
PAUSE ( -- // switch to next if any)
SELF ( -- id // find own id from inside a task;
as well start-address of user variables,
as well the hook for linking-in)
WAKE ( id -- // link into list)
SLEEP ( id -- // link out of list)
RUNS ( id -- // "name" // assign a new action to task 'id')
TASK: ( #r #s -- id // "name" // start definition of a task)
The execution token embedded after using something like
128 128 TASK: START-IN BEGIN RUN-IT 0= UNTIL ;
is hidden. Here, there is only one compiling task, which is the one not being
defined explicitely.
After saving an executable, defined tasks are ready for WAKE when the
executable is started again. The same holds for parts of code having been saved
as external objects when reloading them.
Here, a task may end and may be re-started then by WAKE. It is not necessarily
an endless loop. The 'pad' area and data dictionary allocated past defining a
task, are to be preserved together by '#s', with the parameter stack size.
For a running task, WAKE is a no-op. For a sleeping task, SLEEP is a no-op.
The hook for linking-in may be served from a 'ticker-interrupt' served routine,
so to start and to stop tasks as driven by clock information. For this, the
address gained by 'SELF' is a link field. The action " [ SELF ] LITERAL "
compiles the link field of the compiling task. For a sleeping task (or but the
compiling task being the only one), the contents and the address gained by SELF
are the same, so this following phrase holds:
: SLEEPS? SELF DUP @ = ;
A debugger only acts upon the runtime instance of that current active task from
where the debugger is started.
The above scheme has served a lot of purposes until now, like driving complete
applications (as again consisting of some lot of asynchronous layers) with free
interpreter access.
It _will_ make problems in OS environments as described above.
For an idea...
Ewald
Elizabeth Rather
A number of folks wanted X3J14 to consider multitasking, and several
people submitted proposed wordsets. The reason it failed to progress is
that there is a great deal of existing practice in this area, in
commercial as well as PD Forths, and all of it is so divergent in design
and assumptions that we realized _any_ single approach adopted by the TC
would "break" code relied upon by many users. Even a minimalist
approach of including only PAUSE and perhaps one or two other words
failed because there was no broad-based acceptance of what assumptions
they could embody.
If the fast majority of users of multitasking Forths are relying upon
some particular architecture, they aren't going to adopt the "ANSI way"
regardless of its merits, and we've all wasted a great deal of time.
Elizabeth D. Rather
FORTH, Inc. Products and services for
111 N. Sepulveda Blvd. professional Forth programmers
Manhattan Beach, CA 90266 since 1973. See us at:
310-372-8493/fax 318-7130 http://home.earthlink.net/~forth/