> That's not nearly the same thing as a PSW overflow bit.
> To use that you'd have to catch SIGFPE, decode the instruction to
> figure out where the operands are, calculate the overflow bits,
> figure out what to do with them such that the mainline will find
> it, and find some place to resume execution.
> All in all, a grand mess all to save 14 cycles. Thus to even be
> considered an option you would want to show that the multiply is
> in the center of the processing loop and that operands that would
> overflow are exceedingly rare.
It's even worse: the integer overflow traps are imprecise (like the fp
traps), so, in general, you cannot reliably determine the source of
the exception _unless_ the code has been compiled especially. The
current gcc has support to do so, but I don't think trap support for
integer ops has been done (the gcc backend never generates trapping
integer ops; I suppose the Ada backend might change that, in which
case it might make sense to support this fully).
--david
-- To unsubscribe: send e-mail to axp-list-request@redhat.com with 'unsubscribe' as the subject. Do not send it to axp-list@redhat.com
Copyright © 1995-1997 Red Hat Software. Legal notices