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 | 11 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 8 of 8 — ← Prev page 1 2 3 4 5 6 7 [8]
| From | minforth@arcor.de |
|---|---|
| Date | 2017-04-11 22:12 -0700 |
| Message-ID | <5ae256e5-1def-4e09-a52a-cd76dc422506@googlegroups.com> |
| In reply to | #57082 |
Am Mittwoch, 12. April 2017 03:06:06 UTC+2 schrieb foxaudio...@gmail.com: > It would be nonsense until you hit a wall and throw it out and use a multi-tasking FORTH instead. > > Coop taskers combined with interrupts for non-deterministic inputs work very well in Forth where have complete control of when to switch. Typically you Pause on IO like Emit and inside the KEY loop so it's very smooth. > > I have built small databases in applications without formal record locking because I could control the record update routine to not yield until complete. It becomes so simple. > > Seems to have fallen out of favour. > > B I've been there too. ;-) But believe me, you won't like risking time slice overload = severe system error, caused by an uncritical operation.
[toc] | [prev] | [next] | [standalone]
| From | Lars Brinkhoff <lars.spam@nocrew.org> |
|---|---|
| Date | 2017-04-12 07:39 +0200 |
| Subject | Multitasking with Forth processors |
| Message-ID | <8660iaw5f6.fsf_-_@molnjunk.nocrew.org> |
| In reply to | #57105 |
A multitasking context switch on a regular processor usually involves moving around the stack pointers. But in a Forth processor the stacks may be on chip, and the stack pointers may not be accessible. So how would you do a context switch in this programming model?
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2017-04-11 22:58 -0700 |
| Subject | Re: Multitasking with Forth processors |
| Message-ID | <87efwyjhf9.fsf@nightsong.com> |
| In reply to | #57107 |
Lars Brinkhoff <lars.spam@nocrew.org> writes: > But in a Forth processor the stacks may be on chip, and the stack > pointers may not be accessible. So how would you do a context switch in > this programming model? Chuck Moore's most recent approach (Seaforth, GreenArrays) has been to lots of parallel on-die cpus and use a separate cpu for each task. The Parallax Propeller was a different take on the idea and there was a Forth for it: https://en.wikipedia.org/wiki/Parallax_Propeller The GA instruction set also includes a coroutine swap opcode that exchanges TOS with the instruction counter. That lets you have a few lightweight coroutines that each carefully makes sure the stack balance hasn't changed when they switch.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-04-12 03:00 -0400 |
| Subject | Re: Multitasking with Forth processors |
| Message-ID | <ockj5f$7c2$1@dont-email.me> |
| In reply to | #57108 |
On 4/12/2017 1:58 AM, Paul Rubin wrote: > Lars Brinkhoff <lars.spam@nocrew.org> writes: >> But in a Forth processor the stacks may be on chip, and the stack >> pointers may not be accessible. So how would you do a context switch in >> this programming model? > > Chuck Moore's most recent approach (Seaforth, GreenArrays) has been to > lots of parallel on-die cpus and use a separate cpu for each task. The > Parallax Propeller was a different take on the idea and there was a > Forth for it: > > https://en.wikipedia.org/wiki/Parallax_Propeller I have always felt the GA144 concept was more like an FPGA than it was a multiprocessor. The F18A CPUs on the GA144 are very limited in capability with only 64 words of RAM and 64 words of ROM if I remember correctly. They are fairly fast and simple with timing that is not too hard to understand (although it still needs software to provide reasonable timing estimates). Communications are done through special hardware channels that allow the CPU to pause while waiting to resume processing. The parallax is very much a traditional CPU will significant amounts of memory. The processors are a typical speed and design. Communications are done through memory. This is very much another in the line of typical multiprocessors. > The GA instruction set also includes a coroutine swap opcode that > exchanges TOS with the instruction counter. That lets you have a few > lightweight coroutines that each carefully makes sure the stack balance > hasn't changed when they switch. I never understood the utility of such an instruction. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2017-04-12 12:18 +0200 |
| Subject | Re: Multitasking with Forth processors |
| Message-ID | <ockuu5$6tj$1@cherry.spenarnc.xs4all.nl> |
| In reply to | #57112 |
In article <ockj5f$7c2$1@dont-email.me>, rickman <gnuarm@gmail.com> wrote: >On 4/12/2017 1:58 AM, Paul Rubin wrote: >> Lars Brinkhoff <lars.spam@nocrew.org> writes: >>> But in a Forth processor the stacks may be on chip, and the stack >>> pointers may not be accessible. So how would you do a context switch in >>> this programming model? >> >> Chuck Moore's most recent approach (Seaforth, GreenArrays) has been to >> lots of parallel on-die cpus and use a separate cpu for each task. The >> Parallax Propeller was a different take on the idea and there was a >> Forth for it: >> >> https://en.wikipedia.org/wiki/Parallax_Propeller > >I have always felt the GA144 concept was more like an FPGA than it was a >multiprocessor. The F18A CPUs on the GA144 are very limited in >capability with only 64 words of RAM and 64 words of ROM if I remember >correctly. They are fairly fast and simple with timing that is not too >hard to understand (although it still needs software to provide >reasonable timing estimates). Communications are done through special >hardware channels that allow the CPU to pause while waiting to resume >processing. > >The parallax is very much a traditional CPU will significant amounts of >memory. The processors are a typical speed and design. Communications >are done through memory. This is very much another in the line of >typical multiprocessors. > > >> The GA instruction set also includes a coroutine swap opcode that >> exchanges TOS with the instruction counter. That lets you have a few >> lightweight coroutines that each carefully makes sure the stack balance >> hasn't changed when they switch. > >I never understood the utility of such an instruction. It can be used to keep code together that is not executed in sequence: \ Switch to hex for the duration of the definition. : HEX: R> BASE @ >R >R HEX CO R> BASE ! ; : H. HEX: . ; Usage: 12 H. 12 . C 12 Groetjes Albert >Rick C 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 | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-04-12 17:11 -0400 |
| Subject | Re: Multitasking with Forth processors |
| Message-ID | <ocm50r$8bv$1@dont-email.me> |
| In reply to | #57137 |
On 4/12/2017 6:18 AM, Albert van der Horst wrote: > In article <ockj5f$7c2$1@dont-email.me>, rickman <gnuarm@gmail.com> wrote: >> On 4/12/2017 1:58 AM, Paul Rubin wrote: >>> Lars Brinkhoff <lars.spam@nocrew.org> writes: >>>> But in a Forth processor the stacks may be on chip, and the stack >>>> pointers may not be accessible. So how would you do a context switch in >>>> this programming model? >>> >>> Chuck Moore's most recent approach (Seaforth, GreenArrays) has been to >>> lots of parallel on-die cpus and use a separate cpu for each task. The >>> Parallax Propeller was a different take on the idea and there was a >>> Forth for it: >>> >>> https://en.wikipedia.org/wiki/Parallax_Propeller >> >> I have always felt the GA144 concept was more like an FPGA than it was a >> multiprocessor. The F18A CPUs on the GA144 are very limited in >> capability with only 64 words of RAM and 64 words of ROM if I remember >> correctly. They are fairly fast and simple with timing that is not too >> hard to understand (although it still needs software to provide >> reasonable timing estimates). Communications are done through special >> hardware channels that allow the CPU to pause while waiting to resume >> processing. >> >> The parallax is very much a traditional CPU will significant amounts of >> memory. The processors are a typical speed and design. Communications >> are done through memory. This is very much another in the line of >> typical multiprocessors. >> >> >>> The GA instruction set also includes a coroutine swap opcode that >>> exchanges TOS with the instruction counter. That lets you have a few >>> lightweight coroutines that each carefully makes sure the stack balance >>> hasn't changed when they switch. >> >> I never understood the utility of such an instruction. > > It can be used to keep code together that is not > executed in sequence: > > \ Switch to hex for the duration of the definition. > : HEX: R> BASE @ >R >R HEX CO R> BASE ! ; > > : H. HEX: . ; > > Usage: > 12 H. 12 . > > C 12 Yes, this could be done. As I said, I've never understood the utility of such an instruction. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | foxaudioresearch@gmail.com |
|---|---|
| Date | 2017-04-12 13:50 -0700 |
| Subject | Re: Multitasking with Forth processors |
| Message-ID | <dd9ec80c-f9fb-4fbe-be12-b061a047bf93@googlegroups.com> |
| In reply to | #57107 |
On Wednesday, April 12, 2017 at 1:39:26 AM UTC-4, Lars Brinkhoff wrote: > A multitasking context switch on a regular processor usually involves > moving around the stack pointers. > > But in a Forth processor the stacks may be on chip, and the stack > pointers may not be accessible. So how would you do a context switch in > this programming model? I have considered this question and I believe the Forth type solution would ask: How many tasks are required for the application? (ie: not dynamic) Then create enough total stack space on the chip for that number of tasks. Since you can run a Forth CPU with 20 cells per stack quiet well, it would not be so bad. The only other alternative I can think of is to create a mechanism that can use the internal stacks or external stacks in memory and prioritize which processes get the fast stacks and which processes get the slower stacks. BF
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2017-04-12 13:30 -1000 |
| Subject | Re: Multitasking with Forth processors |
| Message-ID | <4_-dnbr_icXnJXPFnZ2dnUU7-dtQAAAA@supernews.com> |
| In reply to | #57173 |
On 4/12/17 10:50 AM, foxaudioresearch@gmail.com wrote: > On Wednesday, April 12, 2017 at 1:39:26 AM UTC-4, Lars Brinkhoff wrote: >> A multitasking context switch on a regular processor usually involves >> moving around the stack pointers. >> >> But in a Forth processor the stacks may be on chip, and the stack >> pointers may not be accessible. So how would you do a context switch in >> this programming model? > > I have considered this question and I believe the Forth type solution would > ask: How many tasks are required for the application? (ie: not dynamic) > > Then create enough total stack space on the chip for that number of tasks. > Since you can run a Forth CPU with 20 cells per stack quiet well, it would > not be so bad. > > The only other alternative I can think of is to create a mechanism that can > use the internal stacks or external stacks in memory and prioritize which > processes get the fast stacks and which processes get the slower stacks. Actually, I have seen all those options used. Cheers, Elizabeth -- Elizabeth D. Rather FORTH, Inc. 6080 Center Drive, Suite 600 Los Angeles, CA 90045 USA
[toc] | [prev] | [next] | [standalone]
| From | Jan Coombs <jenfhaomndgfwutc@murmic.plus.com> |
|---|---|
| Date | 2017-04-14 12:20 +0100 |
| Subject | Re: Multitasking with Forth processors |
| Message-ID | <20170414122056.498bab8a@t530.lan> |
| In reply to | #57107 |
On Wed, 12 Apr 2017 07:39:25 +0200 Lars Brinkhoff <lars.spam@nocrew.org> wrote: > A multitasking context switch on a regular processor usually > involves moving around the stack pointers. > > But in a Forth processor the stacks may be on chip, and the > stack pointers may not be accessible. So how would you do a > context switch in this programming model? In hardware, for example (from memory): If your processor is built in a small FPGA with 256x16b RAM blocks, then your might have 8 tasks with 32 deep stacks, using one RAM block for each set of 8 stacks. Two RAM blocks in total, one for data, one for return addresses. In this case the lower five bits of stack memory address come from a task's stack pointer, and the higher three bits from a task select register, which also selects the current stack pointer. Calling the task switch word PAUSE saves the return address for the current task on it's currently selected return stack. After checking the status and priority of other tasks, PAUSE writes a new value to the task select register if a task switch is needed. When PAUSE exits, the return address comes from the current task's return stack. Data belonging to the resumed task is also on the currently selected data stack. This is about the simplest I've seen, there are others. Jan Coombs
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-04-14 16:47 -0400 |
| Subject | Re: Multitasking with Forth processors |
| Message-ID | <ocrcbb$e40$1@dont-email.me> |
| In reply to | #57283 |
On 4/14/2017 7:20 AM, Jan Coombs wrote: > On Wed, 12 Apr 2017 07:39:25 +0200 > Lars Brinkhoff <lars.spam@nocrew.org> wrote: > >> A multitasking context switch on a regular processor usually >> involves moving around the stack pointers. >> >> But in a Forth processor the stacks may be on chip, and the >> stack pointers may not be accessible. So how would you do a >> context switch in this programming model? > > In hardware, for example (from memory): > > If your processor is built in a small FPGA with 256x16b RAM > blocks, then your might have 8 tasks with 32 deep stacks, using > one RAM block for each set of 8 stacks. Two RAM blocks in total, > one for data, one for return addresses. > > In this case the lower five bits of stack memory address come > from a task's stack pointer, and the higher three bits from a > task select register, which also selects the current stack > pointer. > > Calling the task switch word PAUSE saves the return address for > the current task on it's currently selected return stack. After > checking the status and priority of other tasks, PAUSE writes a > new value to the task select register if a task switch is > needed. > > When PAUSE exits, the return address comes from the current > task's return stack. Data belonging to the resumed task is also > on the currently selected data stack. > > This is about the simplest I've seen, there are others. In an FPGA it may make more sense to share the CPU between all 8 tasks concurrently. A block RAM can be used for the stack memories as you describe, but all the hardware registers can be implemented in the distributed RAM many FPGAs have. So with 8 processors there are 8 copies of the program counter, 8 copies of each stack pointer and so forth. The logic of the chip can be built in an 8 stage pipeline. Each processor's operations flow through the pipeline just one instruction at a time. The pipeline provides a way for all 8 processors to share the logic without arbitration or overhead. With a clock running at 8*M MHz, the processors will execute instructions at M MHz with no pipeline stalls, no software scheduling. I assume these processors all run from on chip memory which will have no trouble keeping up with an 8*M MHz clock. Using off chip memory will complicate and slow things down considerably. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2017-04-10 07:42 -1000 |
| Message-ID | <pP-dnQ6CbIBvXnbFnZ2dnUU7-TXNnZ2d@supernews.com> |
| In reply to | #56986 |
On 4/9/17 11:20 PM, Andrew Haley wrote: > Alex <alex@rivadpm.com> wrote: >> On 4/10/2017 01:37, Elizabeth D. Rather wrote: >>> >>> In many applications, there's nothing wrong with letting the multitasker >>> spin when nothing's going on, because in a PC, for example, it doesn't >>> cost any extra power. >> >> This is not true. Modern processors & PCs, and the OSes that run on >> them, support a number of sleep states to conserve power, and spinning >> on the spot disrupts them. > > Some of them do. > >>> The cost is one machine instruction per task. >>> Typically putting a task to sleep is 3-4 machine instructions, and >>> waking the next one up maybe 5-6, so the whole thing is really pretty >>> efficient compared with conventional multitaskers. >> >> Again, this is not true, and there are many good reasons why this >> primitive technique isn't used. It is horribly inefficient of power; >> an Intel chip consumes several watts, up to hundreds, on full blast, >> and fractions of that while halted. It is cripplingly disruptive of >> other processes in the system, since the spinning task is consuming >> a scarce resource to no effective end. It is highly disruptive of >> the overall functioning of the system. > > You're not thinking about the full range of Forth systems. If you're > running Forth under some other OS it makes sense to use its facilities > appropriately, and in particular to use OS threads and system calls. > If you're running Forth natively on an embedded system you might spin > if there's nothing to do, or you might modify the multi-tasking loop > to put the processor to sleep. It's not hard to do that, but there's > no point if it's not needed. The world is not a PC. Exactly. Note my qualifier, "In many applications..." above. The multitasker used in polyFORTH and chipFORTH is not appropriate for systems co-resident with modern OSs. SwiftForth under Windows uses Windows features for multitasking. SwiftX, which assumes a native target environment, is much like the original multitasker with power-saving features where they are available. Cheers, Elizabeth -- Elizabeth D. Rather FORTH, Inc. 6080 Center Drive, Suite 600 Los Angeles, CA 90045 USA
[toc] | [prev] | [standalone]
Page 8 of 8 — ← Prev page 1 2 3 4 5 6 7 [8]
Back to top | Article view | comp.lang.forth
csiph-web