Robert Finch wrote:
Working on a simple OS I thought it might be useful to be able to poll
for interrupts when interrupts are disabled. I think there may be times
where it is acceptable to process certain kinds of interrupts even if
they were disable. So, I added a poll-for-interrupt instruction to the architecture. Which just checks for interrupts and continues if there is
not one. I have seen wait-for-interrupt instructions before, but not
sure about polling.
I also added a two-up-level return from interrupt instruction. I have
not seen this in other architectures, but I needed it at one point.
Interrupt information is stored on an internal stack, and it is tricky
(slow) to manipulate it for a two-up-level return. It is an eight level
stack with two or three words of information per level. It was a bit
much to copy it all in software, so I added the hardware return. But it
is a lot of extra hardware for a very rare occurrence.
Finding this discussion on interrupts informative. I have only done a
modicum of work on an OS; tried to get things working with spinlocks.
I'm not sure what your "polling for interrupts" would do.
That's what the cpu already does - in the background at the start of
each instruction the cpu polls for interrupts.
Most cpu's have a "wait for interrupt" or "halt" instruction which
stops fetching and sits waiting for an interrupt to be injected.
It is typically used when the OS has no work to do and
doesn't want to sit in a spin-loop burning calories.
So it goes into a lower power state waiting for a wakeup event.
There is an optimization that has been around a while where a driver
shuts off interrupts from a particular device and switches to polling
that one device, removing the interrupt setup and delivery overhead,
making that time available for doing work. But that is driver specific.
DEC had a paper on this for a TCP/IP driver.
Eliminating Receive Livelock in an Interrupt-driven Kernel, 1995
http://bitsavers.trailing-edge.com/pdf/dec/tech_reports/WRL-95-8.pdf
The idea is that polling is more expensive when request rate is low,
and interrupts are more expensive when request rate is high.
We can dynamically adapt to optimize between the two,
making that time available for making forward progress.
But this interrupt masking is at the device level and has
nothing to do with the cpu interrupt mechanism.
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)