Python Operating System???

[Bengt Richter]

On Sat, 8 Jan 2005 21:29:47 -0600, "John Roth" <newsgroups at jhrothjr.com> wrote:

>
>"Bengt Richter" <bokr at oz.net> wrote in message 
>news:41e09808.360402200 at news.oz.net...
>> On Sat, 08 Jan 2005 12:47:52 -0500, Peter Hansen <peter at engcorp.com> 
>> wrote:
>>
>>>Paul Rubin wrote:
>>>> When Unix was first written, people thought implementing an OS in C
>>>> was ludicrous.  Everyone knew OS's had to be written in assembler.
>>>
>>>Actually, when Unix was first written that belief was entirely
>>>correct, and OSes *did* have to be written in assembler.
>>>
>>>That is, pure C did not have the capability to handle all
>>>that was required.  I recall it taking a good decade before it
>>>became *common* to find C compilers with, for example, @interrupt
>>>support to let the compiler generate code that properly saved
>>>all registers and used RTI instead of RTS (or whatever it might
>>>have been called one one's particular flavour of CPU).
>>>
>>>Now, once you added a few tiny interrupt handlers, and some context
>>>switching (stack manipulation) routines, pretty much everything else
>>>*could* be done in C, but that doesn't invalidate the point.
>>>
>>>I think it's safe to say that none of pure C, pure Lisp, or pure Python
>>>are really capable of being used as the *sole* language to build
>>>an operating system.
>>>
>>>It's also safe to say that this is a largely irrelevant point.
>>>It would probably only be of academic interest to try to do
>>>something like that.  Any practical attempt would not think more
>>>than twice of resorting to a little "glue" in assembler or in
>>>the form of "canned" byte sequences built by hand and stuck
>>>into the appropriate places in memory...
>> Well, usually there's more than one tool in the chain from source
>> to bootable loader and OS image, even if you are writing in C and 
>> assembler,
>> and there's usually more to an OS than the bootable image contains.
>>
>> So ISTM "writing an OS in <language>" is pretty loose talk ;-)
>
>Most people who work in the field know what it means, though.
Even if they know the whole story intimately, IMO it is not unlikely
that they are talking about particular chapters, and it may not
be clear whether they are thinking totally radically of rewriting
ALL software in the system in Python, visualizing a holy grail of
saying goodby to both GNU and M$ and having a purely Python-defined
system (which would mean Python tool chains that could prepare binary
images (no theoretical problem) for a computer's boot BIOS and on
from there, as a tour de force project, or whether they want e.g.
to integrate  Python front end to gcc (or at one remove via C as is easier),
and not reinvent so many wheels.

>One of the touchstones of language design is whether you can
>write the compiler and runtime in that language. PyPy is working
>on that for Python, Squeak Smalltalk is written in Smalltalk and
>then converted to C for compilation of the runtime. Both of them
This "runtime" is then represented as an executable file that an
OS shell you are using will ask its host OS kernel to load and execute
as an OS-managed user process, right? Or is it bootable? If so,
in what format that what loader understands? 

>are completely virtualizable: you can run them (very slowly) under
>themselves for testing.
But what binary is running? The compiled C output of the backend?
Interpeting the Python source of itself to spit out the same C that it itself
was compiled from? That's cool. And it shows that you can prepare
a binary with the help of the C compiler+linker (most likely with gcc libraries)
to produce a userland program executable.

But I suspect some are thinking that Python source should implement
the whole environment it runs in. That's more radical ;-)
I would guess a cross development system hosted on a normal PC OS
but targeting some limited embedded environment would be
where I'd expect to see this kind of thing first. But still
going via C tools to the end product most likely, since C is so ubiquitous.

>
>Given that everything in Python is an object, I see no reason
>why one couldn't create a set of objects that are appropriate
>for an operating system kernel and can also be converted
>cleanly to the operating system subset of C, and write a converter
>that does it.
OSCTypes?
>
>That's the easy part. The hard part is writing the operating
>system. Look at the (lack of) progress the GNU HURD
>project has been making recently.
>
There are more interesting things to do than reinvent wheels though,
even if it is fun doing it in Python ;-)

Regards,
Bengt Richter