Has someone tried to add interrupt support to Riscy Pygness?

On 05/23/2011 12:20 AM, Elizabeth D Rather wrote:
> On 5/21/11 11:46 PM, Arlet Ottens wrote:
>> On 05/22/2011 10:15 AM, Elizabeth D Rather wrote:
>>
>>>>
>>>>> To a limited extent you can get away with pushing something
>>>>> temporarily
>>>>> on whatever is the current data stack, provided you get it off again
>>>>> before exiting the ISR. But that's a far cry from executing high level
>>>>> Forth.
>>>>
>>>> Why for a limited extent ? And of course you have to pop everything
>>>> from
>>>> the stack that you put on.
>>>
>>> My point is that all of what you describe adds unnecessary overhead. If
>>> you follow the model I described above, you only need a few instructions
>>> in your ISR (typically 3-5 for a simple "read a value and put it
>>> somewhere"), and it would cost more than that just to get into a
>>> high-level Forth routine. Much easier to just do the bare minimum at
>>> interrupt time and let the task responsible for the interrupting device
>>> do the high level processing.
>>
>> If you defer the work to a task, you have the extra overhead of context
>> switches, which are generally more expensive than saving state in the
>> ISR. If you can do all the work in the ISR, or at least do all the work
>> in the majority of cases, this actually costs less overall.
>
> In my experience, there's usually some component of the response that's
> time-critical and some that isn't. In the case of a clock tick, that
> event has to be registered immediately, but there isn't any further
> processing to occur. In the case of receipt of an interrupt that signals
> the completion of a process that some task has been waiting for (e.g. a
> disk read) notifying the task is all that has to be done, and *all* the
> subsequent activity is at the task level. My objective is to handle the
> time-critical steps, whatever they are, *without delay*, which means
> without scheduling a task or instantiating a context for high-level
> Forth (and I agree with Stephen that trying to do that for an ITC Forth
> makes no sense at all). There is no overhead involved in entering an ISR
> in our systems.

Sure, but there are also different problems. For example, a stepper 
motor hooked up to a bit-bang SPI bus that needs to be advanced 2000 
times per second. You don't want too much jitter, so doing it in the 
timer ISR itself becomes a viable option.

It would be nice to have the option so you could choose to run the ISR 
in assembly, or a higher level language, depending on the particular 
circumstances. In my experience, I've written 90% of my ISR code in a 
higher level language.

>
> In a multitasking Forth, context switches are occurring, but (at least
> in the implementations I'm familiar with) they are vastly less costly
> than in more conventional multi-tasked executives: typically on the
> order of half-dozen machine instructions to activate a task and fewer to
> de-activate one.

If it only takes a half-dozen instruction to do a context switch, I'm 
sure it doesn't have to take more to set up an environment to run Forth 
in an interrupt context.

>
> Cheers,
> Elizabeth
>

On May 22, 3:25=A0pm, wzab <wza...@gmail.com> wrote:
> Therefore approach with blocking of interrupts in ISR and passing
> control to the high level Forth word (which may be defined by user in
> interactive session) seemed very good.

I don't see any problem with having the inner interpreter poll for
interrupts, as long as you carefully review words that alter stack
pointers such as THROW and PAUSE. You may need to disable interrupts
in parts of such words. I remember a story of someone who modified the
inner interpreter on an early single-interrupt computer to emulate a
multi-interrupt machine and it was a great success.

-Brad

On May 22, 3:08=A0pm, John Passaniti <john.passan...@gmail.com> wrote:
> On May 22, 7:25=A0am, Albert van der Horst <alb...@spenarnc.xs4all.nl>
> wrote:
>
> > Isn't this overly pessimistic?
>
> The thing about this discussion that bothers me is talking about
> interrupts in the abstract.

We're in trouble then because thoughts are abstractions so talking in
the abstract cannot be overcome ;-).

[SNIP]

Jean-Francois Michaud