Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #52599 > unrolled thread
| Started by | polymorph self <jackvanc3@gmail.com> |
|---|---|
| First post | 2016-11-13 18:33 -0800 |
| Last post | 2016-11-29 13:58 -0500 |
| Articles | 20 on this page of 129 — 26 participants |
Back to article view | Back to comp.lang.forth
Are stack machines inherently faster? polymorph self <jackvanc3@gmail.com> - 2016-11-13 18:33 -0800
Re: Are stack machines inherently faster? rickman <gnuarm@gmail.com> - 2016-11-13 23:02 -0500
Re: Are stack machines inherently faster? polymorph self <jackvanc3@gmail.com> - 2016-11-14 16:59 -0800
Re: Are stack machines inherently faster? rickman <gnuarm@gmail.com> - 2016-11-14 22:27 -0500
Re: Are stack machines inherently faster? Ilya Tarasov <ilya74.tarasov@gmail.com> - 2016-11-17 06:26 -0800
Re: Are stack machines inherently faster? foxaudioresearch@gmail.com - 2016-11-17 08:08 -0800
Re: Are stack machines inherently faster? mhx@iae.nl - 2016-11-17 10:52 -0800
Re: Are stack machines inherently faster? "Elizabeth D. Rather" <erather@forth.com> - 2016-11-17 09:57 -1000
Re: Are stack machines inherently faster? Paul Rubin <no.email@nospam.invalid> - 2016-11-17 15:58 -0800
Re: Are stack machines inherently faster? foxaudioresearch@gmail.com - 2016-11-17 16:29 -0800
Re: Are stack machines inherently faster? john <anon@example.com> - 2016-11-18 08:26 +0000
Re: Are stack machines inherently faster? stephen@mpeforth.com (Stephen Pelc) - 2016-11-18 11:17 +0000
Re: Are stack machines inherently faster? foxaudioresearch@gmail.com - 2016-11-18 06:37 -0800
Re: Are stack machines inherently faster? stephen@mpeforth.com (Stephen Pelc) - 2016-11-18 15:30 +0000
Re: Are stack machines inherently faster? polymorph self <jackvanc3@gmail.com> - 2016-11-27 00:25 -0800
Re: Are stack machines inherently faster? Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2016-11-27 05:08 -0500
Re: Are stack machines inherently faster? "Elizabeth D. Rather" <erather@forth.com> - 2016-11-27 15:12 -1000
Re: Are stack machines inherently faster? hughaguilar96@gmail.com - 2016-11-27 21:06 -0800
Re: Are stack machines inherently faster? john <anon@example.com> - 2016-11-28 12:20 +0000
Re: Are stack machines inherently faster? Alex <alex@rivadpm.com> - 2016-11-28 13:43 +0000
Re: Are stack machines inherently faster? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-11-28 08:52 -0600
Re: Are stack machines inherently faster? Alex <alex@rivadpm.com> - 2016-11-28 17:19 +0000
Re: Are stack machines inherently faster? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-11-28 11:58 -0600
Re: Are stack machines inherently faster? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-11-28 20:39 +0100
Re: Are stack machines inherently faster? john <anon@example.com> - 2016-11-28 21:56 +0000
Re: Are stack machines inherently faster? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-11-28 23:22 +0100
Re: Are stack machines inherently faster? john <anon@example.com> - 2016-11-29 11:06 +0000
Re: Are stack machines inherently faster? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-11-29 09:44 -0600
Re: Are stack machines inherently faster? hughaguilar96@gmail.com - 2016-12-02 13:07 -0800
Re: Are stack machines inherently faster? hughaguilar96@gmail.com - 2016-11-28 19:37 -0800
Re: Are stack machines inherently faster? hughaguilar96@gmail.com - 2016-11-28 19:02 -0800
Re: Are stack machines inherently faster? Alex <alex@rivadpm.com> - 2016-11-29 14:41 +0000
Re: Are stack machines inherently faster? hughaguilar96@gmail.com - 2016-11-29 21:32 -0800
Re: Are stack machines inherently faster? rickman <gnuarm@gmail.com> - 2016-11-29 12:43 -0500
Re: Are stack machines inherently faster? Alex <alex@rivadpm.com> - 2016-11-29 18:38 +0000
Re: Are stack machines inherently faster? Brad Eckert <hwfwguy@gmail.com> - 2016-11-29 13:57 -0800
Re: Are stack machines inherently faster? hughaguilar96@gmail.com - 2016-12-02 16:50 -0800
Re: Are stack machines inherently faster? polymorph self <jackvanc3@gmail.com> - 2016-12-01 00:19 -0800
Re: Are stack machines inherently faster? mhx@iae.nl - 2016-11-18 10:58 -0800
Re: Are stack machines inherently faster? "HAA" <someone@microsoft.com> - 2016-11-19 11:29 +1100
Re: Are stack machines inherently faster? "Elizabeth D. Rather" <erather@forth.com> - 2016-11-18 18:18 -1000
Re: Are stack machines inherently faster? Paul Rubin <no.email@nospam.invalid> - 2016-11-19 00:31 -0800
Re: Are stack machines inherently faster? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-11-20 14:02 +0000
Re: Are stack machines inherently faster? Paul Rubin <no.email@nospam.invalid> - 2016-11-20 23:16 -0800
Re: Are stack machines inherently faster? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-11-22 09:51 +0000
Re: Are stack machines inherently faster? Brad Eckert <hwfwguy@gmail.com> - 2016-11-24 14:16 -0800
Re: Are stack machines inherently faster? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-11-25 15:26 +0000
Re: Are stack machines inherently faster? stephen@mpeforth.com (Stephen Pelc) - 2016-11-19 17:42 +0000
Re: Are stack machines inherently faster? hughaguilar96@gmail.com - 2016-11-21 14:26 -0800
Re: Are stack machines inherently faster? Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2016-11-22 10:38 +0000
Re: Are stack machines inherently faster? hughaguilar96@gmail.com - 2016-11-24 12:46 -0800
Re: Are stack machines inherently faster? Cecil Bayona <cbayona@cbayona.com> - 2016-11-24 15:15 -0600
Re: Are stack machines inherently faster? hughaguilar96@gmail.com - 2016-11-24 14:30 -0800
Re: Are stack machines inherently faster? Ilya Tarasov <ilya74.tarasov@gmail.com> - 2016-11-25 05:37 -0800
Re: Are stack machines inherently faster? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-11-25 09:58 -0600
Re: Are stack machines inherently faster? Ilya Tarasov <ilya74.tarasov@gmail.com> - 2016-11-26 10:39 -0800
Re: Are stack machines inherently faster? Cecil Bayona <cbayona@cbayona.com> - 2016-11-25 12:26 -0600
Re: Are stack machines inherently faster? Ilya Tarasov <ilya74.tarasov@gmail.com> - 2016-11-26 10:57 -0800
Re: Are stack machines inherently faster? Cecil Bayona <cbayona@cbayona.com> - 2016-11-26 13:40 -0600
Re: Are stack machines inherently faster? Ilya Tarasov <ilya74.tarasov@gmail.com> - 2016-12-01 05:35 -0800
Re: Are stack machines inherently faster? hughaguilar96@gmail.com - 2016-12-01 18:38 -0800
Re: Are stack machines inherently faster? polymorph self <jackvanc3@gmail.com> - 2016-12-01 21:52 -0800
Re: Are stack machines inherently faster? Ron Aaron <rambamist@gmail.com> - 2016-12-02 08:45 +0200
Re: Are stack machines inherently faster? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-12-02 08:50 +0000
Re: Are stack machines inherently faster? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-12-02 10:34 +0100
Re: Are stack machines inherently faster? john <anon@example.com> - 2016-12-02 10:20 +0000
Re: Are stack machines inherently faster? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-12-02 10:04 +0000
Re: Are stack machines inherently faster? Ron Aaron <rambamist@gmail.com> - 2016-12-02 11:59 +0200
Re: Are stack machines inherently faster? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-12-02 10:44 +0000
Re: Are stack machines inherently faster? Ron Aaron <rambamist@gmail.com> - 2016-12-02 13:23 +0200
Re: Are stack machines inherently faster? Lars Brinkhoff <lars.spam@nocrew.org> - 2016-12-02 15:12 +0100
Re: Are stack machines inherently faster? Ron Aaron <rambamist@gmail.com> - 2016-12-03 17:35 +0200
Re: Are stack machines inherently faster? Lars Brinkhoff <lars.spam@nocrew.org> - 2017-01-09 10:31 +0100
Re: Are stack machines inherently faster? Ron Aaron <rambamist@gmail.com> - 2017-01-09 12:01 +0200
Re: Are stack machines inherently faster? Lars Brinkhoff <lars.spam@nocrew.org> - 2017-01-09 13:53 +0100
Re: Are stack machines inherently faster? Ron Aaron <rambamist@gmail.com> - 2017-01-09 14:59 +0200
Re: Are stack machines inherently faster? minforth@arcor.de - 2017-01-09 08:15 -0800
Re: Are stack machines inherently faster? Lars Brinkhoff <lars.spam@nocrew.org> - 2017-01-09 19:33 +0100
Re: Are stack machines inherently faster? Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2016-12-03 01:58 -0500
Re: Are stack machines inherently faster? "Elizabeth D. Rather" <erather@forth.com> - 2016-12-02 21:09 -1000
Re: Are stack machines inherently faster? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-12-03 13:01 +0100
Re: Are stack machines inherently faster? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-12-04 14:51 +0000
Re: Are stack machines inherently faster? Ilya Tarasov <ilya74.tarasov@gmail.com> - 2016-12-02 04:28 -0800
Re: Are stack machines inherently faster? stephen@mpeforth.com (Stephen Pelc) - 2016-11-25 16:10 +0000
Re: Are stack machines inherently faster? hughaguilar96@gmail.com - 2016-11-25 16:51 -0800
Re: Are stack machines inherently faster? hughaguilar96@gmail.com - 2016-11-26 15:09 -0800
Re: Are stack machines inherently faster? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-11-26 13:03 +0100
Re: Are stack machines inherently faster? franck.bensusan@gmail.com - 2016-11-27 10:11 -0800
Re: Are stack machines inherently faster? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-11-25 16:00 +0000
Re: Are stack machines inherently faster? Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2016-11-24 22:44 +0000
Re: Are stack machines inherently faster? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-11-24 23:11 +0000
Re: Are stack machines inherently faster? hughaguilar96@gmail.com - 2016-11-24 16:38 -0800
Re: Are stack machines inherently faster? Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2016-11-25 07:28 +0000
Re: Are stack machines inherently faster? foxaudioresearch@gmail.com - 2016-11-25 04:24 -0800
Re: Are stack machines inherently faster? Alex <alex@rivadpm.com> - 2016-11-25 14:37 +0000
Re: Are stack machines inherently faster? foxaudioresearch@gmail.com - 2016-11-26 10:54 -0800
Re: Are stack machines inherently faster? luser droog <mijoryx@yahoo.com> - 2016-11-27 10:56 -0800
Re: Are stack machines inherently faster? polymorph self <jackvanc3@gmail.com> - 2016-11-27 00:27 -0800
Re: Are stack machines inherently faster? luser droog <mijoryx@yahoo.com> - 2016-11-27 11:42 -0800
Re: Are stack machines inherently faster? hughaguilar96@gmail.com - 2016-11-21 14:35 -0800
Re: Are stack machines inherently faster? "HAA" <someone@microsoft.com> - 2016-11-22 17:43 +1100
Re: Are stack machines inherently faster? john <anon@example.com> - 2016-11-22 12:51 +0000
Re: Are stack machines inherently faster? hughaguilar96@gmail.com - 2016-11-24 13:30 -0800
Re: Are stack machines inherently faster? Paul Rubin <no.email@nospam.invalid> - 2016-11-18 20:27 -0800
Re: Are stack machines inherently faster? polymorph self <jackvanc3@gmail.com> - 2016-11-27 00:23 -0800
Re: Are stack machines inherently faster? polymorph self <jackvanc3@gmail.com> - 2016-11-27 00:22 -0800
Re: Are stack machines inherently faster? hughaguilar96@gmail.com - 2016-11-17 12:50 -0800
Re: Are stack machines inherently faster? polymorph self <jackvanc3@gmail.com> - 2016-11-27 00:22 -0800
Re: Are stack machines inherently faster? Manuel Rodriguez <aa5@gmx.net> - 2016-11-28 11:00 -0800
Re: Are stack machines inherently faster? Walter Banks <walter@bytecraft.com> - 2016-11-28 16:10 -0500
Re: Are stack machines inherently faster? rickman <gnuarm@gmail.com> - 2016-11-29 13:58 -0500
Re: Are stack machines inherently faster? Cecil Bayona <cbayona@cbayona.com> - 2016-11-30 00:46 -0600
Re: Are stack machines inherently faster? rickman <gnuarm@gmail.com> - 2016-11-30 02:01 -0500
Re: Are stack machines inherently faster? Walter Banks <walter@bytecraft.com> - 2016-12-01 13:01 -0500
Re: Are stack machines inherently faster? hughaguilar96@gmail.com - 2016-12-03 17:15 -0800
Re: Are stack machines inherently faster? Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2016-12-04 02:29 -0500
Re: Are stack machines inherently faster? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-12-04 03:41 -0600
Re: Are stack machines inherently faster? Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2016-12-04 10:10 -0500
Re: Are stack machines inherently faster? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-12-04 17:16 +0000
Re: Are stack machines inherently faster? Paul Rubin <no.email@nospam.invalid> - 2016-11-28 13:33 -0800
Re: Are stack machines inherently faster? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-11-28 23:17 +0100
Re: Are stack machines inherently faster? Brad Eckert <hwfwguy@gmail.com> - 2016-11-29 09:17 -0800
Re: Are stack machines inherently faster? rickman <gnuarm@gmail.com> - 2016-11-29 14:46 -0500
Re: Are stack machines inherently faster? Brad Eckert <hwfwguy@gmail.com> - 2016-11-29 13:44 -0800
Re: Are stack machines inherently faster? rickman <gnuarm@gmail.com> - 2016-11-29 18:39 -0500
Re: Are stack machines inherently faster? Brad Eckert <hwfwguy@gmail.com> - 2016-11-30 15:00 -0800
Re: Are stack machines inherently faster? rickman <gnuarm@gmail.com> - 2016-11-30 18:42 -0500
Re: Are stack machines inherently faster? "Elizabeth D. Rather" <erather@forth.com> - 2016-11-30 14:26 -1000
Re: Are stack machines inherently faster? rickman <gnuarm@gmail.com> - 2016-11-29 13:58 -0500
Page 2 of 7 — ← Prev page 1 [2] 3 4 5 6 7 Next page →
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2016-11-28 08:52 -0600 |
| Message-ID | <xNGdnSCP3ogL2aHFnZ2dnUU7-W3NnZ2d@supernews.com> |
| In reply to | #52921 |
Alex <alex@rivadpm.com> wrote: > > You are very confused about this, and predictably didactic & rude to > Elizabeth. > > Circular buffers are but one method for handling incoming or > outgoing data, and they have been used for a lot longer than you > realise. I've often found circular buffers often to be more trouble than they are worth. Of course, you have to guess how big to make them, but that's not all. When a protocol handler starts a transaction, the first thing you sometimes have to do is clear outstanding garbage from the input buffer. I found myself doing this and realized that it makes no sense at all: you might as well receive directly into the receive packet buffer, handling any checksum as each character is received, and awaken the task once the packet is ready. (This is for a single-duplex protocol: other protocols are available.) > ISRs are typically very short and do as little work as is possible. > The general rule is to try and minimise the amount of time in > interrupts, esecialy if they block other activity, and to do the > bulk of the work outside of the interrupt. An ISR may be as simple > as moving a task pointer from a blocked to a ready queue as part of > a scheduler, and the work is done later by the task. Yes indeed. In the Classic Forth case that's a single store instruction. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2016-11-28 17:19 +0000 |
| Message-ID | <o1hos9$vo9$1@dont-email.me> |
| In reply to | #52924 |
On 11/28/2016 14:52, Andrew Haley wrote: > Alex <alex@rivadpm.com> wrote: >> Circular buffers are but one method for handling incoming or >> outgoing data, and they have been used for a lot longer than you >> realise. > > I've often found circular buffers often to be more trouble than they > are worth. Of course, you have to guess how big to make them, but > that's not all. When a protocol handler starts a transaction, the > first thing you sometimes have to do is clear outstanding garbage from > the input buffer. I found myself doing this and realized that it > makes no sense at all: you might as well receive directly into the > receive packet buffer, handling any checksum as each character is > received, and awaken the task once the packet is ready. (This is for > a single-duplex protocol: other protocols are available.) > >> ISRs are typically very short and do as little work as is possible. >> The general rule is to try and minimise the amount of time in >> interrupts, esecialy if they block other activity, and to do the >> bulk of the work outside of the interrupt. An ISR may be as simple >> as moving a task pointer from a blocked to a ready queue as part of >> a scheduler, and the work is done later by the task. > > Yes indeed. In the Classic Forth case that's a single store > instruction. > > Andrew. > Traditionally data has been moved over the wire, into a buffer on the network card, from the network card to memory managed by the OS, and then moved again to the application's buffers. Now we have technologies like RDMA (remote direct memory access) which gives zero copy networking straight into application memory, and iWarp and RoCE that provide the protocol stack. With hardware support, data can be moved with very small latencies in the hundreds of nS range. The software stack and handling of interrupts has become a sizeable percentage of the overhead. You really don't get to do that much work in nanoseconds. -- Alex
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2016-11-28 11:58 -0600 |
| Message-ID | <t-6dnVrCLael7aHFnZ2dnUU78THNnZ2d@supernews.com> |
| In reply to | #52925 |
Alex <alex@rivadpm.com> wrote: > > Traditionally data has been moved over the wire, into a buffer on > the network card, from the network card to memory managed by the OS, > and then moved again to the application's buffers. Yep. That's the traditional non-Forth-OS way of doing it. > Now we have technologies like RDMA (remote direct memory access) > which gives zero copy networking straight into application memory, > and iWarp and RoCE that provide the protocol stack. Mmm, yes, at the big end. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2016-11-28 20:39 +0100 |
| Message-ID | <o1i15m$o7k$1@cherry.spenarnc.xs4all.nl> |
| In reply to | #52924 |
In article <xNGdnSCP3ogL2aHFnZ2dnUU7-W3NnZ2d@supernews.com>, Andrew Haley <andrew29@littlepinkcloud.invalid> wrote: >Alex <alex@rivadpm.com> wrote: >> >> You are very confused about this, and predictably didactic & rude to >> Elizabeth. >> >> Circular buffers are but one method for handling incoming or >> outgoing data, and they have been used for a lot longer than you >> realise. > >I've often found circular buffers often to be more trouble than they >are worth. Of course, you have to guess how big to make them, but >that's not all. When a protocol handler starts a transaction, the >first thing you sometimes have to do is clear outstanding garbage from >the input buffer. I found myself doing this and realized that it >makes no sense at all: you might as well receive directly into the >receive packet buffer, handling any checksum as each character is >received, and awaken the task once the packet is ready. (This is for >a single-duplex protocol: other protocols are available.) In manx (control of musical instruments) I've about a dozen to a few dozen midi messages with time stamps. That is hard without a circular buffer. > >> ISRs are typically very short and do as little work as is possible. >> The general rule is to try and minimise the amount of time in >> interrupts, esecialy if they block other activity, and to do the >> bulk of the work outside of the interrupt. An ISR may be as simple >> as moving a task pointer from a blocked to a ready queue as part of >> a scheduler, and the work is done later by the task. > >Yes indeed. In the Classic Forth case that's a single store >instruction. Then there are systems with multiple interrupt levels where the main program can be locked out by lesser interrupts. There I found it better to do substantial calculations under interrupt. In this case a simulation of the expected behaviour of a carriage plus mirror. That calculation must be finished before the next command to move the mirror at 2 mS intervals. This was the optical delay line at the VLT (very large telescope) of ESO at Paranal. So let's not be dogmatic about this. [There is a pitfall, one must make sure the interrupt routine to save and restore the floating point registers. ] > >Andrew. 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 | john <anon@example.com> |
|---|---|
| Date | 2016-11-28 21:56 +0000 |
| Message-ID | <MPG.32a6b880c29c3a9e9896ce@news.virginmedia.com> |
| In reply to | #52929 |
In article <o1i15m$o7k$1@cherry.spenarnc.xs4all.nl>, albert@cherry.spenarnc.xs4all.nl says... > > Then there are systems with multiple interrupt levels where the main > program can be locked out by lesser interrupts. There I found it better > to do substantial calculations under interrupt. In this case a simulation > of the expected behaviour of a carriage plus mirror. That calculation > must be finished before the next command to move the mirror at > 2 mS intervals. > This was the optical delay line at the VLT (very large telescope) of > ESO at Paranal. > curious - how does such a system ensure it doesn't miss an interrupt? I can see clearing the int flag on entry to the interrupt routine but what if 2 more come along - you can reset while still processing the first to see the second on leaving but I can't see how you would recognise the third. Or doesn't it matter in this application? -- john ========================= http://johntech.co.uk "Bleeding Edge Forum" http://johntech.co.uk/forum/ =========================
[toc] | [prev] | [next] | [standalone]
| From | albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2016-11-28 23:22 +0100 |
| Message-ID | <o1iamk$p2s$1@cherry.spenarnc.xs4all.nl> |
| In reply to | #52932 |
In article <MPG.32a6b880c29c3a9e9896ce@news.virginmedia.com>, john <anon@example.com> wrote: >In article <o1i15m$o7k$1@cherry.spenarnc.xs4all.nl>, >albert@cherry.spenarnc.xs4all.nl says... >> >> Then there are systems with multiple interrupt levels where the main >> program can be locked out by lesser interrupts. There I found it better >> to do substantial calculations under interrupt. In this case a simulation >> of the expected behaviour of a carriage plus mirror. That calculation >> must be finished before the next command to move the mirror at >> 2 mS intervals. >> This was the optical delay line at the VLT (very large telescope) of >> ESO at Paranal. >> > >curious - how does such a system ensure it doesn't miss an interrupt? >I can see clearing the int flag on entry to the interrupt routine >but what if 2 more come along - you can reset while still processing >the first to see the second on leaving but I can't see how you would recognise >the third. >Or doesn't it matter in this application? Om each level the time between interrupts are known. So whatever happens at lower priority interrupts, a higher level interrupt knows it has the time to complete before the interrupt at that level repeats. You're right that this is particular to this situation. > >-- >john 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 | john <anon@example.com> |
|---|---|
| Date | 2016-11-29 11:06 +0000 |
| Message-ID | <MPG.32a771955e05ca799896cf@news.virginmedia.com> |
| In reply to | #52934 |
> In article <o1iamk$p2s$1@cherry.spenarnc.xs4all.nl>, albert@cherry.spenarnc.xs4all.nl says... > > In article <MPG.32a6b880c29c3a9e9896ce@news.virginmedia.com>, > john <anon@example.com> wrote: > >In article <o1i15m$o7k$1@cherry.spenarnc.xs4all.nl>, > >albert@cherry.spenarnc.xs4all.nl says... > >> > >> Then there are systems with multiple interrupt levels where the main > >> program can be locked out by lesser interrupts. There I found it better > >> to do substantial calculations under interrupt. In this case a simulation > >> of the expected behaviour of a carriage plus mirror. That calculation > >> must be finished before the next command to move the mirror at > >> 2 mS intervals. > >> This was the optical delay line at the VLT (very large telescope) of > >> ESO at Paranal. > >> > > > >curious - how does such a system ensure it doesn't miss an interrupt? > >I can see clearing the int flag on entry to the interrupt routine > >but what if 2 more come along - you can reset while still processing > >the first to see the second on leaving but I can't see how you would recognise > >the third. > >Or doesn't it matter in this application? > > Om each level the time between interrupts are known. Ahh .. I see. That makes all the difference of course. > So whatever > happens at lower priority interrupts, a higher level interrupt knows > it has the time to complete before the interrupt at that level > repeats. > You're right that this is particular to this situation. > > > > >-- > >john > > Groetjes Albert -- john ========================= http://johntech.co.uk "Bleeding Edge Forum" http://johntech.co.uk/forum/ =========================
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2016-11-29 09:44 -0600 |
| Message-ID | <mN6dnWNvttXtP6DFnZ2dnUU7-Y-dnZ2d@supernews.com> |
| In reply to | #52929 |
Albert van der Horst <albert@cherry.spenarnc.xs4all.nl> wrote: > In article <xNGdnSCP3ogL2aHFnZ2dnUU7-W3NnZ2d@supernews.com>, > Andrew Haley <andrew29@littlepinkcloud.invalid> wrote: >>Alex <alex@rivadpm.com> wrote: >>> >>> You are very confused about this, and predictably didactic & rude to >>> Elizabeth. >>> >>> Circular buffers are but one method for handling incoming or >>> outgoing data, and they have been used for a lot longer than you >>> realise. >> >>I've often found circular buffers often to be more trouble than they >>are worth. > >>> ISRs are typically very short and do as little work as is possible. >>> The general rule is to try and minimise the amount of time in >>> interrupts, esecialy if they block other activity, and to do the >>> bulk of the work outside of the interrupt. An ISR may be as simple >>> as moving a task pointer from a blocked to a ready queue as part of >>> a scheduler, and the work is done later by the task. >> >>Yes indeed. In the Classic Forth case that's a single store >>instruction. > Then there are systems with multiple interrupt levels where the main > program can be locked out by lesser interrupts. There I found it better > to do substantial calculations under interrupt. In this case a simulation > of the expected behaviour of a carriage plus mirror. That calculation > must be finished before the next command to move the mirror at > 2 mS intervals. > This was the optical delay line at the VLT (very large telescope) of > ESO at Paranal. > > So let's not be dogmatic about this. Oh, sure. If you need the result of the calculation right now, you do that calculation right now. Note the "often" in the sentence above: no dogmatism intended. I'm saying that I've seen people carefully use circular buffers to make sure "nothing gets lost" when getting rid of stale bytes is precisely what is required. The point I'm making is do what is required: no more, no less. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-12-02 13:07 -0800 |
| Message-ID | <5c1537dd-149a-4788-8189-70acd528ed5d@googlegroups.com> |
| In reply to | #52958 |
On Tuesday, November 29, 2016 at 8:44:54 AM UTC-7, Andrew Haley wrote: > Albert van der Horst <albert@cherry.spenarnc.xs4all.nl> wrote: > > In article <xNGdnSCP3ogL2aHFnZ2dnUU7-W3NnZ2d@supernews.com>, > > Andrew Haley <andrew29@littlepinkcloud.invalid> wrote: > >>I've often found circular buffers often to be more trouble than they > >>are worth. > > I'm > saying that I've seen people carefully use circular buffers to make > sure "nothing gets lost" when getting rid of stale bytes is precisely > what is required. Stale bytes??? So, you tell the customer that your micro-controller isn't actually losing I/O data due to the fact that your buffer is only one element in size, but rather that the bytes were stale and had to be discarded, just like stale bread. Why am I the only person who thinks that the concept of "stale bytes" is funny? It must be because I have a: "serious misunderstanding of how pointers work." Or perhaps that I'm just: "very confused." The Forth Inc. motto seems to be: "If you can't dazzle them with brilliance, baffle them with bull!" > The point I'm making is do what is required: no > more, no less. You are an employee of Forth Inc. --- this is why Elizabeth Rather appointed you to the Forth-200x committee --- this is why the point that you are making is exacly the same as the point that Elizabeth Rather has been making for 30 years. Elizabeth Rather has made a career out of opposing general-purpose code-libraries. Apparently everybody who works at Forth Inc. is required to parrot this idiocy. This is why nobody has taken Forth seriously since 1994.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-11-28 19:37 -0800 |
| Message-ID | <706ed50a-19ec-416f-ae1d-07add4c5d991@googlegroups.com> |
| In reply to | #52924 |
On Monday, November 28, 2016 at 7:52:13 AM UTC-7, Andrew Haley wrote: > Alex <alex@rivadpm.com> wrote: > > > > You are very confused about this, and predictably didactic & rude to > > Elizabeth. > > > > Circular buffers are but one method for handling incoming or > > outgoing data, and they have been used for a lot longer than you > > realise. > > I've often found circular buffers often to be more trouble than they > are worth. I wonder if Alex is an employee of Forth Inc.. I know that Andrew Haley is an employee of Forth Inc though --- he has admitted it --- and, of course, that is why Elizabeth Rather appointed him to the Forth-200x committee. Consider this thread: https://groups.google.com/forum/#!topic/comp.lang.forth/pqhqqvWg9zk%5B51-75%5D Here Elizabeth Rather said that a UART driver should only support half-duplex unless the applicaton needs full-duplex, but that this is never needed. On Monday, April 25, 2016 at 5:07:26 PM UTC-7, Elizabeth D. Rather wrote: > I can't think offhand of a case in which a > full-duplex port literally has concurrent streams of data flowing in and > out. LOL --- that is the definition of "full-duplex" --- she should look these terms up in a technical dictionary before she uses them. But, Andrew Haley predictably supported her: On Tuesday, April 26, 2016 at 2:04:29 AM UTC-7, Andrew Haley wrote: > Paul Rubin <no.email@nospam.invalid> wrote: > > Maybe if I know the application only uses half-duplex, I can > > implement some hacky thing that relies on that fact. But if I'm > > supplying a library facility it wouldn't occur to me to limit it > > like that. > > I'm sure it wouldn't, because you don't really think in the Forth way. > Don't speculate! In that thread it became obvious that Elizabeth Rather doesn't know what full-duplex is, and Andrew Haley obediently supporter her. Now in this thread it is obvious that Elizabeth Rather doesn't know what a circular buffer is, and Andrew Haley is obediently supporting her. It makes sense that Andrew Haley should support Elizabeth Rather --- he is an employee of Forth Inc. --- she signs his paychecks. But why should anybody else in the Forth community support Elizabeth Rather? ANS-Forth is a cult --- all of the ANS-Forth programmers obediently support Elizabeth Rather's idiotic pronouncements regarding computer I/O --- this is very similar to how the Heaven's Gate cult members supported their leaders' idiotic pronouncements regarding the Hale-Bopp comet. Ultimately, all of the ANS-Forth cult members' arguments boil down to telling everybody else: "You don't really think in the Forth way!"
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-11-28 19:02 -0800 |
| Message-ID | <9bb01e48-9ba4-4a57-9ffc-e6920e9b4a06@googlegroups.com> |
| In reply to | #52921 |
On Monday, November 28, 2016 at 6:43:08 AM UTC-7, Alex wrote: > On 11/28/2016 05:06, hughaguilar96@gmail.com wrote: > > On Sunday, November 27, 2016 at 6:12:54 PM UTC-7, Elizabeth D. Rather > > wrote: > >> It can be even simpler. In SwiftX we follow the convention that a > >> task managing an interrupt-driven device initiates an operation and > >> then "sleeps" until an interrupt signals its completion. The > >> interrupt routine does only the minimum required (tally a counter, > >> read a number and store it, etc.) and wakes the task, which does > >> any other processing in high-level Forth. It isn't necessary to > >> save & restore all registers, and typical interrupt routines use > >> only one (often none, depending on the processer). Often interrupt > >> routines are only a few instructions long (4-6, sometimes fewer). > > > > This is nonsense, as usual. > > > > An ISR (interrupt service routine) typically uses a circular buffer. > > An ISR doing input would put the data into the buffer, and the main > > program would remove data from the buffer (hopefully before it gets > > full). An ISR doing output would take data from the buffer, and the > > main program would put data into the buffer (usually at a much higher > > speed than the output port is operating at). > > > > An ISR is not going to be 4-6 instructions long --- it is going to be > > much longer, and it is going to use some registers --- you can't work > > with a circular buffer without at least two registers, and that would > > be pretty restrictive. > > > > Most likely, you don't know what a circular buffer is. Your ISRs are > > super-short because they just use a single variable as their buffer. > > The problem with this, of course, is that the main-program has to be > > reading from or writing to that variable as fast as the data comes in > > or goes out. This has almost no benefit compared to the main-program > > directly accessing the I/O port. The only benefit is that the > > processor can be put in low-power sleep mode while it waits for an > > interrupt, which would be useful if the I/O is very slow. This is a > > minor benefit though. You should just learn what a circular buffer is > > so your main-program doesn't have to be totally on top of the I/O but > > it can just let I/O be done in the background while it does more > > important work. > > > > In the 1980s the 6502 was commonly used as a micro-controller. It had > > absolute-indexed addressing which I think was provided primarily for > > implementing 256-byte circular buffers. Everybody knew about circular > > buffers in the 1980s. I think they were well-known in the late 1970s > > too --- maybe in the early 1970s, or the 1960s, they were unknown --- > > of course, COBOL programmers such as yourself don't know any > > computer-science whatsoever, then or now. > You are very confused about this, and predictably didactic & rude to > Elizabeth. I'm not "very confused" about this --- you are just brown-nosing Elizabeth Rather --- are you an employee of Forth Inc.? > Circular buffers are but one method for handling incoming or outgoing > data, and they have been used for a lot longer than you realise. Circular buffers are the primary (as a practical matter, the only) method for handdling I/O --- they have likely been used for as long as computers have existed --- I said the 1960s (I doubt that the computers of the 1950s had interrupts). Elizzbeth Rather clearly doesn't know what circular buffers are --- she should learn about these basic concepts --- or just stop pretending to be a programmer, which annoys the heck out of me. > A circular buffer can be as simple as a block of data, addressed by an > index modulo the number of buffers. I have no idea why you think a pair > of registers is required. Neither is data movement needed, since we can > use a circular buffer of pointers to data. One accumulator to hold the datum, and one index register to point into the buffer --- on the 6502 these would be A and Y. I didn't say data movement is needed. The ISR just loads or stores a single byte from or to the buffer. The main-program needs to do data movement because it typically loads or stores a block of daa from or to the buffer. I don't know why you would want a circular buffer of pointers to data --- each datum is typically one or two bytes --- you are not really making any sense. > ISRs are typically very short and do as little work as is possible. The > general rule is to try and minimise the amount of time in interrupts, > esecialy if they block other activity, and to do the bulk of the work > outside of the interrupt. An ISR may be as simple as moving a task > pointer from a blocked to a ready queue as part of a scheduler, and the > work is done later by the task. I didn't say that ISRs should be long and do unnecessary work.
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2016-11-29 14:41 +0000 |
| Message-ID | <o1k3vo$asn$1@dont-email.me> |
| In reply to | #52939 |
On 11/29/2016 03:02, hughaguilar96@gmail.com wrote: > On Monday, November 28, 2016 at 6:43:08 AM UTC-7, Alex wrote: >> On 11/28/2016 05:06, hughaguilar96@gmail.com wrote: > >> You are very confused about this, and predictably didactic & rude >> to Elizabeth. > > I'm not "very confused" about this --- you are just brown-nosing > Elizabeth Rather --- are you an employee of Forth Inc.? Yes, of course you are confused. It goes with you being a furtlewangling paranoid wanktit. No, I am not an employee of Forth Inc. > >> Circular buffers are but one method for handling incoming or >> outgoing data, and they have been used for a lot longer than you >> realise. > > Circular buffers are the primary (as a practical matter, the only) > method for handdling I/O --- they have likely been used for as long > as computers have existed --- I said the 1960s (I doubt that the > computers of the 1950s had interrupts). You said they were unknown until the late 1970s originally. Just a couple of decades out. Have you never heard of FIFO queues for IO? Hugely popular. For example, the Linux IO scheduler uses FIFO queues, and SCSI disk commands are queue based. They mainly have a place for slower byte oriented devices like tape, cards, keyboards and so on. > >> A circular buffer can be as simple as a block of data, addressed by >> an index modulo the number of buffers. I have no idea why you think >> a pair of registers is required. Neither is data movement needed, >> since we can use a circular buffer of pointers to data. > > One accumulator to hold the datum, and one index register to point > into the buffer --- on the 6502 these would be A and Y. That's an implementation detail specific to some set of hardware, not a description of the algorithm for a circular buffer. > > I didn't say data movement is needed. The ISR just loads or stores a > single byte from or to the buffer. The main-program needs to do data > movement because it typically loads or stores a block of daa from or > to the buffer. Why do all that data movement? Can you think of a way of avoiding it? > > I don't know why you would want a circular buffer of pointers to data > --- each datum is typically one or two bytes --- you are not really > making any sense. Is a read off disk or from a network just one or two bytes per interrupt? The solution to avoiding lots of redundant data movement is to use pointers. Write it once, point to it and avoid moving the data again. But we've already had this discussion some time ago about your sort routine that shuffled the data rather than pointers to the data. You didn't seem to understand then either. -- Alex
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-11-29 21:32 -0800 |
| Message-ID | <18303b31-a8b4-4e35-9ed0-2369191f314d@googlegroups.com> |
| In reply to | #52957 |
On Tuesday, November 29, 2016 at 7:41:11 AM UTC-7, Alex wrote:
> On 11/29/2016 03:02, hughaguilar96@gmail.com wrote:
> > On Monday, November 28, 2016 at 6:43:08 AM UTC-7, Alex wrote:
> >> On 11/28/2016 05:06, hughaguilar96@gmail.com wrote:
>
> >
> >> You are very confused about this, and predictably didactic & rude
> >> to Elizabeth.
> >
> > I'm not "very confused" about this --- you are just brown-nosing
> > Elizabeth Rather --- are you an employee of Forth Inc.?
>
> Yes, of course you are confused. It goes with you being a furtlewangling
> paranoid wanktit. No, I am not an employee of Forth Inc.
Oh, you're Alex McDonald! LOL
You are the same Alex who sent me this death threat by email:
-----------------------------------------------------------------------------
On Wed, Jun 8, 2016 at 2:29 PM, Alex McDonald <alex@rivadpm.com> wrote:
On 01/06/16 16:20, hughaguilar96@gmail.com wrote:
> The RfD was going to be a slam-dunk from a ladder for Alex McDonald > --- but then Alex McDonald disappeared --- now the RfD is left in
> limbo while Anton and Bernd search for a new pocket-boy who will put > his name on the RfD.
Then the Forth-200x committee had Alex McDonald pretending to represent
>the "Forth community," but Alex "I do standards for a living" McDonald
> disappeared. This is a chronic problem for the Forth-200x committee
> --- their pocket boys disappear --- then they have to find new
> pocket boys to put their names on the RfDs.
Unfortunately, you're still here, and I suspect you won't do me the tremendous favour of fucking off or dieing any time soon. Ah well.
I still occasionally read clf. Personal reasons and your continued existence have stopped me being an active contributor. I'll continue to lurk for the moment.
--
Alex "I still do standards for a living" McDonald
-----------------------------------------------------------------------------
So, do you still do standards for a living? Who signs your paycheck --- Forth Inc., I would assume
> The solution to avoiding lots of redundant data movement is to use
> pointers. Write it once, point to it and avoid moving the data again.
> But we've already had this discussion some time ago about your sort
> routine that shuffled the data rather than pointers to the data. You
> didn't seem to understand then either.
I remember that you criticized my SORT function and said that I had a: "serious misunderstanding of how pointers work." That was truly the stupidest thing you have ever said, and you have said a lot of stupid things.
This is my SORT function from the novice package:
\ All of these macros use the locals from SORT, and can only be called from SORT.
macro: adr ( index -- adr )
recsiz * array + ;
macro: left ( x -- y ) 2* 1+ ;
macro: right ( x -- y ) 2* 2 + ;
macro: heapify ( x -- )
dup >r begin \ r: -- great
dup left dup limit < if dup adr rover adr 'comparer execute if rdrop dup >r then then drop
dup right dup limit < if dup adr r@ adr 'comparer execute if rdrop dup >r then then drop
dup r@ <> while
adr r@ adr recsiz exchange
r@ repeat
drop rdrop ;
macro: build-max-heap ( -- )
limit 1- 2/ begin dup 0>= while dup heapify 1- repeat drop ;
: sort { array limit recsiz 'comparer -- }
recsiz [ w 1- ] literal and abort" *** SORT: record size must be a multiple of the cell size ***"
build-max-heap
begin limit while -1 +to limit
0 adr limit adr recsiz exchange
0 heapify repeat ;
\ The SORT locals:
\ array \ the address of the 0th element
\ limit \ the number of records in the array
\ recsiz \ the size of a record in the array \ this must be a multiple of W (FIELD assures this)
\ 'comparer \ adrX adrY -- X>Y?
\ Note for the novice:
\ This code was originally written with colon words rather than macros, and using items rather than local variables.
\ After it was debugged, it was changed to use macros and locals so that it would be fast and reentrant.
\ One of the reasons why the heap-sort was chosen is because it is not recursive, which allows macros to be used.
\ Using macros allows the data (array, limit, recsiz, 'comparer) to be held in locals rather than items, which is reentrant.
\ See the file SORT.4TH for an early version.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-11-29 12:43 -0500 |
| Message-ID | <o1keko$jlg$1@dont-email.me> |
| In reply to | #52921 |
On 11/28/2016 8:43 AM, Alex wrote: > On 11/28/2016 05:06, hughaguilar96@gmail.com wrote: >> On Sunday, November 27, 2016 at 6:12:54 PM UTC-7, Elizabeth D. Rather >> wrote: >>> It can be even simpler. In SwiftX we follow the convention that a >>> task managing an interrupt-driven device initiates an operation and >>> then "sleeps" until an interrupt signals its completion. The >>> interrupt routine does only the minimum required (tally a counter, >>> read a number and store it, etc.) and wakes the task, which does >>> any other processing in high-level Forth. It isn't necessary to >>> save & restore all registers, and typical interrupt routines use >>> only one (often none, depending on the processer). Often interrupt >>> routines are only a few instructions long (4-6, sometimes fewer). >> >> This is nonsense, as usual. >> >> An ISR (interrupt service routine) typically uses a circular buffer. >> An ISR doing input would put the data into the buffer, and the main >> program would remove data from the buffer (hopefully before it gets >> full). An ISR doing output would take data from the buffer, and the >> main program would put data into the buffer (usually at a much higher >> speed than the output port is operating at). >> >> An ISR is not going to be 4-6 instructions long --- it is going to be >> much longer, and it is going to use some registers --- you can't work >> with a circular buffer without at least two registers, and that would >> be pretty restrictive. >> >> Most likely, you don't know what a circular buffer is. Your ISRs are >> super-short because they just use a single variable as their buffer. >> The problem with this, of course, is that the main-program has to be >> reading from or writing to that variable as fast as the data comes in >> or goes out. This has almost no benefit compared to the main-program >> directly accessing the I/O port. The only benefit is that the >> processor can be put in low-power sleep mode while it waits for an >> interrupt, which would be useful if the I/O is very slow. This is a >> minor benefit though. You should just learn what a circular buffer is >> so your main-program doesn't have to be totally on top of the I/O but >> it can just let I/O be done in the background while it does more >> important work. >> >> In the 1980s the 6502 was commonly used as a micro-controller. It had >> absolute-indexed addressing which I think was provided primarily for >> implementing 256-byte circular buffers. Everybody knew about circular >> buffers in the 1980s. I think they were well-known in the late 1970s >> too --- maybe in the early 1970s, or the 1960s, they were unknown --- >> of course, COBOL programmers such as yourself don't know any >> computer-science whatsoever, then or now. >> > > You are very confused about this, and predictably didactic & rude to > Elizabeth. > > Circular buffers are but one method for handling incoming or outgoing > data, and they have been used for a lot longer than you realise. > > A circular buffer can be as simple as a block of data, addressed by an > index modulo the number of buffers. I have no idea why you think a pair > of registers is required. Neither is data movement needed, since we can > use a circular buffer of pointers to data. > > ISRs are typically very short and do as little work as is possible. The > general rule is to try and minimise the amount of time in interrupts, > esecialy if they block other activity, and to do the bulk of the work > outside of the interrupt. An ISR may be as simple as moving a task > pointer from a blocked to a ready queue as part of a scheduler, and the > work is done later by the task. I'm not sure why the emphasis of this discussion is on moving data in the interrupt routine. These days all but the low end MCUs use hardware to move data to/from an I/O device and memory. We often call that DMA although in some cases the hardware used is actually a very simple programmable processor. The interrupt routine has only to pass through to the task the fact that the transfer has completed and it is time to awaken the task that uses the data. You likely won't have this in a $0.50 processor used to control a toy or control panel for a microwave, but then those devices aren't going to be moving much data and likely won't be using interrupts. A/D and D/A conversion is a common example of I/O that requires blocks of data to be moved. This is handled by hardware in a great number of processors even at the low end. An extreme example is the GA144 where *all* I/O is done by allocating to each I/O task the hardware of a dedicated processor. Then the comms between the processors is handled by dedicated hardware. But then the GA144 is not exactly a low end device. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2016-11-29 18:38 +0000 |
| Message-ID | <o1khsm$vvh$1@dont-email.me> |
| In reply to | #52960 |
On 11/29/2016 17:43, rickman wrote: > On 11/28/2016 8:43 AM, Alex wrote: >> >> ISRs are typically very short and do as little work as is possible. The >> general rule is to try and minimise the amount of time in interrupts, >> esecialy if they block other activity, and to do the bulk of the work >> outside of the interrupt. An ISR may be as simple as moving a task >> pointer from a blocked to a ready queue as part of a scheduler, and the >> work is done later by the task. > > I'm not sure why the emphasis of this discussion is on moving data in > the interrupt routine. These days all but the low end MCUs use hardware > to move data to/from an I/O device and memory. We often call that DMA > although in some cases the hardware used is actually a very simple > programmable processor. The interrupt routine has only to pass through > to the task the fact that the transfer has completed and it is time to > awaken the task that uses the data. > By move I meant load and store. -- Alex
[toc] | [prev] | [next] | [standalone]
| From | Brad Eckert <hwfwguy@gmail.com> |
|---|---|
| Date | 2016-11-29 13:57 -0800 |
| Message-ID | <b960fe31-d9c8-485d-9fd9-ac7a8d347fcd@googlegroups.com> |
| In reply to | #52960 |
On Tuesday, November 29, 2016 at 10:43:03 AM UTC-7, rickman wrote: > > ISRs are typically very short and do as little work as is possible. The > > general rule is to try and minimise the amount of time in interrupts, > > esecialy if they block other activity, and to do the bulk of the work > > outside of the interrupt. An ISR may be as simple as moving a task > > pointer from a blocked to a ready queue as part of a scheduler, and the > > work is done later by the task. > > I'm not sure why the emphasis of this discussion is on moving data in > the interrupt routine. These days all but the low end MCUs use hardware > to move data to/from an I/O device and memory. We often call that DMA > although in some cases the hardware used is actually a very simple > programmable processor. The interrupt routine has only to pass through > to the task the fact that the transfer has completed and it is time to > awaken the task that uses the data. > I think Elizabeth was referring to the high-priority / low-priority task split that worked so well on ancient hardware (and works well today). The low priority task is serviced by a rapid cooperative multitasker. The technique can be used outside of Forth. One time our development team farmed out development of a communication stack (in C). The code worked, but it was blocking our code in a lot of places. I wrote a little cooperative task switcher in assembly to make it yield to our code.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-12-02 16:50 -0800 |
| Message-ID | <f593bc73-a049-4838-ac30-09d6d912b914@googlegroups.com> |
| In reply to | #52908 |
On Sunday, November 27, 2016 at 6:12:54 PM UTC-7, Elizabeth D. Rather wrote: > In SwiftX we follow the convention that a task > managing an interrupt-driven device initiates an operation and then > "sleeps" until an interrupt signals its completion. The interrupt > routine does only the minimum required (tally a counter, read a number > and store it, etc.) and wakes the task, which does any other processing > in high-level Forth. All of this talk about DMA is just hand-waving to distract from what Elizabeth Rather said above: "read a number and store it." She is talking about I/O that produces one number at a time, such as a DAC or UART --- at Forth Inc. they use a simple variable, so their buffer can contain one element --- the main-program has to transfer the data one number at a time, just as it would if there no interrupts. The only advantage that Forth Inc. is deriving from the use of an interrupt is that they can go into low-power sleep mode while waiting for slow I/O --- other than that though, they might as well just not use interrupts at all --- even by 1970s standards, this would be pretty primitive; I think you would have to go back to the early 1960s to find processors without interrupts.
[toc] | [prev] | [next] | [standalone]
| From | polymorph self <jackvanc3@gmail.com> |
|---|---|
| Date | 2016-12-01 00:19 -0800 |
| Message-ID | <6edcc04d-7d67-4bcd-b26c-b8d31342fdd9@googlegroups.com> |
| In reply to | #52895 |
On Sunday, November 27, 2016 at 5:08:26 AM UTC-5, Rod Pemberton wrote: > On Sun, 27 Nov 2016 00:25:22 -0800 (PST) > polymorph self <jackvanc3@gmail.com> wrote: > > > > Probably not. Remember also that assembler code is harder to write > > > and to maintain, and affects both cost and time to market. As I keep > > > pointing out, I haven't written an interrupt routine in assembler > > > for an ARM for about 15 years ... except to prove that I can still > > > do it. A good code generator is an enabling technology. > > > > > by the gods I can't even imagine writing an interrupt in assembler > > It's no different than coding a subroutine or procedure in assembly. > You just have to take care of some extra steps. > > There are a bunch of people who have done so for the x86 processor on > alt.os.development. I have yet to see anyone on a.o.d. who codes for > the ARM processor. > > > how the hell did you learn such? > > You read the programmer instruction manuals from the processor > manufacturer. You teach yourself how to program in assembly. Then, > like everything else in life, you solve the puzzle. You make it work by > doing what needs to be done. Think of it as a procedure with a few > extra layers wrapped around the code for a procedure. > > For x86, the basic sequence is: > > disable interrupts > preserve registers > (optionally) switch stacks > do what needs to be done for the interrupt procedure > (optionally) restore stacks > restore registers > enable interrupts > return from interrupt > > Of course, you have to do that sequence in assembly. But, you don't > have to code the interrupt in assembly. You can code most of it > in a high level language like C. However, most high level languages > don't provide a mechanism to implement interrupt routines. So, you > have to find a method to transfer from assembly to the high level > language, and a way to transfer back too. This is more assembly code. > This code is custom to each compiler. > > > Rod Pemberton Interesting...so humans like me could learn it given some time and effort....
[toc] | [prev] | [next] | [standalone]
| From | mhx@iae.nl |
|---|---|
| Date | 2016-11-18 10:58 -0800 |
| Message-ID | <368615e8-0f88-4941-8dfc-340a4388e15b@googlegroups.com> |
| In reply to | #52710 |
On Friday, November 18, 2016 at 3:37:37 PM UTC+1, foxaudio...@gmail.com wrote: > On Friday, November 18, 2016 at 6:17:01 AM UTC-5, Stephen Pelc wrote: > > On Thu, 17 Nov 2016 15:58:33 -0800, Paul Rubin > > <no.email@nospam.invalid> wrote: > > > > >I don't know about Foxaudio, but I'd say "very well" means the ITC > > >performance is enough to satisfy users' real-world requirements. Most > > >of my stuff these days is written in Python and it's fast enough for my > > >purposes, and Gforth-itc is probably >10x faster than Python. I've > > >never written a Forth program that wasn't a benchmark, that used enough > > >computation time for me to notice. > > > > One of our clients has a recalculation that used to take 15 or so > > seconds on our DTC ProForth for Windows. The boss excitedly took > > me to his office to show that the conversion to VFX Forth took > > about 1.5 seconds. To him, that was important. > > > > These days, there are plenty of algorithms that do not follow the > > "90% of the time in 10% of the code" model. > > > > Stephen > > > > -- > > Stephen Pelc, stephenXXX@mpeforth.com > > MicroProcessor Engineering Ltd - More Real, Less Time > > 133 Hill Lane, Southampton SO15 5AF, England > > tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691 > > web: http://www.mpeforth.com - free VFX Forth downloads > > That's a better ratio of improvement over DTC in intel than I would have > expected Stephen, so VFX is quite efficient. > > I have a question. > > Let me begin with the fact that I have nothing but praise for the excellent > work MPE has done in pushing the envelope in native code generation with Forth > compilers. Here here. > > I find myself wondering what you would have done with that client if they had > requested a speedup on that recalculation and you had NOT developed VFX? > ( I am assuming they were prepared to pay for the work) > > Could you have hand coded a few time critical/inner loop routines and achieved those results? In the past I posted on pinholed eForth and mxForth. When developing these I enabled specific optimizations with options so that I could test all the combinations. These postings backup Stephen's numbers. They also backup the observation that at some point the Forth does not get faster anymore and one needs to overhaul the code generator from scratch. When I have some time again I will give iForth speculative threads and rewrite the code generator for AVX2. But first there will be SPICE written in Forth :-) -marcel
[toc] | [prev] | [next] | [standalone]
| From | "HAA" <someone@microsoft.com> |
|---|---|
| Date | 2016-11-19 11:29 +1100 |
| Message-ID | <o0o6e4$a9a$1@gioia.aioe.org> |
| In reply to | #52709 |
Stephen Pelc wrote: > On Thu, 17 Nov 2016 15:58:33 -0800, Paul Rubin > <no.email@nospam.invalid> wrote: > > >I don't know about Foxaudio, but I'd say "very well" means the ITC > >performance is enough to satisfy users' real-world requirements. Most > >of my stuff these days is written in Python and it's fast enough for my > >purposes, and Gforth-itc is probably >10x faster than Python. I've > >never written a Forth program that wasn't a benchmark, that used enough > >computation time for me to notice. > > One of our clients has a recalculation that used to take 15 or so > seconds on our DTC ProForth for Windows. The boss excitedly took > me to his office to show that the conversion to VFX Forth took > about 1.5 seconds. To him, that was important. > > These days, there are plenty of algorithms that do not follow the > "90% of the time in 10% of the code" model. > > Stephen No doubt your client could also demonstrate that VFX is faster than SwiftForth. Yet Forth Inc still exists and presumably gets work. The model which states 'fastest is best' appears not to follow. What happens when 1.5 seconds is not good enough? Discard Forth for C? That's not unreasonable either. CPU, clock, language, facilities, I rank greater than compiler technology. Get those wrong and it won't matter whether it's DTC or NCC.
[toc] | [prev] | [next] | [standalone]
Page 2 of 7 — ← Prev page 1 [2] 3 4 5 6 7 Next page →
Back to top | Article view | comp.lang.forth
csiph-web