Kernels writting in languages other than C

Nick Carlson · Post by **Nick Carlson** » Fri Feb 29, 2008 6:15 pm

Most kernels I've come across are written in C (with the rare c++ exception).

I'm wondering, does any know of any kernels which have been written in other languages? Is it even a possibility? I know there are several factors which play into this (the size of the languages standard library being one).

Thanks.

Colonel Kernel · Post by **Colonel Kernel** » Fri Feb 29, 2008 6:25 pm

Singularity is written mostly in Sing# (a dialect of C#).

JackScott · Post by **JackScott** » Fri Feb 29, 2008 6:33 pm

Somebody on this forum is writing their OS in FreeBasic.
And of course, many people try and write whole operating systems in assembly. Quite a few do well with that.

Edit: I'm pretty sure it's Combuster. You may also want to look at the pages in the wiki on Languages, if you haven't already.

Colonel Kernel · Post by **Colonel Kernel** » Fri Feb 29, 2008 6:52 pm

IIRC the first version of L4 was written entirely in assembler.

Nick Carlson · Post by **Nick Carlson** » Fri Feb 29, 2008 6:54 pm

Yeah, assembler's kind of a given. The freebasic kernel sounds interesting though.

Laksen · Post by **Laksen** » Fri Feb 29, 2008 8:22 pm

My kernel is written in Object Pascal. It works great in 32 bit. The compiler has support for 64bit code generation but I'm still searching for a objcopy equivalent that can copy objects from pe64 to elf64 or something else

Dex · Post by **Dex** » Sat Mar 01, 2008 9:42 pm

I have a freepascal OS example, if you interested ?.

essial · Post by **essial** » Sat Mar 01, 2008 10:38 pm

You can write your kernel in any language that has the support required. That it, it must:

- Compile binaries and/or object files you can link with other files
- Not have an os-dependent library, or allow you to override said library (e.g. the c++ new/delete/constructors/etc)

You'll almost always have to have SOME assembly so it will either need to support inline assembly blocks, or at the very least, you need to link assembler objects with your other code; in which case, of course, it will need to be able to 'extern' functions and perhaps variables that may be defined in an assembler object.

speal · Post by **speal** » Sat Mar 01, 2008 11:13 pm

I'm currently working on an OS project in D. You can take a look here: http://www.devlime.com

That said, I think the previous post requires some clarification as to what it means to develop a kernel in a particular language.

There are kernels in Java and Lisp, but in these cases there must be some form of runtime environment (interpreter, VM, etc...) running underneath. This base level must be written in a language that can be compiled to native machine code for the computer. While I'd still consider this to be developing a kernel in lisp or Java, there's a significant amount of work being done in a different, lower-level language to allow this.

If you're trying to build a kernel in a particular language because you think it'll be easier, make sure it's a language that can be executed natively on the machine. If you believe a functional language is the ultimate platform for kernel development, the extra work of writing an unhosted interpreter in a systems programming language may be worth the extra work.

I believe there are also projects that compile languages that are typically not natively executable to machine code. I'm no expert in this area, but I'm sure there are plenty of good sources here and on Google if you decide to go that route.

essial · Post by **essial** » Sat Mar 01, 2008 11:31 pm

speal wrote:There are kernels in Java and Lisp, but in these cases there must be some form of runtime environment (interpreter, VM, etc...) running underneath. This base level must be written in a language that can be compiled to native machine code for the computer. While I'd still consider this to be developing a kernel in lisp or Java, there's a significant amount of work being done in a different, lower-level language to allow this.

Sorry, I was making the assumption that his kernel was not going to be ran inside a virtual machine (VM). Yes, you can use managed languages. In fact, my OS runs all drivers and applications inside of managed VMs. But I personally do not think (and cannot see how its even possible) the kernel itself should be in a managed language, because the kernel is supposed to be , itself, the one in charge of managing everything else.

speal · Post by **speal** » Sat Mar 01, 2008 11:42 pm

I agree with you in all but the most extreme cases. Your answer was good, but I think it's reasonable to acknowledge the possibility that someone could write a minimal VM that provides almost no services, and to then write a majority of the kernel components in a hosted language.

Very rarely is a kernel written in only one language (the most common case being assembly and C). Composing a kernel of multiple programs is just another step in this direction, and could lend itself well to distributed environments, or the interpreted/hosted languages I mentioned above.

On a side note:
Is Singularity run inside a minimal .net environment, or have they developed a native compiler for it? IIRC it's the latter, but I may be wrong.

essial · Post by **essial** » Sat Mar 01, 2008 11:53 pm

I believe its the latter. The singularity project is what inspired me to design my OS the way I have. Although my filesystem specs do not allow for paths of any kind, and memory addressing is by handles, not pointers; so I guess its well off the singularity beaten path, but I still am going to run all applications and drivers in VM.

I personally think VM is the way of the future. With virtual machines running all application code and drivers, security will go through the roof. If an application cannot modify binary data, then there is no excuse for the OS to allow invalid things to take place. For example, the VM application cannot exploit some bug to enject code into the kernel, since all memory operations are done through managed objects with handles.

As far as speed is concerned, I also think that a VM OS would run just as fast, if not faster, than a native OS. Current OS's (Windows and Linux included) are designed around ideas from the 80's, back with 8mb of ram was crazy good, and 300mhz was blazing fast. With 3.4ghz 2-core processors and 2048mb of ram the norm in today's systems, VM should run at seemingly the same speed as a native binary. Ontop of that, the need for antivirus and such will be eliminated, AND of course, the processor's cache doesn't have to reset or flush since you never have to change descriptors.

*end rant*

speal · Post by **speal** » Sun Mar 02, 2008 12:12 am

The virtual machine idea is an interesting one for operating systems, but I'm still in doubt as to how much protection it provides. Protection levels, IO permission maps, and virtual memory provide enough protection for a single process, but if a whole runtime environment is going to be protected a virtual machine seems to be a good means of doing this.

I doubt you'd see a performance improvement when switching from a microkernel (process isolated) environment to a virtualized kernel (hardware isolated) environment unless you could reduce the amount of communication in and out of virtual machines to offset the overhead of maintaining and switching between them. The protection/reliability may be worth the trade-off in any case, since processing power is getting pretty cheap these days, and in many cases a reliable system is more important than an bleeding-edge speedy system.

essial · Post by **essial** » Sun Mar 02, 2008 12:18 am

Theres another benefit to VM processes that isn't easily implementable in standard binaries: remote functionality. That is, you have two applications running, and one application calls a function on another application directly, and it acts just as if it were called on the host application. I plan on doing this for the mouse driver for example: mousedrv.app runs in memory, and publishes 1 function, GetMouseState() which returns a structure containing the mouse location and buttons and such. When the user program wants the position of the mouse, it simply imports that function from the driver app. When the user app calls GetMouseState, it literally executes the function on the mouse app as if its called natively; returning any result and variable params back to the caller of course. This is almost impossible with binary implementations because of the need for namespaces, and namespace security. Whereas in a VM style OS, calling a function of another task, with permissions/security, is almost trivial.

We'll see how it works out for me anyway :p

speal · Post by **speal** » Sun Mar 02, 2008 12:23 am

What you're describing is actually an RPC/RMI system, and it's not constrained to virtual machines at all. You may be able to get some extra performance out of it if you're clever about passing data between virtual machines. Sounds like an interesting approach, but you might want to consider implementing a fast RPC system in processes before jumping into complex VM implementation.

Good luck!