How much of an operating system could be written in, say, Python?

Question

This is a pretty-much theoretical question, but..

How much of an operating system could be written in a language like Python, Ruby, Perl, or Lisp, Haskell etc?

It seems like a lot of the stuff like init.d could trivially be done in a scripting language. One of the firewall-device-OS's (m0n0wall) uses PHP for its system-configuration (including on boot). And one could argue that "emacs is an OS, mostly written in Lisp"..

Of course there are bits that would have to be assembly/C, but how much could be regular .py/rb/.pl/.el/.hk files..? It might not have the best performance, but it would be, by far, the most easiest-to-modify OS ever...

Answer 1

House - Haskell User's Operating System and Environment. It is even bootable inside VM and you could play with it.

Sources are very readable, IMO.

Answer 2

Python does not natively provide constructs to talk directly to the hardware, like raw pointers for memory-mapped I/O and many other constructs provided by C/ASM. However, there is proof that most everything in an OS can be written in a more abstracted language; the Singularity OS from Microsoft is written almost exclusively in variants of C#. There's an extremely small amount of C/ASM to do interrupt handlers and such, but everything else, including what most of us consider to be "the kernel" can be done in essentially any Turing-complete language.

It should be noted that Singularity's choice to implement these low-level constructs in C/ASM should not be interpreted as a fundamental limitation of the syntax or other aspects of high-level languages. One could certainly make a variant of Python that emitted and dealt appropriately with the necessary assembly code.

Answer 3

Technically, any of it could be, if you write a compiler to do so. OSes have been done in Java (JNode), .NET (MOSA, Singularity, SharpOS, Cosmos), Haskell (HOUSE), Python (Unununium), etc.

Edit: I see a lot of people talking about the very lowest level being an area where this couldn't be done; this isn't true.

There's no reason that the compiler for X language can't be extended to handle any low-level operation and expose it to the language. All functionality can be achieved from any language, it's simply a matter of picking the right tool for the job. Sometimes this is Python, sometimes this is C, sometimes this is assembly.

Look to projects like Cosmos and SharpOS to see a pure high-level OS Done Right (TM).

Answer 4

Beyond the kernel (and by this, I mean kernel, microkernel style), and something to compile the runtimes for each of said dynamic languages, just about anything and everything COULD be if you were building your own operating system. It's just not practical. Heck, init.d is written primarily in sh as far as I'm aware. But sh, while not powerful, is VERY lightweight and as far as I know, efficient in what it does. Higher level languages like Python, Perl, etc, could handle it fine, but it'd be alot slower, and would take alot more memory for instances of interpreters.

It's possible, it's just not practical.

Answer 5

It's difficult to imagine kernels / device drivers etc written in (e.g. Python) - the memory management would be a bit of a headache.

On the other hand, almost all the userspace code could be. Under Linux, there is no requirement that "init" be a native machine-code binary - it can be a python script or something, no problem.

Answer 6

The one interesting outcome from Singularity is, you don't need a MMU (memory management unit) in the CPU any more, since all userland code is "managed". I could see this beneficial in embedded scenarios, using non-MMU Linux and on top of that scripted applications.

Answer 7

See Genera / OpenGenera for an example of an OS written in Lisp that was actually in use for quite a while on LispMachines.
Haskell has House.

Answer 8

As long as the programming language has the ability to manipulate binary files, you could write a complete OS in the particular language. This is not to say that it is easy, or practical. It just makes sense that, if your chosen language can manipulate binary, then you can go as low-level as you need.

Answer 9

I would say this is not possible. Responses to this question keep referring to changes to the language or using the language to generated low level (kernel) code. This is just using one language to write another language. While I agree that both of these would allow you to then write an operating system, I would then argue that it is now not the same language. So, an operating system could be written in many different languages but not every language (without change or language by pass) can be used to write an operating system.

The finial answer to the original question is almost all, but not all. The only acceptation are languages which can access CPU level instructions.

Answer 10

"cleese" - an operating system written almost entirely in Python

Answer 11

I'm surprised nobody has mentioned Java hardware. It should be an inspiration for us to further the evolution of hardware by creating an even higher level processor.

There's another project I just found called "Pycorn".

If there was a Python bytecode processor, it would be feasible to make a fast operating system in 100% Python. The processor could implement the entire CPython bytecode, or anything that is compatible with the Python language (But not C modules!). The processor would have to handle reference counting, classes, and objects. Native hashing for dicts would be very helpful, all the complex data structure manipulations which Python currently needs in software should be done purely in hardware. There would be no concept of pointers, which I see as a prime motivation for building such a processor, as it would be impossible to smash the stack.

Everything would be objects! The kernel itself would call methods on the memory object, although you wouldn't need to touch it much since the hardware will handle allocation and garbage collection anyways. Interrupt handlers can simply be set to python methods. MSRs, caches, debug registers, and I/O ports are objects.

There's a interesting discussion about implementing Python on an FPGA here.

On another note, (pertaining to a Python O/S on a non-Python processor) to the people claiming you can't make inline assembly Pythonic, it's pretty simple to just emit assembly from an abstraction, ex:

asm = MetaASM()
asm.r1 = 1234
asm.r2 = r1 + 5
asm.io.out(r1)

You could switch to architecture specific assembly for performance needs or architecture specific operations / registers when necessary:

asm = ASM("IA-32")
asm.xor(asm.eax, asm.eax)
asm.cr0 = asm.eax
asm.invtlb
asm.fs.0x00123456 = asm.eax
asm.al = 123
asm.dword.ptr.eax = 1234 # mov dword ptr [eax], 1234
asm.push(asm.eax)

CorePy comes to interest on this topic.