Python OS

[Diez B. Roggisch]

> 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... 

-- 
Regards,

Diez B. Roggisch