Path: utzoo!attcan!uunet!munnari.oz.au!goanna!ok From: ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) Newsgroups: comp.arch Subject: Re: Interrupts in user space Message-ID: <3783@goanna.cs.rmit.oz.au> Date: 18 Sep 90 08:32:38 GMT References: <12738@encore.Encore.COM> Organization: Comp Sci, RMIT, Melbourne, Australia Lines: 40 In article <12738@encore.Encore.COM>, jkenton@pinocchio.encore.com (Jeff Kenton) writes: > From article , by moss@cs.umass.edu (Eliot Moss): > > My reaction is that there is no reason why an interrupt of this kind need go > > through the OS kernel. > With the recent RISC chips (88000, MIPS and i860 come to mind) the overhead > of getting the machine state safely saved away in the low level exception > code is substantial. But you are still thinking in terms of asynchronous interrupts. What we're talking about here is a "trap", and there isn't the slightest reason why a trap should have to save any more state than a procedure call. The trap is synchronous: it cannot happen at an _arbitrary_ point during the execution of an instruction, only when the architect chose to have it be detected. It relates specifically to the currently executing thread, not to some other I/O device. To make this absolutely specific and relate it to existing practice, suppose we wanted to provide something like the VAX mode where integer overflow generates a trap. So suppose we wanted to have an instruction ADDI src1, src2, dest ;; dest := src1 + src2 ;; on (signed) overflow, this sets dest to the result modulo ;; 2**32, and calls the procedure whose address is stored in ;; [0x400]. Why does *this* have to do more state-saving than the instruction sequence LOAD [0x400], rtemp CALL rtemp If you use the same machinery for this as you do for "power failure" and "device ready", yes it's reasonable to expect a detour through the OS. But why _should_ you implement _this_ kind of trap that way? -- Heuer's Law: Any feature is a bug unless it can be turned off.