multitasking
SagaLore
handling it? If anyone has any links to how to implement multitasking, I
would be much obliged - I haven't seem to run across any examples or
explanations on it.
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 80,000 Newsgroups - 16 Different Servers! =-----
Marcel Hendrix
SagaLore <saga...@pcspower.net> wrote:
> How much overhead involves multitasking, and how efficient would forth be in
> handling it? If anyone has any links to how to implement multitasking, I
> would be much obliged - I haven't seem to run across any examples or
> explanations on it.
The last article I can remember was in Dr Dobbs, a few years ago. It
discussed a multitasker for eForth.
-marcel
Tom Zimmer
There is a nice little multi tasker included with Win32Forth. It is in a file
called TASKER.F, and it was written by Bill Muench. It is all high level Forth,
and includes a very simple example of usage, so you might want to look at that.
Tom Zimmer
SagaLore wrote:
> How much overhead involves multitasking, and how efficient would forth be in
> handling it? If anyone has any links to how to implement multitasking, I
> would be much obliged - I haven't seem to run across any examples or
> explanations on it.
>
Stan Barr
>In article <38d06...@goliath.newsfeeds.com>,
>> How much overhead involves multitasking, and how efficient would forth be in
>> handling it? If anyone has any links to how to implement multitasking, I
>> would be much obliged - I haven't seem to run across any examples or
>> explanations on it.
>
>discussed a multitasker for eForth.
>
See also Tim Hendtlass' "Real Time Forth" which has a chapter on multitasking.
It's available for downloading from the usual sources (sorry I don't have a
specific url for it). The source code in MULTASK.SEQ from F-PC is useful
reading as well.
--
Cheers,
Stan Barr st...@dial.pipex.com
The future was never like this!
Jerry Avins
>
> How much overhead involves multitasking, and how efficient would forth be in
> handling it? If anyone has any links to how to implement multitasking, I
> would be much obliged - I haven't seem to run across any examples or
> explanations on it.
>
> http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
> -----== Over 80,000 Newsgroups - 16 Different Servers! =-----
The cooperative multitasker in Z-80 POLYforth was quite effective, and
made a context switch in about as much time as the calling overhead of
two Forth words. The code, if I remember, fit on one screen (16 lines).
Another couple of screens supplied the supporting words: PAUSE, words to
schedule and deschedule tasks (TERMINAL, BACKGROUND, etc.), and to start
and stop other tasks and to access their dictionaries. I/O words were
two bytes larger. They included a call to PAUSE.
Jerry
--
Engineering is the art of making what you want from things you can get.
-----------------------------------------------------------------------
Jos v.d.Ven
SagaLore <saga...@pcspower.net> wrote:
> How much overhead involves multitasking, and how efficient would forth be
in
> handling it? If anyone has any links to how to implement multitasking, I
> would be much obliged - I haven't seem to run across any examples or
> explanations on it.
>
Charles Esson
http://forth.cx/multitaskingpaper/multitasking_paper.html
It talks about the requirements for real time control.
SagaLore wrote:
> How much overhead involves multitasking, and how efficient would forth be in
> handling it? If anyone has any links to how to implement multitasking, I
> would be much obliged - I haven't seem to run across any examples or
> explanations on it.
>
Brad Rodriguez
8051 CamelForth multitasker. See
<http://www.zetetics.com/bj/papers/8051task.pdf>.
Be advised, however, that this is *not* representative of the usual
overhead required by a Forth multitasker. On the 8051 I chose to copy
the internal stack out to RAM on a task switch, which gives more
flexibility (an unlimited number of tasks) but increases the overhead
substantially.
An earlier multitasker I wrote for the Zilog Super8 did a context switch
in about 13 usec, as I recall. This is much more typical of a Forth
multitasker (depending on CPU). I wrote a brief article (application
note?) some years back about the Super8 multitasker, but have not yet
posted it to my web site.
- Brad
SagaLore wrote:
>
> How much overhead involves multitasking, and how efficient would forth be in
> handling it? If anyone has any links to how to implement multitasking, I
> would be much obliged - I haven't seem to run across any examples or
> explanations on it.
>
> -----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
> http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
> -----== Over 80,000 Newsgroups - 16 Different Servers! =-----
--
Brad Rodriguez, Ph.D. T-Recursive Technology bj...@aazetetics.com
Email address spoofed to block spam. Remove "aa" from name & domain.
Embedded software & hardware design... http://www.zetetics.com/recursiv
See the CamelForth page at............ http://www.zetetics.com/camel
Elizabeth D. Rather
>
> SagaLore wrote:
> >
> > How much overhead involves multitasking, and how efficient would forth be in
> > handling it? If anyone has any links to how to implement multitasking, I
> > would be much obliged - I haven't seem to run across any examples or
> > explanations on it.
> >
> > -----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
> > http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
> > -----== Over 80,000 Newsgroups - 16 Different Servers! =-----
>
> made a context switch in about as much time as the calling overhead of
> two Forth words. The code, if I remember, fit on one screen (16 lines).
> Another couple of screens supplied the supporting words: PAUSE, words to
> schedule and deschedule tasks (TERMINAL, BACKGROUND, etc.), and to start
> and stop other tasks and to access their dictionaries. I/O words were
> two bytes larger. They included a call to PAUSE.
This is an algorithm that's been used in our products with little change
since the 70's, through a very large number of very demanding
applications, both embedded and desk-top. In the days before PCs became
cheap, we ran multiple users on a single box; I've taught programming
courses with 5 users on an 8085 and 16 on a 4.77 MHz PC-XT, all with
instantaneous response times. We once ran 128 tasks on a Z-80.
In 1974 we developed a database system for PacTel (big telephone co.)
that involved 16 terminals doing real-time updates to a 300 Mb database
(record size at the time). Our requirement was <1 sec. response time.
In fact, response time was <.1sec (instantaneous), so they doubled the
number of terminals, and it was still instantaneous. This was on a 64Kb
Data General Nova (older folks may remember them...).
As Jerry notes, all I/O pauses. This is the magic secret to making a
cooperative algorithm really effective: all I/O must relinquish the CPU
at least for the duration of the operation. Since most computers spend
most of their time waiting for I/O, this maximizes the cycles available
to all tasks. A cooperative algorithm is also most efficient because it
minimizes the amount of context that has to be saved and restored; on
most of our systems it consists of 3 registers.
Cheers,
Elizabeth
--
===============================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310-372-8493
111 N. Sepulveda Blvd. Fax: +1 310-318-7130
Manhattan Beach, CA 90266
http://www.forth.com
"Forth-based products and Services for real-time
applications since 1973."
===============================================
William J. Leary Jr.
> This was on a 64Kb Data General Nova (older folks
> may remember them...).
I reluctantly agree with the "older folks" part. I was very fond of the DG
Nova instruction set.
I was about to tag you on an error, since the Nova could only address 32K
words... but then I noticed you used "Kb" rather than just "K". And THEN I
remembered there were mods for the Nova that allowed up to 128K words (and
probably more, but I only worked with the 128Kw system).
- Bill
Jerry Avins
>
...
>
> In 1974 we developed a database system for PacTel (big telephone co.)
> that involved 16 terminals doing real-time updates to a 300 Mb database
> (record size at the time). Our requirement was <1 sec. response time.
> In fact, response time was <.1sec (instantaneous), so they doubled the
> Data General Nova (older folks may remember them...).
>
meeting. Would you like to borrow the manual for a bit of nostalgia?
Elizabeth D. Rather
>
> "Elizabeth D. Rather" wrote:
> >
> ...
> >
> > In 1974 we developed a database system for PacTel (big telephone co.)
> > that involved 16 terminals doing real-time updates to a 300 Mb database
> > (record size at the time). Our requirement was <1 sec. response time.
> > In fact, response time was <.1sec (instantaneous), so they doubled the
> > number of terminals, and it was still instantaneous. This was on a 64Kb
> > Data General Nova (older folks may remember them...).
> >
> Elizabeth, I was playing with a Nova 1200 around the time of our first
> meeting. Would you like to borrow the manual for a bit of nostalgia?
Thanks, but our library (which resembles a museum) has several :-)
Paul E. Bennett
era...@forth.com "Elizabeth D. Rather" writes:
> Jerry Avins wrote:
[%X]
> > Elizabeth, I was playing with a Nova 1200 around the time of our first
> > meeting. Would you like to borrow the manual for a bit of nostalgia?
>
> Thanks, but our library (which resembles a museum) has several :-)
As a matter of idle curiosity (no great shakes if you cannot off the top
of your head remember the figures) how big is the Forth Inc archive of
old code and how many processors does it cover? It sounds like it could
be an extremely valuable resource.
--
Paul E. Bennett ................... <p...@amleth.demon.co.uk>
Forth based HIDECS Consultancy .... <www.amleth.demon.co.uk>
Tel: +44 (0)7971-620145
Going Forth Safely
Chris Jakeman
>
> See also Tim Hendtlass' "Real Time Forth" which has a chapter on multitasking.
> It's available for downloading from the usual sources (sorry I don't have a
> specific url for it).
The FAQ Books has:
??, Hendtlass, Real-Time Forth (on-line in Postscript format from
www.forth.org at
ftp://ftp.taygeta.com/pub/Forth/Literature/rtf5pps.zip
--
Bye for now ____/ / __ / / / / /
/ / / _/ / / / /
Chris Jakeman __/ / / __ / / /_/
/ / / / / / / \
[Please unspam my __/ __/ ____/ ___/ __/ _\
address to reply]
Forth Interest Group United Kingdom
Voice +44 (0)1733 753489 chapter at http://forth.org.uk
SagaLore
> And I improved the multitasker in F-PC, my version multaskA.seq for
> 'All' or 'advanced' is able to abort at any place in any task without
> harm to the system. Dr. Ting and Tom Zimmer always stated, that that
> isn't possible, but I mangaged it :-)
Why does Dr. Ting and Mr. Zimmer feel it isn't possible? What reasons do
they give?
Wolfgang Allinger
On 01 Apr 00 at group /comp/lang/forth in article
<38e68...@goliath.newsfeeds.com>
<saga...@pcspower.net> (SagaLore) wrote:
>
>> And I improved the multitasker in F-PC, my version multaskA.seq for
>> 'All' or 'advanced' is able to abort at any place in any task
>> without harm to the system. Dr. Ting and Tom Zimmer always stated,
>> that that isn't possible, but I mangaged it :-)
>
>Why does Dr. Ting and Mr. Zimmer feel it isn't possible? What reasons
>do they give?
Couldn't find remarks to this problem by Dr. Ting, so it might be a
misinformation by me, but Tom made a statement in his multask.seq:
++++++++++++
ABORT note by Tom Zimmer 07/28/91 17:05:38.57
Typically small amounts of memory are assigned to each background task.
These memory amounts are in fact so small, that should any background
task encounter an error that causes it to vector through ABORT, then
F-PC will immediately detect an out of memory error since the space
between HERE and SP@ is very small in a typical task. It is therefore
imperative that a background task NOT be allowed to call ABORT.
------------
and from my multaskA.seq:
\ NOTAM: it seems, that I can do now ABORT in tasks, because I heavily
\ tinkered with (?error) (?error)' and better QUITnew
\ MULTIabort and more small stuff.
\ ALL980708
So it was not the problem of ABORT, but how (?error) ... QUIT handling
an ABORT. I didn't change the stack depth for the tasks, they are still
very small!
Bye from Germany
Wolfgang
--
FORTHing @ work | *Cheap* ...pick any
Dipl.-Ing. Wolfgang Allinger | *Fast* *Good* ... *two* of them
Germany ------------------------------------
## KreuzPunkt v3.12d R ## | reply address set
SagaLore
> >> And I improved the multitasker in F-PC, my version multaskA.seq for
> >> 'All' or 'advanced' is able to abort at any place in any task
> >> without harm to the system. Dr. Ting and Tom Zimmer always stated,
> >> that that isn't possible, but I mangaged it :-)
> >
> >Why does Dr. Ting and Mr. Zimmer feel it isn't possible? What reasons
> >do they give?
>
> Couldn't find remarks to this problem by Dr. Ting, so it might be a
> misinformation by me, but Tom made a statement in his multask.seq:
>
> ++++++++++++
> ABORT note by Tom Zimmer 07/28/91 17:05:38.57
>
> Typically small amounts of memory are assigned to each background task.
> These memory amounts are in fact so small, that should any background
> task encounter an error that causes it to vector through ABORT, then
> F-PC will immediately detect an out of memory error since the space
> between HERE and SP@ is very small in a typical task. It is therefore
> imperative that a background task NOT be allowed to call ABORT.
Ahh, I see. So it is an interpretor dependent problem.
Wolfgang Allinger
On 02 Apr 00 at group /comp/lang/forth in article
<38e76...@goliath.newsfeeds.com>
<saga...@pcspower.net> (SagaLore) wrote:
>> >> without harm to the system. Dr. Ting and Tom Zimmer always
>> >> stated, that that isn't possible, but I mangaged it :-)
>> >
>> >Why does Dr. Ting and Mr. Zimmer feel it isn't possible? What
>> >reasons do they give?
>>
>> ++++++++++++
>> ABORT note by Tom Zimmer 07/28/91 17:05:38.57
>>
>> Typically small amounts of memory are assigned to each background
[...]
>> task. It is therefore imperative that a background task NOT be
>> allowed to call ABORT.
>
>Ahh, I see. So it is an interpretor dependent problem.
No, its not, the problem is with (?error)... it's a design/
implementation error!
It's a bug and not a feature.
Didn't you read my explanations?
bye from germany
Andrew Haley
: Couldn't find remarks to this problem by Dr. Ting, so it might be a
: misinformation by me, but Tom made a statement in his multask.seq:
: ++++++++++++
: ABORT note by Tom Zimmer 07/28/91 17:05:38.57
: Typically small amounts of memory are assigned to each background task.
: These memory amounts are in fact so small, that should any background
: task encounter an error that causes it to vector through ABORT, then
: F-PC will immediately detect an out of memory error
: ------------
: So it was not the problem of ABORT, but how (?error) ... QUIT handling
: an ABORT.
Right. I don't knw F-PC at all. However, a very small background
task may well be better with no ABORT vector at all: in many cases
it's unnecessary, and in a system with a few hundred (or indeed a few
thousand) tasks it may be a significant saving. The minimum number of
bytes of user area for a background task may only be ten bytes or so.
Andrew.
Wolfgang Allinger
On 03 Apr 00 at group /comp/lang/forth in article
<8c9sj7$eo5$1...@korai.cygnus.co.uk>
<a...@cygnus.remove.co.uk> (Andrew Haley) wrote:
Hi Andrew,
yes, best not having an ABORT, but you can't be shure. There might be
one hidden deep in a kernel function and it bites you, when you didn't
need it.
So I decided on an ABORT I must first stop the tasker, then restore the
'OPERATOR' task environment. The OPERATOR task is the normal loop in F-
PC with QUIT ... Then perform the rest of the abort sequence and moan
which task had the abort and where it happened. I unravel and analyse
automatically the return stack of that nasty task and show the nesting.
In the moment 9 unraveled entries, thats more than most of my tasks are
nested.
Such a message might be similar to (I didn't remember excatly, because
no ABORTs are still happening in this application.)
" abort message " R: [2344] ABORT [4422] CHECKLIMITS [6652] .... more
nestings ... [A800] ADCloop [BC00] TASK3
So I can see, that it was from TASK3, nesting via ADCloop ... and in
CHECKLIMITS the ABORT happened. The cfa's are shown also in hex in [...]
So with my way, I'm still compatible to any words in F-PC, which ABORT,
I don't care how big or small their stacks are. My TASKstacks are some
30..100 bytes deep.
I also had some difficulties to recover from grafic mode to text mode
and start the editor ... again, but this is also possible now. I seldom
reboot the F-PC, since I tamed the ABORT and multitasker... :-)
So there was one guy with a mashed eMail addr, which asked for the
multitasker last week. It's still sitting in a ZIP with a lot af other
goodies and waiting for anybody who's interested :-) Some 256kB of
modifications to F-PC, few might only run under the F-PC-ak version of
Arndt Klingelnberg, however it should be easy to reconvert them back to
F-PC v3.60.
This samples are in F:\FPC-ALL\ALL.zip (you hav no acces to my
computers, however, I wrote the path here, so I know where to search),
if anybody will request & check/test this and might put it to taygeta,
he is wellcome. I'll ship him my modifications.
Andrew Haley
: >a very small background task may well be better with no ABORT
: >vector at all: in many cases it's unnecessary, and in a system with
: >a few hundred (or indeed a few thousand) tasks it may be a
: >significant saving. The minimum number of bytes of user area for a
: >background task may only be ten bytes or so.
: yes, best not having an ABORT, but you can't be shure. There might be
: one hidden deep in a kernel function and it bites you, when you didn't
: need it.
That's certainly possible, but I think it's only right to observe that
such a Forth is not suitable for any serious use.
For example, in a professional Forth suitable for real world use, you
can vector words like BLOCK to abort (or possibly retry) depending on
application requirements. This is really important. Only the
application task knows whether it's worth retrying or whether to fail.
This is an area where a native Forth is so much better than a
conventional OS, in which retrying is automatic and the application
gets no choice.
: So I decided on an ABORT I must first stop the tasker, then restore the
: 'OPERATOR' task environment.
But how do you know OPERATOR isn't doing something really important?
Andrew.
Wolfgang Allinger
On 04 Apr 00 at group /comp/lang/forth in article
<8ccau1$c5b$1...@korai.cygnus.co.uk>
<a...@cygnus.remove.co.uk> (Andrew Haley) wrote:
>I wrote:
>: >a very small background task may well be better with no ABORT
>: >vector at all: in many cases it's unnecessary, and in a system with
>: >a few hundred (or indeed a few thousand) tasks it may be a
>: >significant saving. The minimum number of bytes of user area for a
>: >background task may only be ten bytes or so.
>
>: yes, best not having an ABORT, but you can't be shure. There might
>be : one hidden deep in a kernel function and it bites you, when you
>didn't : need it.
>
>That's certainly possible, but I think it's only right to observe that
>such a Forth is not suitable for any serious use.
Oh I see :-( not serious? I have running systems at several plants, 3
shifts/day, 365 days/year. At Mercedes-Benz a system runs in a
production line and they didn't order a spare system. My system runs
rockstable, never any problems. It meassures geometric values with
resolutions down to 0.1 痠 and controls a final assembly machine. And I
have only a few 100msec to check these parts.
A other kind of system runs at Foxboro, also in the final assembly line.
They first only want 1 system and a spare system, no more. But these
system runs also rockstable, they never before had seen such a high
qualitity system. In the meantime they ordered a total of 17 systems.
And talking on 4 more :-). They fired all the other contractors with
their Windoze clickerdieclack BSOD and run my 'unserious' F-PCak (THX to
Tom Zimmer and Arndt Klingelberg) under DOS. I had to adapt my system to
any type of their high end controllers... Each day there are some 100k$
worth of manufactured controllers running through these adjustment
places.
>For example, in a professional Forth suitable for real world use, you
>can vector words like BLOCK to abort (or possibly retry) depending on
>application requirements. This is really important. Only the
>application task knows whether it's worth retrying or whether to fail.
That's not very interesting in my machines, I read data from the real
world. If there is any error, which I decided is a fault, then it
aborts. There is no chance to get this part a second time, because it's
still gone down the assembly line. So I had to stop and call somebody to
fix the problem.
>This is an area where a native Forth is so much better than a
>conventional OS, in which retrying is automatic and the application
>gets no choice.
Yes, forth is a much better system. And F-PC for PC is much better than
the commercial systems from LMI. Why? because I can fix any problems. I
have any sources. I can get any support I want. There is no ignorance or
arrogance. I got help whenever I need it and I gave help whenever I
could help.
>: So I decided on an ABORT I must first stop the tasker, then restore
>the : 'OPERATOR' task environment.
>
>But how do you know OPERATOR isn't doing something really important?
The OPERATOR task does nothing important, only waits for input from the
human operator. eg. if he presses enter-key three times without any
other keys, it starts again. Yes it is the Forth interpreter. So if
there ist any problem, the operator might input some words of a special
TEST vocabulary, to check printer or some mechanics... No, most of these
humans don't know, that they are typing forth words :-)
BTW I did ultrasonic testing machines running with some 60 湣, also made
3 system where 24 RTX2000 did the job in parallel, where I otherwise
need a farm of 256+ 8031/16MHz. There where some 300.000 meassurements
each second. Yes these RTX2000 where the first which run in Europe. The
1st chip my partner got as 1st price on a raffle by Harris at a Forth
conference @ UofR. And these system were very heavy realtime
applications for nuclear power plant testing machines.
Bye Wolfgang
Andrew Haley
: On 04 Apr 00 at group /comp/lang/forth in article
: <8ccau1$c5b$1...@korai.cygnus.co.uk>
: <a...@cygnus.remove.co.uk> (Andrew Haley) wrote:
: >: yes, best not having an ABORT, but you can't be shure. There might
: >be : one hidden deep in a kernel function and it bites you, when you
: >didn't : need it.
: >
: >That's certainly possible, but I think it's only right to observe that
: >such a Forth is not suitable for any serious use.
: Oh I see :-( not serious? I have running systems at several plants
I would have thought that this was obvious; any Forth system which can
abort unexpectedly in hidden functions in the kernel is IMO not
suitable for any serious use. I didn't say that people wouldn't use
it in such applications, just that it isn't suitable.
I'm amazed that you find this contentious; how can you use any system
where you don't know when kernel functions might unexpectedly abort
when they're supposed to be doing something important?
I would have thought that the right thing to do is to go through the
kernel finding out where the ABORTs are and decide whether to remove
them.
: >For example, in a professional Forth suitable for real world use, you
: >can vector words like BLOCK to abort (or possibly retry) depending on
: >application requirements. This is really important. Only the
: >application task knows whether it's worth retrying or whether to fail.
: That's not very interesting in my machines, I read data from the real
: world. If there is any error, which I decided is a fault, then it
: aborts.
There's a world of difference between your application deciding
there's a fault and the kernel ABORTing when your application didn't
expect it.
: >This is an area where a native Forth is so much better than a
: >conventional OS, in which retrying is automatic and the application
: >gets no choice.
: Yes, forth is a much better system. And F-PC for PC is much better than
: the commercial systems from LMI. Why? because I can fix any problems. I
: have any sources.
Please, to begin: "commercial" does not equate to "professional" or
"serious". There's a lot of great free software and a lot of clunky
unfree software. Much free software is of suitable for professional
use.
But if you have source, the problem you described of a kernel function
with a hidden ABORT shouldn't be possible. You already know which
functions might abort because you've read the kernel source.
I'm only talking about Forths like the one you described with hidden
aborts in kernel functions.
: >: So I decided on an ABORT I must first stop the tasker, then restore
: >the : 'OPERATOR' task environment.
: >
: >But how do you know OPERATOR isn't doing something really important?
: The OPERATOR task does nothing important
Oh, okay. You were describing how it works in your particular
application, which is fair enough. You weren't suggesting this as a
general mechanism, where OPERATOR might be doing something vital.
Andrew.
Marcel Hendrix
>
> On 04 Apr 00 at group /comp/lang/forth in article
> <8ccau1$c5b$1...@korai.cygnus.co.uk>
> <a...@cygnus.remove.co.uk> (Andrew Haley) wrote:
>
>> That's certainly possible, but I think it's only right to observe that
>> such a Forth is not suitable for any serious use.
>
> shifts/day, 365 days/year
I love these real-world stories!
-marcel
Jerry Avins
I want to back Alli up on this. In the industrial control systems I
built (and wrote), no serious work is done by a terminal task. OPERATOR
is usually idle, waiting for input, and perhaps another terminal task
writes status reports and scheduled maintenance demands, and accepts
status queries, from an auxiliary terminal. (It had been observed that
OPERATOR was occasionally being used for recreation or homework. The
danger of an ABORT being then too real, I closed that door.) Just as a
program will be factored into words that can be tested separately, a
good industrial controller will be factored into tasks whose
interactions will be few and explicit. If OPERATOR is doing something
vital, the system is, in my opinion, poorly factored. A fully-powered
OPERATOR, under the direction of a not-so-fully-powered operator, can be
counted on to crash any system sooner or later.
Jerry
--
Engineering is the art of making what you want from things you can get.
-----------------------------------------------------------------------
Andrew Haley wrote:
>
> Wolfgang Allinger (A...@business.forth-ev.de) wrote:
>
> : On 04 Apr 00 at group /comp/lang/forth in article
> : <8ccau1$c5b$1...@korai.cygnus.co.uk>
> : <a...@cygnus.remove.co.uk> (Andrew Haley) wrote:
>
> : >: yes, best not having an ABORT, but you can't be shure. There might
> : >be : one hidden deep in a kernel function and it bites you, when you
> : >didn't : need it.
> : >
> : >That's certainly possible, but I think it's only right to observe that
> : >such a Forth is not suitable for any serious use.
>
Wolfgang Allinger
On 05 Apr 00 at group /comp/lang/forth in article
<95493244...@dibbs3.eur.cis.philips.com>
<m.a.m....@nl.cis.philips.com> (Marcel Hendrix) wrote:
>Wolfgang Allinger wrote in message <7bGrd...@business.forth-ev.de>.
>>..
>> On 04 Apr 00 at group /comp/lang/forth in article
>> <8ccau1$c5b$1...@korai.cygnus.co.uk>
>> <a...@cygnus.remove.co.uk> (Andrew Haley) wrote:
>>
>>> That's certainly possible, but I think it's only right to observe
>>> that such a Forth is not suitable for any serious use.
>>
>> Oh I see :-( not serious? I have running systems at several plants,
>> 3 shifts/day, 365 days/year
>
>I love these real-world stories!
Hi Marcel
I love it too, it's never dull nor theoretic :-)
And I forgot to mention, that some of these system are running for
several years without crashes except powerline loss etc. However if
power was installed, they startup automatically and still work :-)
Wolfgang Allinger
On 05 Apr 00 at group /comp/lang/forth in article
<j...@ieee.org> (Jerry Avins) wrote:
>Andrew,
>
>I want to back Alli up on this. In the industrial control systems I
>built (and wrote), no serious work is done by a terminal task.
Yes!
>OPERATOR is usually idle, waiting for input, and perhaps another
>terminal task writes status reports and scheduled maintenance demands,
>and accepts status queries, from an auxiliary terminal. (It had been
>observed that OPERATOR was occasionally being used for recreation or
>homework.
Yeah, always the same old song.
>The danger of an ABORT being then too real, I closed that
>door.) Just as a program will be factored into words that can be
>tested separately, a good industrial controller will be factored into
>tasks whose interactions will be few and explicit. If OPERATOR is
>doing something vital, the system is, in my opinion, poorly factored.
ACK
>A fully-powered OPERATOR, under the direction of a
>not-so-fully-powered operator, can be counted on to crash any system
>sooner or later.
ACK you made my day :-)
But I also tamed the ABORT and I prefer it as a good way, to stop my
system. So it's no harm, if there is an unexpected/unknown abort deep
inside some kernel function. Machine stops, operator tell's me, what's
written on the screen. Remember I'm able to unravel the return stack and
nail down the the place, where the abort came from.
bye from germany
Wolfgang Allinger
On 05 Apr 00 at group /comp/lang/forth in article
<a...@cygnus.remove.co.uk> (Andrew Haley) wrote:
>I would have thought that this was obvious; any Forth system which can
>abort unexpectedly in hidden functions in the kernel is IMO not
>suitable for any serious use. I didn't say that people wouldn't use
>it in such applications, just that it isn't suitable.
>
>I'm amazed that you find this contentious; how can you use any system
>where you don't know when kernel functions might unexpectedly abort
>when they're supposed to be doing something important?
>I would have thought that the right thing to do is to go through the
>kernel finding out where the ABORTs are and decide whether to remove
>them.
No I'm not interested in doing so, if the kernel hit's an abort,
something strange has happened, normaly with my systems I can't recover
without operator handling. Abandoning all aborts from kernel will
complicate it. I don't speek for aborts due to a lousy programmer, but
aborts for timeouts etc are still fine.
So why not abort and stop the whole tasking. It's much more safe to wait
for a restart by the operator and not having the production line running
and producing dolls without heads! Because some tasks are still running
or try to recover gracefully.
Another example, if I lose control of the DUT via serial bus (I have
there some timeout aborts :-) , I can't do nothing exept stop the whole
testing machine. My program can't decide what to do and any operation
with an unsafe machine I may harm peoples. So the only thing I can do is
an emergency stop and cry for a human operator.
And the safest way is to stop definitely all multitasking.
And after my system aborts, it may be started up again without
rebooting, because I managed it to handle any unexpected abort.
Try this with other systems, one of the worst examples are windows PC's
in production lines, No chance to have a day without BSOD.
My systems never stop or hang as long as the hardware is ok.
At Daimler-Benz in Duesseldorf at the powersteering production line, I
think there are some 50 PC controlling lot's of things, my system is the
only one, which must never be rebooted. Yes, as I begun, they were
laughing on me with DOS and Forth, no there is nobodody laughing any
longer, exept me :-)
and startup without rebooting the system.
>There's a world of difference between your application deciding
>there's a fault and the kernel ABORTing when your application didn't
>expect it.
There might be an abort due to a timeout. And such an abort is a good
one. Also aborts due to a harddisk error is a good one.
>Please, to begin: "commercial" does not equate to "professional" or
>"serious". There's a lot of great free software and a lot of clunky
>unfree software. Much free software is of suitable for professional
>use.
ACK
>But if you have source, the problem you described of a kernel function
>with a hidden ABORT shouldn't be possible. You already know which
>functions might abort because you've read the kernel source.
Maybe I didn't make it clear, but I still want aborts and want to see,
from where the are initiated. And with my multitasker expansion I can
see it.
>Oh, okay. You were describing how it works in your particular
>application, which is fair enough. You weren't suggesting this as a
>general mechanism, where OPERATOR might be doing something vital.
I cant see a multitasker system, where the operator task does any
important stuff. The operator task should start the multitasking, but
any special job should be done by severals tasks. However my operator
task is normaly an endless loop, checking some function keys and
switching some display functions and controlling the order for the
special tasks...
Bye Wolfgang
Andrew Haley
: No I'm not interested in doing so, if the kernel hit's an abort,
: something strange has happened, normaly with my systems I can't recover
: without operator handling. Abandoning all aborts from kernel will
: complicate it.
Well, okay: but that's a special case. In many Forth apps there isn't
an operator to solve such problems, and sometimes a task is doing
something that can't be stopped. A servo loop is a good example of
this.
: >There's a world of difference between your application deciding
: >there's a fault and the kernel ABORTing when your application didn't
: >expect it.
: There might be an abort due to a timeout. And such an abort is a good
: one. Also aborts due to a harddisk error is a good one.
Well, maybe. Or maybe not. In truth, what the programmer should have
is choice; to abort, or retry, or whatever. And in your case abortion
is appropriate.
: >Oh, okay. You were describing how it works in your particular
: >application, which is fair enough. You weren't suggesting this as a
: >general mechanism, where OPERATOR might be doing something vital.
: I cant see a multitasker system, where the operator task does any
: important stuff.
Why not? In a deeply embedded system OPERATOR has nobody to talk to.
You might as well use it for something.
: The operator task should start the multitasking, but any special job
: should be done by severals tasks. However my operator task is
: normaly an endless loop, checking some function keys and switching
: some display functions and controlling the order for the special
: tasks...
Well, okay. That's true in your application.
Andrew.
Wolfgang Allinger
On 06 Apr 00 at group /comp/lang/forth in article
<8ci246$877$1...@korai.cygnus.co.uk>
<a...@cygnus.remove.co.uk> (Andrew Haley) wrote:
>Wolfgang Allinger (A...@business.forth-ev.de) wrote:
>
>: No I'm not interested in doing so, if the kernel hit's an abort,
>: something strange has happened, normaly with my systems I can't
>recover : without operator handling. Abandoning all aborts from kernel
>will : complicate it.
>
>Well, okay: but that's a special case. In many Forth apps there isn't
>an operator to solve such problems, and sometimes a task is doing
>something that can't be stopped. A servo loop is a good example of
>this.
A servo loop as I understand is something were a motor is controlled,
eg. a robots arm or a roler conveyor with 50tons of 900°C steel block...
When this servo loop runs in trouble, eg. cable is broken, if you are a
lucky guy, you might hit a timeout abort, the best you can do is an
emergency stop, or you may kill people :-( And the best emergency stop
in my Forth applications is, killing the multitasker.
So I can't see any chance in a production line on earth, were you can
still work with servos having trouble. It's an other story, if you
controll a robot on the Mars, if you managed to land it:-)
So I think servo loops are good examples for an abort.
>: I cant see a multitasker system, where the operator task does any
>: important stuff.
>
>Why not? In a deeply embedded system OPERATOR has nobody to talk to.
>You might as well use it for something.
Even in all my deeply embedded system, the operator task watches all the
time, if I want to jump in via serial interface or something else.
If the Operator task does any important job, I have a good chance, that
I loose control of the system. Because the operator task is busy with
something 'important' and I can't get it back under my control.
>
>: The operator task should start the multitasking, but any special job
>: should be done by severals tasks. However my operator task is
>: normaly an endless loop, checking some function keys and switching
>: some display functions and controlling the order for the special
>: tasks...
>
>Well, okay. That's true in your application.
I believe, it should be true on all applications.
Bye from Germany
Andrew Haley
: >Well, okay: but that's a special case. In many Forth apps there isn't
: >an operator to solve such problems, and sometimes a task is doing
: >something that can't be stopped. A servo loop is a good example of
: >this.
: A servo loop as I understand is something were a motor is controlled,
: eg. a robots arm or a roler conveyor with 50tons of 900°C steel block...
Or a glass microscope slide with a living tissue sample on it; the
servo holds the precious sample at an exact temperature.
: When this servo loop runs in trouble, eg. cable is broken, if you are a
: lucky guy, you might hit a timeout abort, the best you can do is an
: emergency stop, or you may kill people
If a cable is broken, sure: the servo is physically incapable of
functioning. But often a servo is responsible for holding something
steady, in which case in must never stop. No matter what.
: So I can't see any chance in a production line on earth, were you can
: still work with servos having trouble. It's an other story, if you
: controll a robot on the Mars, if you managed to land it:-)
Right. At last.
: >: The operator task should start the multitasking, but any special job
: >: should be done by severals tasks. However my operator task is
: >: normaly an endless loop, checking some function keys and switching
: >: some display functions and controlling the order for the special
: >: tasks...
: >
: >Well, okay. That's true in your application.
: I believe, it should be true on all applications.
With no display? With no serial port? At the bottom of the sea?
With 128 bytes of RAM?
Really?
Andrew.
Elizabeth D. Rather
>
> On 06 Apr 00 at group /comp/lang/forth in article
> <8ci246$877$1...@korai.cygnus.co.uk>
> <a...@cygnus.remove.co.uk> (Andrew Haley) wrote:
>
> >Wolfgang Allinger (A...@business.forth-ev.de) wrote:
> >
> >: No I'm not interested in doing so, if the kernel hit's an abort,
> >: something strange has happened, normaly with my systems I can't
> >recover : without operator handling. Abandoning all aborts from kernel
> >will : complicate it.
> >
> >an operator to solve such problems, and sometimes a task is doing
> >something that can't be stopped. A servo loop is a good example of
> >this.
> A servo loop as I understand is something were a motor is controlled,
> eg. a robots arm or a roler conveyor with 50tons of 900°C steel block...
> lucky guy, you might hit a timeout abort, the best you can do is an
> in my Forth applications is, killing the multitasker.
>
> still work with servos having trouble. It's an other story, if you
> controll a robot on the Mars, if you managed to land it:-)
>
Our Express industrial controls package has been used in industrial
environments where it's controlling >3,000 points (several points each
for numerous devices such as conveyors, lifts, dumpers, gates, etc.).
Such an application will have dozens of tasks running concurrently. A
breakdown of any of these devices (and they _do_ break, being frequently
very complicated mechanical devices) will have certain consequences that
must be carefully managed. For example, material may need to be shunted
to a different conveyor, or intake farther up the line restricted or
rerouted. Totally shutting down the system as in an ABORT would be
catastrophic. This is an important area where the use of CATCH/THROW
for handling unexpected events is particularly valuable, because at
various levels of the system you can decide, based on the THROW code,
whether to handle this event locally (and how) or pass it up to a higher
level in the system.
Cheers,
Elizabeth
Jerry Avins
I didn't think that we were discussing a case of mechanical breakdown
that the program can manage. Even a broken cable can elicit a sensible
response, maybe a loud recording: LOOK OUT BELOW! Some motions in
industrial systems need to be commanded to stop, otherwise they keep
going and going and .... Conveyors are often like that. Alli is writing
about what should happen when the program breaks. He allows it to break
for certain system errors, but it isn't necessary that it break for all.
Sometimes you want it to brake.
CATCH and THROW are very nice, but Alli's patch of F-PC has advantages,
too: the code fits into one mind, all of it accessible. Sometimes I
think that that's the only path to safety.
Wolfgang Allinger
On 07 Apr 00 at group /comp/lang/forth in article
<8ckcc7$t6a$1...@korai.cygnus.co.uk>
<a...@cygnus.remove.co.uk> (Andrew Haley) wrote:
>Wolfgang Allinger (A...@business.forth-ev.de) wrote:
[servos and ABORT...]
>If a cable is broken, sure: the servo is physically incapable of
>functioning. But often a servo is responsible for holding something
>steady, in which case in must never stop. No matter what.
I insist :-) if the system relies on a servo, holding something under
any condition, what about power fail to this servo? It can't hold it any
longer. If you have a system, which must clamp something under any
condition, you must have a mechanical lock. Otherwise you might harm
somebody.
>With no display? With no serial port? At the bottom of the sea?
>
>With 128 bytes of RAM?
>
>Really?
Yes, because this system never knows, when I wan't to ask it something.
I've made systems with only 2kB PROM and 64byte RAM, however even these
ones watch out for any intrusion of it's master (me) and don't do
anythink important in the background loop, that's the typical operators
task, where the system sit's, as long there is nothing else to do. The
only other things what an operator-task is allowed to do, anything what
not will hang in an endless loop.
Bye from germany
Wolfgang Allinger
On 07 Apr 00 at group /comp/lang/forth in article
<38EE18DD...@forth.com>
<era...@forth.com> (Elizabeth D. Rather) wrote:
>Wolfgang Allinger wrote:
[ ABORT in Multitasking]
>Our Express industrial controls package has been used in industrial
>environments where it's controlling >3,000 points (several points each
>for numerous devices such as conveyors, lifts, dumpers, gates, etc.).
>Such an application will have dozens of tasks running concurrently. A
>breakdown of any of these devices (and they _do_ break, being
>frequently very complicated mechanical devices) will have certain
>consequences that must be carefully managed.
Yes, but on these installation, a breakdown is a normal condition that
shouldn't trigger an ABORT.
>For example, material
>may need to be shunted to a different conveyor, or intake farther up
>the line restricted or rerouted. Totally shutting down the system as
>in an ABORT would be catastrophic. This is an important area where
>the use of CATCH/THROW for handling unexpected events is particularly
>valuable, because at various levels of the system you can decide,
>based on the THROW code, whether to handle this event locally (and
>how) or pass it up to a higher level in the system.
ACK, I agree, that different ways will end up in Rome :-)
So with a plant controlling system I also didn't like to have an ABORT.
So CATCH/TROW is better.
*My* forth systems are all working on a single machine (sometimes very
complicated), and if there is anything out of order, then I can't
operate it any longer, because there is no redundancy. If anything is
out of order e.g. I lost controll on a part of it, there is only one
safe state: stopping the system.
Bye from germany
Andrew Haley
: On 07 Apr 00 at group /comp/lang/forth in article
: <8ckcc7$t6a$1...@korai.cygnus.co.uk>
: <a...@cygnus.remove.co.uk> (Andrew Haley) wrote:
: >Wolfgang Allinger (A...@business.forth-ev.de) wrote:
: I insist :-) if the system relies on a servo, holding something under
: any condition, what about power fail to this servo?
Then it fails; if it cannot fail, and locks aren't possible, it must
have a reliable PSU. Of course most servos aren't safety critical;
some systems respond to power failure in a safe (but potentially
expensive) way. In that case, you want to know that the servo won't
stop simply because of some unforseen state in a computer. This is,
of course, a good reason why you might implement such a servo
controller in a dedicated computer.
: It can't hold it any longer. If you have a system, which must clamp
: something under any condition, you must have a mechanical
: lock.
But what about the example I posted (and you deleted)? No lock
possible there.
: >With no display? With no serial port? At the bottom of the sea?
: >
: >With 128 bytes of RAM?
: >
: >Really?
: Yes, because this system never knows, when I wan't to ask it something.
I don't get this at all. You are potentially making millions of these
things, and yet you want to devote memory in every device to a
potential operator. Even in devices with no physical way of
interacting.
Andrew.
Wolfgang Allinger
On 08 Apr 00 at group /comp/lang/forth in article
<38EFC11D...@ieee.org>
<j...@ieee.org> (Jerry Avins) wrote:
>CATCH and THROW are very nice, but Alli's patch of F-PC has
>advantages, too: the code fits into one mind, all of it accessible.
>Sometimes I think that that's the only path to safety.
ACK and my mind is a very small one :-) so it's very safe :-))
Bye from germany
Wolfgang Allinger
Wolfgang Allinger
On 10 Apr 00 at group /comp/lang/forth in article
<8cs4rk$72g$1...@korai.cygnus.co.uk>
<a...@cygnus.remove.co.uk> (Andrew Haley) wrote:
>I don't get this at all. You are potentially making millions of these
>things, and yet you want to devote memory in every device to a
>potential operator. Even in devices with no physical way of
>interacting.
Ok I see, we have different sights of systems, so do it your way and
I'll do it my way.
Bye from germany
Wolfgang
Andreas Kochenburger
>Andrew,
>I want to back Alli up on this. In the industrial control systems I
>is usually idle, waiting for input, and perhaps another terminal task
>writes status reports and scheduled maintenance demands, and accepts
>status queries, from an auxiliary terminal. (It had been observed that
>danger of an ABORT being then too real, I closed that door.) Just as a
>program will be factored into words that can be tested separately, a
>good industrial controller will be factored into tasks whose
>interactions will be few and explicit. If OPERATOR is doing something
>OPERATOR, under the direction of a not-so-fully-powered operator, can be
>counted on to crash any system sooner or later.
Control programs are very often organized in sequences that run
cyclically e.g. every 100ms. Slow process like tank level or
temperature control can run much slower. Thus you can have several
concurrent sequences of different cycles. The background or idle task
is often used for communication and MMI.
An error must not stop other sequences or the background task -
otherwise the machine would stop completely. That would not be
accepted.
An error will trigger a predefined shutdown sequence to drive the
machine to a defined state e.g. set outputs to zero, trigger alarms
and print a message, or switch controllers from auto to manual.
Object-oriented programming techniques go well together with RT
control development, since error reaction and startup behavior can be
programmed as class methods.
Andreas