Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #56858 > unrolled thread
| Started by | "HAA" <someone@microsoft.com> |
|---|---|
| First post | 2017-04-08 20:53 +1000 |
| Last post | 2017-04-10 07:42 -1000 |
| Articles | 20 on this page of 151 — 21 participants |
Back to article view | Back to comp.lang.forth
polyForth multitasker question "HAA" <someone@microsoft.com> - 2017-04-08 20:53 +1000
Re: polyForth multitasker question Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-08 12:29 -0500
Re: polyForth multitasker question "HAA" <someone@microsoft.com> - 2017-04-10 09:50 +1000
Re: polyForth multitasker question David Schultz <abuse@127.0.0.1> - 2017-04-09 19:25 -0500
Re: polyForth multitasker question "HAA" <someone@microsoft.com> - 2017-04-10 10:52 +1000
Re: polyForth multitasker question Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-10 08:58 -0500
Re: polyForth multitasker question "HAA" <someone@microsoft.com> - 2017-04-15 10:39 +1000
Re: polyForth multitasker question "HAA" <someone@microsoft.com> - 2017-04-11 11:12 +1000
Re: polyForth multitasker question Paul Rubin <no.email@nospam.invalid> - 2017-04-10 18:22 -0700
Re: polyForth multitasker question "HAA" <someone@microsoft.com> - 2017-04-11 12:17 +1000
Re: polyForth multitasker question Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-11 03:10 -0500
Re: polyForth multitasker question "Elizabeth D. Rather" <erather@forth.com> - 2017-04-09 14:37 -1000
Re: polyForth multitasker question Paul Rubin <no.email@nospam.invalid> - 2017-04-09 18:05 -0700
Re: polyForth multitasker question "Elizabeth D. Rather" <erather@forth.com> - 2017-04-09 15:50 -1000
Re: polyForth multitasker question Lars Brinkhoff <lars.spam@nocrew.org> - 2017-04-10 07:47 +0200
Re: polyForth multitasker question "HAA" <someone@microsoft.com> - 2017-04-10 12:20 +1000
Re: polyForth multitasker question Alex <alex@rivadpm.com> - 2017-04-10 09:11 +0100
Re: polyForth multitasker question Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-10 04:20 -0500
Re: polyForth multitasker question Alex <alex@rivadpm.com> - 2017-04-10 10:53 +0100
Re: polyForth multitasker question Alex <alex@rivadpm.com> - 2017-04-10 11:24 +0100
Re: polyForth multitasker question "HAA" <someone@microsoft.com> - 2017-04-11 12:05 +1000
Re: polyForth multitasker question Alex <alex@rivadpm.com> - 2017-04-11 14:27 +0100
Re: polyForth multitasker question minforth@arcor.de - 2017-04-11 07:08 -0700
Re: polyForth multitasker question foxaudioresearch@gmail.com - 2017-04-11 18:06 -0700
Re: polyForth multitasker question Paul Rubin <no.email@nospam.invalid> - 2017-04-11 18:58 -0700
Re: polyForth multitasker question foxaudioresearch@gmail.com - 2017-04-12 13:57 -0700
Re: polyForth multitasker question Paul Rubin <no.email@nospam.invalid> - 2017-04-12 18:02 -0700
Re: polyForth multitasker question foxaudioresearch@gmail.com - 2017-04-12 19:47 -0700
Re: polyForth multitasker question Paul Rubin <no.email@nospam.invalid> - 2017-04-12 21:22 -0700
Re: polyForth multitasker question foxaudioresearch@gmail.com - 2017-04-13 02:57 -0700
Re: polyForth multitasker question minforth@arcor.de - 2017-04-12 23:17 -0700
Re: polyForth multitasker question Paul Rubin <no.email@nospam.invalid> - 2017-04-13 00:13 -0700
Re: polyForth multitasker question "Elizabeth D. Rather" <erather@forth.com> - 2017-04-13 09:43 -1000
Re: polyForth multitasker question Paul Rubin <no.email@nospam.invalid> - 2017-04-13 19:34 -0700
Re: polyForth multitasker question "Elizabeth D. Rather" <erather@forth.com> - 2017-04-13 19:57 -1000
Re: polyForth multitasker question rickman <gnuarm@gmail.com> - 2017-04-14 02:45 -0400
Re: polyForth multitasker question "Elizabeth D. Rather" <erather@forth.com> - 2017-04-13 21:28 -1000
Re: polyForth multitasker question anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-14 07:53 +0000
Re: polyForth multitasker question Paul Rubin <no.email@nospam.invalid> - 2017-04-14 01:44 -0700
Re: polyForth multitasker question minforth@arcor.de - 2017-04-14 02:01 -0700
Re: polyForth multitasker question Paul Rubin <no.email@nospam.invalid> - 2017-04-14 11:28 -0700
Re: polyForth multitasker question rickman <gnuarm@gmail.com> - 2017-04-14 16:23 -0400
Re: polyForth multitasker question "Elizabeth D. Rather" <erather@forth.com> - 2017-04-13 22:46 -1000
Re: polyForth multitasker question anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-14 11:31 +0000
Re: polyForth multitasker question Paul Rubin <no.email@nospam.invalid> - 2017-04-14 11:23 -0700
Re: polyForth multitasker question "Elizabeth D. Rather" <erather@forth.com> - 2017-04-14 10:06 -1000
Re: polyForth multitasker question Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-14 08:13 -0500
Re: polyForth multitasker question anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-14 14:12 +0000
Re: polyForth multitasker question pahihu <pahihu@gmail.com> - 2017-04-14 09:30 -0700
Re: polyForth multitasker question anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-15 08:46 +0000
Re: polyForth multitasker question pahihu <pahihu@gmail.com> - 2017-04-15 13:07 -0700
Re: polyForth multitasker question Paul Rubin <no.email@nospam.invalid> - 2017-04-15 17:27 -0700
Re: polyForth multitasker question foxaudioresearch@gmail.com - 2017-04-15 18:18 -0700
Re: polyForth multitasker question anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-17 13:53 +0000
Re: polyForth multitasker question Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-14 11:34 -0500
Re: polyForth multitasker question hughaguilar96@gmail.com - 2017-04-14 11:31 -0700
Re: polyForth multitasker question Julian Fondren <julian.fondren@gmail.com> - 2017-04-14 12:14 -0700
Re: polyForth multitasker question hughaguilar96@gmail.com - 2017-04-14 12:46 -0700
Re: polyForth multitasker question hughaguilar96@gmail.com - 2017-04-14 12:48 -0700
Re: polyForth multitasker question hughaguilar96@gmail.com - 2017-04-14 12:50 -0700
Re: polyForth multitasker question albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-04-15 14:39 +0200
Re: polyForth multitasker question Julian Fondren <julian.fondren@gmail.com> - 2017-04-15 11:48 -0700
Re: polyForth multitasker question Alex <alex@rivadpm.com> - 2017-04-14 22:07 +0100
Re: polyForth multitasker question anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-15 16:47 +0000
Re: polyForth multitasker question "Elizabeth D. Rather" <erather@forth.com> - 2017-04-15 11:36 -1000
Re: polyForth multitasker question foxaudioresearch@gmail.com - 2017-04-15 17:07 -0700
Re: polyForth multitasker question "Elizabeth D. Rather" <erather@forth.com> - 2017-04-15 14:17 -1000
Re: polyForth multitasker question hughaguilar96@gmail.com - 2017-04-15 18:27 -0700
Re: polyForth multitasker question Ron Aaron <rambamist@gmail.com> - 2017-04-16 06:53 +0300
Re: polyForth multitasker question hughaguilar96@gmail.com - 2017-04-15 22:00 -0700
Re: polyForth multitasker question Ron Aaron <rambamist@gmail.com> - 2017-04-16 08:59 +0300
Re: polyForth multitasker question lehs <skydda.barnen@gmail.com> - 2017-04-15 22:19 -0700
Re: polyForth multitasker question hughaguilar96@gmail.com - 2017-04-15 17:26 -0700
Re: polyForth multitasker question Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-16 09:10 -0500
Re: polyForth multitasker question "Elizabeth D. Rather" <erather@forth.com> - 2017-04-16 09:13 -1000
Re: polyForth multitasker question anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-16 16:28 +0000
Re: polyForth multitasker question "Elizabeth D. Rather" <erather@forth.com> - 2017-04-16 09:27 -1000
Re: polyForth multitasker question Paul Rubin <no.email@nospam.invalid> - 2017-04-16 14:45 -0700
Re: polyForth multitasker question "Elizabeth D. Rather" <erather@forth.com> - 2017-04-16 17:50 -1000
Re: polyForth multitasker question anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-17 12:13 +0000
Re: polyForth multitasker question Paul Rubin <no.email@nospam.invalid> - 2017-04-17 13:27 -0700
Re: polyForth multitasker question Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-18 03:49 -0500
Re: polyForth multitasker question Alex <alex@rivadpm.com> - 2017-04-18 13:47 +0100
Re: polyForth multitasker question Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-18 14:30 -0500
Re: polyForth multitasker question hughaguilar96@gmail.com - 2017-04-16 20:58 -0700
Re: polyForth multitasker question "HAA" <someone@microsoft.com> - 2017-04-18 11:47 +1000
Re: polyForth multitasker question Paul Rubin <no.email@nospam.invalid> - 2017-04-17 19:19 -0700
Re: polyForth multitasker question Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-18 04:34 -0500
Re: polyForth multitasker question Paul Rubin <no.email@nospam.invalid> - 2017-04-19 02:00 -0700
Re: polyForth multitasker question "HAA" <someone@microsoft.com> - 2017-04-19 18:10 +1000
Re: polyForth multitasker question Paul Rubin <no.email@nospam.invalid> - 2017-04-19 01:41 -0700
Re: polyForth multitasker question "HAA" <someone@microsoft.com> - 2017-04-19 21:38 +1000
Re: polyForth multitasker question Lars Brinkhoff <lars.spam@nocrew.org> - 2017-04-19 10:56 +0200
Re: polyForth multitasker question Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-19 07:22 -0500
Re: polyForth multitasker question hughaguilar96@gmail.com - 2017-04-17 20:10 -0700
Re: polyForth multitasker question stephen@mpeforth.com (Stephen Pelc) - 2017-04-18 09:35 +0000
Re: polyForth multitasker question hughaguilar96@gmail.com - 2017-04-18 08:01 -0700
Re: polyForth multitasker question Julian Fondren <julian.fondren@gmail.com> - 2017-04-18 09:03 -0700
Re: polyForth multitasker question Cecil Bayona <cbayona@cbayona.com> - 2017-04-18 11:07 -0500
Re: polyForth multitasker question Cecil Bayona <cbayona@cbayona.com> - 2017-04-18 10:59 -0500
Re: polyForth multitasker question "HAA" <someone@microsoft.com> - 2017-04-19 19:13 +1000
Re: polyForth multitasker question Paul Rubin <no.email@nospam.invalid> - 2017-04-15 17:36 -0700
Re: polyForth multitasker question anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-16 16:27 +0000
Re: polyForth multitasker question Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-16 04:32 -0500
Re: polyForth multitasker question "Elizabeth D. Rather" <erather@forth.com> - 2017-04-14 10:15 -1000
Re: polyForth multitasker question albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-04-15 13:07 +0200
Re: polyForth multitasker question anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-17 15:13 +0000
Re: polyForth multitasker question Paul Rubin <no.email@nospam.invalid> - 2017-04-14 01:36 -0700
Re: polyForth multitasker question "Elizabeth D. Rather" <erather@forth.com> - 2017-04-13 22:48 -1000
Re: polyForth multitasker question rickman <gnuarm@gmail.com> - 2017-04-14 16:36 -0400
Re: polyForth multitasker question Paul Rubin <no.email@nospam.invalid> - 2017-04-14 14:55 -0700
Re: polyForth multitasker question hughaguilar96@gmail.com - 2017-04-14 15:27 -0700
Re: polyForth multitasker question Alex <alex@rivadpm.com> - 2017-04-14 23:45 +0100
Re: polyForth multitasker question hughaguilar96@gmail.com - 2017-04-16 21:13 -0700
Re: polyForth multitasker question Alex <alex@rivadpm.com> - 2017-04-17 16:57 +0100
Re: polyForth multitasker question hughaguilar96@gmail.com - 2017-04-17 20:08 -0700
Re: polyForth multitasker question rickman <gnuarm@gmail.com> - 2017-04-14 20:29 -0400
Re: polyForth multitasker question "Elizabeth D. Rather" <erather@forth.com> - 2017-04-14 15:34 -1000
Re: polyForth multitasker question Paul Rubin <no.email@nospam.invalid> - 2017-04-14 19:43 -0700
Re: polyForth multitasker question rickman <gnuarm@gmail.com> - 2017-04-14 23:03 -0400
Re: polyForth multitasker question Paul Rubin <no.email@nospam.invalid> - 2017-04-14 23:50 -0700
Re: polyForth multitasker question rickman <gnuarm@gmail.com> - 2017-04-15 03:55 -0400
Re: polyForth multitasker question Paul Rubin <no.email@nospam.invalid> - 2017-04-15 01:38 -0700
Re: polyForth multitasker question rickman <gnuarm@gmail.com> - 2017-04-15 11:50 -0400
Re: polyForth multitasker question john <anon@example.com> - 2017-04-15 12:03 +0100
Re: polyForth multitasker question anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-15 12:41 +0000
Re: polyForth multitasker question rickman <gnuarm@gmail.com> - 2017-04-15 12:14 -0400
Re: polyForth multitasker question Paul Rubin <no.email@nospam.invalid> - 2017-04-15 17:32 -0700
Re: polyForth multitasker question rickman <gnuarm@gmail.com> - 2017-04-15 20:41 -0400
Re: polyForth multitasker question anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-17 14:57 +0000
Re: polyForth multitasker question hughaguilar96@gmail.com - 2017-04-14 20:45 -0700
Re: polyForth multitasker question rickman <gnuarm@gmail.com> - 2017-04-14 23:56 -0400
Re: polyForth multitasker question albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-04-15 14:32 +0200
Re: polyForth multitasker question rickman <gnuarm@gmail.com> - 2017-04-15 12:05 -0400
Re: polyForth multitasker question Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-15 04:10 -0500
Re: polyForth multitasker question foxaudioresearch@gmail.com - 2017-04-13 03:19 -0700
Re: polyForth multitasker question Alex <alex@rivadpm.com> - 2017-04-13 15:46 +0100
Re: polyForth multitasker question foxaudioresearch@gmail.com - 2017-04-14 11:37 -0700
Re: polyForth multitasker question "Elizabeth D. Rather" <erather@forth.com> - 2017-04-13 09:48 -1000
Re: polyForth multitasker question Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-13 05:37 -0500
Re: polyForth multitasker question minforth@arcor.de - 2017-04-11 22:12 -0700
Multitasking with Forth processors Lars Brinkhoff <lars.spam@nocrew.org> - 2017-04-12 07:39 +0200
Re: Multitasking with Forth processors Paul Rubin <no.email@nospam.invalid> - 2017-04-11 22:58 -0700
Re: Multitasking with Forth processors rickman <gnuarm@gmail.com> - 2017-04-12 03:00 -0400
Re: Multitasking with Forth processors albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-04-12 12:18 +0200
Re: Multitasking with Forth processors rickman <gnuarm@gmail.com> - 2017-04-12 17:11 -0400
Re: Multitasking with Forth processors foxaudioresearch@gmail.com - 2017-04-12 13:50 -0700
Re: Multitasking with Forth processors "Elizabeth D. Rather" <erather@forth.com> - 2017-04-12 13:30 -1000
Re: Multitasking with Forth processors Jan Coombs <jenfhaomndgfwutc@murmic.plus.com> - 2017-04-14 12:20 +0100
Re: Multitasking with Forth processors rickman <gnuarm@gmail.com> - 2017-04-14 16:47 -0400
Re: polyForth multitasker question "Elizabeth D. Rather" <erather@forth.com> - 2017-04-10 07:42 -1000
Page 6 of 8 — ← Prev page 1 2 3 4 5 [6] 7 8 Next page →
| From | "HAA" <someone@microsoft.com> |
|---|---|
| Date | 2017-04-19 19:13 +1000 |
| Message-ID | <od79ob$13at$1@gioia.aioe.org> |
| In reply to | #57541 |
Stephen Pelc wrote: > On Mon, 17 Apr 2017 20:10:50 -0700 (PDT), hughaguilar96@gmail.com > wrote: > > >Nobody has ever written a commercial program in ANS-Forth > > That's a lie. Sure, you can wriggle, but the fact is that one of MPE's > customers ships a Forth appplication containing 1.2 million lines of > Forth source code. The application is built on VFX Forth, an ANS > Forth. > > There are other apps built on other ANS Forths. > > Stephen This looks like a re-telling of 'stone soup'.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2017-04-15 17:36 -0700 |
| Message-ID | <8737d9fat3.fsf@nightsong.com> |
| In reply to | #57381 |
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes: at least the O(n log(n)) implementation of looking up the next > task to be woken would probably be overkill. I'd expect O(log n) using a heap as priority queue.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-04-16 16:27 +0000 |
| Message-ID | <2017Apr16.182713@mips.complang.tuwien.ac.at> |
| In reply to | #57405 |
Paul Rubin <no.email@nospam.invalid> writes:
>anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
> at least the O(n log(n)) implementation of looking up the next
>> task to be woken would probably be overkill.
>
>I'd expect O(log n) using a heap as priority queue.
Yes, that's what I meant.
- 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: http://www.forth200x.org/forth200x.html
EuroForth 2016: http://www.euroforth.org/ef16/
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-04-16 04:32 -0500 |
| Message-ID | <tKidnbk8XMK5p27FnZ2dnUU7-TfNnZ2d@supernews.com> |
| In reply to | #57381 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >>>>> "Elizabeth D. Rather" <erather@forth.com> writes: >>>>>>In fact, it's far less complicated than that. Each task knows how >>>>>>long it's sleeping, and each time around the round-robin checks to >>>>>>see if it's wake-up time yet. A very few instructions each time. >>>>> >>>>> If you have 100 tasks waiting in MS, >>>> >>>>IMO, this is the wrong way to think about it. >>>> >>>>You probably don't, or at least it's unlikely in a system where most >>>>tasks are stopped most of the time waiting for some kind of I/O event. >>> >>> Then you have the same scaling problem. >> >>Not entirely, no: there a substantial difference between stopped tasks >>and tasks that are woken every time around the round robin. > > Makes me wonder why waiting for I/O is optimized in this way, but > waiting for the timer is not. Why wonder? It's not as if it hasn't already been explained in this thread, at length. >>> This approach has its charms, but the other approach of having a >>> scalable thing, giving the users the freedom to roam outside the >>> narrow confines of the implementor's imagination, also has its >>> advantages. >> >>I agree. It's a contrast between the "add the hooks and facilities >>now just in case" approach and the Forth approach that's described in >>Thinking Forth. One can lead to very neat, compact, and simple >>systems, and one leads to more complex but perhaps more scalable and >>general-purpose ones. > > It's a false dichotomy. You don't get a scalable and general-purpose > system by adding "hooks and facilities just in case", you get a > bloated system. You have to find a good balance, and the art is in > finding that balance. I agree with that too. I don't agree with you about where that line is, and that's not surprising: every programmer will have their own opinion, based on their own experience. I'm pretty sure that if you have a few tasks which need to pause occasionally, you do not need a solution which will scale to hundreds or thousands of tasks. > And the dogmas "minimize implementation complexity" and "minimize > functionality" that are advocated by many here are adverse to > finding a good balance. Nonsense. > People stop exploring the options, because the dogmas prevent them. Nonsense squared. Cubed, even! The point about simple systems is to find that sweet spot for the applications in hand. The idea is the exact opposite of missing functionality and special-purpose hacks: it's to do the right thing, to make it simple, and to make it beautiful. And that is not to install a priority queue just because you have half a dozen tasks occasionally doing MS. >>The Forth scheduler, despite its supposed lack of sophistication, was >>able to run many terminals on a lowly IBM PC even when it was >>supposedly "impossible" to run conventional multi-user systems on that >>hardware. > > Which multi-user system was that? VM/CMS? Or VMS? Yes, you cannot > run these systems on an IBM 5150. All of them, as far as I know. >>Those multi-user systems used things like priority queues >>and sophisticated schedulers, supposedly for efficiency, but such >>systems didn't scale *downwards*. Scalability goes in both >>directions! > > Doing the MS optimizations discussed here would certainly be > possible on an IBM PC, but with 256KB max (i.e., a few hundred tasks > at the most) at least the O(n log(n)) implementation of looking up > the next task to be woken would probably be overkill. You can't see the wood for the trees. It's not that a more complex MS implementation could not have been done on such a system. Simple systems are the result of hundreds or thousands of decisions, any one of which may be too small to make a measurable (or even noticeable) impact. Taken all together, however, they result in an elegant and well-engineered whole. > You probably don't want to do concurrency-oriented programming with > that little RAM, so you don't need the scalability. I don't understand what you mean by "concurrency-oriented programming" in this sentence. >> That "tiny hardware" probably makes up many (most?) of >>the computers in the world. > > That may be the case, but how many programmers program them? And > how many program them in Forth? If a few dozen programmers at Bosch > program the engine control microcontrolers for millions of cars, you > may count that as millions of computers, but I still count it as a > few dozen programmers. But even these few dozen probably don't > program in Forth, because Forth is not widespread enough. And the > unbalanced minimization dogmas have something to do with that. Or > in other words: If you give up the desktop, you also give up a large > part of the tiny computers. If all you do do with Forth is ape more conventional approaches, all you've got is Reverse Polish C with an interactive environment. There's no point in having that, IMO. If anything about Forth is worth having, it's the insistence on simplification. And the result of that simplification is that the application programmer can easily understand what is going on. >>Also, I'm thinking about the joy of knowing that the system you just >>shipped is the simplest cleanest, and (yes!) most perfect you know how >>to make. That's got to be worth something. > > Sure, it may get you a prize at a demo coding contest. In the rest of > the world, sorry, this is not worth much. It's an interesting philosophical point, though: whether it's ever worth an engineer doing something really well if the result can't be measured in dollars or microseconds. However, if you insist on being completely soulless, I do know that complex systems are hard to debug and test, and the usual response to that is to provide more complex and powerful tools to asist with that debugging and testing. In the case of MS in a simple polled loop, there is so little to go wrong that it can be seen at a glance to be correct; not so much priority queues. You could argue that because priority queues are so well understood they can be treated as black boxes. But every working programmer knows that black boxes go wrong, and then they have to be cracked open, and that takes time and costs money. And, of course, that decision will be iterated many times, for many subsystems. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2017-04-14 10:15 -1000 |
| Message-ID | <z76dnVsFzsFisGzFnZ2dnUU7-IPNnZ2d@supernews.com> |
| In reply to | #57290 |
On 4/14/17 4:12 AM, Anton Ertl wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >> Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >>> "Elizabeth D. Rather" <erather@forth.com> writes: >>>> In fact, it's far less complicated than that. Each task knows how >>>> long it's sleeping, and each time around the round-robin checks to >>>> see if it's wake-up time yet. A very few instructions each time. >>> >>> If you have 100 tasks waiting in MS, >> >> IMO, this is the wrong way to think about it. >> >> You probably don't, or at least it's unlikely in a system where most >> tasks are stopped most of the time waiting for some kind of I/O event. > > Then you have the same scaling problem. Not at all, if your tasks can actually be stopped waiting for an event you can manage a lot of them effortlessly. > Also, an example of a system with a huge number of tasks waiting on > timers is a game, where various agents in the game are implemented as > tasks. Some of these agents (and that can easily be hundreds or > thousands) just do something at various intervals, say every 5s; a > natural way to implement this is: > > begin do-something 5000 ms again > > [Yes, an interface that is not relative to the current time would be > even better than MS.] Yes, that's really the point I'm trying to make. >> If you really do need hundreds of tasks waiting in MS, then you can >> code a version of MS which is optimized for a large number of tasks. >> That version of MS is complicated because you'll have to maintain a >> priority queue. A fast priority queue with O(n log n) insertion time >> requires a heap or a balanced binary tree, and the result is more than >> an order of magnitude more complex than that simple version of MS. > > True, but it scales. What I think Andrew is saying is not to design a complicated scheme because you might need it some day, but to use a simple method and when the complex requirement arises, code for it. > As an intermediate variant, you can have a separate MS task list, and > scan that completely whenever the next MS timer is reached, and wakes > these tasks. Slightly more complex than the polling variant, but > already much more efficient. > >>> It's simple, but it does not scale. >> >> That's true. And it's a good thing. That's the big idea of Forth >> design: do the simple thing, and only if it turns out to be inadequate >> do the complicated thing. > > This approach has its charms, but the other approach of having a > scalable thing, giving the users the freedom to roam outside the > narrow confines of the implementor's imagination, also has its > advantages. That's the approach of OSs that can't be changed easily. Fortunately, Forth is so malleable that the freedom is inherent. Solve the problem you have, not the imaginary one you might have somedat. > In the present case, we know how to do the scalable thing, it's not > very expensive, and it has been used in other environments, so I think > that the advantages of the scalable approach outweigh the > disadvantages (unless you are on tiny hardware where you cannot afford > hundreds of tasks anyway). When I first met Leon Wagner he was working with a project that involved over 100 tasks on an 8080. I say do the simple way until you need more complexity. Cheers, Elizabeth -- Elizabeth D. Rather FORTH, Inc. 6080 Center Drive, Suite 600 Los Angeles, CA 90045 USA
[toc] | [prev] | [next] | [standalone]
| From | albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2017-04-15 13:07 +0200 |
| Message-ID | <ocsut2$v0f$1@cherry.spenarnc.xs4all.nl> |
| In reply to | #57277 |
In article <2017Apr14.095322@mips.complang.tuwien.ac.at>, Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >"Elizabeth D. Rather" <erather@forth.com> writes: >>In fact, it's far less complicated than that. Each task knows how long >>it's sleeping, and each time around the round-robin checks to see if it's >>wake-up time yet. A very few instructions each time. > >If you have 100 tasks waiting in MS, that's maybe 1000 instructions >and 100 cache line touches (20% of the L1 cache of a recent Intel CPU) >every time a working task PAUSEs. And if you have 1000 such tasks, >every PAUSE scrubs the L1 cache and causes 1000 L1 cache misses (i.e., >about 50000 cycles from the cache misses alone). It's simple, but it >does not scale. We all know that the Intel processors are a bad design, especially for this kind of thing. On a transputer e.g. the task switch between worker tasks would be instantaneous, and the I/O would be handled by high priority task that has hardware assisted invisible save of 3 (three) registers. And it scales very good. What Elizabeth sketches (and what you would do on a transputer) is have one task counting the MS, that would wake up other tasks. > >And it burns CPU when everything is waiting. If the CPU has nothing to do you waste computer power. Whether you waste energy that depends much of hardware design. There is no way you can avoid trouble on an Intel if there are more task switches per second than can accomodated. >- anton >-- Groetjes Albert -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-04-17 15:13 +0000 |
| Message-ID | <2017Apr17.171308@mips.complang.tuwien.ac.at> |
| In reply to | #57362 |
albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) writes:
>In article <2017Apr14.095322@mips.complang.tuwien.ac.at>,
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>"Elizabeth D. Rather" <erather@forth.com> writes:
>>>In fact, it's far less complicated than that. Each task knows how long
>>>it's sleeping, and each time around the round-robin checks to see if it's
>>>wake-up time yet. A very few instructions each time.
>>
>>If you have 100 tasks waiting in MS, that's maybe 1000 instructions
>>and 100 cache line touches (20% of the L1 cache of a recent Intel CPU)
>>every time a working task PAUSEs. And if you have 1000 such tasks,
>>every PAUSE scrubs the L1 cache and causes 1000 L1 cache misses (i.e.,
>>about 50000 cycles from the cache misses alone). It's simple, but it
>>does not scale.
>
>We all know that
has the same meaning as "It's not true that".
>the Intel processors are a bad design, especially for
>this kind of thing.
It's a poor craftsman that blames his tools. Remember Snabb
<https://lwn.net/Articles/713918/>? It runs on Intel processors and
has an average of 70ns (i.e. 1.4 T800 cycles) to process a packet.
> On a transputer e.g. the task switch between
>worker tasks would be instantaneous
Nothing is instantaneous; it's a bit hard to find numbers, but
<http://www.classiccmp.org/transputer/> claims that "process context
switching time can be as little as one microsecond.".
And the issue at hand is not the task switch (that would consume about
20 cycles (5ns @4GHz, 200 times faster than a transputer) on a recent
Intel CPU if the switched-to task is in L2 cache, and about 60 cycles
(15ns @4GHz, still 66 times faster than a transputer) if it is in L3
cache).
Instead, the issue is how to deal with waiting tasks. And there the
Forth, Inc. way has a similar issue on the transputer as on current
high-performance CPUs: Either you put the stuff that's accessed on
visiting into the on-chip RAM, consuming a significant amount of these
valuable resources, or you put it in off-chip RAM, and then going
through all the stopped tasks costs quite a bit of time, and going
through the "running" tasks that run MS costs even more time.
>What Elizabeth sketches (and what you would do on a transputer)
>is have one task counting the MS, that would wake up other
>tasks.
No, what she sketched is that the time is updated by an interrupt, and
every task waiting in MS is actually a "running" task that checks if
its time has come, and if not PAUSEs.
>>And it burns CPU when everything is waiting.
>
>If the CPU has nothing to do you waste computer power.
>Whether you waste energy that depends much of hardware design.
When you run code, this costs energy. Of course you can design
computers to burn just as much when halted, but that kind of design
has fallen out of favour quite some time ago. Instead, hardware
designers have made great efforts to burn less whenever the
opportunity offers itself.
>There is no way you can avoid trouble on an Intel if there
>are more task switches per second than can accomodated.
There is no way you can avoid trouble on anything if there are more
anything required than can be accomodated. But that is not the issue
at hand.
- 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: http://www.forth200x.org/forth200x.html
EuroForth 2016: http://www.euroforth.org/ef16/
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2017-04-14 01:36 -0700 |
| Message-ID | <87r30vgzd2.fsf@nightsong.com> |
| In reply to | #57273 |
"Elizabeth D. Rather" <erather@forth.com> writes: > It's nice if the hardware will sleep and wake you up in n > milliseconds, but then what if multiple tasks are waiting on different > intervals? That gets complicated. If someone is keeping track, that > takes cycles. Most schedulers these days have a priority queue of pending timeouts, so the hardware timer is set to wake up when the next timeout is due, the timeout is popped from the queue and serviced, and the scheduler then figures out how long to sleep til the next timeout is due. The scheduler probably also has to wake on interrupts.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2017-04-13 22:48 -1000 |
| Message-ID | <0pmdnYfoRM11EW3FnZ2dnUU7-UnNnZ2d@supernews.com> |
| In reply to | #57278 |
On 4/13/17 10:36 PM, Paul Rubin wrote: > "Elizabeth D. Rather" <erather@forth.com> writes: >> It's nice if the hardware will sleep and wake you up in n >> milliseconds, but then what if multiple tasks are waiting on different >> intervals? That gets complicated. If someone is keeping track, that >> takes cycles. > > Most schedulers these days have a priority queue of pending timeouts, so > the hardware timer is set to wake up when the next timeout is due, the > timeout is popped from the queue and serviced, and the scheduler then > figures out how long to sleep til the next timeout is due. The > scheduler probably also has to wake on interrupts. > The problem with that scenario is the amount of time spent in the scheduler as compared with the amt of time spend doing actual work. I've never seen a prioritized scheduler that didn't contribute a lot of overhead to the tasks to be done. Cheers, Elizabeth -- Elizabeth D. Rather FORTH, Inc. 6080 Center Drive, Suite 600 Los Angeles, CA 90045 USA
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-04-14 16:36 -0400 |
| Message-ID | <ocrbm2$c86$1@dont-email.me> |
| In reply to | #57278 |
On 4/14/2017 4:36 AM, Paul Rubin wrote: > "Elizabeth D. Rather" <erather@forth.com> writes: >> It's nice if the hardware will sleep and wake you up in n >> milliseconds, but then what if multiple tasks are waiting on different >> intervals? That gets complicated. If someone is keeping track, that >> takes cycles. > > Most schedulers these days have a priority queue of pending timeouts, so > the hardware timer is set to wake up when the next timeout is due, the > timeout is popped from the queue and serviced, and the scheduler then > figures out how long to sleep til the next timeout is due. The > scheduler probably also has to wake on interrupts. I can't picture a scheduler that handles asynchronous interrupts other than the scheduling hardware timer. The purpose of interrupts is to handle asynchronous events that need attention. That part of the code is kept as small as practical and the remaining part of the code can be handled by the scheduler waking a process on a periodic basis (or other means if you don't need a scheduler, like polling). The point is the scheduler really shouldn't be getting in the path of interrupts other than the scheduling timer. There is no need and it just complicates things. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2017-04-14 14:55 -0700 |
| Message-ID | <87a87ihcxe.fsf@nightsong.com> |
| In reply to | #57320 |
rickman <gnuarm@gmail.com> writes: > the remaining part of the code can be handled by the scheduler waking > a process on a periodic basis.. The point is the scheduler really > shouldn't be getting in the path of interrupts other than the > scheduling timer. There is no need and it just complicates things. Why wake a process on a periodic basis if nothing is happening? Example: an entry keypad on a door, that gets used a few times a day. There's no reason to burn power waking up every few msec to see if a button has been pressed. Instead, pressing a button raises an interrupt that wakes up the scheduler, which then figures out which task is waiting on the button press.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-04-14 15:27 -0700 |
| Message-ID | <434df736-1a19-4030-9975-d5ea46747bf2@googlegroups.com> |
| In reply to | #57329 |
On Friday, April 14, 2017 at 2:55:27 PM UTC-7, Paul Rubin wrote: > rickman <gnuarm@gmail.com> writes: > > the remaining part of the code can be handled by the scheduler waking > > a process on a periodic basis.. The point is the scheduler really > > shouldn't be getting in the path of interrupts other than the > > scheduling timer. There is no need and it just complicates things. > > Why wake a process on a periodic basis if nothing is happening? > Example: an entry keypad on a door, that gets used a few times a day. > There's no reason to burn power waking up every few msec to see if a > button has been pressed. Instead, pressing a button raises an interrupt > that wakes up the scheduler, which then figures out which task is > waiting on the button press. This seems obvious. The subject of multi-tasking has actually be figured out already. This was pretty well known as far back as the late 1970s. There is no need to speculate on the subject in 2017. Elizabeth Rather believes that every program has to be figured out from scratch, and that every program is different so a custom application-specific solution needs to be written. She believes that this results in super-optimized programs. No it doesn't! It results in a muddled mess written by programmers who don't know what they are doing (because they aren't able to learn from past experience) and don't have time to figure it out (because the application program has a deadline). If you have general-purpose code available, programming should be pretty straight-forward and easy --- not every program has to be a brain-buster --- you can invest your meager supply of brain-power in something other than figuring out programming problems that were done to death 40 years ago. An RTOS certainly counts as being general-purpose code --- there are several available in C --- none of the C programmers are speculating on how multi-tasking could be done, as if they were the first to ever encounter the problem. Similarly, in America the days of Lewis and Clark are long gone. Now we have fast reliable cars and a freeway system. We have maps (GPS too, although I don't have that). We have campgrounds and hostels, so you can sleep at night and not worry about getting eaten by a grizzly bear.
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-04-14 23:45 +0100 |
| Message-ID | <ocrj8n$868$1@dont-email.me> |
| In reply to | #57330 |
On 4/14/2017 23:27, hughaguilar96@gmail.com wrote: > This seems obvious. > > The subject of multi-tasking has actually be figured out already. > This was pretty well known as far back as the late 1970s. There is no > need to speculate on the subject in 2017. You do talk some serious shite bollox. https://lwn.net/Articles/224865/ -- Alex
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-04-16 21:13 -0700 |
| Message-ID | <591c0db0-ca03-428d-b92c-460ec97423ec@googlegroups.com> |
| In reply to | #57332 |
On Friday, April 14, 2017 at 3:45:38 PM UTC-7, Alex wrote: > On 4/14/2017 23:27, hughaguilar96@gmail.com wrote: > > This seems obvious. > > > > The subject of multi-tasking has actually be figured out already. > > This was pretty well known as far back as the late 1970s. There is no > > need to speculate on the subject in 2017. > > You do talk some serious shite bollox. > > https://lwn.net/Articles/224865/ > > -- > Alex The basics of multi-tasking were well known as far back as the late 1970s. As that article mentioned, there are still problems in working out the details, and there likely always will be. Just because you can show a link to a magazine article on the subject, doesn't mean that you know anything about the subject. To work out the details, it is necessary to start with a basic understanding of the subject. As I said, this basic understanding was figured out 40 years ago. Elizabeth Rather says: "you can't set a processor clock to interrupt you " She obviously doesn't have a basic understanding of how timers work, although timers have been available since the 1970s. She also spoke out against using full-duplex in a UART, although UARTS have been available since the 1970s and full-duplex the whole point (the 'A' means "asynchronous"). Elizabeth Rather doesn't know anything about computer programming --- she is an idiot salesperson --- anybody who takes her seriously on technical matters is making a fool of himself. Of course, you already told us that you: "do standards for a living" --- so making a fool of yourself now by accepting Elizabeth Rather as the "leading expert" on multi-tasking is redundant. P.S. Spelling the word "shit" as "Shite" is offensive to Shite Moslems. You are really a nasty piece of shit yourself!
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-04-17 16:57 +0100 |
| Message-ID | <od2oft$t8g$1@dont-email.me> |
| In reply to | #57474 |
On 4/17/2017 05:13, hughaguilar96@gmail.com wrote: > On Friday, April 14, 2017 at 3:45:38 PM UTC-7, Alex wrote: >> On 4/14/2017 23:27, hughaguilar96@gmail.com wrote: >>> This seems obvious. >>> >>> The subject of multi-tasking has actually be figured out already. Wot you said. >>> This was pretty well known as far back as the late 1970s. There >>> is no need to speculate on the subject in 2017. >> >> You do talk some serious shite bollox. >> >> https://lwn.net/Articles/224865/ >> >> -- Alex > > The basics of multi-tasking were well known as far back as the late > 1970s. No, Hugh, seriously? "The basics"? Where did you say that? You didn't; you're a lying shite*. They weren't well understood at all. For instance, mainframe schedulers were truly horrible and unpredictable. I worked on early versions of the https://en.wikipedia.org/wiki/Workload_Manager in the late 1980s and early 1990s. > > As that article mentioned, there are still problems in working out > the details, and there likely always will be. Just because you can > show a link to a magazine article on the subject, doesn't mean that > you know anything about the subject. And you do? Ha fucking ha. Don't make me laugh. > > P.S. Spelling the word "shit" as "Shite" is offensive to Shite > Moslems. You are really a nasty piece of shit yourself! > They're Shi'ites. You're a shite. *http://www.urbandictionary.com/define.php?term=shite -- Alex
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-04-17 20:08 -0700 |
| Message-ID | <415c883e-57f4-4c1d-accb-88be4592ca58@googlegroups.com> |
| In reply to | #57496 |
On Monday, April 17, 2017 at 8:57:46 AM UTC-7, Alex wrote: > On 4/17/2017 05:13, hughaguilar96@gmail.com wrote: > > As that article mentioned, there are still problems in working out > > the details, and there likely always will be. Just because you can > > show a link to a magazine article on the subject, doesn't mean that > > you know anything about the subject. > > And you do? Ha fucking ha. Don't make me laugh. I don't claim to be an expert on multi-tasking. I'm not really participating in this thread because I don't have any code to post. I'm just pointing out that the basic principles of multi-tasking were well-known in the 1970s. I know the basic principles (all programmers do). It is not necessary to start from total ignorance on the subject of multi-tasking --- it is reasonable to start from the basic principles. Elizabeth Rather is starting from (and ending at) total ignorance. She says that it is not possible to program a timer to interrupt the processor after a certain period of time. WTF??? Timers have had this capability since the 1970s (as Anton Ertl pointed out, this was done on the mighty Commodore-64). She says that it is necessary for the multi-tasker to sit in a spin-loop polling the timer. WTF??? This has never been a good idea. This may have been done in the 1960s because timers couldn't interrupt the processor --- I wouldn't know, as the 1960s were before my time --- Elizabeth Rather was a COBOL programmer back then and this is the source of all of her knowledge of programming that she continues to spout on comp.lang.forth in 2017. We have to stop considering Elizabeth Rather to be the "leading expert" of the Forth community. This just makes the entire Forth community look stupid. You seem to be happy with this, but that is because you are stupid anyway --- it is a problem for people who weren't born stupid --- this is why nobody wants to be a Forth programmer, and hasn't since 1994.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-04-14 20:29 -0400 |
| Message-ID | <ocrpc8$nqb$1@dont-email.me> |
| In reply to | #57329 |
On 4/14/2017 5:55 PM, Paul Rubin wrote: > rickman <gnuarm@gmail.com> writes: >> the remaining part of the code can be handled by the scheduler waking >> a process on a periodic basis.. The point is the scheduler really >> shouldn't be getting in the path of interrupts other than the >> scheduling timer. There is no need and it just complicates things. > > Why wake a process on a periodic basis if nothing is happening? > Example: an entry keypad on a door, that gets used a few times a day. > There's no reason to burn power waking up every few msec to see if a > button has been pressed. Instead, pressing a button raises an interrupt > that wakes up the scheduler, which then figures out which task is > waiting on the button press. I worked for a defense company some time back when they bought a small outfit to get a contract. The contract fell through and they farmed some other work out to these guys. It was a small MCU controlling a cabled remote control with a small display. They ended up writing the code 100% in interrupts. There was no main body of code. Our local software guy who was brought into the project late saw that and blew a gasket. After the company laid off all the guys from the remote office the local guy had the code rewritten to use interrupts the way they work well. In the case of a button being pressed the requirement in some cases was to perform a calculation that could take considerable time (from an MCU point of view). In the general case you would not want to do that in an interrupt routine. Tying the scheduler to an interrupt is a poor way to use an interrupt and makes it hard to do anything time critical using the other interrupts. The scheduler runs infrequently for tasks that are low priority and have little timing consequence. I don't know if you are that unfamiliar with the use of interrupts or if you are just pulling my chain. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2017-04-14 15:34 -1000 |
| Message-ID | <etmdnRPcX5Ix5WzFnZ2dnUU7-UnNnZ2d@supernews.com> |
| In reply to | #57337 |
On 4/14/17 2:29 PM, rickman wrote: > On 4/14/2017 5:55 PM, Paul Rubin wrote: >> rickman <gnuarm@gmail.com> writes: >>> the remaining part of the code can be handled by the scheduler waking >>> a process on a periodic basis.. The point is the scheduler really >>> shouldn't be getting in the path of interrupts other than the >>> scheduling timer. There is no need and it just complicates things. >> >> Why wake a process on a periodic basis if nothing is happening? >> Example: an entry keypad on a door, that gets used a few times a day. >> There's no reason to burn power waking up every few msec to see if a >> button has been pressed. Instead, pressing a button raises an interrupt >> that wakes up the scheduler, which then figures out which task is >> waiting on the button press. In polyFORTH, it's actually simpler than that. There is no "scheduler" per se. All tasks have a STATUS cell in their user area (actually, the first cell of the user area). When a task is idle, that cell contains a jump to the next task in sequence (unless the processor has provision for a 'sleep' state, which in the polyFORTH era most did not). When all tasks are idle, the processor is jumping from one to the next in a circular fashion. When an interrupt occurs, the interrupt code sets the STATUS cell to the routine that will wake it up (and may also do any time-critical steps, such as record which button was pressed). That's all. The task will wake up on its turn and will do all the rest of the processing. PAUSE leaves STATUS set to the wakeup code, so the task will wake up next time around the circuit, having given any other active tasks a chance to run. STOP leaves it idle, pending an interrupt to wake it up (or another task can give it something to do). > I worked for a defense company some time back when they bought a small > outfit to get a contract. The contract fell through and they farmed > some other work out to these guys. It was a small MCU controlling a > cabled remote control with a small display. They ended up writing the > code 100% in interrupts. There was no main body of code. Our local > software guy who was brought into the project late saw that and blew a > gasket. After the company laid off all the guys from the remote office > the local guy had the code rewritten to use interrupts the way they work > well. > > In the case of a button being pressed the requirement in some cases was > to perform a calculation that could take considerable time (from an MCU > point of view). In the general case you would not want to do that in an > interrupt routine. Tying the scheduler to an interrupt is a poor way to > use an interrupt and makes it hard to do anything time critical using > the other interrupts. The scheduler runs infrequently for tasks that > are low priority and have little timing consequence. Yes, that is normal. The polyFORTH multitasker has no concept of priority, although in one application long ago we had to give one task priority, and did so by giving it multiple slots in the round robin. In reality, most tasks are idle 99.999% of the time, and when awakened stay awake for only a few microseconds at most. Cheers, Elizabeth -- Elizabeth D. Rather FORTH, Inc. 6080 Center Drive, Suite 600 Los Angeles, CA 90045 USA
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2017-04-14 19:43 -0700 |
| Message-ID | <871ssugzm0.fsf@nightsong.com> |
| In reply to | #57337 |
rickman <gnuarm@gmail.com> writes: > They ended up writing the code 100% in interrupts. There was no main > body of code. Our local software guy who was brought into the project > late saw that and blew a gasket. That's a style that I've heard of. If all the stuff in the ISRs was quick enough I thought it was considered ok. > perform a calculation that could take considerable time. .. you would > not want to do that in an interrupt routine. Right. THe ISR would just log the event that the button had been pressed. The calculation then would be done by a scheduled task that picked up the logged event. Thta's why the ISR would wake up the scheduler. > The scheduler runs infrequently for tasks that are low priority and > have little timing consequence. I'd want pressing a button to have quick response (in human terms) if possible, like 100 msec. Are you saying to wake up the cpu at 10 hz, 24 hours a day? That doesn't sound like a good use of power. I'd only want to wake it when someone actually presses a button, which might be months. > I don't know if you are that unfamiliar with the use of interrupts or > if you are just pulling my chain. Maybe I don't understand or maybe we're not using the terminology the same way. I'm envisioning the scheduler as an event loop that reads logged events like timer tickets, button presses, etc. ISR's log the events, and the scheduler reads them and dispatches to tasks. If there are no events to process, the scheduler puts the cpu to sleep. Eventually, some ISR (maybe an alarm) wakes it back up. Seems pretty natural.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-04-14 23:03 -0400 |
| Message-ID | <ocs2cj$6r0$1@dont-email.me> |
| In reply to | #57341 |
On 4/14/2017 10:43 PM, Paul Rubin wrote: > rickman <gnuarm@gmail.com> writes: >> They ended up writing the code 100% in interrupts. There was no main >> body of code. Our local software guy who was brought into the project >> late saw that and blew a gasket. > > That's a style that I've heard of. If all the stuff in the ISRs was > quick enough I thought it was considered ok. > >> perform a calculation that could take considerable time. .. you would >> not want to do that in an interrupt routine. > > Right. THe ISR would just log the event that the button had been > pressed. The calculation then would be done by a scheduled task that > picked up the logged event. Thta's why the ISR would wake up the > scheduler. "Wake up the scheduler" is a term full of importance. Dig into that if you want to understand what is going on. >> The scheduler runs infrequently for tasks that are low priority and >> have little timing consequence. > > I'd want pressing a button to have quick response (in human terms) if > possible, like 100 msec. Are you saying to wake up the cpu at 10 hz, 24 > hours a day? That doesn't sound like a good use of power. I'd only > want to wake it when someone actually presses a button, which might be > months. How much power do you think it takes? What processor? What is the power source? >> I don't know if you are that unfamiliar with the use of interrupts or >> if you are just pulling my chain. > > Maybe I don't understand or maybe we're not using the terminology the > same way. I'm envisioning the scheduler as an event loop that reads > logged events like timer tickets, button presses, etc. ISR's log the > events, and the scheduler reads them and dispatches to tasks. If there > are no events to process, the scheduler puts the cpu to sleep. > Eventually, some ISR (maybe an alarm) wakes it back up. Seems pretty > natural. The point is there is a *lot* of ground to cover here. Of course you don't run a scheduler as a wait loop if you don't need to or if you don't have the power. But for an interrupt to "wake up" the scheduler requires a mechanism to do that. I just don't feel like digging into all the grody details so I described a timer based approach which others were already discussing. If you don't know how much power the timer based approach uses, and you don't know the details of the system, then why object? If you want to discuss a way to wake up the scheduler then which approach would you use? BTW, waking up nearly any embedded processor I have used at a 10 Hz rate would use barely any more power than the timer itself. -- Rick C
[toc] | [prev] | [next] | [standalone]
Page 6 of 8 — ← Prev page 1 2 3 4 5 [6] 7 8 Next page →
Back to top | Article view | comp.lang.forth
csiph-web