Python OS

[Peter Hansen]

Jeremy Jones wrote:
> Peter Hansen wrote:
>> You _cannot_ use Python for a time-critical interrupt, even
>> when you allow for pure C or assembly code as the bridge
>> (since Python _cannot_ be used natively for interrupts, of
>> course), because -- as noted above! -- the interrupt must
>> execute in a few hundred CPU cycles.
> 
> I'm really not trying to contradict nor stir things up.  But the OP 
> wanted to know if it were possible to prototype an OS and in a 
> follow-up, referred to a virtual OS.  Maybe I mis-read the OP, but it 
> seems that he is not concerned with creating a _real_ OS (one that talks 
> directly to the machine), it seems that he is concerned with building 
> all the components that make up an OS for the purpose of....well.....he 
> didn't really state that.....or maybe I missed it.

Richard's post, to which I was replying, didn't include the
proper attributions for his quoted material, so I don't at
this point know who actually wrote what.  There was someone
who said you could do interrupts in Python (the argument
being that this was so "because you can do them in C", which
is non-sensical given that they are different languages with
different capabilities), and then someone else wrote about
"time-critical code" of "a few hundred CPU cycles", and then
Richard's reply in effect justified the original argument
again (at least, that was my interpretation.  I don't know
if he meant to do that.  I suspect not, given his rebuttal.)

Note that I have *no idea* who the OP was in this thread, nor
what questions he asked or what claims he was making.  Sorry,
I didn't read it in that detail.  I just saw the message to
which I replied, with the unattributed stuff just as I quoted
it, and reacted purely to it.  Probably a bad idea, but I
stand by what I said.

If, as you suggest, the OP just wants a prototype, then I say
wonderful, use Python.  Just don't waste time writing real
interrupts in Python, and certainly don't try to make the
prototype work in an environment where 100 CPU cycles is
important...

> So, asking in total ignorance, and deferring to someone with obviously 
> more experience that I have (like you, Peter), would it be possible to 
> create an OS-like application that runs in a Python interpreter that 
> does OS-like things (i.e. scheduler, interrupt handling, etc.) and talks 
> to a hardware-like interface?  If we're talking about a virtual OS, 
> (again, I'm asking in ignorance) would anything really be totally time 
> critical?  Especially if the point were learning how an OS works?

Sure, everything you describe would be straightforward and
work wonderfully with Python.

> I totally agree with you...sort of.  I totally agree with your technical 
> assessment.  However, I'm reading the OP a different way.  

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

>> Of course, if you will allow both assembly/C code here and
>> there as a bridge, *and* you are willing to accept an operating
>> system that is arbitrarily slower at certain time-critical
>> operations (such as responding to mouse activities) than we
>> are used to now, then certainly Python can be used for such things...
>>
> OK - so here's my answer.  It should be possible, but it will be slower, 
> which seems to be acceptable for what he meant when mentioning 
> prototyping and a virtual OS.  But here's another question.  Would it be 
> possible, if I've interpreted him correctly, to write the whole thing in 
> Python without directly calling C code or assembly?  

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

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.

The argument should really be about *how little* assembly
and/or C you can get away with, and perhaps here is where
Mel Wilson should step in with some of his thoughts on the
matter, as I've heard him discuss some ideas in this area. ;-)

-Peter