Bob La Quey wrote:
The interrupt response takes many clock cycles.
Andy can perhaps shed some light on the modern state
of affairs.
Heh. You give me far too much credit.
However, last I checked, interrupt latency was generally a bigger
function of the system and OS than the processor.
Also, interrupts on a normal x86 system pass through a bunch of chips
before actually hitting the processor in order to handle "legacy"
issues. Those are normally quite slow, as well.
If you lock the interrupt handler into cache, reserve a couple of
registers for interrupt-only use, etc. the whole thing becomes very
deterministic (and fast). How does vxWorks handle being a real-time OS
on x86?
The big problem x86 had was the fact that it was register starved.
Consequently, when an interrupt hit, the first thing you had to do was
open up a couple of registers by flushing to memory. That's not a good
thing for fast interrupt servicing. You still see this with the
"-fomit-frame-pointer" option to gcc for x86. That extra register is
worth completely clobbering your ability to do stack walking when
something goes wrong.
In addition, don't confuse RISC with deep pipelining; the two are
orthogonal. In fact, the early RISC systems with shallow pipelining
were much better than the corresponding CISC systems (with unpredictable
latency instructions - anyone remember polynomial evaluate on VAX?) as
they literally could stop on a dime (generally within 5 very fast
clocks) since every instruction ran in exactly the same short number of
clocks (that obviously changed later).
To top things off, even deeply pipelined systems (like the Alpha 21264)
can often be run in a "precise interrupts/traps" mode in which the
system can and will stop on a dime when an interrupt hits (all
instructions in flight after the interrupt are immediately flushed).
However, that normally has a pretty major impact on *overall* system
performance. Normally, letting your current thread run until it hits a
memory access (which will stall it out anyway) is a better choice than
servicing the interrupt immediately.
-a
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
