| |
In lugnet.robotics.rcx.pbforth, Richard Lucock writes:
> But it does seem to depend on the return stack having a particular structure
Hi,
the nice thing in this solution is that it doesn't inspect or touch the user
return stack at all. The structures that are used to get to the FIP
(instruction pointer) - namely: the position of the saved D-stack in the
*private* R-stack and the top three words on the saved (user) D-stack - are
explicitly set up in the forth interrupt handler, so they could only be
different in another pbForth-version.
There actually is one possibility where it may not work: if the interrupt is
called just before pbForth writes a new value to the instruction pointer (like
in MOV.W @rRSP+,rFIP in {EXIT}) the modified instruction pointer gets
overwritten to what it "should be" again; however as long as the run key is
pressed down the ISR code keeps setting the FIP to the AborterWord, so it'll
just work a couple of milliseconds later.
Btw, here is a little improvement to the original code:
In the AborterWord, set a flag (like "InAborterWord") and clear it just before
the COLD statement. In AborterISR only do something if that flag is clear.
This prevents the AborterWord itself getting continuosly interrupted as long as
run is pressed...
But as Ralph hinted, there may be a much easier solution at all.
Greetings,
Alex
|
|
Message is in Reply To:
 | | Re: Aborting from ISR
|
| Hi, (...) Yup, that does what I want, although I can't remember enough about forth internals to work out why it works. But it does seem to depend on the return stack having a particular structure, so I do wonder - what happens if the interrupt (...) (22 years ago, 20-Jul-02, to lugnet.robotics.rcx.pbforth)
|
10 Messages in This Thread:
 
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
