"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:Well, usually there's more than one tool in the chain from sourceWhen 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...
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