interrupting for overflow and loop termination
|
From: David Hopwood on 11 Sep 2005 19:33 David Hopwood wrote: > andrewspencers(a)yahoo.com wrote: > >> [...] when you wrote in your prior message: >> >>> OTOH, ints _can_ be a win in other situations, specifically when they >>> are used to guard against/handle really exceptional situations, where >>> the extra overhead of a taken interrupts can be amortized over many runs >>> when nothing happens. >> >> Which such situations did you have in mind? > > I didn't write that; Terje Mathisen did. But to answer the question, some examples of where this approach can be effective are using unmapped guard pages to detect stack overflows, exhaustion of an allocation space, or null pointer accesses in languages that require null pointer checks. Note that these are cases in which the relevant operation (allocating a stack frame or object, indirecting through a pointer) is extremely common, and the interrupt-based optimization is in "infrastructure" code so that a single implementation can apply to many programs. Even then it may not pay off: hacks like this should be reevaluated every so often to see whether they are really giving a performance improvement that justifies their complexity. -- David Hopwood <david.nospam.hopwood(a)blueyonder.co.uk>
From: andrewspencers on 12 Sep 2005 00:01 David Hopwood wrote: > I didn't write that; Terje Mathisen did. Sorry about that! I would put on my dunce cap, but I seem to have lost it...
From: glen herrmannsfeldt on 12 Sep 2005 00:12 Nick Maclaren wrote: (snip) > 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 .... I remember when I was learning PDP-10 assembler, and considering translating a S/360 multiple precision arithmetic package, asking someone how to do unsigned arithmetic. This was the first machine I knew of with the negative, zero, overflow, carry, flags. S/360 uses the condition codes, with four possible values aren't enough, so both signed and unsigned (logical) add and subtract are used. Also, add logical won't generate an overflow interrupt. -- glen
From: glen herrmannsfeldt on 12 Sep 2005 00:15 Terje Mathisen wrote: (snip) > It is _not_ better: > a) If the loop count is high, the loop branch will always be correctly > predicted, except for the loop exit, right? > b) If the loop count is stored in a fixed register, like ECX for an x86 > LOOP instruction, or otherwise designated, then the number of branch > misses should be zero instead of one. I wonder if any change the prediction based on ECX? It would be nice to know maybe one loop cycle in advance, depending on prefetch buffer size and loop size. -- glen
From: glen herrmannsfeldt on 12 Sep 2005 00:17
andrewspencers(a)yahoo.com wrote: (snip) > Yes, but I wasn't arguing against using a loop count register or > against updating it inside the loop; I was arguing against including > instructions inside the loop which conditionally branch based on the > value in the register. I wanted the processor to watch the register and > trigger an interrupt when it reached some target value, the same way > that the processor watches e.g. the program counter and triggers an > interrupt when it matches the value in a breakpoint register, with zero > impact on program execution speed until the interrupt is triggered. Why would it have zero impact? Note that S/370 PER, which has breakpoints triggered by an instruction within a range of addresses, clearly states that there may be a performance penalty. The logic is still there, instruction or not, and still takes time. -- glen |