ImperialViolet

BRiX (30 Aug 2002)

BRiX (which I linked to yesterday) popped up on /. while I was in Korea and I've only just got round to having a look at it.

Basically, it's a safe-language OS (where the OS doesn't need to protect processes from each other because the language they are all written in prevents them being bad). It's an old-trick, but I never seen a serious implementation and it would be cool if BRiX reached even a first-beta level (satanic red on black colour scheme not withstanding).

However, I'm undecided on the merits of the safe-language approach. Firstly it mandates that every program be written in the language/byte code (where the changes with each safe-language OS). In BRiX's case the language is called Crush and looks like a typed dialect of Lisp. Learning a new language and rewriting everything in it is a nasty barrier to entry, even if it does hold a certain appeal in terms of cleaning out old code.

With this in mind I'm wondering if a decompiler could statically analyse compiled C code and determine if it's safe. I think, in theory if system calls were treated as non-deterministic, then it should be possible. The practice, on the other hand, might be somewhat painful.

Just a quick FAQ for anybody asking Why work with machine code, why not the C code?. Mainly because I think I would end up compiling the C code to a reasonably low level anyway. By working from the C code I might get some loop structure etc for free, but since it's perfectly legal to build loops out of gotos I would have to do control-flow analysis anyway, so why have the pain of processing C?

It might be that working with RTL (gcc's intermediate code rep) would be better. There are flags for dumping RTL trees (see your gcc manpage) but I have no experience with RTL. And, of course, if you are happy with the machine code you can run it, but if you are only happy with the RTL you still have to trust a compiler to generate good binaries.