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

Nick Maclaren nmm1 at cus.cam.ac.uk
Thu Jul 20 12:03:41 CEST 2006


Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
>
> But couldn't you just put in an interrupt handler that
> counts the interrupts, for the purpose of measurement?

No, but the reasons are very arcane.

The general reason is that taking an interrupt handler and returning
is not transparent, and is often not possible on modern systems.  If
that problem is at the hardware level (as on the Alpha and 3086/7),
you are stuffed.  But, more often, it is due the the fact that the
architecture means that such handling can only be done at maximally
privileged level.

Now, interrupting into that level has to be transparent, in order to
support TLB misses, clock interrupts, device interrupts, machine-check
interrupts and so on.  But the kernels rarely support transparent
callbacks from that state into user code (though they used to); it is
actually VERY hard to do, and even the mainframes had problems.  This
very commonly means that such counting breaks other facilities, unless
it is done IN the privileged code.

Of course, a GOOD hardware architecture wouldn't leave the process
state when it gets a floating-point interrupt, but would just invoke
an asynchronous routine call.  That used to be done.

As I said, none of this is directly relevant to emulated implementations,
such as the current Python ones, but it IS to the design of an arithmetic
specification.    It could become relevant if Python wants to start to use
a hardware implementation, because your proposal would mean that it would
have to try to ensure that such callbacks are transparent.

As one of the few people still working who has extensive experience
with doing that, I can assure you that it is an order of magnitude
fouler than you can imagine.  A decimal order of magnitude :-(

But note that I wasn't saying that such things should be put into the
API, merely that there is a very good reason to do so for hardware
implementations and ones used to tune code for such implementations.
Personally, I wouldn't bother.


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