"Bengt Richter" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]
On Sat, 08 Jan 2005 12:47:52 -0500, Peter Hansen <[EMAIL PROTECTED]> 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. 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 are completely virtualizable: you can run them (very slowly) under themselves for testing.

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.

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.

John Roth




Regards,
Bengt Richter

-- http://mail.python.org/mailman/listinfo/python-list

Reply via email to