Python OS

[salvatore]

http://unununium.org/

Regards

 

[Mike Meyer]

How so? An interrupt is a address the processor directly jumps to by
adjusting its PC. The JVM doesn't even have the idea of function pointers.
Invoking a (even static) method involves several lookups in dicts until the
actual code pointer is known - and that's byte code then, not machine
code.

No, that's how most modern machines generate interrupts. That doesn't
mean the your JVM-based system would have to do it that way. An
interrupt could trigger a lookup in a privlieged dict to find a code
pointer.

As your examples show, one can implement a VM ontop of a considederably thin
layer of low level code and expose hooks that allow for system
functionality to be developed in a high-level language running bytecode.
Fine. Never doubted that. I've written myself C-wrappings that allowed
python callables to be passed as callbacks to the C-lib - no black magic
there. But that took some dozen lines of C-code, and time-critical
interrupts won't work properly if you allow their code beeing implemented
in a notably slower language.

If you followed the link in my last post, you saw a paper on one of
the early LISPMs, which put a virtual LISP machine in silicon. The
same could be done for JVM. However, the success of LISPMs and Forth
in silicon would contraindicate doing that.

<mike

 

[Peter Hansen]

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

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

 

[Diez B. Roggisch]

If you followed the link in my last post, you saw a paper on one of

the early LISPMs, which put a virtual LISP machine in silicon. The

From that page:

"""
n the software of the Lisp Machine system, code is written in only two
languages (or "levels"): Lisp, and CONS machine microcode There is never
any reason to hand-code macrocode, since it corresponds so closely with
Lisp; anything one could write in macrocode could be more easily end
clearly written in the corresponding Lisp. The READ, EVAL, and PRINT
functions are completely written in Lisp, including their subfunctions
(except that APPLY of compiled functions is in micro-code). This
illustrates the ability to write system functions in Lisp.
"""

So they do have a underlying assembler. As I said before: I never doubted
the possibilty to tightly integrate a higher level language that even is
interpreted and a piece of hardware together so that the OS is based on
that hl language.

But you simply don't _want_ your virtual memory paging code written in
python or (uncompiled) lisp, lest you like to drink lots of coffe sitting
idly in front of your machine

same could be done for JVM. However, the success of LISPMs and Forth
in silicon would contraindicate doing that.

Then we're not talking about "V"Ms AFAIK there have been attempts to make
java bytecode interpreters in hardware - but I'm not aware that these have
been a large success in the market or even reached a level where they
entered the market at all.

 

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