>> 1) An exception 10H is a math coprocessor fault. I believe 
>> you could get a fault on storing a value if the math 
>> coprocessor control flags were set to cause an exception 
>> on a variety of errors, instead of the mode to just fix
>> things up and continue.
>
>Do you know how this is done?!

The "_control87" C run-time function sets/gets the FP control register
using #defined mask bits. The docs claim the default is all exceptions
disabled. I have a fuzzy memory of this not actually being the case under
some version of something though.

For a store, a variety of exceptions are listed in the Intel processor
manual (which is available as PDF from Intel's site).

>> Setting the coprocessor flags get's especially sticky if 
>> you call a DLL, and the DLL may have some different 
>> assumption about the coprocessor mode flags than the 
>> program (or a different DLL).
>
>This shouldn't happen since the DLL called is a '100% Squeak DLL' ;-) and
>it's compiled under *exactly* the same settings as the VM.

In theory yes, unfortunatly there may be a LOT of DLL's loaded into your
process automagically. One of those DLL may have a control path that
changes the FP mode and returns without setting it back, like when some
error happens. The behaivor is YOUR FP code blows up 15 minutes later
because the FP exception is no longer masked. Serious FP code will often
turn exception handling back on, otherwise you have to check for NaN's in
every result value, even in cases where everything ran just fine.

>I've read about this but do you know how to find out if MMX mode is
>currently active?!

The FP tag word has a 2-bit field for each FP/MMX register. I believe the
MSVC debugger will show the FP tag register if you open the register
window. A value of FFFF means the FP registers are empty, 0000 means all
full, and MAY indicate a missing EMMS instruction after MMX code (a MMX
instruction set's the tag register to 0000).

Trapping in the debugger at the failure will be required first.

>> You can probably make the MSVC debugger trap the exception, 
>> you just have to add an exception code 10H to the list of 
>> known exceptions and tell it to always trap it. Actually, 
>> exceptions can have just about ANY number as software can 
>> call RaiseException with any value. 
>
>Interesting - I've just checked RaiseException and you're right. I always
>assumed that SEH is used for hardware exceptions only...

I often use custom exception values to pass serious errors up the call
stack in C. A cleanup routine at an outer level can look at the code and
decide how to clean things up, and what to tell the caller. This makes the
code much more robust, but also makes it pretty platform dependent.

You have to open the exception setting window in the debugger and add your
custom values and description.

- Jan