Python OS

[Jeremy Jones]

Peter Hansen wrote:

> Richard Blackwood wrote:
>
>>
>>>> P.S.  If one can program interrupt routines in C, they can do the same
>>>> in Python.
>>>
>>>
>>> Show me how you set the interrupt jumptables to your routines in 
>>> python and
>>> how you write time-critical code which has to be executed in a few 
>>> hundred
>>> cpu-cycles. And how good that works together with the GIL.
>>>
>> Here is my logic:  If one can do X in C and Python is C-aware (in 
>> other words Python can be exposed to C) then Python can do X via such 
>> exposure.
>
>
> Unfortunately the logic is flawed, even in the case that you
> quoted above!

Yes and no.  See below.

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

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?

>
> Given that the cost of invoking the Python interpreter on
> a bytecode-interrupt routine would be several orders of
> magnitude higher, I don't understand why you think it
> is possible for it to be as fast.

I totally agree with you...sort of.  I totally agree with your technical 
assessment.  However, I'm reading the OP a different way.  If he did 
mean a virtual OS and if time isn't critical, and he was thinking, 
"well, I'm getting shot down for proposing to do this in Python, so 
maybe it isn't possible in Python, but it is possible in C and since I 
can call C from Python, then I should be able to do it", then maybe he 
has a point.  Or, maybe I'm just totally misreading the OP.  So, if he's 
saying that he can just call the C code from python and it'd be just as 
fast doing interrupt handling that way, then I agree with you.  But if 
he's talking about just the functionality and not the time, is that 
possible?

>
> 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?  Even if it were 
unbearably slow and unfit for use for anything other than, say, a 
learning experience?  Kind of like a combustion engine that has part of 
it replaced with transparent plastic - you dare not try to run it, but 
you can manually move the pistons, etc.  It's only good for education.

> -Peter

Jeremy