Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!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: <3793@goanna.cs.rmit.oz.au> Date: 20 Sep 90 04:04:21 GMT References: <12738@encore.Encore.COM> <1990Sep18.152339.25203@tera.com> Organization: Comp Sci, RMIT, Melbourne, Australia Lines: 56 In article <1990Sep18.152339.25203@tera.com>, bob@tera.com (Bob Alverson) writes: > In article <3783@goanna.cs.rmit.oz.au> ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes: > For a "RISC", having operations which both compute (or load) and > conditionally branch is not a large problem. I have to confess that I'm playing devil's advocate here. I too am a True Believer in the Revealed Instruction Set Creed. But I don't recall either Rubin or me talking about "RISC"s in this context. > However, you must expect > to have at least one and probably several branch delay slots after the > instruction. The particular case we were considering was "fetch from a buffer and trap on underflow". For many of today's machines, we've already to worry about memory fetch delay, which would typically swamp the delay due to the comparison. Let's look at what's involved in a RISCish version: FETCH curptr, limit, dest -- now it is safe to use "dest" As far as delay slot filling is concerned, this is exactly like [ Bcc | LOAD (curptr), dest ] {that is, both kinds of instruction combined in one}. Either the instructions in the delay slots can safely be executed anyway, or else you have to be able to annul them. But that's true of any conditional branch. How complex is this condition? Well, the 88k does "if R1 = R2 then goto L" as one conditional branch, and that's all we need here. So > If the condition you are checking is more complicated > than the conditions the regular jumps test, in _this_ specific case the condition would _not_ be more complicated. > 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? What "extended" delay slots? One or two slots, depending on how the machine handles other _simple_ conditional branches. If I have a conditional branch BEQ R1, R2, L my code at label L doesn't have to worry about exceptions in the delay slot instructions following BEQ. It's the handler for _those_ exceptions which has to worry. So if an exception could happen in the one or two instructions following a FETCH instruction, it's the handler (this one's in the OS kernel) for _those_ exceptions which has to know that FETCH is like a conditional branch, but it already has to know about conditional branches. -- Heuer's Law: Any feature is a bug unless it can be turned off.