[Python-Dev] Strategy for converting the decimal module to C

[James Y Knight]

On Jul 21, 2006, at 6:18 AM, Nick Maclaren wrote:
> To cut a long story short, it is impractical for a language run-time
> system to call user-defined handlers with any degree of reliability
> unless the compiled code and run-time interoperate carefully - I have
> been there and done that many times, but few people still working  
> have.
> On architectures with out-of-order execution (and interrupts), you
> have to assume that an interrupt may occur anywhere, even when the
> code does not use the relevant facility.  Floating-point overflow
> in the middle of a list insertion?  That's to be expected.

While this _is_ a real problem, is it _not_ a general problem as you  
are describing it. Processors are perfectly capable of generating  
precise interrupts, and the inability to do so has nothing to do with  
the out-of-order execution, etc. Almost all interrupts are precise.  
The only interesting one which is not, on x86 processors, is the x87  
floating point exception, which is basically for historical reasons.  
It has never been precise, ever since the actual 8087 coprocessor  
chip for the 8086. However, all is not lost: the exception cannot  
occur randomly. It can only occur on *some* floating point  
instruction, even if the instruction is not the one the error  
actually occurred in. So, unless your list insertion code uses  
floating point instructions, you should not get a floating point  
exception during your list insertion.

Also, looking forward, the "simd" floating point instructions (ie mmx/ 
sse/sse2/sse3) _do_ generate precise interrupts. And on x86-64, x87  
instructions are deprecated and everyone is recommended to use the  
simd ones, instead (so, for example, gcc defaults to using them).

James