OSNews

This thing has an awful tendency to have one of my CPU cores run amok, I wonder if it uses timer interrupts properly... But indeed, I must admit that apart from that it does work reasonably well.


*bends down indeed, impressed by how far people have gone with what looks like a language only suitable for mad mathematicians when browsing code snippets*

However, I wonder : if haskell is a "safe" language, how do they manage to create a pointer targeting a specific memory region, which is required e.g. for VESA VBE ? Or to trigger BIOS interrupts ?

Edited 2011-02-07 20:21 UTC

"However, I wonder : if haskell is a 'safe' language, how do they manage to create a pointer targeting a specific memory region, which is required e.g. for VESA VBE ? Or to trigger BIOS interrupts ?"

A safe compiler can assure us that all pointers are in bounds before being dereferenced. Most of these bounds checks would be "free" code since the values are implied within the code paths.

The compiler might track two pointer variable attributes: SAFE & UNSAFE.

A function could explicitly ask for validated pointers.
This way, the compiler knows that any pointer it gets is already safe to use without a bounds check.

void Func(attribute(SAFE) char*x) {
// safely dereference x
}

for(char *p = (char*)0xa0000; p<(char*)0xaffff; p++) {
Func(p); // no extra bounds check needed, the code path implies the pointer is in valid range.
}

char*p;
fscan("%p", &p); // yucky dangerous pointer
Func(p); // here the compiler is forced to implicitly bounds check the pointer, since the function is requesting a safe pointer.

This is not a performance penalty because code which does not validate the pointer is a bug waiting to be exploited anyways.


The SAFE/UNSAFEness of pointers can be tracked under the hood and need not complicate the language. Although if we wanted to, we could certainly make it explicit.


Developers of safe languages have been doing this type of safe code analysis for a long time. It really works.
Unfortunately for OS developers, most safe languages are interpreted rather than compiled, but JVM and CLR show that it is possible.

This is somewhat as much as impressive than my own attempt to do something similar, yet using existing kernel code (Minix 3) and functional language (Erlang).

The biggest problem so far is that Minix 3 is only "self-compiling" : you can only developp and hack Minix FROM Minix (no cross development possible due to hackish code targeted to their own C compiler -ACK- no pun intended) and the big dependence of Erlang to GCC's specific extensions.

C portability has never been so much discutable...

On a brighter note, I also greatly considered this thesis project as programming interface :

http://www.csse.uwa.edu.au/~joel/vfpe/index.html

It is written in Java, and might scales better over Haskell than Erlang, yet I find some "operations" to be more intuitive using emacs (plain text editing) than creating "tempo" objects to fit functional's lazyness :/

My 0.02€ :p

Kochise

EDIT : typo

Edited 2011-02-08 17:23 UTC

Well, I for one, consider that a *decent desktop OS* needs to be able to run:
-an HW accelerated games such as Doom3.
-a fully featured webbrowser
-a fully featured office suite (say LibreOffice).

Wake me up when they reach this point..
And then there is also the issue of hardware support..

If they can support PCI and VESA, they can support HW accelerated graphics as well, it's only a matter of writing lots of chipset-specific code in order to support it, which is a brute force development task.


Again, porting webkit/gecko or an office suite on a new architecture is a brute force development task once some prerequisites (like a libc implementation and a graphics stack) are there. I sure would like to see some complex applications around to see how well they perform, but Kochise's example does show that it's possible to write a simple GUI desktop OS with haskell.


Again, that's not the point of such a proof-of-concept OS. They only have to show that it's possible to implement support for any hardware, by implementing support for various hardware (which they've done), the rest is only a matter of development time.

Of course, I'd never use this OS as it stands. But it does prove that it's possible to write a desktop OS in this language, which is my original concern.

Edited 2011-02-08 10:15 UTC