Linked by Thom Holwerda on Fri 24th Nov 2006 19:34 UTC, submitted by Lambda
OSNews, Generic OSes House is a demo of software written in Haskell, running in a standalone environment. It is a system than can serve as a platform for exploring various ideas relating to low-level and system-level programming in a high-level functional language.
Thread beginning with comment 185562
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[2]: would be cool if...
by alphaVirgo on Sun 26th Nov 2006 22:32 UTC in reply to "RE: would be cool if..."
Member since:

Assembly code isn't much faster than good C code. The problem is SSE, but a really good compiler (maybe with something slightly less powerful than whole-program analysis) could give you speed comparable to hand-optimized assembly code.

The argument about monolithic kernels is flawed because with a secure language (in particular: no arbitrary pointers like in C) you can pretty much eliminate the overhead of micro-kernels. Even if that is not enough we could have something like a hybrid kernel (drivers as modules loaded into kernel). That would be basically as fast as a "real" monolithic kernel, but without most of the inflexibility and complexity.

Also, you forget that speed is not everything. Drivers and other insecure kernel code are responsible for a lot of system crashes. A more secure language (see Sing# which is used in Singularity) could solve a lot of problems. Maybe you could optinoally enable a garbage collector (good GCs with native code compilers can be pretty fast, don't compare this to Java's performance). If you really need maximum performance you could still combine it with insecure assembly-like code.

I also don't think it's bad that the layer is basically an entire OS. Who cares? That means less code for the actual OS sitting on top of the layer and more drivers for all OSes. There is so much code that every OS reimplements in a very similar way. The only difference is the way plug-n-play works, the VFS, the scheduler, the VM subsystem, processes, threads, single vs multiple address spaces, security, and maybe a few minor things I forgot. The abstraction layer could offer everything that is important. There is absolutely nothing speaking against adding support for what you mentioned at the end (flash drive and physical allocation).

We have so much duplicated code in every OS. The development time could be spent on really important things. Why does nobody sit down and write a cool layer in a secure language (no, please let's do away with stupid C/C++ for system-critical code!).

Reply Parent Score: 3