Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #32547 > unrolled thread
| Started by | Jason Damisch <jasondamisch@yahoo.com> |
|---|---|
| First post | 2014-07-22 14:44 -0700 |
| Last post | 2014-07-30 22:55 -0700 |
| Articles | 20 on this page of 97 — 20 participants |
Back to article view | Back to comp.lang.forth
What for Break Key No Work? Jason Damisch <jasondamisch@yahoo.com> - 2014-07-22 14:44 -0700
Re: What for Break Key No Work? Roger Levy <roger.levy@gmail.com> - 2014-07-22 14:50 -0700
Re: What for Break Key No Work? Jason Damisch <jasondamisch@yahoo.com> - 2014-07-22 15:04 -0700
Re: What for Break Key No Work? Jason Damisch <jasondamisch@yahoo.com> - 2014-07-22 16:03 -0700
Re: What for Break Key No Work? BruceMcF <agila61@netscape.net> - 2014-07-22 18:34 -0700
Re: What for Break Key No Work? Jason Damisch <jasondamisch@yahoo.com> - 2014-07-22 19:32 -0700
Re: What for Break Key No Work? Spam@ControlQ.com - 2014-07-22 22:43 -0400
Re: What for Break Key No Work? Jason Damisch <jasondamisch@yahoo.com> - 2014-07-23 09:57 -0700
Re: What for Break Key No Work? "Elizabeth D. Rather" <erather@forth.com> - 2014-07-23 07:12 -1000
Re: What for Break Key No Work? Jason Damisch <jasondamisch@yahoo.com> - 2014-07-23 10:15 -0700
Re: What for Break Key No Work? rickman <gnuarm@gmail.com> - 2014-07-22 22:44 -0400
Re: What for Break Key No Work? Jason Damisch <jasondamisch@yahoo.com> - 2014-07-23 09:58 -0700
Re: What for Break Key No Work? "Elizabeth D. Rather" <erather@forth.com> - 2014-07-23 21:28 -1000
Re: What for Break Key No Work? BruceMcF <agila61@netscape.net> - 2014-07-23 13:12 -0700
Re: What for Break Key No Work? Jason Damisch <jasondamisch@yahoo.com> - 2014-07-23 14:52 -0700
Re: What for Break Key No Work? Mark Wills <markwills1970@gmail.com> - 2014-07-24 01:54 -0700
Re: What for Break Key No Work? rickman <gnuarm@gmail.com> - 2014-07-24 07:54 -0400
Re: What for Break Key No Work? Mark Wills <markwills1970@gmail.com> - 2014-07-24 06:49 -0700
Re: What for Break Key No Work? rickman <gnuarm@gmail.com> - 2014-07-24 10:39 -0400
Re: What for Break Key No Work? bruce.mcfarling@gmail.com - 2014-07-24 08:52 -0700
Re: What for Break Key No Work? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-07-24 13:07 -0500
Re: What for Break Key No Work? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-07-25 10:50 +0000
Re: What for Break Key No Work? Bernd Paysan <bernd.paysan@gmx.de> - 2014-07-25 14:38 +0200
Re: What for Break Key No Work? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-07-25 17:07 +0000
Re: What for Break Key No Work? Bernd Paysan <bernd.paysan@gmx.de> - 2014-07-26 00:36 +0200
Re: What for Break Key No Work? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-07-27 13:47 +0000
Re: What for Break Key No Work? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-07-25 09:21 -0500
Re: What for Break Key No Work? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-07-25 17:10 +0000
Re: What for Break Key No Work? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-07-26 04:38 -0500
Re: What for Break Key No Work? Bernd Paysan <bernd.paysan@gmx.de> - 2014-07-26 15:56 +0200
Re: What for Break Key No Work? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-07-27 13:27 +0000
Re: What for Break Key No Work? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-07-27 09:36 -0500
Re: What for Break Key No Work? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-07-28 11:38 +0000
Re: What for Break Key No Work? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-07-28 10:42 -0500
Re: What for Break Key No Work? "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-07-25 16:56 -0400
Re: What for Break Key No Work? "Elizabeth D. Rather" <erather@forth.com> - 2014-07-26 09:33 +0000
Re: What for Break Key No Work? rickman <gnuarm@gmail.com> - 2014-07-24 19:40 -0400
Re: What for Break Key No Work? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-07-25 00:00 +0000
Re: What for Break Key No Work? rickman <gnuarm@gmail.com> - 2014-07-24 22:17 -0400
Re: What for Break Key No Work? bruce.mcfarling@gmail.com - 2014-07-25 06:54 -0700
Re: What for Break Key No Work? "Elizabeth D. Rather" <erather@forth.com> - 2014-07-25 13:13 -0400
Re: What for Break Key No Work? rickman <gnuarm@gmail.com> - 2014-07-25 13:24 -0400
Re: What for Break Key No Work? bruce.mcfarling@gmail.com - 2014-07-25 14:37 -0700
Re: What for Break Key No Work? rickman <gnuarm@gmail.com> - 2014-07-25 19:01 -0400
Re: What for Break Key No Work? bruce.mcfarling@gmail.com - 2014-07-25 16:20 -0700
Re: What for Break Key No Work? rickman <gnuarm@gmail.com> - 2014-07-25 22:02 -0400
Re: What for Break Key No Work? rickman <gnuarm@gmail.com> - 2014-07-25 22:17 -0400
Re: What for Break Key No Work? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-07-26 09:09 +0000
Re: What for Break Key No Work? rickman <gnuarm@gmail.com> - 2014-07-26 05:36 -0400
Re: What for Break Key No Work? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-07-26 04:41 -0500
Re: What for Break Key No Work? rickman <gnuarm@gmail.com> - 2014-07-26 22:50 -0400
Re: What for Break Key No Work? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-07-27 02:49 -0500
Re: What for Break Key No Work? rickman <gnuarm@gmail.com> - 2014-07-27 15:08 -0400
Re: What for Break Key No Work? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-07-27 14:11 -0500
Re: What for Break Key No Work? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-07-28 12:00 +0000
Re: What for Break Key No Work? rickman <gnuarm@gmail.com> - 2014-07-28 10:41 -0400
Re: What for Break Key No Work? Bernd Paysan <bernd.paysan@gmx.de> - 2014-07-27 14:31 +0200
Re: What for Break Key No Work? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-07-27 13:08 +0000
Re: What for Break Key No Work? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-07-27 19:37 +0000
Re: What for Break Key No Work? rickman <gnuarm@gmail.com> - 2014-07-27 16:35 -0400
Re: What for Break Key No Work? "Elizabeth D. Rather" <erather@forth.com> - 2014-07-27 22:24 +0000
Re: What for Break Key No Work? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-07-28 13:14 +0000
Re: What for Break Key No Work? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-07-28 03:41 -0500
Re: What for Break Key No Work? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-07-28 12:09 +0000
Re: What for Break Key No Work? rickman <gnuarm@gmail.com> - 2014-07-28 10:48 -0400
Re: What for Break Key No Work? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-07-28 15:29 +0000
Re: What for Break Key No Work? rickman <gnuarm@gmail.com> - 2014-07-28 14:30 -0400
Re: What for Break Key No Work? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-07-29 08:12 +0000
Re: What for Break Key No Work? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-07-28 13:10 +0000
Re: What for Break Key No Work? bruce.mcfarling@gmail.com - 2014-07-27 11:33 -0700
Re: What for Break Key No Work? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-07-28 11:55 +0000
Re: What for Break Key No Work? "Alex McDonald" <blog@rivadpm.com> - 2014-07-28 14:03 +0100
Re: What for Break Key No Work? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-07-27 13:02 +0000
Re: What for Break Key No Work? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-07-26 08:57 +0000
Re: What for Break Key No Work? rickman <gnuarm@gmail.com> - 2014-07-26 05:05 -0400
Re: What for Break Key No Work? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-07-26 09:20 +0000
Re: What for Break Key No Work? "Alex McDonald" <blog@rivadpm.com> - 2014-07-23 23:48 +0100
Re: What for Break Key No Work? rickman <gnuarm@gmail.com> - 2014-07-24 04:53 -0400
Re: What for Break Key No Work? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-07-24 10:59 +0000
Re: What for Break Key No Work? mhx@iae.nl - 2014-07-24 04:23 -0700
Re: What for Break Key No Work? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-07-24 19:28 +0000
Re: What for Break Key No Work? "Elizabeth D. Rather" <erather@forth.com> - 2014-07-24 13:01 -1000
Re: What for Break Key No Work? Roelf Toxopeus <rt4all@notthis.hetnet.nl> - 2014-07-25 10:13 +0200
Re: What for Break Key No Work? "Elizabeth D. Rather" <erather@forth.com> - 2014-07-22 17:11 -1000
Re: What for Break Key No Work? Jason Damisch <jasondamisch@yahoo.com> - 2014-07-23 09:59 -0700
Re: What for Break Key No Work? David Schultz <abuse@127.0.0.1> - 2014-07-22 17:47 -0500
Re: What for Break Key No Work? rickman <gnuarm@gmail.com> - 2014-07-22 19:12 -0400
Re: What for Break Key No Work? Jason Damisch <jasondamisch@yahoo.com> - 2014-07-22 16:21 -0700
Re: What for Break Key No Work? rickman <gnuarm@gmail.com> - 2014-07-22 22:51 -0400
Re: What for Break Key No Work? Matthias Trute <matthias.trute@gmail.com> - 2014-07-23 02:18 -0700
Re: What for Break Key No Work? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-07-23 13:21 +0000
Re: What for Break Key No Work? Jason Damisch <jasondamisch@yahoo.com> - 2014-07-23 10:02 -0700
Re: What for Break Key No Work? Bernd Paysan <bernd.paysan@gmx.de> - 2014-07-24 04:10 +0200
Re: What for Break Key No Work? mhx@iae.nl - 2014-07-23 13:45 -0700
Re: What for Break Key No Work? BruceMcF <agila61@netscape.net> - 2014-07-23 16:37 -0700
Re: What for Break Key No Work? "Clyde W. Phillips Jr." <cwpjr02@gmail.com> - 2014-07-30 16:13 -0700
Re: What for Break Key No Work? francois.ganza@wanadoo.fr - 2014-07-30 22:55 -0700
Page 3 of 5 — ← Prev page 1 2 [3] 4 5 Next page →
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2014-07-25 13:13 -0400 |
| Message-ID | <W6qdnVWiaqrODU_OnZ2dnUVZ_hmdnZ2d@supernews.com> |
| In reply to | #32629 |
On 7/24/14 7:40 PM, rickman wrote: > On 7/24/2014 11:52 AM, bruce.mcfarling@gmail.com wrote: >> On Thursday, July 24, 2014 10:39:21 AM UTC-4, rickman wrote: >>> You don't need to check at every semi do you? I think once around the >>> loop is enough. The semi is used greatly and adding any code to that >>> would slow down the process. Adding it to the looping words would not >>> have as much impact. >> >> Checking it in BRANCH and ?BRANCH (or whatever the branching >> operations that implement the loops are called in the implementation >> at hand) might be more often than checking it at SEMI if there are >> nothing but primitives in the loop ... but BRANCH and ?BRANCH would be >> the place to check it if you wanted to go that route, as that is >> precisely where you can get caught in an endless loop. >> >> Doing it with an interrupt seems a more natural approach, if available. > > Doing what with an interrupt? Detecting and responding to a Break or CtrlC, I assume. Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2014-07-25 13:24 -0400 |
| Message-ID | <lqu3tk$n49$1@dont-email.me> |
| In reply to | #32653 |
On 7/25/2014 1:13 PM, Elizabeth D. Rather wrote: > On 7/24/14 7:40 PM, rickman wrote: >> On 7/24/2014 11:52 AM, bruce.mcfarling@gmail.com wrote: >>> On Thursday, July 24, 2014 10:39:21 AM UTC-4, rickman wrote: >>>> You don't need to check at every semi do you? I think once around the >>>> loop is enough. The semi is used greatly and adding any code to that >>>> would slow down the process. Adding it to the looping words would not >>>> have as much impact. >>> >>> Checking it in BRANCH and ?BRANCH (or whatever the branching >>> operations that implement the loops are called in the implementation >>> at hand) might be more often than checking it at SEMI if there are >>> nothing but primitives in the loop ... but BRANCH and ?BRANCH would be >>> the place to check it if you wanted to go that route, as that is >>> precisely where you can get caught in an endless loop. >>> >>> Doing it with an interrupt seems a more natural approach, if available. >> >> Doing what with an interrupt? > > Detecting and responding to a Break or CtrlC, I assume. Yes, I know that. No one seems to be giving details on how to do this. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | bruce.mcfarling@gmail.com |
|---|---|
| Date | 2014-07-25 14:37 -0700 |
| Message-ID | <854d2f08-ef40-4535-a008-1d2f568da058@googlegroups.com> |
| In reply to | #32655 |
On Friday, July 25, 2014 1:24:55 PM UTC-4, rickman wrote: > On 7/25/2014 1:13 PM, Elizabeth D. Rather wrote: >>> Doing what with an interrupt? >> >> Detecting and responding to a Break or CtrlC, I assume. > > Yes, I know that. No one seems to be giving details on how to do this. Anton appears to be, "Gforth directly throws when it receives an asynchronous signal. My experience is that, while there is no guarantee, nothing was broken unexpectedly yet. We restore state when we finish in a number of places, and that does prevent real problems (we experienced such problems earlier)."
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2014-07-25 19:01 -0400 |
| Message-ID | <lqunkd$ufd$1@dont-email.me> |
| In reply to | #32661 |
On 7/25/2014 5:37 PM, bruce.mcfarling@gmail.com wrote: > On Friday, July 25, 2014 1:24:55 PM UTC-4, rickman wrote: >> On 7/25/2014 1:13 PM, Elizabeth D. Rather wrote: >>>> Doing what with an interrupt? >>> >>> Detecting and responding to a Break or CtrlC, I assume. >> >> Yes, I know that. No one seems to be giving details on how to do this. > > Anton appears to be, "Gforth directly throws when it receives an asynchronous signal. My experience is that, while there is no guarantee, nothing was broken unexpectedly yet. We restore state when we finish in a number of places, and that does prevent real problems (we experienced such problems earlier)." I don't see any mention of using interrupts. In my experience interrupts are used in this sort of context in small systems with simple or no OS. Anton mentions an "asynchronous signal" I assume in the context of a complex OS like Windows or Linux. The interrupt may be part of this, but it is completely invisible to the user as it comes from the keyboard or a system timer (most likely the latter) and is processed to create a message. The "asynchronous event" refers to the system sending a message to the task, no? I'm just looking for an explanation of what was meant by using "an interrupt". If that was supposed to be a synonym for "asynchronous signal" then I understand. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | bruce.mcfarling@gmail.com |
|---|---|
| Date | 2014-07-25 16:20 -0700 |
| Message-ID | <2c176e57-2f20-47df-8293-c2b7860365dd@googlegroups.com> |
| In reply to | #32663 |
On Friday, July 25, 2014 7:01:22 PM UTC-4, rickman wrote: > On 7/25/2014 5:37 PM, BruceMcF wrote: > > > On Friday, July 25, 2014 1:24:55 PM UTC-4, rickman wrote: > > >> On 7/25/2014 1:13 PM, Elizabeth D. Rather wrote: > > >>>> Doing what with an interrupt? > > >>> > > >>> Detecting and responding to a Break or CtrlC, I assume. > > >> > > >> Yes, I know that. No one seems to be giving details on how to do this. > > > > > > Anton appears to be, "Gforth directly throws when it receives an asynchronous signal. My experience is that, while there is no guarantee, nothing was broken unexpectedly yet. We restore state when we finish in a number of places, and that does prevent real problems (we experienced such problems earlier)." > > I don't see any mention of using interrupts. In my experience > interrupts are used in this sort of context in small systems with simple > or no OS. > Anton mentions an "asynchronous signal" I assume in the > context of a complex OS like Windows or Linux. The interrupt may be > part of this, but it is completely invisible to the user as it comes > from the keyboard or a system timer (most likely the latter) and is > processed to create a message. The OP question is about why a Forth system on a particular peculiar, through widely distributed, OS doesn't exhibit a particular behavior in response to the user pressing the [Break] key. > The "asynchronous event" refers to the > system sending a message to the task, no? If that message halts the execution of: : FRED BEGIN AGAIN ; FRED ... which it does, then there is an interrupt occurring somewhere between the Ctrl-C and the THROW. The loop is bring interrupted on a regular basis, since its running on a multiprocessing OS, but that interrupt is not being *used to* halt the loop in response to the [Break] key in the way that the OP expected from experience from an early BASIC on an earlier OS. > I'm just looking for an explanation of what was meant by using "an > interrupt". Shift the quotation marks ... I believe you are looking for an explanation for what was meant by "using", ie, relying on the loop being interrupted as part of the response to the user request, as opposed to the compiled code doing the halt itself, eg via a backward BRANCH checking for a pending halt signal.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2014-07-25 22:02 -0400 |
| Message-ID | <lqv284$kae$1@dont-email.me> |
| In reply to | #32664 |
On 7/25/2014 7:20 PM, bruce.mcfarling@gmail.com wrote: > On Friday, July 25, 2014 7:01:22 PM UTC-4, rickman wrote: >> On 7/25/2014 5:37 PM, BruceMcF wrote: >> >>> On Friday, July 25, 2014 1:24:55 PM UTC-4, rickman wrote: >> >>>> On 7/25/2014 1:13 PM, Elizabeth D. Rather wrote: >> >>>>>> Doing what with an interrupt? >> >>>>> >> >>>>> Detecting and responding to a Break or CtrlC, I assume. >> >>>> >> >>>> Yes, I know that. No one seems to be giving details on how to do this.. >> >>> >> >>> Anton appears to be, "Gforth directly throws when it receives an asynchronous signal. My experience is that, while there is no guarantee, nothing was broken unexpectedly yet. We restore state when we finish in a number of places, and that does prevent real problems (we experienced such problems earlier)." >> >> I don't see any mention of using interrupts. In my experience >> interrupts are used in this sort of context in small systems with simple >> or no OS. > >> Anton mentions an "asynchronous signal" I assume in the >> context of a complex OS like Windows or Linux. The interrupt may be >> part of this, but it is completely invisible to the user as it comes >> from the keyboard or a system timer (most likely the latter) and is >> processed to create a message. > > The OP question is about why a Forth system on a particular peculiar, through widely distributed, OS doesn't exhibit a particular behavior in response to the user pressing the [Break] key. > >> The "asynchronous event" refers to the >> system sending a message to the task, no? > > If that message halts the execution of: > : FRED BEGIN AGAIN ; FRED > > .... which it does, then there is an interrupt occurring somewhere between the Ctrl-C and the THROW. > > The loop is bring interrupted on a regular basis, since its running on a multiprocessing OS, but that interrupt is not being *used to* halt the loop in response to the [Break] key in the way that the OP expected from experience from an early BASIC on an earlier OS. > >> I'm just looking for an explanation of what was meant by using "an >> interrupt". > > Shift the quotation marks ... I believe you are looking for an explanation for what was meant by "using", ie, relying on the loop being interrupted as part of the response to the user request, as opposed to the compiled code doing the halt itself, eg via a backward BRANCH checking for a pending halt signal. Not really. I understand the difference between the two. In the one case the code in the loop has specific instructions to allow the loop to exit when something external sets a flag. In the case of the real time interrupt control is passed to the system we determines that the process needs to be "handled". What I want to know is how the process conveys control back to the Forth outer interpreter. The Forth process is stuck in a loop and the CPU is now executing the OS. How does the Forth process return to running the interpreter rather than the user code? -- Rick
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2014-07-25 22:17 -0400 |
| Message-ID | <lqv33g$olk$2@dont-email.me> |
| In reply to | #32665 |
On 7/25/2014 10:02 PM, rickman wrote: > On 7/25/2014 7:20 PM, bruce.mcfarling@gmail.com wrote: >> On Friday, July 25, 2014 7:01:22 PM UTC-4, rickman wrote: >>> On 7/25/2014 5:37 PM, BruceMcF wrote: >>> >>>> On Friday, July 25, 2014 1:24:55 PM UTC-4, rickman wrote: >>> >>>>> On 7/25/2014 1:13 PM, Elizabeth D. Rather wrote: >>> >>>>>>> Doing what with an interrupt? >>> >>>>>> >>> >>>>>> Detecting and responding to a Break or CtrlC, I assume. >>> >>>>> >>> >>>>> Yes, I know that. No one seems to be giving details on how to do >>>>> this.. >>> >>>> >>> >>>> Anton appears to be, "Gforth directly throws when it receives an >>>> asynchronous signal. My experience is that, while there is no >>>> guarantee, nothing was broken unexpectedly yet. We restore state >>>> when we finish in a number of places, and that does prevent real >>>> problems (we experienced such problems earlier)." >>> >>> I don't see any mention of using interrupts. In my experience >>> interrupts are used in this sort of context in small systems with simple >>> or no OS. >> >>> Anton mentions an "asynchronous signal" I assume in the >>> context of a complex OS like Windows or Linux. The interrupt may be >>> part of this, but it is completely invisible to the user as it comes >>> from the keyboard or a system timer (most likely the latter) and is >>> processed to create a message. >> >> The OP question is about why a Forth system on a particular peculiar, >> through widely distributed, OS doesn't exhibit a particular behavior >> in response to the user pressing the [Break] key. >> >>> The "asynchronous event" refers to the >>> system sending a message to the task, no? >> >> If that message halts the execution of: >> : FRED BEGIN AGAIN ; FRED >> >> .... which it does, then there is an interrupt occurring somewhere >> between the Ctrl-C and the THROW. >> >> The loop is bring interrupted on a regular basis, since its running on >> a multiprocessing OS, but that interrupt is not being *used to* halt >> the loop in response to the [Break] key in the way that the OP >> expected from experience from an early BASIC on an earlier OS. >> >>> I'm just looking for an explanation of what was meant by using "an >>> interrupt". >> >> Shift the quotation marks ... I believe you are looking for an >> explanation for what was meant by "using", ie, relying on the loop >> being interrupted as part of the response to the user request, as >> opposed to the compiled code doing the halt itself, eg via a backward >> BRANCH checking for a pending halt signal. > > Not really. I understand the difference between the two. In the one > case the code in the loop has specific instructions to allow the loop to > exit when something external sets a flag. In the case of the real time > interrupt control is passed to the system we determines that the process > needs to be "handled". What I want to know is how the process conveys > control back to the Forth outer interpreter. The Forth process is stuck > in a loop and the CPU is now executing the OS. How does the Forth > process return to running the interpreter rather than the user code? That should be --- In the case of the real time interrupt control is passed to the system which determines that the process needs to be "handled". -- Rick
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2014-07-26 09:09 +0000 |
| Message-ID | <53d3704e$0$15938$e4fe514c@dreader35.news.xs4all.nl> |
| In reply to | #32665 |
In article <lqv284$kae$1@dont-email.me>, rickman <gnuarm@gmail.com> wrote: >On 7/25/2014 7:20 PM, bruce.mcfarling@gmail.com wrote: >> On Friday, July 25, 2014 7:01:22 PM UTC-4, rickman wrote: >>> On 7/25/2014 5:37 PM, BruceMcF wrote: >>> >>>> On Friday, July 25, 2014 1:24:55 PM UTC-4, rickman wrote: >>> >>>>> On 7/25/2014 1:13 PM, Elizabeth D. Rather wrote: >>> >>>>>>> Doing what with an interrupt? >>> >>>>>> >>> >>>>>> Detecting and responding to a Break or CtrlC, I assume. >>> >>>>> >>> >>>>> Yes, I know that. No one seems to be giving details on how to do this.. >>> >>>> >>> >>>> Anton appears to be, "Gforth directly throws when it receives an >asynchronous signal. My experience is that, while there is no >guarantee, nothing was broken unexpectedly yet. We restore state when >we finish in a number of places, and that does prevent real problems (we >experienced such problems earlier)." >>> >>> I don't see any mention of using interrupts. In my experience >>> interrupts are used in this sort of context in small systems with simple >>> or no OS. >> >>> Anton mentions an "asynchronous signal" I assume in the >>> context of a complex OS like Windows or Linux. The interrupt may be >>> part of this, but it is completely invisible to the user as it comes >>> from the keyboard or a system timer (most likely the latter) and is >>> processed to create a message. >> >> The OP question is about why a Forth system on a particular peculiar, >through widely distributed, OS doesn't exhibit a particular behavior in >response to the user pressing the [Break] key. >> >>> The "asynchronous event" refers to the >>> system sending a message to the task, no? >> >> If that message halts the execution of: >> : FRED BEGIN AGAIN ; FRED >> >> .... which it does, then there is an interrupt occurring somewhere >between the Ctrl-C and the THROW. >> >> The loop is bring interrupted on a regular basis, since its running on >a multiprocessing OS, but that interrupt is not being *used to* halt the >loop in response to the [Break] key in the way that the OP expected from >experience from an early BASIC on an earlier OS. >> >>> I'm just looking for an explanation of what was meant by using "an >>> interrupt". >> >> Shift the quotation marks ... I believe you are looking for an >explanation for what was meant by "using", ie, relying on the loop being >interrupted as part of the response to the user request, as opposed to >the compiled code doing the halt itself, eg via a backward BRANCH >checking for a pending halt signal. > >Not really. I understand the difference between the two. In the one >case the code in the loop has specific instructions to allow the loop to >exit when something external sets a flag. In the case of the real time >interrupt control is passed to the system we determines that the process >needs to be "handled". What I want to know is how the process conveys >control back to the Forth outer interpreter. The Forth process is stuck >in a loop and the CPU is now executing the OS. How does the Forth >process return to running the interpreter rather than the user code? There is this COLD start address and a WARM start address. The Forth implementor has to put some thoughts into what's done at a WARM start address versus a COLD start address. These are a lot of details that are all handled on a nitty gritty basis. In a COLD start you have to open a block file, and in a WARM start you may assume the handle is still valid, but you have to use REPOSITION-FILE because you have lost any knowledge about where the file pointer hangs out. You must document what the effect of UPDATE is, if a program is interrupted. Probably you have to admit that you can't be sure whether an updated block is written to disk, so the advise up is to just look at it manually. etc. etc. This requires intimate knowledge of the system, and it is easy to overlook something. In other words, don't try this at home. If your implementor doesn't provide the facility, you better give up (for professional use). If you're just hobbying and learning, this is an excellent opportunity to go where no one has threaded before. > >-- > >Rick 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 | 2014-07-26 05:36 -0400 |
| Message-ID | <lqvsrb$qb7$1@dont-email.me> |
| In reply to | #32678 |
On 7/26/2014 5:09 AM, Albert van der Horst wrote: > > There is this COLD start address and a WARM start address. > The Forth implementor has to put some thoughts into what's done at > a WARM start address versus a COLD start address. > These are a lot of details that are all handled on a nitty gritty basis. > In a COLD start you have to open a block file, and in a WARM start you > may assume the handle is still valid, but you have to use REPOSITION-FILE > because you have lost any knowledge about where the file pointer hangs out. > You must document what the effect of UPDATE is, if a program is interrupted. > Probably you have to admit that you can't be sure whether an updated block > is written to disk, so the advise up is to just look at it manually. > etc. etc. > > This requires intimate knowledge of the system, and it is easy to overlook > something. In other words, don't try this at home. If your implementor > doesn't provide the facility, you better give up (for professional use). > > If you're just hobbying and learning, this is an excellent opportunity to > go where no one has threaded before. Yes, I think a lot of this is second nature to you. I think at a different level I guess. People have mentioned more than one Forth system which does process the Cntl-C to return the user to the prompt. In at least on case it tries to debug the failure and provide some useful info. I guess I am asking how they are currently doing this. I think we started this fork of the conversation talking about interrupts. I'm still not clear on what is meant by interrupt. I am thinking of the traditional interrupt in a CPU. I realize that interrupts are commonly used in a CPU to generate exceptions. In the case of an OS like Windows or Linux the interrupts are totally internal to the OS. A user program like Forth doesn't know it is being suspended a bazillion times. My question is how is that Forth process redirected to something that can look at the current state of the failed code and give an error report. If you just want the Forth prompt back the program can be killed and restarted. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-07-26 04:41 -0500 |
| Message-ID | <rfCdnX1GltBJ6k7OnZ2dnUVZ8h6dnZ2d@supernews.com> |
| In reply to | #32665 |
rickman <gnuarm@gmail.com> wrote: > > Not really. I understand the difference between the two. In the > one case the code in the loop has specific instructions to allow the > loop to exit when something external sets a flag. In the case of > the real time interrupt control is passed to the system we > determines that the process needs to be "handled". What I want to > know is how the process conveys control back to the Forth outer > interpreter. The Forth process is stuck in a loop and the CPU is > now executing the OS. How does the Forth process return to running > the interpreter rather than the user code? In the simplest case, the signal handler can simply jump to ABORT, which clears the stacks, resets whatever is necessary, and retuens to the text interpreter. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2014-07-26 22:50 -0400 |
| Message-ID | <lr1pda$8pv$1@dont-email.me> |
| In reply to | #32686 |
On 7/26/2014 5:41 AM, Andrew Haley wrote: > rickman <gnuarm@gmail.com> wrote: >> >> Not really. I understand the difference between the two. In the >> one case the code in the loop has specific instructions to allow the >> loop to exit when something external sets a flag. In the case of >> the real time interrupt control is passed to the system we >> determines that the process needs to be "handled". What I want to >> know is how the process conveys control back to the Forth outer >> interpreter. The Forth process is stuck in a loop and the CPU is >> now executing the OS. How does the Forth process return to running >> the interpreter rather than the user code? > > In the simplest case, the signal handler can simply jump to ABORT, > which clears the stacks, resets whatever is necessary, and retuens to > the text interpreter. The "signal handler"... can you explain what you mean by this? The Forth program is in a loop. How does the "signal handler" get invoked? -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-07-27 02:49 -0500 |
| Message-ID | <bdSdnY0o8LxgM0nOnZ2dnUVZ_vGdnZ2d@supernews.com> |
| In reply to | #32705 |
rickman <gnuarm@gmail.com> wrote: > On 7/26/2014 5:41 AM, Andrew Haley wrote: >> rickman <gnuarm@gmail.com> wrote: >>> >>> Not really. I understand the difference between the two. In the >>> one case the code in the loop has specific instructions to allow the >>> loop to exit when something external sets a flag. In the case of >>> the real time interrupt control is passed to the system we >>> determines that the process needs to be "handled". What I want to >>> know is how the process conveys control back to the Forth outer >>> interpreter. The Forth process is stuck in a loop and the CPU is >>> now executing the OS. How does the Forth process return to running >>> the interpreter rather than the user code? >> >> In the simplest case, the signal handler can simply jump to ABORT, >> which clears the stacks, resets whatever is necessary, and retuens to >> the text interpreter. > > The "signal handler"... can you explain what you mean by this? The > Forth program is in a loop. How does the "signal handler" get invoked? Say we're running hosted on an OS like UNIX. (Other OSs are similar, but differ in details.) When Forth starts it registers a handler for an INT signal (SIGINT). When a user hits ctrl-C, the kernel looks for a SIGINT handler, finds one, and calls the handler that Forth registered. http://en.wikipedia.org/wiki/Signal_handler Andrew.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2014-07-27 15:08 -0400 |
| Message-ID | <lr3ino$4pl$1@dont-email.me> |
| In reply to | #32708 |
On 7/27/2014 3:49 AM, Andrew Haley wrote: > rickman <gnuarm@gmail.com> wrote: >> On 7/26/2014 5:41 AM, Andrew Haley wrote: >>> rickman <gnuarm@gmail.com> wrote: >>>> >>>> Not really. I understand the difference between the two. In the >>>> one case the code in the loop has specific instructions to allow the >>>> loop to exit when something external sets a flag. In the case of >>>> the real time interrupt control is passed to the system we >>>> determines that the process needs to be "handled". What I want to >>>> know is how the process conveys control back to the Forth outer >>>> interpreter. The Forth process is stuck in a loop and the CPU is >>>> now executing the OS. How does the Forth process return to running >>>> the interpreter rather than the user code? >>> >>> In the simplest case, the signal handler can simply jump to ABORT, >>> which clears the stacks, resets whatever is necessary, and retuens to >>> the text interpreter. >> >> The "signal handler"... can you explain what you mean by this? The >> Forth program is in a loop. How does the "signal handler" get invoked? > > Say we're running hosted on an OS like UNIX. (Other OSs are similar, > but differ in details.) When Forth starts it registers a handler for > an INT signal (SIGINT). When a user hits ctrl-C, the kernel looks for > a SIGINT handler, finds one, and calls the handler that Forth > registered. > > http://en.wikipedia.org/wiki/Signal_handler Thanks, I think I am back on solid ground. The signal is the software equivalent of a hardware interrupt. Rather than restore full context of the process, the Cntl-C signal handler is called and in this case would end up executing an abort. I guess I was getting all the details mixed up in my mind about the differences of a software signal and a hardware interrupt. Restoring a process to it's state at the time of the interrupt is straight forward. Invoking the signal handler would be rather complex in this case as the code can't assume anything about the operating context. The stack pointer may be corrupted and even I/O may have been munged. Interesting problem to deal with. I hope I don't have to do it ever. lol -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-07-27 14:11 -0500 |
| Message-ID | <C-udnchTevpm00jOnZ2dnUVZ_i2dnZ2d@supernews.com> |
| In reply to | #32718 |
rickman <gnuarm@gmail.com> wrote: > On 7/27/2014 3:49 AM, Andrew Haley wrote: >> >> Say we're running hosted on an OS like UNIX. (Other OSs are similar, >> but differ in details.) When Forth starts it registers a handler for >> an INT signal (SIGINT). When a user hits ctrl-C, the kernel looks for >> a SIGINT handler, finds one, and calls the handler that Forth >> registered. >> >> http://en.wikipedia.org/wiki/Signal_handler > > Thanks, I think I am back on solid ground. The signal is the software > equivalent of a hardware interrupt. Rather than restore full context of > the process, the Cntl-C signal handler is called and in this case would > end up executing an abort. > > I guess I was getting all the details mixed up in my mind about the > differences of a software signal and a hardware interrupt. > Restoring a process to it's state at the time of the interrupt is > straight forward. > Invoking the signal handler would be rather complex in this case as > the code can't assume anything about the operating context. The > stack pointer may be corrupted and even I/O may have been munged. > Interesting problem to deal with. I hope I don't have to do it > ever. lol Exactly, yes, hence my suggestion that it's better to poll for interruptions at known sage points. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-07-28 12:00 +0000 |
| Message-ID | <2014Jul28.140048@mips.complang.tuwien.ac.at> |
| In reply to | #32718 |
rickman <gnuarm@gmail.com> writes:
> Invoking the signal handler would be rather complex in this case as
>the code can't assume anything about the operating context. The stack
>pointer may be corrupted
There is no reason why any stack pointer would be corrupted when a
Ctrl-C is pressed. But we did have a problem on the PowerPC, where an
EXECUTE of a non-xt then executed some code that did corrupt the C
stack pointer before producing a SIGILL (illegal instruction) signal;
by default the signal handler uses the C stack, and of course that did
not work with a corrupted stack pointer. Fortunately, you can change
the signal handler's C stack with sigaltstack, so we did that, and now
even a corrupted C stack pointer is no problem for signal handling in
Gforth. The Forth stack pointers are set by the signal handler anyway
(there is no efficient and portable way to access the current value of
the Forth stack pointers from the signal handler).
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2014: http://www.euroforth.org/ef14/
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2014-07-28 10:41 -0400 |
| Message-ID | <lr5nfr$fd5$1@dont-email.me> |
| In reply to | #32729 |
On 7/28/2014 8:00 AM, Anton Ertl wrote: > rickman <gnuarm@gmail.com> writes: >> Invoking the signal handler would be rather complex in this case as >> the code can't assume anything about the operating context. The stack >> pointer may be corrupted > > There is no reason why any stack pointer would be corrupted when a > Ctrl-C is pressed. But we did have a problem on the PowerPC, where an > EXECUTE of a non-xt then executed some code that did corrupt the C > stack pointer before producing a SIGILL (illegal instruction) signal; > by default the signal handler uses the C stack, and of course that did > not work with a corrupted stack pointer. Fortunately, you can change > the signal handler's C stack with sigaltstack, so we did that, and now > even a corrupted C stack pointer is no problem for signal handling in > Gforth. The Forth stack pointers are set by the signal handler anyway > (there is no efficient and portable way to access the current value of > the Forth stack pointers from the signal handler). I'm not suggesting that using Cntl-C would cause a corruption. I am saying the user would *use* the Cntl-C to get control back from a user program which may have corrupted any manner of context. I don't understand your last statement. Isn't the signal handler running in the same context as the user code? Why would it not have access to the Forth stack pointers? -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2014-07-27 14:31 +0200 |
| Message-ID | <lr2red$5vb$1@online.de> |
| In reply to | #32705 |
rickman wrote: > The "signal handler"... can you explain what you mean by this? The > Forth program is in a loop. How does the "signal handler" get invoked? By the operating system. A signal is sort of an interrupt to a user program, the operating system stops whatever it is doing, and invokes the signal handler (with all registers saved on the stack). -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-07-27 13:08 +0000 |
| Message-ID | <2014Jul27.150857@mips.complang.tuwien.ac.at> |
| In reply to | #32665 |
rickman <gnuarm@gmail.com> writes:
>What I want to know is how the process conveys
>control back to the Forth outer interpreter. The Forth process is stuck
>in a loop and the CPU is now executing the OS. How does the Forth
>process return to running the interpreter rather than the user code?
In Gforth, it works like this: the signal handler performs a longjmp()
to a place that IIRC is in the C function that calls the actual engine
function. This C function then pushes the throw code on the stack,
and sets the IP to the start of THROW, and then invokes the engine,
which dutyfully performs a THROW.
This is all done with a separate data and return stack area, and the
THROW then sets the stack pointers from the ones stored when the
surrounding CATCH was called. Unless the application has its own
CATCH, the surrounding CATCH is from the system; after this CATCH has
caught the THROW, it produces an error message and restarts the text
interpreter.
In any case, the interrupted definition never regains control.
Does that answer your question?
As a twist, the debugging engine (gforth, not gforth-fast) saves IP
and RP frequently in a global variable; this allows the C part to push
IP (which points to the interrupted word at this time) on the return
stack before invoking THROW; and THROW then produces a full backtrace,
instead of a backtrace that only starts with (essentially) the next
surrounding CATCH.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2014: http://www.euroforth.org/ef14/
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2014-07-27 19:37 +0000 |
| Message-ID | <53d554e7$0$4630$e4fe514c@dreader36.news.xs4all.nl> |
| In reply to | #32713 |
In article <2014Jul27.150857@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>rickman <gnuarm@gmail.com> writes:
>>What I want to know is how the process conveys
>>control back to the Forth outer interpreter. The Forth process is stuck
>>in a loop and the CPU is now executing the OS. How does the Forth
>>process return to running the interpreter rather than the user code?
>
>In Gforth, it works like this: the signal handler performs a longjmp()
>to a place that IIRC is in the C function that calls the actual engine
>function. This C function then pushes the throw code on the stack,
>and sets the IP to the start of THROW, and then invokes the engine,
>which dutyfully performs a THROW.
Using direct system calls it is even simpler:
suppose we have a constant SIGTERM that defines the number of the ^C
interrupt, and WARM is the address in Forth where we jump to.
It is a jump, so there is no stack involved.
This WARM is assembler code, so it can save and inspect all it wants,
e.g. it can find out that the stack pointer was corrupted.
Let __NR_signal be the number of the system call that sets signals.
Let _ push a don't care to the stack.
Then
SIGTERM WARM _ __NR_signal XOS
will take care that on ^C Forth jumps to WARM.
A reasonable action is to do COLD minus initializing the user variables.
>- anton
--
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 | 2014-07-27 16:35 -0400 |
| Message-ID | <lr3nrk$bcb$1@dont-email.me> |
| In reply to | #32713 |
On 7/27/2014 9:08 AM, Anton Ertl wrote: > rickman <gnuarm@gmail.com> writes: >> What I want to know is how the process conveys >> control back to the Forth outer interpreter. The Forth process is stuck >> in a loop and the CPU is now executing the OS. How does the Forth >> process return to running the interpreter rather than the user code? > > In Gforth, it works like this: the signal handler performs a longjmp() > to a place that IIRC is in the C function that calls the actual engine > function. This C function then pushes the throw code on the stack, > and sets the IP to the start of THROW, and then invokes the engine, > which dutyfully performs a THROW. I don't know what you mean by the "engine function". Is that the inner interpreter or do you mean the THROW function? I guess I think in terms of STC but you are talking DTC or ITC? > This is all done with a separate data and return stack area, and the > THROW then sets the stack pointers from the ones stored when the > surrounding CATCH was called. Unless the application has its own > CATCH, the surrounding CATCH is from the system; after this CATCH has > caught the THROW, it produces an error message and restarts the text > interpreter. So the signal handler has to set it's own stack pointer on entry to a dedicated memory space, no? > In any case, the interrupted definition never regains control. > > Does that answer your question? Almost. What was actually confusing me is that I don't think I've ever learned the details of how control passes from the OS running in kernel mode (or whatever it is called) to the application running in protected mode. I kept getting mixed up thinking control could only pass to the application at the point it left off. I expect that the OS simply restores all context of the application except for setting the address of the signal handler for the program counter. BTW, is there a preferred name for the program counter vs. instruction pointer? I use them interchangeably. I am referring to the CPU's IP, not the Forth IP. > As a twist, the debugging engine (gforth, not gforth-fast) saves IP > and RP frequently in a global variable; this allows the C part to push > IP (which points to the interrupted word at this time) on the return > stack before invoking THROW; and THROW then produces a full backtrace, > instead of a backtrace that only starts with (essentially) the next > surrounding CATCH. -- Rick
[toc] | [prev] | [next] | [standalone]
Page 3 of 5 — ← Prev page 1 2 [3] 4 5 Next page →
Back to top | Article view | comp.lang.forth
csiph-web