[Python-Dev] Strategy for converting the decimal module to C (original) (raw)

James Y Knight foom at fuhm.net
Fri Jul 21 17:05:51 CEST 2006

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

More information about the Python-Dev mailing list