OSDev.org

I know that this is possible, because its been done before (here).
But is it any easier or more efficient than using C or C++? I'm assuming that higher level = less code, so that would be a plus, but just I don't see how something as low level as an operating system could be written in a language like Python. Where do I start?

Python, even in its most basic form, still depends on a fairly solid POSIX subsystem, which must be written in a language such as C or C++.

I imagine an "operating system" in Python would be a very rudimentary low-level framework which provides just enough functionality to run Python and then allowing Python to run everything. Even so, you'd still be writing an awful lot of low-level code before you were able to write Python code.

Alternatively you may consider writing your own parser for a Python-like language which compiles into a binary format.

pcmattman wrote:Python, even in its most basic form, still depends on a fairly solid POSIX subsystem, which must be written in a language such as C or C++.

Well, my plan was to build a basic kernel in C/C++, add C/C++ standard libraries, and then port Python to it.

I.e., you want to write an operating system supporting a Python runtime. (Which is, from the view of the OS, just another user-space application.)

There is little to be gained from writing a kernel in a higher-level language.

On the one hand you gain the expressiveness of the language (although expressiveness is a feature more powerful the higher-level the problem, e.g. distributed computing, enterprise level integration etc., whereas a kernel is as low-level as it gets).

On the other hand you have one more language in the kernel proper (in addition to the ASM you need to get started and the C/C++ you need to get Python running), and you have a language in your kernel that is unlike that which your kernel-experienced peers are familiar with and that which is used in tutorials, examples, and suggestions.

If you chose Python because you don't feel familiar with C/C++, it might be an indicator that you should become more familiar with low-level code, as this helps big time when doing OS Dev.

If you chose Python because you believe then everything will become much simpler... I don't believe it offsets the additional complexity of having the Python support code in kernel space.

And last but not least, the Python runtime code available is most certainly not designed to run in kernel space, meaning it will require much more than "just porting" it.

Here's something to consider - the PyPy project has a compiler for a statically-typed subset of Python called RPython. You might be able to write kernel-level code with that.

bgraybr wrote:I'm assuming that higher level = less code

This assumption is not correct (in the case of python vs. C/asm for OS Dev). Remember, higher level langauges ease the expression of computation typically at the expense of abstracting away from the low-level (annoying) details necessary to manipulate the device known as the computer. But operating system development focuses primarily in controlling a computer.

Both tools have their place. Python, like any other Turing complete language, can be used to make an OS (with some slight add-ons). But in the case of OS development, python is just another Turing tarpit, just in the opposite direction that usually occurs.

bah, a bunch of academic crap==lack of real world experience.

This is the second time I've seen you inject an offtopic attack on academia into a thread.

That's a fun Superiority Complex you have. But what do I know? I don't have a psychology degree after all.

dude, relax, it was a joke.

I believe it's possible, though you'd require some modification to the language such as introducing a new static class that can wrap around memory blocks without the need for reference counting or attaching type info to the data.

I'm interested in high level pointer-less languages that can be JIT'ed since they can offer a great performance boost while still maintaining security. For example, a system call can be as efficient as calling a function inside the kernel, IPC can be done by passing around objects and strings. Pointers and IO are allowed, but only inside drivers (the JITer would provide the security), and inline assembly only allowed within the kernel. Switching to process would be no heavier to switching threads as all processes share the same addressing spaces.

The main problem with this would be memory fragmentation since every application would be access the same master pool of memory, but an advantage of JIT'ing is you can know what is referencing each piece of allocated memory, so even though it would be slow you could move memory around (something you'd do in a kernel thread or when you can't find a suitable spot to allocate memory).

Your user space applications would be portable across different architectures and would be able to take advantage of instruction sets (MMX, SSEx) automatically if they're available. You can also integrate in OS-specific constants at JIT-time. And to some extent you could run your general user programs on top of another OS.