Python OS

Diez B. Roggisch deetsNOSPAM at
Mon Nov 8 13:45:24 CET 2004

> I didn't read the OP, just Richard.  Unless he was the OP,
> in which case I'm confused about various comments that have
> been made, but not concerned enough to go back and try to
> figure the whole thing out.  *Your* comments appear right
> on the mark, as far as I can see. ;-)

Richard was the OP. 

> Nope.  Python has no ability to interface to something that is
> defined only at the assembly level (interrupt routines) without
> using assembly.  (I don't even mention C here, as it requires
> special non-standard C extensions to support these things, in
> effect doing a quick escape to assembly.)

My words.... 
> I'll add an additional note:  there's a qualitative difference
> between being fast enough to respond to hardware interrupts
> at the 100-CPU cycle sort of level of performance, and at
> a speed 100 times slower.  It's not a matter of just having
> a slower overall system, which might be fine for a prototype
> or a simulation.  In fact *it simply won't work*.  That's
> because if hardware interrupts aren't answered fast enough,
> in most non-trivial cases _information will be lost_, and
> that means the system is broken.  That's the definition of
> a "hard realtime system", by the way, and an unfortunate
> reason that Python in its current form (i.e. assuming its
> bytecode interpreted rather than compiled to some kind of
> native code) cannot ever be used at the lowest levels of
> an OS.

Yup. And writing an OS is exactly about these nitty gritty things -
otherwise, its only a collection of more or less useful lib routines. So
writing a "virtual os" that doesn't have to deal with problems like these
is barely useful for teaching anything about  writing an os at all... 


Diez B. Roggisch

More information about the Python-list mailing list