Path: utzoo!attcan!uunet!samsung!crackers!m2c!umvlsi!dime!dime.cs.umass.edu!moss From: moss@cs.umass.edu (Eliot Moss) Newsgroups: comp.arch Subject: Interrupts in user space Message-ID: Date: 17 Sep 90 12:44:23 GMT References: <2516@l.cc.purdue.edu> <6838.26e7f109@vax1.tcd.ie> <2123@key.COM> <3747@goanna.cs.rmit.oz.au> <2128@key.COM> Sender: news@dime.cs.umass.edu Reply-To: moss@cs.umass.edu Organization: Dept of Comp and Info Sci, Univ of Mass (Amherst) Lines: 32 In-reply-to: sjc@key.COM's message of 17 Sep 90 04:12:20 GMT In article <2128@key.COM> sjc@key.COM (Steve Correll) writes: Well, Prof. Rubin _did_ ask for an "interrupt", and most Unix kernels insist on being involved in any interrupts. And Unix is not unique in this. My reaction is that there is no reason why an interrupt of this kind need go through the OS kernel. I feel that there are many synchronous interrupts that should be deliverable directly to the user program (or language run-time system) without kernel intervention. Examples include overflow, divide by zero, range/bounds errors, and even certain kinds of memory access faults (i.e., ones where the user program is going to take and handle the exception). It is reasonable for the machine to do a forced call through a vector location in user space. If the user really does not want to handle the error, putting a bad address in the vector would force a trap into the kernel. While we're on the subject, a user-implemented flavor of system call is nice, too. I'm thinking of something akin to the PDP-10 UUO (unimplemented user operation) instruction. A short instruction that calls through a vector. This is essneitally a call to a global subroutine, but exactly which subroutine it is can be changed dynamically (by changing the vector), and the instruction fits into substantially fewer bits. (Not entirely clear what the interaction is with RISC here.) Cheers! -- J. Eliot B. Moss, Assistant Professor Department of Computer and Information Science Lederle Graduate Research Center University of Massachusetts Amherst, MA 01003 (413) 545-4206; Moss@cs.umass.edu