🚀 go-pugleaf

In <tonyn-0109950144230001@tonyn.tiac.net>, tonyn@tiac.net (Tony Nelson) writes:
>I see some discussion here about "negligable preemtion / interrupt overhead".

>On any CPU, interrupt processing requires a context switch (also required
>for preemption and system services).  

Not necessarily. When you're thinking in CISC-isms, sure. You need to
save a return address, registers, maybe this happens
automatically. That may or may not be much real overhead, it's
certainly not a full context switch (eg, a task swicth) unless the OS
so defines it. But it's at least on the order of a subroutine. 

When you get to RISC processors, things aren't quite so clear. For
example, on the MIPS series, a fast interrupt simply runs two
instructions, then returns to where it was before the
interrupts. Those instructions could cause a trap, call a subroutine,
or just set a flag. It's left to the OS to decide just how much of a
context switch this is, if any. 

>Nowadays the penalty for an interrupt is much greater, because of
>processor caches (or rather, fast processors but memory at the same speed
>as before).  The context switch now requires flushing the cache, so the
>processor will run slowly for a while as instructions are fetched from
>"real memory".  

If the caches are physically addressed, as practically all of them are
these days, there's no need for any cache flushing when you service an
interrupt routine. These routines are in unswappable memory, so
there's never the question of any physical aliasing (which would
mandate a flush of at last the affected page). Certainly there's a
fair chance the interrupt routines won't be in the cache(s), and loading
them will throw something out, but that's a trivial bit of overhead.

>Deterministic real-time processing is difficult to do with
>interrupts. 

This is true, in the right context. That's why DSP OSs typically use a
macroquantum based form of cooperative multitasking to schedule hard
realtime tasks -- each task has a very small amount of work to do
within the macroquantum. It's called by the OS, does its work,
returns, and the next task is called.

This, of course, has absolutely nothing to do with microquantum
cooperative task scheduling, as seen on Windows or the Mac. Those
systems are completely indeterminant; the microquantum only determines
if a task will be swapped, should it call a swapper function. There's
no telling when an arbitrary program will call a swapper function. 
There's also a tremendous bit of task overhead, based on support of
legacy code that couldn't be swapped, from the single-tasking days.
Sure, that's going away with new code, but so is the cooperative
model. 


>Coupled with the overhead of context switching, this makes
>interrupt-driven programming impractical for device controllers (such
>as, say, a car or a wheelchair).  

There's no point. Such devices have a fixed amount of work to do, and
their design guarantees they can do it. In a PC, it's quite possible
to have considerably more work to do than processor time
available. Without interrupts and prioritized, preemptive tasks,
everything slows down. With them, deterministic processing can be done
first. Another factor is multiprocessing; in a typical PC, you don't
have a single processor, you have a central processor and several I/O
processors (SCSI, Graphics, etc.). Without a pre-emptable system,
there's no way to schedule task B while task A is waiting for a disk
load to complete. You wind up burning useful CPU time polling ready
registers. 

Dave Haynie          | ex-Commodore Engineering |   for DiskSalv 3 &
Sr. Systems Engineer |  Hardwired Media Company | "The Deathbed Vigil"
Scala Inc., US R&D   |    Ki No Kawa Aikido     |     info@iam.com

	     "I don't owe you anything!" -Foo Fighters