interrupting for overflow and loop termination
|
From: glen herrmannsfeldt on 10 Sep 2005 01:08 andrewspencers(a)yahoo.com wrote: > glen herrmannsfeldt wrote: (snip) >>A special loop exiting >>instruction or condition would then trigger the previously >>specified exit. > Well a special condition, yes: for example, when register X is zero. > But a special instruction inside the loop? That's called "comparison > followed by conditional branch", which is exactly what we're trying to > avoid! That isn't what I was saying, but it is a fine difference. The address is specified before the loop, you can call it an interrupt address or a future branch address. Inside the loop, does it matter if it is one instruction or two? If it is a comparison followed by a conditional interrupt as two instructions? How about a compare and conditional branch as one instruction? Or a compare and conditional interrupt as one instruction. > My argument is essentially this: > Interrupt-triggered events are better than polling-triggered events, > assuming that the cost of setting up the interrupt is less than the > total cost of all the polling repetitions. > Compare-and-branch inside a loop is a poll of the loop-exiting > condition. > Thus for a high-repetition loop, an interrupt-triggered exit is better > than a compare-and-branch exit. Branches predicted as not taken that aren't taken have a fairly low cost already. It might be a relative branch with an 8 bit offset, so the cost is 8 bits of instruction. It might be that the compare and relative branch could be in one instruction. When branch prediction logic works right conditional branches are pretty cheap. That is why so much work goes into them. -- glen
From: Anton Ertl on 10 Sep 2005 02:24 andrewspencers(a)yahoo.com writes: >Are there any CPU architectures which tie the overflow flag to an >interrupt, so that programs don't have to put a flag test and >conditional branch after each arithmetic operation in order to avoid >modular arithmetic? MIPS and Alpha On MIPS, add traps on overflow, addu does modulo arithmetic. A student of mine once used add by mistake, resulting in a SIGFPE under Ultrix or Irix. On Alpha, add does modulo arithmetic, addv traps on overflow. - anton -- M. Anton Ertl Some things have to be seen to be believed anton(a)mips.complang.tuwien.ac.at Most things have to be believed to be seen http://www.complang.tuwien.ac.at/anton/home.html
From: andrewspencers on 10 Sep 2005 02:54 glen herrmannsfeldt wrote: > > But a special instruction inside the loop? That's called "comparison > > followed by conditional branch", which is exactly what we're trying to > > avoid! > > That isn't what I was saying, but it is a fine difference. > The address is specified before the loop, you can call it an > interrupt address or a future branch address. > > Inside the loop, does it matter if it is one instruction or two? I mean _zero_ test/branch/soft interrupt/etc instructions inside the loop. > If it is a comparison followed by a conditional interrupt as > two instructions? How about a compare and conditional branch > as one instruction? Or a compare and conditional interrupt > as one instruction. No, not a soft interrupt; I'm talking about a hard interrupt, triggered by the output of some hardware-implemented logic function of a register's bits. Thus, the program sets an interrupt to trigger when the register reaches some predefined value, and then enters an infinite loop, and the interrupt will break the infinite loop.
From: glen herrmannsfeldt on 10 Sep 2005 05:41 andrewspencers(a)yahoo.com wrote: > glen herrmannsfeldt wrote: >>>But a special instruction inside the loop? That's called "comparison >>>followed by conditional branch", which is exactly what we're trying to >>>avoid! >>That isn't what I was saying, but it is a fine difference. >>The address is specified before the loop, you can call it an >>interrupt address or a future branch address. >>Inside the loop, does it matter if it is one instruction or two? > I mean _zero_ test/branch/soft interrupt/etc instructions inside the > loop. I thought we were discussion comparison or search operations, in which case it should be doing some comparing in the loop. (snip) > No, not a soft interrupt; I'm talking about a hard interrupt, triggered > by the output of some hardware-implemented logic function of a > register's bits. > Thus, the program sets an interrupt to trigger when the register > reaches some predefined value, and then enters an infinite loop, and > the interrupt will break the infinite loop. That is fine, though I find the distinction between hard and soft not so obvious. I was considering doing something inside the loop which might exit the loop early, such as the completion of a search operation. In any case, the exit address is stored somewhere before entering the loop, and the loop is exited at the appropriate time to that address. Does it matter if the exit address is in a general register instead of a special location for interrupts? Though I am still finding the distinction hard to make. Say compare to the S/360 BCTR instruction, decrement a register and branch to the address in another register if the value isn't zero. Your loop still needs a counter, and it still needs a branch at the end. How much difference can there be between a conditional branch based on the register value and an unconditional branch with an interrupt based on that register value? BCTR is 16 bits long, so instruction fetch time isn't very limiting. Note that there is a fair amount of overhead needed to perform a precise interrupt as you will require. With an imprecise interrupt the processor could execute a few more loop cycles before the interrupt was actually taken, which isn't good for searching. The things people used to do to make fast processors, but don't anymore. -- glen
From: Nick Maclaren on 10 Sep 2005 05:41
In article <1126308566.021605.110950(a)z14g2000cwz.googlegroups.com>, <andrewspencers(a)yahoo.com> wrote: >Nick Maclaren wrote: >>> Are there any CPU architectures which tie the overflow flag to an >>> interrupt, so that programs don't have to put a flag test and >>> conditional branch after each arithmetic operation in order to avoid >>> modular arithmetic? >> Many, even today, > >Which ones? z/OS (System/390). I can't remember which of the RISC ones can still do it, and would have to read the architectures to remind myself. I think that x86 can. >>> And similarly, are there any architectures which tie the output of a >>> logic function (hardwired or programmable) of the bits of a register or >>> combination of registers to an interrupt, in order to provide >>> interrupt-based loop termination and interrupt-based pattern matching? >> after decades of the ghastly approach to eliminating >> overflow errors by eliminating overflow detection. But, switch it on, >> and you will find an awfully high proportion of compiled code, run-time >> systems and libraries fall over horribly. > >I'm a bit confused here; if the overflow flag can be tied to an >interrupt, and a program isn't explictly written to use that feature, >then turning the feature on and then running the program will cause the >program to fall over horribly if it experiences an overflow, >_regardless_ of whether the program was just ignoring the overflow flag >(which is the wrong thing to do if there's a possibility of overflow) >or actually checking the overflow flag and taking an appropriate course >of action. I'm talking not about using the interrupt-on-overflow >feature as an error checking mechanism, but as an optimization. Nope. The point is that sloppy programmers often use signed arithmetic when they should be using unsigned. On a twos complement machine, ignoring overflow on signed arithmetic is almost equivalent to using unsigned arithmetic, so they get away with it. Until someone switches on overflow trapping .... Regards, Nick Maclaren. |