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 4 of 8 — ← Prev page 1 2 3 [4] 5 6 7 8 Next page →
| From | albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2017-04-15 14:39 +0200 |
| Message-ID | <oct49t$vgg$1@cherry.spenarnc.xs4all.nl> |
| In reply to | #57305 |
In article <981beee3-6be0-4552-b4e3-92ec56188304@googlegroups.com>,
Julian Fondren <julian.fondren@gmail.com> wrote:
>On Friday, April 14, 2017 at 1:31:04 PM UTC-5, hughag...@gmail.com wrote:
>> Consider this thread in which the ANS-Forth cult member Julien Fondren was trying to educate everybody on singly linked lists:
>> https://groups.google.com/forum/#!topic/comp.lang.forth/0-W-72ziaOo
>>
>> This was his code:
>>
>> : each[ ( list -- )
>> POSTPONE begin POSTPONE dup POSTPONE while ; immediate
>>
>> ( list -- list )
>>
>> : ]each ( list -- )
>> POSTPONE @ POSTPONE repeat POSTPONE drop ; immediate
>>
>> His code will work sometimes, but not always.
>...
>> My code is general-purpose; it works in every situation.
>
>No. There are some "super-simple cases" in which your code will work,
>but consider
>
> \ interim code accessing values left on the return stack
> >r each[ ... r@ ... ]each
>
> \ interim code not consuming the node on the data stack
> each[ dup . ]each
>
> \ interim code trying to skip ahead in the iteration
> each[ dup cell+ @ if @ @ @ then ]each
>
> \ interim code uses EXIT
> each[ 2dup cell+ @ = if 2drop true exit then ]each
>
>None of that works with your code. Your code isn't general-purpose,
>nor does it work in every situation. It evidently only works for the
>situations it was designed for! Honestly, it's disgusting.
That is unfair. That code violates the usage contract.
If you look at my 64 bit windows implementation you will
see a
CALL[ .............. CALL]
construct that has a similar limitation that the return
stack is engaged.
And closer to home, it is a limitation of DO ... LOOP
>
>And also, by preventing use of the return stack and by not reusing the
>value you push to the data stack, you're "exposing the internal
>workings of EACH[ ]EACH to the user", when "the whole point of
>abstraction is to hide the internal workings from the user"!
Really? Or are you just irritated by too grandiose claims?
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 | Julian Fondren <julian.fondren@gmail.com> |
|---|---|
| Date | 2017-04-15 11:48 -0700 |
| Message-ID | <f4bde96d-13db-4391-8689-a04d1c2c4308@googlegroups.com> |
| In reply to | #57368 |
On Saturday, April 15, 2017 at 7:38:29 AM UTC-5, Albert van der Horst wrote: > In article <981beee3-6be0-4552-b4e3-92ec56188304@googlegroups.com>, > Julian Fondren <julian.fondren@gmail.com> wrote: > > > >And also, by preventing use of the return stack and by not reusing the > >value you push to the data stack, you're "exposing the internal > >workings of EACH[ ]EACH to the user", when "the whole point of > >abstraction is to hide the internal workings from the user"! > > Really? Or are you just irritated by too grandiose claims? No, not really. I'm just throwing Hugh's absurd complaints back at him. That's what all those quotes are about.
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-04-14 22:07 +0100 |
| Message-ID | <ocrdgk$i2q$1@dont-email.me> |
| In reply to | #57302 |
On 4/14/2017 19:31, hughaguilar96@gmail.com wrote: > Consider this thread in which the ANS-Forth cult member Julien Fondren was trying to educate everybody on singly linked lists: > https://groups.google.com/forum/#!topic/comp.lang.forth/0-W-72ziaOo > > This was his code: > > : each[ ( list -- ) > POSTPONE begin POSTPONE dup POSTPONE while ; immediate > > ( list -- list ) > > : ]each ( list -- ) > POSTPONE @ POSTPONE repeat POSTPONE drop ; immediate > > His code will work sometimes, but not always. It won't work if the code inside needs access to data on the data-stack, because that data is covered up by the internal data of EACH[ ]EACH that is in the way. He is exposing the internal workings of EACH[ ]EACH to the user, although the whole point of abstraction is to hide the internal workings from the user. Also, his code won't work if the code inside changes the link field of the node that it is working on (see REMOVE in the novice-package). > > My code is general-purpose; it works in every situation. It was my code. Your original code had exactly the problem you describe above. https://groups.google.com/forum/#!original/comp.lang.forth/kH8lPSKdW30/-1Vd0hoyWUsJ -- Alex
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-04-15 16:47 +0000 |
| Message-ID | <2017Apr15.184706@mips.complang.tuwien.ac.at> |
| In reply to | #57293 |
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.
And of course, because all the stopped tasks are still visited when
there is a PAUSE, you incur the cache accesses (and cache evictions)
that I mentioned earlier. It will not incur the cost of executing the
checking code (and avoid the I-cache cost associated with that), but
whether these savings are substantial is in the eye of the beholder.
>> 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.
And the dogmas "minimize implementation complexity" and "minimize
functionality" that are advocated by many here are adverse to finding a
good balance. People stop exploring the options, because the dogmas
prevent them. And as a result, we get functionally deficient systems,
or alternatively, accumulations of special-purpose hacks, each of
which may satisfy the "minimize functionality to minimize
implementation complexity" meme, but in combination are not neat,
compact, and simple, but at least satisfy the "minimize functionality"
dogma by being inflexible.
>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.
>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 probably don't want
to do concurrency-oriented programming with that little RAM, so you
don't need the scalability.
But the IBM 5150 has long been replaced by machines with much more
RAM. Being nostalgic about the great deeds of the 70s and 80s, and
the principles that were helpful (or at least sufficient) at the time
does not help in finding a good balance for many of today's
programming problems.
> 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.
>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.
- 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 | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2017-04-15 11:36 -1000 |
| Message-ID | <z8qdnbfkl5j6D2_FnZ2dnUU7-YXNnZ2d@supernews.com> |
| In reply to | #57381 |
On 4/15/17 6:47 AM, Anton Ertl 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. Because you can't set a processor clock to interrupt you 10 seconds and 5 minutes from now, it ticks at whatever rate it ticks. All you can do is count the ticks in a very short interrupt routine, and a task that is waiting can look at the current tick count. A keyboard, on the other hand, can be ignored except when someone presses a key. > And of course, because all the stopped tasks are still visited when > there is a PAUSE, you incur the cache accesses (and cache evictions) > that I mentioned earlier. It will not incur the cost of executing the > checking code (and avoid the I-cache cost associated with that), but > whether these savings are substantial is in the eye of the beholder. Actually, they aren't "visited" in any real sense. There's a jump to the STATUS cell of the next task. A STOPped task contains a jump to the next STATUS cell, so the "checking code" is exactly one instruction. Only PAUSEd tasks will actually wake up briefly. Wakeup is typically half-dozen instructions. >>> 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. Yes. At least in FORTH, Inc.'s experience, this model has worked for all the applications we've encountered in quite a great many years, now. > And the dogmas "minimize implementation complexity" and "minimize > functionality" that are advocated by many here are adverse to finding a > good balance. People stop exploring the options, because the dogmas > prevent them. And as a result, we get functionally deficient systems, > or alternatively, accumulations of special-purpose hacks, each of > which may satisfy the "minimize functionality to minimize > implementation complexity" meme, but in combination are not neat, > compact, and simple, but at least satisfy the "minimize functionality" > dogma by being inflexible. The multitasker I've been describing was not appropriate for operating under Windows in SwiftForth, so we developed one that was. I don't know what the solution for the Linux/OSX Forth is, since that was after I retired. I do know that the model we've been talking about continues to work great in SwiftX kernels, which are all bare metal (no host OS). >> 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. Well, DOS and Windows on PCs. Before that, yes, it way out-performed VMS and whatever DEC, Data General, and other minicomputer OSs there were. At one point we put 4 terminals on an early 6800 development system that was supposed to be single-user. >> 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 probably don't want > to do concurrency-oriented programming with that little RAM, so you > don't need the scalability. The upper limit of tasks on a native Forth has always been how many the application needed, not hardware or timing resources. A task can be as small as 100 bytes or so. > But the IBM 5150 has long been replaced by machines with much more > RAM. Being nostalgic about the great deeds of the 70s and 80s, and > the principles that were helpful (or at least sufficient) at the time > does not help in finding a good balance for many of today's > programming problems. True. I am not worried about those. We are content with our capability to manage all the demands of our current customers. >> 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. I'm not sure that "unbalanced minimization dogmas" have anything whatever to do with Forth's popularity. Forth suffers because there isn't any publicity given to its successes and availability. >> 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. The problem is not that the "rest of the world" doesn't like what we're doing, it's because they don't know about it except a faint perception that it's a hobbyist toy. Cheers, Elizabeth -- Elizabeth D. Rather FORTH, Inc. 6080 Center Drive, Suite 600 Los Angeles, CA 90045 USA
[toc] | [prev] | [next] | [standalone]
| From | foxaudioresearch@gmail.com |
|---|---|
| Date | 2017-04-15 17:07 -0700 |
| Message-ID | <168c2a5c-e380-42c2-a6c3-e9a74a339197@googlegroups.com> |
| In reply to | #57391 |
"The problem is not that the "rest of the world" doesn't like what we're doing, it's because they don't know about it except a faint perception that it's a hobbyist toy. " I believe that is a true statement Elizabeth. And that is not a tech problem. That is a marketing and corporate communication problem. And the primary tool of marketing is... money. So there is the chicken and egg problem for Forth. (Note: I don't mean marketing the way sales reps think of marketing. I mean money invested strategically with some science behind it to move human thought.) BF
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2017-04-15 14:17 -1000 |
| Message-ID | <qPednWj16OiZJW_FnZ2dnUU7-T_NnZ2d@supernews.com> |
| In reply to | #57399 |
On 4/15/17 2:07 PM, foxaudioresearch@gmail.com wrote: > "The problem is not that the "rest of the world" doesn't like what we're > doing, it's because they don't know about it except a faint perception > that it's a hobbyist toy. " > > I believe that is a true statement Elizabeth. > > And that is not a tech problem. > That is a marketing and corporate communication problem. > > And the primary tool of marketing is... money. > > So there is the chicken and egg problem for Forth. > > (Note: I don't mean marketing the way sales reps think of marketing. > I mean money invested strategically with some science behind it to move human thought.) It needn't be expensive. Mostly it requires that all of you who are involved in professional Forth programming write to journalists with the main tech magazines/web sites describing your latest triumphs and why Forth was important in your success. Cheers, Elizabeth -- Elizabeth D. Rather FORTH, Inc. 6080 Center Drive, Suite 600 Los Angeles, CA 90045 USA
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-04-15 18:27 -0700 |
| Message-ID | <0f878c4a-0cb0-4adc-9e13-79ead10977a7@googlegroups.com> |
| In reply to | #57400 |
On Saturday, April 15, 2017 at 5:17:15 PM UTC-7, Elizabeth D. Rather wrote: > On 4/15/17 2:07 PM, foxaudioresearch@gmail.com wrote: > > "The problem is not that the "rest of the world" doesn't like what we're > > doing, it's because they don't know about it except a faint perception > > that it's a hobbyist toy. " > > > > I believe that is a true statement Elizabeth. > > > > And that is not a tech problem. > > That is a marketing and corporate communication problem. That is a true statement. The rest of the world considers Forth to be a hobbyist toy. This is because ANS-Forth lacks support for numbers and text, which are needed in serious programs. ANS-Forth has a severe tech problem. > > And the primary tool of marketing is... money. > > > > So there is the chicken and egg problem for Forth. > > > > (Note: I don't mean marketing the way sales reps think of marketing. > > I mean money invested strategically with some science behind it to move human thought.) > > It needn't be expensive. Mostly it requires that all of you who are > involved in professional Forth programming write to journalists with the > main tech magazines/web sites describing your latest triumphs and why > Forth was important in your success. Elizabeth Rather is only interested in describing the "triumphs" of those who brown-nose her, or whose work is safely obsolete --- she is not interested in describing the triumphs of those who compete against Forth Inc.. https://www.forth.com/resources/forth-programming-language/ Notice that the section on Forth processors doesn't mention the MiniForth/RACE. This is despite the fact that it was the only Forth processor in the 20th century that wasn't developed by Charles Moore. It doesn't bother me that she doesn't mention it --- I wouldn't expect a corporation to provide advertising space on its website for a competing product --- but I think that Elizabeth Rather is the worst choice for representing the "Forth community" because she is a salesperson for Forth Inc. and hence considers the Forth community to be competition.
[toc] | [prev] | [next] | [standalone]
| From | Ron Aaron <rambamist@gmail.com> |
|---|---|
| Date | 2017-04-16 06:53 +0300 |
| Message-ID | <ocuplb$qpk$1@dont-email.me> |
| In reply to | #57411 |
On 16/04/2017 4:27, hughaguilar96@gmail.com wrote: > That is a true statement. The rest of the world considers Forth to be a hobbyist toy. Question: how, exactly, do you know what "the rest of the world" thinks?
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-04-15 22:00 -0700 |
| Message-ID | <99c8502d-e9ee-434f-8a53-35173ae43438@googlegroups.com> |
| In reply to | #57418 |
On Saturday, April 15, 2017 at 8:53:12 PM UTC-7, Ron Aaron wrote: > On 16/04/2017 4:27, hughaguilar96@gmail.com wrote: > > > That is a true statement. The rest of the world considers Forth to be a hobbyist toy. > > Question: how, exactly, do you know what "the rest of the world" thinks? There are tens of millions of C programmers in the world (maybe even hundreds of millions). Ask them if they consider Forth to be capable of developing commercial application programs, or if they consider Forth to be a hobbyist toy. One of the C programmers is Anton Ertl. You can start by asking him. While you're at it, ask him if Gforth has ever been used to develop a commercial application program.
[toc] | [prev] | [next] | [standalone]
| From | Ron Aaron <rambamist@gmail.com> |
|---|---|
| Date | 2017-04-16 08:59 +0300 |
| Message-ID | <ocv11e$bf5$1@dont-email.me> |
| In reply to | #57421 |
On 16/04/2017 8:00, hughaguilar96@gmail.com wrote: > On Saturday, April 15, 2017 at 8:53:12 PM UTC-7, Ron Aaron wrote: >> On 16/04/2017 4:27, hughaguilar96@gmail.com wrote: >> >>> That is a true statement. The rest of the world considers Forth to be a hobbyist toy. >> >> Question: how, exactly, do you know what "the rest of the world" thinks? > > There are tens of millions of C programmers in the world (maybe even hundreds of millions). Ask them if they consider Forth to be capable of developing commercial application programs, or if they consider Forth to be a hobbyist toy. My question was, how you YOU know? Not "how might one know". As you're very well aware, it's not possible to ask "tens of millions of C programmers" anything at all. I happen to be a "C" programmer myself, by and large. And yet I use and develop Forth(s). You make a bald assertion of fact, but have nothing to back it up except hot air. Yes, Forth is not a popular language. No, that does not mean it's not used by professionals for commercial purposes. Nor does it mean it's not the best solution for some problems, despite "losing out" to C and other languages. I don't presume to know what "the rest of the world" thinks; but I do know you're full of it.
[toc] | [prev] | [next] | [standalone]
| From | lehs <skydda.barnen@gmail.com> |
|---|---|
| Date | 2017-04-15 22:19 -0700 |
| Message-ID | <2f65096b-d2c3-404e-b507-4b981ba7a775@googlegroups.com> |
| In reply to | #57418 |
I guess "the rest of the world" per definition is everyone that doesn't believe in Forth. The problem is not that Forth is fun. Just about any computer language is someones toy. Forth is not developed to suite major industrial interests, it's a very clever approach to programming which seems to be appropriate just for a few niches until now. I don't think there is a significant contraposition between different types of users. Increament of popularity among one type of users do not decrease the popularity among other potential users. Forth should maintain it's original apparence and be exposed to everybody for a long time run. And disunion is never a strength.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-04-15 17:26 -0700 |
| Message-ID | <bd17ef87-6051-4c7f-8a19-92cd708c762d@googlegroups.com> |
| In reply to | #57391 |
On Saturday, April 15, 2017 at 2:36:46 PM UTC-7, Elizabeth D. Rather wrote: > On 4/15/17 6:47 AM, Anton Ertl wrote: > > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: > >> 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. > > Because you can't set a processor clock to interrupt you 10 seconds and > 5 minutes from now, it ticks at whatever rate it ticks. All you can do > is count the ticks in a very short interrupt routine, and a task that is > waiting can look at the current tick count. A keyboard, on the other > hand, can be ignored except when someone presses a key. WTF??? Of course a timer can interrupt the processor periodically. It is not necessary to sit in a spin-loop polling the timer, waiting for it to indicate that 10 seconds and 5 minutes have passed --- you can put the processor to sleep and just let the timer throw an interrupt that wakes up the processor and activates the appropriate ISR.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-04-16 09:10 -0500 |
| Message-ID | <hridnbi6Hfb05m7FnZ2dnUU7-SednZ2d@supernews.com> |
| In reply to | #57391 |
Elizabeth D. Rather <erather@forth.com> wrote: > The multitasker I've been describing was not appropriate for operating > under Windows in SwiftForth, so we developed one that was. I don't know > what the solution for the Linux/OSX Forth is, since that was after I > retired. In SwiftFORTH for Linux, Forth tasks map 1:1 onto POSIX threads, which in turn map 1:1 onto Linux lightweight processes. It would have been possible to avoid using POSIX threads and just use kernel LWPs, but libraries on Linux-based systems often assume that all threads are POSIX threads. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2017-04-16 09:13 -1000 |
| Message-ID | <-rudndRzQZ7eX27FnZ2dnUU7-KWdnZ2d@supernews.com> |
| In reply to | #57441 |
On 4/16/17 4:10 AM, Andrew Haley wrote: > Elizabeth D. Rather <erather@forth.com> wrote: > >> The multitasker I've been describing was not appropriate for operating >> under Windows in SwiftForth, so we developed one that was. I don't know >> what the solution for the Linux/OSX Forth is, since that was after I >> retired. > > In SwiftFORTH for Linux, Forth tasks map 1:1 onto POSIX threads, which > in turn map 1:1 onto Linux lightweight processes. It would have been > possible to avoid using POSIX threads and just use kernel LWPs, but > libraries on Linux-based systems often assume that all threads are > POSIX threads. Good. I'm not surprised. Cheers, Elizabeth -- Elizabeth D. Rather FORTH, Inc. 6080 Center Drive, Suite 600 Los Angeles, CA 90045 USA
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-04-16 16:28 +0000 |
| Message-ID | <2017Apr16.182810@mips.complang.tuwien.ac.at> |
| In reply to | #57391 |
"Elizabeth D. Rather" <erather@forth.com> writes:
>On 4/15/17 6:47 AM, Anton Ertl 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.
>
>Because you can't set a processor clock to interrupt you 10 seconds and
>5 minutes from now, it ticks at whatever rate it ticks.
Even the old C-64 has chips that could be set up to generate
interrupts after some time. Microcontrollers also have such things; I
presented the case of the MSP 430 which can set up a clock to wake it
up after some time, and it can go to sleep in the mean time (stopping
the CPU clock until then). I am sure other microcontrollers have
similiar things.
> All you can do
>is count the ticks in a very short interrupt routine, and a task that is
>waiting can look at the current tick count. A keyboard, on the other
>hand, can be ignored except when someone presses a key.
The situation is just the same: The timer or the keyboard generates an
interrupt, and the interrupt handler (in an accordingly designed
system) can wake up the corresponding tasks.
>> And of course, because all the stopped tasks are still visited when
>> there is a PAUSE, you incur the cache accesses (and cache evictions)
>> that I mentioned earlier. It will not incur the cost of executing the
>> checking code (and avoid the I-cache cost associated with that), but
>> whether these savings are substantial is in the eye of the beholder.
>
>Actually, they aren't "visited" in any real sense. There's a jump to the
>STATUS cell of the next task. A STOPped task contains a jump to the next
>STATUS cell, so the "checking code" is exactly one instruction.
That status cell still has to be loaded into the L1 cache. If you
visit 100 such cells on each PAUSE, this means you typically have 100
cache lines (6.4KB) consumed for just the PAUSE; if you use jump
instructions, you also consume branch predictor resources.
>Wakeup is typically
>half-dozen instructions.
If you really rewrite jump instructions, it costs at least a cache
line flush and I-cache line load, which can be quite expensive; it
only happens on STOP and wakeup, so that should not be so bad.
>> Which multi-user system was that? VM/CMS? Or VMS? Yes, you cannot
>> run these systems on an IBM 5150.
>
>Well, DOS and Windows on PCs.
MS-DOS and MS Windows were not multi-user systems.
>> 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 probably don't want
>> to do concurrency-oriented programming with that little RAM, so you
>> don't need the scalability.
>
>The upper limit of tasks on a native Forth has always been how many the
>application needed, not hardware or timing resources. A task can be as
>small as 100 bytes or so.
Sure, but if these tasks are to do something useful, they need a
little more, that's how I computed my estimate.
>> 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.
>
>I'm not sure that "unbalanced minimization dogmas" have anything
>whatever to do with Forth's popularity. Forth suffers because there
>isn't any publicity given to its successes and availability.
Forth had good publicity in the 1980s. That's how I learned about
Forth. Why is there no longer any publicity?
Forth was sold as system where you can do a lot with very little
hardware. Worked fine in the early 80s. Then the hardware got more
plentiful, and the herd moved on to programming systems that need more
hardware, but offer various conveniences and features.
When Forthers are asked about these features and conveniences, many
explain that these are not needed and how you can work around their
absence; the rest of the world rather stays with the conveniences and
features.
So Forthers concentrated on microcontrollers, where their
little-hardware advantage still gave them an edge, and mostly
abandoned the desktop. But people learn programming on the desktop.
They learn Java or C++ or Python, and the distance to C seems not that
big. So when people decide on the programming language for an project
on a microcontroller, they often choose C, because it's easier to find
C programmers. So we have, e.g., MISRA-C (which may be what the Bosch
programmers are using), but not MISRA-Forth.
So what would a selling point on the desktop be?
Introspection? Forth used to have an edge there, but others have
caught up, while Forth has mostly abandoned this advantage.
Multi-tasking? Forth cannot do anything extraordinary on todays
desktops. Erlang can, and that's why it has more publicity (not
sure how that translates into users).
Associative arrays? Gforth has them (TABLE), so at least Gforth does
not lack this common feature of many popular languages, but that still
does make it stand out among those languages.
etc.
And for any such features, when somebody discusses them, we get
explanations that these features are not needed, that customers have
not asked for them, or if they have asked for them, they got the right
answer: do it yourself, because that's much better and much more
efficient, and you get a cleaner and neater system, and it builds
character. That may all be true, but it does not attract new users.
Of course, here again we have the problem of finding a good balance.
If we want to have Python or Erlang features, one might just as well
switch to Python or Erlang. There are certainly Forth qualities we
want to keep. The point I want to make is that minimalism alone leads
us to a dead end; we have to take a more balanced approach.
>The problem is not that the "rest of the world" doesn't like what we're
>doing, it's because they don't know about it except a faint perception
>that it's a hobbyist toy.
My guess is that the perception is as a thing of the (now-distant)
past. You like to blame poorly-documented hobbyist systems of the
1980s, but these systems are long gone. How come the professional
systems have not been able to overcome that problem? Could it be that
telling potential users that they don't need many of the features that
they expect as a matter of course has something to do with it.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2016: http://www.euroforth.org/ef16/
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2017-04-16 09:27 -1000 |
| Message-ID | <rvqdnRuRWN8PWG7FnZ2dnUU7-cHNnZ2d@supernews.com> |
| In reply to | #57456 |
On 4/16/17 6:28 AM, Anton Ertl wrote: > "Elizabeth D. Rather" <erather@forth.com> writes: >> On 4/15/17 6:47 AM, Anton Ertl 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. >> >> Because you can't set a processor clock to interrupt you 10 seconds and >> 5 minutes from now, it ticks at whatever rate it ticks. > > Even the old C-64 has chips that could be set up to generate > interrupts after some time. Microcontrollers also have such things; I > presented the case of the MSP 430 which can set up a clock to wake it > up after some time, and it can go to sleep in the mean time (stopping > the CPU clock until then). I am sure other microcontrollers have > similiar things. How many different concurrent timings can you have running on this clock? And when one times out, how many instructions does it take to decide which task to wake up? Using the MS counter, you can have unlimited concurrent timings under way, and management of each is trivial. >> All you can do >> is count the ticks in a very short interrupt routine, and a task that is >> waiting can look at the current tick count. A keyboard, on the other >> hand, can be ignored except when someone presses a key. > > The situation is just the same: The timer or the keyboard generates an > interrupt, and the interrupt handler (in an accordingly designed > system) can wake up the corresponding tasks. > >>> And of course, because all the stopped tasks are still visited when >>> there is a PAUSE, you incur the cache accesses (and cache evictions) >>> that I mentioned earlier. It will not incur the cost of executing the >>> checking code (and avoid the I-cache cost associated with that), but >>> whether these savings are substantial is in the eye of the beholder. >> >> Actually, they aren't "visited" in any real sense. There's a jump to the >> STATUS cell of the next task. A STOPped task contains a jump to the next >> STATUS cell, so the "checking code" is exactly one instruction. > > That status cell still has to be loaded into the L1 cache. If you > visit 100 such cells on each PAUSE, this means you typically have 100 > cache lines (6.4KB) consumed for just the PAUSE; if you use jump > instructions, you also consume branch predictor resources. Caches are mostly a contemporary PC thing, (mostly beyond the polyFORTH era). We're mainly talking embedded systems here. >> Wakeup is typically >> half-dozen instructions. > > If you really rewrite jump instructions, it costs at least a cache > line flush and I-cache line load, which can be quite expensive; it > only happens on STOP and wakeup, so that should not be so bad. > >>> Which multi-user system was that? VM/CMS? Or VMS? Yes, you cannot >>> run these systems on an IBM 5150. >> >> Well, DOS and Windows on PCs. > > MS-DOS and MS Windows were not multi-user systems. Exactly. polyFORTH was. >>> 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 probably don't want >>> to do concurrency-oriented programming with that little RAM, so you >>> don't need the scalability. >> >> The upper limit of tasks on a native Forth has always been how many the >> application needed, not hardware or timing resources. A task can be as >> small as 100 bytes or so. > > Sure, but if these tasks are to do something useful, they need a > little more, that's how I computed my estimate. If the task has a terminal-type user it needs more. A background task can do quite a lot of work with a very small user area. It's code is in shared memory. >>> 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. >> >> I'm not sure that "unbalanced minimization dogmas" have anything >> whatever to do with Forth's popularity. Forth suffers because there >> isn't any publicity given to its successes and availability. > > Forth had good publicity in the 1980s. That's how I learned about > Forth. Why is there no longer any publicity? > > Forth was sold as system where you can do a lot with very little > hardware. Worked fine in the early 80s. Then the hardware got more > plentiful, and the herd moved on to programming systems that need more > hardware, but offer various conveniences and features. > > When Forthers are asked about these features and conveniences, many > explain that these are not needed and how you can work around their > absence; the rest of the world rather stays with the conveniences and > features. > > So Forthers concentrated on microcontrollers, where their > little-hardware advantage still gave them an edge, and mostly > abandoned the desktop. But people learn programming on the desktop. > They learn Java or C++ or Python, and the distance to C seems not that > big. So when people decide on the programming language for an project > on a microcontroller, they often choose C, because it's easier to find > C programmers. So we have, e.g., MISRA-C (which may be what the Bosch > programmers are using), but not MISRA-Forth. > > So what would a selling point on the desktop be? FORTH, Inc. focuses on the desktop as a development station for embedded applications. Forth's advantages there remain enormous. > Introspection? Forth used to have an edge there, but others have > caught up, while Forth has mostly abandoned this advantage. > > Multi-tasking? Forth cannot do anything extraordinary on todays > desktops. Erlang can, and that's why it has more publicity (not > sure how that translates into users). > > Associative arrays? Gforth has them (TABLE), so at least Gforth does > not lack this common feature of many popular languages, but that still > does make it stand out among those languages. > > etc. > > And for any such features, when somebody discusses them, we get > explanations that these features are not needed, that customers have > not asked for them, or if they have asked for them, they got the right > answer: do it yourself, because that's much better and much more > efficient, and you get a cleaner and neater system, and it builds > character. That may all be true, but it does not attract new users. > > Of course, here again we have the problem of finding a good balance. > If we want to have Python or Erlang features, one might just as well > switch to Python or Erlang. There are certainly Forth qualities we > want to keep. The point I want to make is that minimalism alone leads > us to a dead end; we have to take a more balanced approach. > >> The problem is not that the "rest of the world" doesn't like what we're >> doing, it's because they don't know about it except a faint perception >> that it's a hobbyist toy. > > My guess is that the perception is as a thing of the (now-distant) > past. You like to blame poorly-documented hobbyist systems of the > 1980s, but these systems are long gone. How come the professional > systems have not been able to overcome that problem? Could it be that > telling potential users that they don't need many of the features that > they expect as a matter of course has something to do with it. I think none of us (companies and users) have made a sufficient effort to tell the story of the advantages Forth has, the positive aspects. Cheers, Elizabetg -- 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-16 14:45 -0700 |
| Message-ID | <87y3v0do1s.fsf@nightsong.com> |
| In reply to | #57459 |
"Elizabeth D. Rather" <erather@forth.com> writes: > How many different concurrent timings can you have running on this > clock? And when one times out, how many instructions does it take to > decide which task to wake up? It's usually enough to have just one timer, which you set to wake up when the next task is due to run. On the wakeup, you run that task and also figure out when the next task is due to run, and reset the timer. The usual algorithm for that might take 50-100 cycles (log n + some overhead) even if the number of tasks is quite large. In the 1 mhz 6502 era that might have hurt. In the 100+ mhz Cortex era it's probably ok. > Caches are mostly a contemporary PC thing, (mostly beyond the > polyFORTH era). We're mainly talking embedded systems here. True. >> MS-DOS and MS Windows were not multi-user systems. > Exactly. polyFORTH was. Certainly there were even older and slower multi-user systems: Unix started on the PDP-11, for example. > FORTH, Inc. focuses on the desktop as a development station for > embedded applications. Forth's advantages there remain enormous. ... > I think none of us (companies and users) have made a sufficient effort > to tell the story of the advantages Forth has, the positive aspects. For my own interests (recreation and trying to exercise a minimalist programming mindset that's useful in other areas) I'm not too worried about the productivity advantages, important for commercial dev environments, that Forth might or might not have. But even after messing with Forth for a number of years now, I'm still not convinced those advantages are really there. However, I haven't yet used it for embedded stuff, which is its strongest area these days.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2017-04-16 17:50 -1000 |
| Message-ID | <P62dnRa426APpmnFnZ2dnUU7-YPNnZ2d@supernews.com> |
| In reply to | #57460 |
On 4/16/17 11:45 AM, Paul Rubin wrote: > "Elizabeth D. Rather" <erather@forth.com> writes: >> How many different concurrent timings can you have running on this >> clock? And when one times out, how many instructions does it take to >> decide which task to wake up? > > It's usually enough to have just one timer, which you set to wake up > when the next task is due to run. On the wakeup, you run that task and > also figure out when the next task is due to run, and reset the timer. > The usual algorithm for that might take 50-100 cycles (log n + some > overhead) even if the number of tasks is quite large. In the 1 mhz 6502 > era that might have hurt. In the 100+ mhz Cortex era it's probably ok. That sounds like a time-slicing algorithm. The ones I'm familiar with are complete asynchronous, event-driven operations. A terminal task is asleep until someone types some commands and presses the RETURN key, then it processes them. A data acquisition task may have no terminal at all, but has an interrupt routine that samples data ever 10 ms. and puts it in a circular queue; the task runs when it gets the CPU, processing whatever samples have come in and storing them on disk. A communications task responds to whatever streams come in on the port it's responsible for, storing the data or perhaps even transmitting it to another destination. Each has its own completely different timing needs, which it alone controls. These kinds of applications don't need or benefit from a central scheduler. They can be made to run that way, but not efficiently. >> Caches are mostly a contemporary PC thing, (mostly beyond the >> polyFORTH era). We're mainly talking embedded systems here. > > True. > >>> MS-DOS and MS Windows were not multi-user systems. >> Exactly. polyFORTH was. > > Certainly there were even older and slower multi-user systems: Unix > started on the PDP-11, for example. Yes. >> FORTH, Inc. focuses on the desktop as a development station for >> embedded applications. Forth's advantages there remain enormous. ... >> I think none of us (companies and users) have made a sufficient effort >> to tell the story of the advantages Forth has, the positive aspects. > > For my own interests (recreation and trying to exercise a minimalist > programming mindset that's useful in other areas) I'm not too worried > about the productivity advantages, important for commercial dev > environments, that Forth might or might not have. But even after > messing with Forth for a number of years now, I'm still not convinced > those advantages are really there. However, I haven't yet used it for > embedded stuff, which is its strongest area these days. I think it's really hard to learn Forth when you don't have a real application to work on. Many of the programmers I've taught have been hired to maintain an application that exists or is in development. That way they have examples of how various components work together. SwiftForth and SwiftX come with some sample programs, which are worthy of study as example, and probably would benefit from having more. Cheers, Elizabeth -- Elizabeth D. Rather FORTH, Inc. 6080 Center Drive, Suite 600 Los Angeles, CA 90045 USA
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-04-17 12:13 +0000 |
| Message-ID | <2017Apr17.141336@mips.complang.tuwien.ac.at> |
| In reply to | #57459 |
"Elizabeth D. Rather" <erather@forth.com> writes:
>On 4/16/17 6:28 AM, Anton Ertl wrote:
>> "Elizabeth D. Rather" <erather@forth.com> writes:
>>> On 4/15/17 6:47 AM, Anton Ertl 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.
>>>
>>> Because you can't set a processor clock to interrupt you 10 seconds and
>>> 5 minutes from now, it ticks at whatever rate it ticks.
>>
>> Even the old C-64 has chips that could be set up to generate
>> interrupts after some time. Microcontrollers also have such things; I
>> presented the case of the MSP 430 which can set up a clock to wake it
>> up after some time, and it can go to sleep in the mean time (stopping
>> the CPU clock until then). I am sure other microcontrollers have
>> similiar things.
>
>How many different concurrent timings can you have running on this
>clock?
One is sufficient (although the C-64 had four 16-bit timers, and each
pair could be combined to a 32-bit timer): You set the timer to the
closest deadline.
> And when one times out, how many instructions does it take to
>decide which task to wake up?
One option is to tell the interrupt handler which task to wake up when
the timer is set up. In that case it does not take any instructions
after timeout (but of course, with your implementation of round-robin
and stopped tasks, there is still the time that's needed to go through
all the running and stopped tasks in front of our freshly-woken task,
but at least the tasks in MS are now treated as stopped and are thus
faster).
The rest of the MS code will then have to go through the MS-stopped
tasks, wake the ones whose time has come, find the one with the
closest not-yet-passed time, and set up the timer to interrupt at the
time, and set up the timer interrupt to wake that task.
You can do this with a linear list walk (taking O(n) time), and that
will cost about as much as the round-robin visits to the MS tasks cost
in your system (but it incurs that cost only when an MS task wakes,
not on every PAUSE). Or you can use a more sophisticated data
structure for better efficiency and scalability. A well-known one is
the binary heap, where the insertion of a task costs O(ln n), and the
removal of the task with the least timeout is also O(ln n). Should
take <100 lines of code to implement.
Actually MS cannot be the only word where more tasks are associated
with the same interrupt. A similar problem must have occured with
BLOCK. I.e., several tasks wanting to read from disk with BLOCK. How
was that solved?
>>> Actually, they aren't "visited" in any real sense. There's a jump to the
>>> STATUS cell of the next task. A STOPped task contains a jump to the next
>>> STATUS cell, so the "checking code" is exactly one instruction.
>>
>> That status cell still has to be loaded into the L1 cache. If you
>> visit 100 such cells on each PAUSE, this means you typically have 100
>> cache lines (6.4KB) consumed for just the PAUSE; if you use jump
>> instructions, you also consume branch predictor resources.
>
>Caches are mostly a contemporary PC thing, (mostly beyond the polyFORTH
>era). We're mainly talking embedded systems here.
Let's look at an example: the STM32F746ZG is certainly no PC CPU. It
has an ARM Cortex-M7 MCU with 1 Mbyte Flash, 216 MHz CPU, 320KB RAM,
etc., and it includes 4KB of instruction and 4KB of data cache (with
32-byte cache lines, i.e., our 100 tasks take 3.2KB of the 4KB data
cache).
It certainly is after the polyForth era, but the discussion was not
about whether the design was good for polyForth, but about whether it
is good now.
One answer is the soulful approach of declaring the design good ex
cathedra, and saying "Don't do that" for all cases where it has
disadvantages. This means that Forth is limited not just to embedded
MCUs, but to slow and very limited MCUs. As the price of the more
powerful MCUs goes down, the domain of Forth would be smaller and
smaller, and the cost advantage of being able to stay with the smaller
MCU thanks to Forth (and thus the cost advantage of Forth) will become
smaller and smaller. Actually, it looks to me like that niche has
already vanished, and those people who still program in Forth don't do
it because they absolutely must fit in a small, cheap MCU where it
delivers superior results to other approaches, but for other reasons.
Few, if any, people, are learning Forth because they want to program
slow and very limited MCUs.
Another answer is to recognize that the design does not scale, and be
prepared to provide something more scalable when it is needed. And in
some cases, one might implement a more scalable approach proactively,
and may then have something that you can use as a marketing argument
for new users, as Erlang did with it's scalable multi-tasking.
>>>> Which multi-user system was that? VM/CMS? Or VMS? Yes, you cannot
>>>> run these systems on an IBM 5150.
>>>
>>> Well, DOS and Windows on PCs.
>>
>> MS-DOS and MS Windows were not multi-user systems.
>
>Exactly. polyFORTH was.
MS-DOS and MS Windows did not use "things like priority queues and
sophisticated schedulers", so Andrew Haley probably did not mean them.
>> Forth was sold as system where you can do a lot with very little
>> hardware. Worked fine in the early 80s. Then the hardware got more
>> plentiful, and the herd moved on to programming systems that need more
>> hardware, but offer various conveniences and features.
>>
>> When Forthers are asked about these features and conveniences, many
>> explain that these are not needed and how you can work around their
>> absence; the rest of the world rather stays with the conveniences and
>> features.
>>
>> So Forthers concentrated on microcontrollers, where their
>> little-hardware advantage still gave them an edge, and mostly
>> abandoned the desktop. But people learn programming on the desktop.
>> They learn Java or C++ or Python, and the distance to C seems not that
>> big. So when people decide on the programming language for an project
>> on a microcontroller, they often choose C, because it's easier to find
>> C programmers. So we have, e.g., MISRA-C (which may be what the Bosch
>> programmers are using), but not MISRA-Forth.
>>
>> So what would a selling point on the desktop be?
>
>FORTH, Inc. focuses on the desktop as a development station for embedded
>applications.
I.e., it's not for most people who learn programming. Few start their
programming by writing embedded applications.
>> My guess is that the perception is as a thing of the (now-distant)
>> past. You like to blame poorly-documented hobbyist systems of the
>> 1980s, but these systems are long gone. How come the professional
>> systems have not been able to overcome that problem? Could it be that
>> telling potential users that they don't need many of the features that
>> they expect as a matter of course has something to do with it.
>
>I think none of us (companies and users) have made a sufficient effort
>to tell the story of the advantages Forth has, the positive aspects.
Lots of people talk about advantages. But when the main advantage is
that you could do things in the 1980s that others could not, and you
ignore all developments since then, focusing on the ever-shrinking
niche of platforms where your approaches from the 1980s are still
doing ok (such as MCUs without caches), most people will quickly lose
interest.
- 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]
Page 4 of 8 — ← Prev page 1 2 3 [4] 5 6 7 8 Next page →
Back to top | Article view | comp.lang.forth
csiph-web