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 4 of 5 — ← Prev page 1 2 3 [4] 5 Next page →
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2014-07-27 22:24 +0000 |
| Message-ID | <zPWdna71V_CW4UjOnZ2dnUVZ_umdnZ2d@supernews.com> |
| In reply to | #32721 |
On 7/27/14 8:35 PM, rickman wrote: > 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. > Really, it does function analogously to a hardware interrupt, which is why they're often called "software interrupts". The program can set up an address for the event to branch to, and perform whatever recovery functions it thinks are appropriate. Exactly what process info is saved and/or restored depends on the OS, but the actual response is basically up to the code that will be called when the event occurs. 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 | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2014-07-28 13:14 +0000 |
| Message-ID | <53d64c99$0$15835$e4fe514c@dreader35.news.xs4all.nl> |
| In reply to | #32722 |
In article <zPWdna71V_CW4UjOnZ2dnUVZ_umdnZ2d@supernews.com>, Elizabeth D. Rather <erather@forth.com> wrote: >On 7/27/14 8:35 PM, rickman wrote: >> 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. >> > >Really, it does function analogously to a hardware interrupt, which is >why they're often called "software interrupts". The program can set up >an address for the event to branch to, and perform whatever recovery >functions it thinks are appropriate. Exactly what process info is saved >and/or restored depends on the OS, but the actual response is basically >up to the code that will be called when the event occurs. The OS can look at a process from the outside. So it can see what its instruction pointer is etc. It can inspect everything. Moreover it can tweak this state, by e.g. setting the stack pointer to a safe area and changing the instruction pointer. When the process continues, it uses the imposed state. > >Cheers, >Elizabeth > 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 | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-07-28 03:41 -0500 |
| Message-ID | <seudnTL5pr5SkUvOnZ2dnUVZ_omdnZ2d@supernews.com> |
| In reply to | #32721 |
rickman <gnuarm@gmail.com> wrote: > On 7/27/2014 9:08 AM, Anton Ertl wrote: > >> 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? sigaltstack(2) is provided for just this purpose on Linux systems: it runs a signal handler on a dedicated stack. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-07-28 12:09 +0000 |
| Message-ID | <2014Jul28.140927@mips.complang.tuwien.ac.at> |
| In reply to | #32721 |
rickman <gnuarm@gmail.com> writes:
>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
Yes, plus more: The engine() function contains all the primitives of
the Forth system. When you invoke it with a given IP, it starts
executing the Forth code at this IP and continues executing Forth code
until it happens upon (BYE) or until a signal handler is invoked.
>> 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?
For the data and return stacks, it uses dedicated memory space,
because it does not know where the data and return stack pointers of
the engine point to, anyway. Later, THROW sets these stack pointers
to the values they had when the innermost CATCH was called.
For the C stack, in most cases it is sufficient to use the existing C
stack in the signal handler, but, as explained in another posting, we
have had cases where the C stack pointer was corrupted before the
exception, and to cater for such cases we also use a separate stack
area for the C stack.
>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.
Yes, something like that.
> 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.
Following fig-Forth, I call the Forth interpreter's thing IP.
Following 6502 usage, I call the CPU's thing PC.
Unfortunately, Intel chooses to call the PC IP.
- 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:48 -0400 |
| Message-ID | <lr5ns2$igh$1@dont-email.me> |
| In reply to | #32731 |
On 7/28/2014 8:09 AM, Anton Ertl wrote: > rickman <gnuarm@gmail.com> writes: >> 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 > > Yes, plus more: The engine() function contains all the primitives of > the Forth system. When you invoke it with a given IP, it starts > executing the Forth code at this IP and continues executing Forth code > until it happens upon (BYE) or until a signal handler is invoked. > >>> 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? > > For the data and return stacks, it uses dedicated memory space, > because it does not know where the data and return stack pointers of > the engine point to, anyway. Later, THROW sets these stack pointers > to the values they had when the innermost CATCH was called. Why would the signal handler not know this? It should be running in the same context. The data and return stacks are just register values which should be the same as in the user code, no? If not, what values do the registers have, arbitrary? > For the C stack, in most cases it is sufficient to use the existing C > stack in the signal handler, but, as explained in another posting, we > have had cases where the C stack pointer was corrupted before the > exception, and to cater for such cases we also use a separate stack > area for the C stack. > >> 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. > > Yes, something like that. > >> 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. > > Following fig-Forth, I call the Forth interpreter's thing IP. > Following 6502 usage, I call the CPU's thing PC. > > Unfortunately, Intel chooses to call the PC IP. I think I am on track enough to understand what is happening. Thanks. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-07-28 15:29 +0000 |
| Message-ID | <2014Jul28.172934@mips.complang.tuwien.ac.at> |
| In reply to | #32741 |
rickman <gnuarm@gmail.com> writes:
>On 7/28/2014 8:09 AM, Anton Ertl wrote:
>> For the data and return stacks, it uses dedicated memory space,
>> because it does not know where the data and return stack pointers of
>> the engine point to, anyway. Later, THROW sets these stack pointers
>> to the values they had when the innermost CATCH was called.
>
>Why would the signal handler not know this? It should be running in the
>same context. The data and return stacks are just register values which
>should be the same as in the user code, no? If not, what values do the
>registers have, arbitrary?
The data and return stack pointers are local variables of the engine()
function; they may reside in registers or in the C stack while
engine() is running. When a signal handler is called, the register
values of the interrupted code are stored in a structure (that is
passed as parameter to the signal handler function). Unfortunately,
there is no portable way to know where these local variables are
stored. So while in principle the signal handler has access to this
information, in practice it doesn't (at least not for the amount of
nonportability we are prepared to deal with).
Fortunately, we don't need that, because THROW resets the stack
pointers to the values at the innermost CATCH anyway. (Actually, the
stack pointers would be nice for debugging, and our debugging engine
keeps the return stack pointer in a global variable, which can be
accessed from any C function, at a cost in performance).
If you do an implementation in assembly language (or a native-code
compiler), things are different: You know exactly where the stack
pointers reside, and you are probably prepared to find out where the
OS stores the particular registers you are interested in.
- 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 14:30 -0400 |
| Message-ID | <lr64rn$uan$1@dont-email.me> |
| In reply to | #32745 |
On 7/28/2014 11:29 AM, Anton Ertl wrote: > rickman <gnuarm@gmail.com> writes: >> On 7/28/2014 8:09 AM, Anton Ertl wrote: >>> For the data and return stacks, it uses dedicated memory space, >>> because it does not know where the data and return stack pointers of >>> the engine point to, anyway. Later, THROW sets these stack pointers >>> to the values they had when the innermost CATCH was called. >> >> Why would the signal handler not know this? It should be running in the >> same context. The data and return stacks are just register values which >> should be the same as in the user code, no? If not, what values do the >> registers have, arbitrary? > > The data and return stack pointers are local variables of the engine() > function; they may reside in registers or in the C stack while > engine() is running. When a signal handler is called, the register > values of the interrupted code are stored in a structure (that is > passed as parameter to the signal handler function). Unfortunately, > there is no portable way to know where these local variables are > stored. So while in principle the signal handler has access to this > information, in practice it doesn't (at least not for the amount of > nonportability we are prepared to deal with). Ok, that makes some sense except what portability issues? Are you saying the way the signal handler access this info depends on the OS this is running under? What are you porting to? > Fortunately, we don't need that, because THROW resets the stack > pointers to the values at the innermost CATCH anyway. (Actually, the > stack pointers would be nice for debugging, and our debugging engine > keeps the return stack pointer in a global variable, which can be > accessed from any C function, at a cost in performance). > > If you do an implementation in assembly language (or a native-code > compiler), things are different: You know exactly where the stack > pointers reside, and you are probably prepared to find out where the > OS stores the particular registers you are interested in. OS? What OS? In the stuff I am doing the OS *is* Forth, lol. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-07-29 08:12 +0000 |
| Message-ID | <2014Jul29.101233@mips.complang.tuwien.ac.at> |
| In reply to | #32750 |
rickman <gnuarm@gmail.com> writes:
>On 7/28/2014 11:29 AM, Anton Ertl wrote:
>> rickman <gnuarm@gmail.com> writes:
>>> On 7/28/2014 8:09 AM, Anton Ertl wrote:
>>>> For the data and return stacks, it uses dedicated memory space,
>>>> because it does not know where the data and return stack pointers of
>>>> the engine point to, anyway. Later, THROW sets these stack pointers
>>>> to the values they had when the innermost CATCH was called.
>>>
>>> Why would the signal handler not know this? It should be running in the
>>> same context. The data and return stacks are just register values which
>>> should be the same as in the user code, no? If not, what values do the
>>> registers have, arbitrary?
>>
>> The data and return stack pointers are local variables of the engine()
>> function; they may reside in registers or in the C stack while
>> engine() is running. When a signal handler is called, the register
>> values of the interrupted code are stored in a structure (that is
>> passed as parameter to the signal handler function). Unfortunately,
>> there is no portable way to know where these local variables are
>> stored. So while in principle the signal handler has access to this
>> information, in practice it doesn't (at least not for the amount of
>> nonportability we are prepared to deal with).
>
>Ok, that makes some sense except what portability issues? Are you
>saying the way the signal handler access this info depends on the OS
>this is running under? What are you porting to?
It depends on the CPU architecture which registers there are. Even on
the same architecture it depends on the gcc version in which register
(or where on the stack) the stack pointers reside. That's already
sufficiently discouraging that I have not investigated whether the OS
makes a difference.
We have tested Gforth-0.7.0 on 8 different architectures (and ports to
architectures that we do not test should also work, and have done so
in the past), with up to 9 compiler versions per platform (and
versions we have not tested on a platform should also work), and a
bunch of different OSs (Linux, HPUX, Solaris, MacOS X/Darwin,
Windows/Cygwin).
>> If you do an implementation in assembly language (or a native-code
>> compiler), things are different: You know exactly where the stack
>> pointers reside, and you are probably prepared to find out where the
>> OS stores the particular registers you are interested in.
>
>OS? What OS? In the stuff I am doing the OS *is* Forth, lol.
Then you don't need to worry about where the OS puts the registers
when calling a 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 | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2014-07-28 13:10 +0000 |
| Message-ID | <53d64bc9$0$15835$e4fe514c@dreader35.news.xs4all.nl> |
| In reply to | #32721 |
In article <lr3nrk$bcb$1@dont-email.me>, rickman <gnuarm@gmail.com> wrote:
>On 7/27/2014 9:08 AM, Anton Ertl wrote:
>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.
In subroutine threaded code there is no difference. In my threaded
code Forth's in a lowlevel context
I use
HIP (High level interpreter pointer)
SPO (parameter stack pointer)
RPO (return stack pointer).
So these are aliases for registers, e,g, in lina 32 this is ESI ESP and EBP.
The user base pointer has no register dedicated to it in my Forth's.
<SNIP>
>
>Rick
--
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 | bruce.mcfarling@gmail.com |
|---|---|
| Date | 2014-07-27 11:33 -0700 |
| Message-ID | <c4b85936-0d76-4128-8125-0ed96beb7881@googlegroups.com> |
| In reply to | #32665 |
On Friday, July 25, 2014 10:02:33 PM UTC-4, rickman wrote: > On 7/25/2014 7:20 PM, BruceMcF wrote: > > On Friday, July 25, 2014 7:01:22 PM UTC-4, rickman wrote: >>> 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. ... What I want to know is how the process conveys control back > to the Forth outer interpreter. Then you actually weren't interested in what was meant by "using an interrupt", since what was MEANT by "using an interrupt" involved relying on the system-provided facility ~ being able to CATCH a word that is interrupted by Ctrl-C under that system means not having to know how the system generates the THROW for the Ctrl-C. Fortunately one of the implementers of that system has explained how they do it for a Linux system. I presume the way that they do it for a Windows system is contained in a source file that is compiled for a gforth targetted at a Windows system.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-07-28 11:55 +0000 |
| Message-ID | <2014Jul28.135556@mips.complang.tuwien.ac.at> |
| In reply to | #32717 |
bruce.mcfarling@gmail.com writes:
>Fortunately one of the implementers of that system has explained how they d=
>o it for a Linux system. I presume the way that they do it for a Windows sy=
>stem is contained in a source file that is compiled for a gforth targetted =
>at a Windows system.
Gforth does it in the same way for Windows as for Unix. However, we
do use the Cygwin library that makes Windows look mostly like Unix to
programs. But I think that you can also set signal handlers in
Windows, and setjmp()/longjmp() certainly is a standard C feature
(although their usage in signal handlers may not be).
- 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 | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2014-07-28 14:03 +0100 |
| Message-ID | <lr5hnn$2gh$1@dont-email.me> |
| In reply to | #32728 |
on 28/07/2014 12:55:52, wrote: > bruce.mcfarling@gmail.com writes: >>Fortunately one of the implementers of that system has explained how they d= >>o it for a Linux system. I presume the way that they do it for a Windows sy= >>stem is contained in a source file that is compiled for a gforth targetted = >>at a Windows system. > > Gforth does it in the same way for Windows as for Unix. However, we > do use the Cygwin library that makes Windows look mostly like Unix to > programs. But I think that you can also set signal handlers in > Windows, and setjmp()/longjmp() certainly is a standard C feature > (although their usage in signal handlers may not be). Cygwin does a lot of work to simulate a SIGINT. For console apps (the ones that look like DOS boxes) see http://msdn.microsoft.com/en-us/library/windows/desktop/ms682066%28v=vs.85%29.aspx for a desciption. Simple it's not, since the spawned process that a CTRL-C generates is exactly that; a separate child process with separate everything, including stack, register contents and so on. Windows apps (those that aren't console apps) do not support interrupts at the user level; everything is managed through a polled FIFO queue of events. CTRL-C is normally recognised as a copy (that is, whatever copy means in that specific window). There's no straightforward way of having them process an interrupt asynchronously. > > - anton
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-07-27 13:02 +0000 |
| Message-ID | <2014Jul27.150208@mips.complang.tuwien.ac.at> |
| In reply to | #32663 |
rickman <gnuarm@gmail.com> writes:
>On 7/25/2014 5:37 PM, bruce.mcfarling@gmail.com wrote:
>> 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.
Yes, the signal thing is in the context of a Unix-like OS. A signal
is the Unix equivalent of an interrupt. Just like you set up an
interrupt handler in a native system, you can set up a signal handler
in Unix, and that handler then gets invoked when the process receives
the signal (e.g., by the user pressing Ctrl-C at the terminal).
In the simplest case the OS receives a hardware interrupt or hardware
exception and converts this into a signal that it then sends to a
user-level process.
- 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-26 08:57 +0000 |
| Message-ID | <53d36d8c$0$15851$e4fe514c@dreader35.news.xs4all.nl> |
| In reply to | #32655 |
In article <lqu3tk$n49$1@dont-email.me>, rickman <gnuarm@gmail.com> wrote: >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. Look at the code for SET-TRAPS in lina. I just follow the instructions set Forth in man kill which is a system call, so documented in chapter 2 of the fine Unix manuals. Or did you think that a clearly system-dependant facility could be solved as standard ISO Forth code? >-- > >Rick -- 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:05 -0400 |
| Message-ID | <lqvr0u$f2d$2@dont-email.me> |
| In reply to | #32676 |
On 7/26/2014 4:57 AM, Albert van der Horst wrote: > In article <lqu3tk$n49$1@dont-email.me>, rickman <gnuarm@gmail.com> wrote: >> 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. > > Look at the code for SET-TRAPS in lina. > I just follow the instructions set Forth in > man kill > which is a system call, so documented in chapter 2 of the fine Unix manuals. > > Or did you think that a clearly system-dependant facility could be solved > as standard ISO Forth code? I figured it was something that could be explained without it becoming a research project. "man kill" sounds like it ends the app. How does this get the Forth app back to the user prompt? -- Rick
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2014-07-26 09:20 +0000 |
| Message-ID | <53d372c5$0$15938$e4fe514c@dreader35.news.xs4all.nl> |
| In reply to | #32677 |
In article <lqvr0u$f2d$2@dont-email.me>, rickman <gnuarm@gmail.com> wrote: >On 7/26/2014 4:57 AM, Albert van der Horst wrote: >> In article <lqu3tk$n49$1@dont-email.me>, rickman <gnuarm@gmail.com> wrote: >>> 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. >> >> Look at the code for SET-TRAPS in lina. >> I just follow the instructions set Forth in >> man kill >> which is a system call, so documented in chapter 2 of the fine Unix manuals. >> >> Or did you think that a clearly system-dependant facility could be solved >> as standard ISO Forth code? > >I figured it was something that could be explained without it becoming a >research project. "man kill" sounds like it ends the app. How does >this get the Forth app back to the user prompt? Source code is available. Use 32 bits lina with lina -e. SEE COLD SEE WARM WANT SET-TRAPS SEE SET-TRAPS SEE SET-TRAPS-WARM All these thingies are one liners. The warm start address is -2 CELLS +ORIGIN . (Yes this is still freaking figForth, x CELLS +ORIGIN are the boot up parameters, i.e. initialisation for user variables.) Research project? I started with unix more than 30 years ago, so I may just be too much used to it. > >-- > >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 | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2014-07-23 23:48 +0100 |
| Message-ID | <lqpe4r$nnh$1@dont-email.me> |
| In reply to | #32584 |
on 23/07/2014 21:12:57, BruceMcF wrote: > On Tuesday, July 22, 2014 10:32:31 PM UTC-4, Jason Damisch wrote: >> On Tuesday, July 22, 2014 6:34:56 PM UTC-7, BruceMcF wrote: >> >> Everything you said makes sense, but I don't understand why it isn't possible for an interrupt to just grab the system and drop me back onto the Forth prompt. >> >> Jason > > Because if you do: > >: FRED BEGIN AGAIN ; FRED > > ... you never return to "the system", so there's no opportunity for > "the system" to do anything at all. > > Remember in a BASIC interpreter, the interpreter is executing each and > every key word separately, while the BEGIN AGAIN in FRED has likely > compiled to something like: FRED1: JUMP FRED1 > or > FRED1: .word BRANCH,FRED1 > > ... and unless there is a break of the processor flow of control, > there is nothing checking the keyboard. > > In Windows7 in Gforth, when I do: > : FRED BEGIN AGAIN ; FRED > > ... and hit "Ctrl-C", I get: > FRED > :2: User Interrupt > >>>FRED<<< > Backtrace > $7EBD43CC branch > > In Win32Forth, it just hangs until the window is killed from Windows. > That's because Windows works differently. Keystrokes (and mouse activities) are queued up until the application asks for them. Win32Forth doesn't ask for them since it's in a never ending loop. There's one exception for programs that use the console. They are applications that look like DOS commands. The queue is handled by a system process that will respond to ctrl-C. That starts another process that can normally do one of two things; either let the parent process continue, or abort the whole process chain. Win32Forth doesn't use a console. If you wish to emulate that beahviour and make it more DOS like, you could poll the queue with a Windows PeekMessage call.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2014-07-24 04:53 -0400 |
| Message-ID | <lqqhhp$hnt$1@dont-email.me> |
| In reply to | #32584 |
On 7/23/2014 4:12 PM, BruceMcF wrote: > On Tuesday, July 22, 2014 10:32:31 PM UTC-4, Jason Damisch wrote: >> On Tuesday, July 22, 2014 6:34:56 PM UTC-7, BruceMcF wrote: >> >> Everything you said makes sense, but I don't understand why it isn't possible for an interrupt to just grab the system and drop me back onto the Forth prompt. >> >> Jason > > Because if you do: > > : FRED BEGIN AGAIN ; FRED > > ... you never return to "the system", so there's no opportunity for "the system" to do anything at all. > > Remember in a BASIC interpreter, the interpreter is executing each and every key word separately, while the BEGIN AGAIN in FRED has likely compiled to something like: > FRED1: JUMP FRED1 > or > FRED1: .word BRANCH,FRED1 > > ... and unless there is a break of the processor flow of control, there is nothing checking the keyboard. > > In Windows7 in Gforth, when I do: > : FRED BEGIN AGAIN ; FRED > > ... and hit "Ctrl-C", I get: > FRED > :2: User Interrupt > >>>FRED<<< > Backtrace > $7EBD43CC branch > > In Win32Forth, it just hangs until the window is killed from Windows. Ok, so how does Gforth get control back to the main Forth program? Is the user program run as a separate process? -- Rick
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-07-24 10:59 +0000 |
| Message-ID | <2014Jul24.125945@mips.complang.tuwien.ac.at> |
| In reply to | #32610 |
rickman <gnuarm@gmail.com> writes:
>On 7/23/2014 4:12 PM, BruceMcF wrote:
>> In Windows7 in Gforth, when I do:
>> : FRED BEGIN AGAIN ; FRED
>>
>> ... and hit "Ctrl-C", I get:
>> FRED
>> :2: User Interrupt
>> >>>FRED<<<
>> Backtrace
>> $7EBD43CC branch
>>
>> In Win32Forth, it just hangs until the window is killed from Windows.
>
>Ok, so how does Gforth get control back to the main Forth program? Is
>the user program run as a separate process?
It seems that the Windows console works like an xterm and sends a
SIGINT to Gforth when the user presses Ctrl-C. The signal handler in
Gforth then translates this into a Forth THROW, and since the user
program does not CATCH the THROW in this case, Gforth's default
exception handler catches it, and prints a backtrace and performs
QUIT.
- 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 | mhx@iae.nl |
|---|---|
| Date | 2014-07-24 04:23 -0700 |
| Message-ID | <f45e835c-4bda-4ec5-a324-4ca024f62b71@googlegroups.com> |
| In reply to | #32614 |
On Thursday, July 24, 2014 12:59:45 PM UTC+2, Anton Ertl wrote: [..] > It seems that the Windows console works like an xterm and sends a > SIGINT to Gforth when the user presses Ctrl-C. The gForth I know on Windows uses the Cygwin console, which indeed works that way. As Cygwin is now finally available for 64bits, this worry is over now. I am thinking of porting the Linux iServer to cygwin64 and have a truly universal source base. The difference between MacOS en Linux is already quite small. -marcel
[toc] | [prev] | [next] | [standalone]
Page 4 of 5 — ← Prev page 1 2 3 [4] 5 Next page →
Back to top | Article view | comp.lang.forth
csiph-web