Greg Ewing <[EMAIL PROTECTED]> wrote: > > > 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. > > I thought we were just talking about counting the number > of floating point exceptions that a particular piece of > code generates. Surely that's deterministic, and isn't
Er, no. Rather fundamentally, on two grounds. Please bear with me, as this IS relevant to Python. See the summary at the end if you like :-) The first is that such things are NOT deterministic, not even on simple CPUs - take a look at the Alpha architecture for an example, and then follow it up with the IA64 one if you have the stomach for it. But that wasn't my main point. It is that modern CPUs have a SINGLE interrupt mechanism (a mistake in itself, but they do), so a CPU may be interrupted when it is running a device driver, other kernel thread or within a system call as much as when running an application. In fact, to some extent, interrupt handlers can themselves be interrupted (let's skip the details). Now, in order to allow the application to run its handler, the state has to be saved, sanitised and converted back to application context; and conversely on return. That is hairy, and is why it is not possible to handle interrupts generated within system calls on many systems. But that is not directly Python's problem. What is, is that the code gets interrupted at an unpredictable place, and the registers and other state may not be consistent as the language run-time system and Python are concerned. It is critical (a) that a sane state is restored before calling the handler and (b) that calling the handler neither relies on nor disturbs any of the "in flight" actions in the interrupted code. 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. It becomes considerably easier if the (run-time system) interrupt handler merely needs to flag or count interrupts, as it can use a minimal handler which is defensive and non-intrusive. Even that is a pretty fair nightmare, as many systems temporarily corrupt critical registers when they think that it is safe. And few think of interrupts when deciding that .... So, in summary, please DON'T produce a design that relies on trapping floating-point exceptions and passing control to a Python function. This is several times harder than implementing fpectl. Regards, Nick Maclaren, University of Cambridge Computing Service, New Museums Site, Pembroke Street, Cambridge CB2 3QH, England. Email: [EMAIL PROTECTED] Tel.: +44 1223 334761 Fax: +44 1223 334679 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
