interrupting for overflow and loop termination
|
From: andrewspencers on 12 Sep 2005 05:02 chl wrote: > <andrewspencers(a)yahoo.com> wrote in message news:1126320161.417289.140570(a)z14g2000cwz.googlegroups.com... > > > Thus for a high-repetition loop, an interrupt-triggered exit is better > > than a compare-and-branch exit. > > In your scenario, what is going to happen when an "interrupt exited" loop > wants to call another "interrupt exited" loop? Isn't this the same as "what happens when a loop using register x wants to call another loop which uses x (in an incompatible way)?"?
From: andrewspencers on 12 Sep 2005 05:11 Terje Mathisen wrote: > I have written code like that, and it is indeed possible to get into > situations where you have a _lot_ of exit tests. However, since these > are all different, a "silent/parallel/interrupt-based" version of it > wouldn't work at all, unless you could setup every single one of these > tests in a list of stuff to be monitored. [snip] > If you had Nick's perfect world where user processes could register to > handle hw exceptions, then your ideas could make a little more sense, > but still only when you have a lot of different code locations that can > share the same logic. > > I.e. stack overflow fixups is a good example, loop processing isn't. In that case, wouldn't bignum code, with a lot of arithmetic overflow tests, be a good example?
From: chl on 12 Sep 2005 05:30 <andrewspencers(a)yahoo.com> wrote in message news:1126515756.562845.69250(a)o13g2000cwo.googlegroups.com... > >> In your scenario, what is going to happen when an "interrupt exited" loop >> wants to call another "interrupt exited" loop? > Isn't this the same as "what happens when a loop using register x wants > to call another loop which uses x (in an incompatible way)?"? Yes, and this eventually means the caller or the callee have to save the current interrupt vector. You still believe this is efficient?
From: Terje Mathisen on 12 Sep 2005 05:50 andrewspencers(a)yahoo.com wrote: > Terje Mathisen wrote: >>If you had Nick's perfect world where user processes could register to >>handle hw exceptions, then your ideas could make a little more sense, >>but still only when you have a lot of different code locations that can >>share the same logic. >> >>I.e. stack overflow fixups is a good example, loop processing isn't. > > In that case, wouldn't bignum code, with a lot of arithmetic overflow > tests, be a good example? > I have also written 3-5 different extended/bignum/arbitrary precision packages, none of them have ever needed any (costly) overflow testing. In a bignum array, arithmetic overflow (i.e. adding two arrays together) only happens at the very end, and this is easily detected and handled at that location (i.e. by extending the (active part of the) result array by one node/word. All the internal operations you use to write such code should be of the unsigned kind, since that makes everything so much easier. :-) On architectures without an explicit carry flag it could seem that carry propagation could be quite costly, but in reality it isn't too bad: You simply do an unsigned compare between the result word and one of the input words, if the result is less then you had a wraparound which means that you need to increment the next word. Doing this efficiently can be somewhat tricky, if you need to do a _lot_ of bignum operations, adding numbers into a fixed accumulator, then you could consider moving to a carry-save representation, but normally you don't need this. I really can't see any way implicit interrupt handling would help with _any_ of this code though! Terje -- - <Terje.Mathisen(a)hda.hydro.com> "almost all programming can be viewed as an exercise in caching"
From: =?ISO-8859-1?Q?Niels_J=F8rgen_Kruse?= on 12 Sep 2005 08:28
Terje Mathisen <terje.mathisen(a)hda.hydro.com> wrote: > andrewspencers(a)yahoo.com wrote: > > > Terje Mathisen wrote: > >>If you had Nick's perfect world where user processes could register to > >>handle hw exceptions, then your ideas could make a little more sense, > >>but still only when you have a lot of different code locations that can > >>share the same logic. > >> > >>I.e. stack overflow fixups is a good example, loop processing isn't. > > > > In that case, wouldn't bignum code, with a lot of arithmetic overflow > > tests, be a good example? > > > I have also written 3-5 different extended/bignum/arbitrary precision > packages, none of them have ever needed any (costly) overflow testing. > > In a bignum array, arithmetic overflow (i.e. adding two arrays together) > only happens at the very end, and this is easily detected and handled at > that location (i.e. by extending the (active part of the) result array > by one node/word. > > All the internal operations you use to write such code should be of the > unsigned kind, since that makes everything so much easier. :-) > > On architectures without an explicit carry flag it could seem that carry > propagation could be quite costly, but in reality it isn't too bad: > > You simply do an unsigned compare between the result word and one of the > input words, if the result is less then you had a wraparound which means > that you need to increment the next word. > > Doing this efficiently can be somewhat tricky, if you need to do a _lot_ > of bignum operations, adding numbers into a fixed accumulator, then you > could consider moving to a carry-save representation, but normally you > don't need this. > > I really can't see any way implicit interrupt handling would help with > _any_ of this code though! I think there is a mismatch here between people talking about serious bignum arithmetic and on the other hand interpreted languages where bignum arithmetic is used for ordinary arithmetic, so that the programmer doesn't have to worry about ranges. -- Mvh./Regards, Niels Jýrgen Kruse, Vanlýse, Denmark |