Python OS

[Diez B. Roggisch]

> Do you mean that there are no entirely C OSs?

I doubt it. e.g. GCC lacks the ability to create proper interrupt routines
for 68k-based architectures, as these need an rte (return from exception)
instead of an rts (return from subroutine) at their end, which GCC isn't
aware of. So for creating a interrupt registry, I had to resort to
assembler - at least by "poking" the right values into ram. This consisted
of a structure


typedef struct {
  short prefix[9];
  t_intHandler handler;
  short suffix[8];
} t_intWrapper;

where handler was set to my C function that was supposed to become an
interrupt handler and

t_intWrapper w = {
    0x4e56, 0x0000,0x08f9,
    0x0001, 0x00ff, 0xfa19,
    0x48e7, 0xfffe, 0x4eb9,
    handler,
    0x4cdf, 0x7fff, 0x08b9, 0x0001, 0x00ff, 0xfa19, 0x4e5e, 0x4e73
  };

beeing the initialisation of that t_intWrapper struct. The code simply
pushes registers on the stack and then jumps into the C function. The
address of such a struct was then set to the appropriate interrupt vector.

Now one can argue if that is still C, as it's written in a cpp-file thats
run through a compiler - but if that really counts as C, then of course you
can write anything in python (or VB or whatever languague you choose) by
simply writing out hexdigits to a file....

> Understood, however, note the terms prototype and virtual.  Perhaps I
> could create virtual hardware where needed, and play around with the
> timing issues in this manner (emulate them and create solutions
> prototyped in Python).

In you first post, you didn't mention virtual - only prototype. And
prototyping an OS for whatever hardware can't be done in pure python. Thats
all that was said. 

Writing a virtual machine for emulation can be done in python of course. But
then you can't write a OS for it in python as well (at least not in
CPython )- as your virtual machine must have some sort of byte-code, memory
model and so on. But the routines you write for the OS now must work
against that machine model, _not_ operate in CPython's execution model
(which is based on an existing os running on real hardware)

Now generating code for that machine in python means that you have to port
python to to your machine model - like jython is to java. That porting work
is akin to the one projects like ceese or unununium, writing memory
allocation routines and so on - for your machine model.

So I'd still say: No, you can't prototype an OS in python, neither for
virtual or real hardware. You _can_ add all sorts of modules, C-code and
what not to boot a machine into a python-interpreter that has all sorts of
os-services at its hand by certain modules, like the forementioned projects
attempt.

But creating a VM only leverages that work to the next level, retaining the
initial problems. If you don't do it that way, you don't prototype anything
like an OS nor implement a machine model but instead meddle some things
together by creating a machine model that is so powerful (e.g. has an
built-in notion for lists, dicts and the like) that it can't be taken
seriously as educational for writing an OS - at least to me, as the virtue
of writing an OS is to actually _deal_ with low-level matters, otherwise
there is no challenge in it. 

I don't say that this is not a worthy project to undertake for educational
purposes - but I wouldn't call it an OS, as it does not teach what creating
an OS from scratch is supposed to teach.

For example you can't write a OS for the JAVA VM, as there is no such things
like interrupts defined for it - instead IO happends "magically" and is
dealt with on the low level with the underlying OS. The VM only consumes
the results.

-- 
Regards,

Diez B. Roggisch