Tracking FP-exceptions without handling them?
I''d like to keep track of how many overflows, underflows and divide-by-zeros that occurred since the last time I cleared the global counter (actually just if occurred), if you understand what I mean?!
signal() doesn''t seem to do it, since if I mask all convenient interupts on ( _controlfp() ) then, as far as I can tell, I have to do a setjmp() and longjump(), but I don''t want to handle the exception just noticing them. And the FPU may very well handle them as usual (actually that is preferred).
Anyone willing to help?
No no. _matherr() won''t do it, it is only called when the standard math-functions: sqrt(), pow(), exp() etc. are generating exceptions. _matherr() ignores the actual FPU-exceptions.
I am interested in noticing division-by-zero and over/underflow during "normal" execution (you know like: fadd, fdiv).
In old DOS one could make a chain of ISR:s as far as I remember. It would be nice to install one FPU-handler (with signal()?) of my own, and calling the old one to mark the results as NaN or something.
But of course: speed is also important; and that is why I shy away from such things as fpiee_except() or whatever it is called, as I think it''s unneccessarily detailed (thus slow) in its error-report structure.
Come on! someone''s got to have the answer to this!
I am interested in noticing division-by-zero and over/underflow during "normal" execution (you know like: fadd, fdiv).
In old DOS one could make a chain of ISR:s as far as I remember. It would be nice to install one FPU-handler (with signal()?) of my own, and calling the old one to mark the results as NaN or something.
But of course: speed is also important; and that is why I shy away from such things as fpiee_except() or whatever it is called, as I think it''s unneccessarily detailed (thus slow) in its error-report structure.
Come on! someone''s got to have the answer to this!
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
Recommended Tutorials
Advertisement