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

Nick Maclaren nmm1 at cus.cam.ac.uk
Tue Jul 25 11:06:08 CEST 2006

Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:

But we weren't talking about asynchronous exceptions, we were talking about floating point exceptions. Unless your TLB miss handler uses floating point arithmethic, there's no way it can get interrupted by one. (And if it does use floating point arithmetic in a way that can cause an exception, you'd better write it to deal with that!)

I am really not getting my message across, am I?

Yes, that is true - as far as it goes. The trouble is that designing systems based on assuming that IS true as far as it goes means that they don't work when it goes further. And it does. Here are a FEW of the many examples of where the simplistic model is likely to fail in an x86 context:

The compiled code has made a data structure temporarily inconsistent because the operation is safe (say, list insertion), and then gets an asynchronous interrupt (e.g. SIGINT). The SIGINT handler does some operation (e.g. I/O) that implicitly uses floating-point, which then interrupts.

The x86 architecture is extended to include out-of-order floating-point as it had in the past, many systems have today, and is very likely to happen in the future. It is one of the standard ways to get better performance, after all, and is on the increase.

The x86 architecture is extended to support micro-threading. I have not been told by Intel or AMD that either have such plans, but I have very good reason to believe that both have such projects. IBM and Sun certainly do, though I don't know if IBM's is/are relevant.

Regards, Nick Maclaren, University of Cambridge Computing Service, New Museums Site, Pembroke Street, Cambridge CB2 3QH, England. Email: nmm1 at cam.ac.uk Tel.: +44 1223 334761 Fax: +44 1223 334679

More information about the Python-Dev mailing list