[comp.sys.acorn] Re History of interrupt latency

RWilson@acorn.co.uk (01/18/91)

... and a subtle point that Roger didn't make explicit, for those
other-CPU fans who said "use a SYNC instruction with interrupts
off; the NMI restarts the CPU in 0 cycles" - this is not
feasible.  The point is that, although the foreground process
sits in a tight loop* on Beebs, Atoms, Archimedes (not ARM UNIX
boxes - real scheduling**) IRQ tasks such as clock increments,
sound, event timers, serial line, flashing colours and the like
carry on, interrupting the foreground tight loop, and then being
interrupted themselves by the floppy/econet data transfer FIQ.
Thus you can't stop the CPU for the duration of a data transfer,
it has to be available for IRQ processing, and making
restrictions about the type of instruction you can use (short) in
IRQs is completely infeasible - an awful lot goes on in a
Beeb/Archie IRQ.

Hope this helps, OK Roger?

	- Huge


*well it sits in a tight loop during floppy reads and writes, but
econet receives are obviously asynchronous, so the foreground
could be anywhere, and depending on version/implementation,
econet transmits are launch-and-leave, then ask later whether it
worked, so again the foreground could be anywhere.

**the Unix boxes put the foreground process to sleep in the
kernel in traditional fashion, so again anything can happen
meanwhile - obviously including applications whose instruction
set usage cannot be curtailed.  When the FIQ processing has
finished, it causes an IRQ using the 'always 1' bit in the IRQ
source register, which the kernel can understand means 'wake up
the sleeping guy who started a FIQ task'.

	fin.

   ---------------------  Hugo Tyson  -------------------------
Harlequin Limited, Barrington Hall, Barrington, Cambridge, CB2 5RG
England;    Tel.  (UK) 0223 872522  (International) +44 223 872522
   ------------------------------------------------------------

(posted by RWilson - but not edited by him!)