Path: utzoo!attcan!uunet!zephyr.ens.tek.com!uw-beaver!tera.com!bob From: bob@tera.com (Bob Alverson) Newsgroups: comp.arch Subject: Re: Interrupts in user space Message-ID: <1990Sep18.152339.25203@tera.com> Date: 18 Sep 90 15:23:39 GMT References: <12738@encore.Encore.COM> <3783@goanna.cs.rmit.oz.au> Sender: news@tera.com Reply-To: bob@colossus.tera.com.UUCP (Bob Alverson) Organization: Tera Computer Company Lines: 27 In article <3783@goanna.cs.rmit.oz.au> ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes: >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. For a "RISC", having operations which both compute (or load) and conditionally branch is not a large problem. However, you must expect to have at least one and probably several branch delay slots after the instruction. If the condition you are checking is more complicated than the conditions the regular jumps test, then this complex op will probably need more branch delay slots than a normal jump. If exceptions can occur while you are in these extended delay slots, then the trap handler must know about them and handle yet another bizarre case properly. Is it worth it? If you insist on no branch delay slots, then the instruction will take longer to execute than the simple instructions it replaces, since it cannot draw from the surrounding instructions to keep the pipeline full (whereas the compiler can schedule the pipeline with separate instructions). Bob (bob@tera.com)