Assembly language exception handling
I''m just going through the intel software development books at the moment and they''re not giving me a very definite idea of whether to handle exceptions or not. I can think of some cases where handling numeric floating point exceptions might be useful in a computer game but I''d just like to know if windows cares or not about doing so.
Yes exceptions should always be handled or resolved if they are due to a bug.
Peace out,
Mathematix.
Peace out,
Mathematix.
I meant the floating point exceptions specifically which are masked by default anyway. I''m quite happy with that, but if there is the option of writing my own exception handler for say a floating point divide by zero, I would like to take advantage of it if it will shave off a few cycles. I was just wondering if that''s okay to do in the win32 environment. Does every task have its own vector table for exceptions? And is it a good idea to mess around with them? I''ve read in a few places that user exception handling is wrapped up in functions provided by MSVC, and I was wondering if that was right? Cheers for the help.
Christ programming is too complicated, why the hell don''t I just become a porn star or something?
Christ programming is too complicated, why the hell don''t I just become a porn star or something?
Are these exceptions a regular occurance, if so, review your code. When I have to handle ther possibility of a ''divide by zero'' error I am careful to write specific code to handle them. It isn''t a matter of whether the compiler or operating system handles them for you, the system will simply tell you that such an exception has been raised and leaves it to you to handle it appropriately.
Peace out,
Mathematix.
Peace out,
Mathematix.
No Mathematix, the exceptions philscott is speaking of are different.
Most language specifications dictate that such ''unusual'' floating point conditions are an error and generate a software exception (what you are thinking of Mathematix). The IEEE floating-point format has special values to handle these cases, and the intel FPU implements the behavior correctly for S/Q NaN & +/- Inf (I believe SNaN is always a code error btw).
I don''t recall if floating-point division by zero mutates into +/- Inf or QNaN. If it''s QNaN then you need to do something about it, but I think it results in Inf, which is acceptable in many cases. Division by Inf produces 0 as desired - Inf/Inf produces QNaN as does 0/0.
Under-flow also produces an FPU expcetion, if you care if/when a value drops into a denormalized form. IIRC, this is ''bump'' transfer followed by another ''bump'' transfer when the denormal under-flows to zero.
If you write your algorithms to work properly under Inf & NaN conditions, then the system will be far more stable than relying on the values staying in the representable real number range.
Also, FPU exceptions are detected asyncronously unless you issue fwait to wait for the FPU to complete (poor pipelining, but may be desired in some cases).
Windows doesn''t care, but the code that the compiler generates may.
Most language specifications dictate that such ''unusual'' floating point conditions are an error and generate a software exception (what you are thinking of Mathematix). The IEEE floating-point format has special values to handle these cases, and the intel FPU implements the behavior correctly for S/Q NaN & +/- Inf (I believe SNaN is always a code error btw).
I don''t recall if floating-point division by zero mutates into +/- Inf or QNaN. If it''s QNaN then you need to do something about it, but I think it results in Inf, which is acceptable in many cases. Division by Inf produces 0 as desired - Inf/Inf produces QNaN as does 0/0.
Under-flow also produces an FPU expcetion, if you care if/when a value drops into a denormalized form. IIRC, this is ''bump'' transfer followed by another ''bump'' transfer when the denormal under-flows to zero.
If you write your algorithms to work properly under Inf & NaN conditions, then the system will be far more stable than relying on the values staying in the representable real number range.
Also, FPU exceptions are detected asyncronously unless you issue fwait to wait for the FPU to complete (poor pipelining, but may be desired in some cases).
Windows doesn''t care, but the code that the compiler generates may.
Yeah, divide by zeros produce +/- inf when the exception is masked and sNans always produce errors if the invalid operation exception is unmasked, which as I said is going to be fine for most cases. I just wanted to know about these exceptions in case a situation arises when I want to do my own handling of numeric fp exceptions without just checking the exception flags.
When I unmask the divide by zero exception and perform a divide by zero I get a message box saying "Divide by zero" which I assume is windows' exception handler for a divide by zero. I was wondering if it's safe and in some cases sensible to override this and write your own exception handler. I was messing around in C++ using __try and __except, putting assembly statements into the __try block to unmask bit 2 of the fpu control word and then performing a divide by zero operation but I could never get any of the statements in the following __except block to execute even when I set the condition to 1. I don't really know what I'm doing and I'm not finding much assistance in the MSVC help.
Cheers.
[edited by - philscott on November 7, 2002 6:51:08 AM]
[edited by - philscott on November 7, 2002 7:24:32 AM]
When I unmask the divide by zero exception and perform a divide by zero I get a message box saying "Divide by zero" which I assume is windows' exception handler for a divide by zero. I was wondering if it's safe and in some cases sensible to override this and write your own exception handler. I was messing around in C++ using __try and __except, putting assembly statements into the __try block to unmask bit 2 of the fpu control word and then performing a divide by zero operation but I could never get any of the statements in the following __except block to execute even when I set the condition to 1. I don't really know what I'm doing and I'm not finding much assistance in the MSVC help.
Cheers.
[edited by - philscott on November 7, 2002 6:51:08 AM]
[edited by - philscott on November 7, 2002 7:24:32 AM]
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement