🚀 go-pugleaf

In article <448@cpocd2.UUCP> howard@cpocd2.UUCP (Howard A. Landman) writes:
>In article <4376@columbia.UUCP> eppstein@tom.columbia.edu (David Eppstein) writes:
>>[David implies that an interrupt requires a complete context switch
>>of writing all active windows to memory and reloading them after
>>handling the interrupt]
>
>[Howard points out that for an interrupt, the operating system code
>that handles the interrupt can promise not to trash active windows,
>and continue to use the existing stack.  He also points out that
>context switches between user processes occur relatively infrequently
>and thus the overhead of writing out all active windows and reading in
>new windows on a context switch is not important.]

I agree with this, so I'm going to change the subject slightly.  Lately
I've been thinking about operating systems which would perform a complete
context switch on every interrupt.  In particular, code for handling
interrupts would run in a restricted environment (ie user mode) where 
their ability to accidentally trash other interrupt handlers, the operating 
system, and device drivers would be minimized.

My biggest problem with this concept is that context switching, even
on a machine with "only" 16 registers is extremely expensive.
I'd be interested in hearing about architechtures that minimize the
expense of a context switch.
 
(The expected advantage of the OS I'm toying with is that it would
make it much easier to write and debug programs (subroutines?) that
are normally part of a Unix kernel.  I've been writing some device
drivers lately, and I'm getting frustrated with the cycle of fixing
a bug, compiling the code, linking it with the kernel, rebooting the
system, testing the code and finding another bug, rebooting the system
to fix the new bug...
 
(If device drivers ran in user land, my cycle would be reduced to:
fixing a bug, compiling the code, testing the code and finding a bug...)
 
-- Chuck