Lambda the Ultimate

I don't mean to sound harsh but, while there are some nice concepts there, I expect the results will just vanish into the black hole of their next version of Windoze. I'm also suspicious of the abstract instruction set thing. That means the whole system runs on a virtual machine so you're going to burn cash paying for extra clock cycles to support that. I suppose JIT could largely fix that though. Then you will have the usual MS bloat on top of that. Overall, it sounds like a great way to keep Intel and AMD share prices high. I'm more interested in languages that just compile down to machine code but without the Disco era quirks of C. I'm also interested in OSS, not giving Gates free labor.

First of all, I've done some OS programming in Object Pascal using the Free Pascal compiler. Yes, it's easily possible. You just need to write a malloc for the System unit and fill in a bunch of dummy I/O functions that the linker removes as dead code later on. After that, you get OS programming with classes, exceptions, and dynamic arrays!

Of course, if nothing satisfies you, you could always throw your ideas in on my proposal.

Unfortunately, you do sound harsh. I'd hope that we'd be able to discuss languages and related research in a civilised way here without gratuitous Microsoft-bashing (and I'd hope that we were all mature enough to avoid cutesy insults like "Windoze"). There are plenty of other forums on the web where you can take that sort of thing, thank you very much; I don't much care for it in LtU.

As regards Singularity, their language of choice (Sing#) is interesting in itself: contract-based (from Spec#) with the addition of message-passing channels to support concurrency. It supports low-level code generation while maintaining CLR-style type safety.

As regards that low-level code generation, CIL instructions are compiled at installation time with a portable compiler optimised for hardware-management code generation. The kernel provides GC and a managed heap, but otherwise the various bits of managed code end up running directly on the metal. It's a useful compromise between an abstract VM (making the development model simpler) and direct machine code execution.

Singularity does rely on an assembly-code interrupt manager; but its services are available to other components, allowing device drivers to be written in managed code, among other things.

There was nothing gratuitous or uncivilized in my post. I just don't have much interest in MS's model of development and said as much. I'll call Windoze Windoze if I damn well please. It's a common slang term at this point as every one knows.

I regard Wolf Logan's response to you as being to the point about both the substance of MS's singularity project, and about the non-constructive nature of the common "Windoze" slang term.

The various labs that make up Microsoft Research have been the source of much material of interest in programming languages, and LtU should be a place where these Microsoft researchers should feel happy participating. This is not because LtU takes any kind of stand against free software, but because LtU is above all a place that is about bringing attention to and discussing interesting material related to programming languages.

And there is relevant LtU policy:

6. Off-topic subjects The following subjects are considered off-topic:

(a) Rants and "bashing": In general, rants and "bashing" of corporations, languages, and paradigms is off-topic here. However, criticism that is relevant to the subject of programming languages is acceptable, if it is offered in a professional manner, with an appropriate amount of detail and/or references.

I agree with Chris and Wolf.

I made it clear that I felt there *was* interesting research going on there. I even pointed out that JIT could eliminate most of the performance hit from the VM. I was speculating, however, about the likely future fate of this research given what I know about MS in the past. Since my interest in this topic has to do with the future trends in OSes and systems languages and not particularly with any desire to make my own OS I feel such speculations WERE very much on topic. Apparently, such futurological musings are not welcome here.

Like many industrial research labs that have come on gone; being studied by MS Research doesn't mean that a given technology will be productized. I don't like MS all that much either--mainly for their behavior as a business entity--but that doesn't mean that their research efforts, many of which are excellent, should be ignored or dismissed.

I have no idea what will become of Singularity. It may form the core of some future OS offering--goodness knows MS needs to do something different, as the monolithic OS market is in grave danger--at some point the OEM bubble will burst and then what do you do? It may remain in the labs, interesting technology but not become productized. It may become part of a MS product offering, but not be the core of one. The underlying technology may be productized by someone else.

On the contrary, musings are the point of much of LtU; nobody objected to your original question regarding non-C operating systems.

As others have already stated, there are certainly a variety of OSs not written in C. I might take the opportunity to point out that, of course, what language a thing in written in has little to do with how close to the metal the end result is executed. This is why we have JITters, and why such things as the Dynamic Language Runtime are interesting in their approach in taking traditionally interpreted languages and allowing them to exist in a realm where their programs may be piece-wise compiled.

The thing about Ada is that's it's a fairly old language (I was wondering about the bleeding edge stuff mostly) and it's been pigeon-holed as an American DOD fetish, mainly because it largely is. It's really too bad though that Ada didn't come along just a few years earlier, as I think we'd now have all our system software written in it.

Ada is continuously being updated. They recently released the spec for Ada 2005, and the GNAT gcc compiler supports most of it already IIRC.

Keep in mind that Ada implementations do not have to provide GC.

I was looking at this a while ago. Everyone says the Ada spec allows for GC to exist, but it doesn't specify a GC. I saw a few sites that talked about extensions to certain implementations of Ada to support GC.[1]

Also, there is apparently an Ada on JVM implementation that uses Java's GC.

[1] http://www.enyo.de/fw/software/gnat-gc/

D is quite nice. I have it installed here along a zillion other languages. It really does seem to be "C++ done right". I guess I was just interested in finding out how far "out" you can get with a language and still be able to write a network card driver in it (that remains responsive of course). I'm interested in whether there's something fundamental about C and C derived languages or whether it's all just arbitrary. What do aliens write their OSes in, that sort of thing.

Very interesting. I'm gonna download this. Hard to beat the sheer coolness of Lisp.

Or Oberon.

Seems well documented too. I like that. Also the emphasis on being able to apply formal reasoning to OSes seems the right direction to go. I liked that emphasis in Haskell. My main criticism is that rsync is a bit user unfriendly and there don't seem to be tarballs or anything else to download. Also the current code doesn't compile (Linux, AMD64 dual core) Go Hopkins BTW, my mom used to work at the JHU hospital.

Preferred mechanism is actually to pull via mercurial these days. The rsync thing is just a way to guarantee a clean tree. We're actually prepping a pre-release this week, so the ease of access situation is about to change.

I just got what I think is your latest release via rsync (I don't have Hg) It needed a couple dependencies I didn't have that the configure script didn't tell me about. They were the ici stuff (uchar.h) and the Boehm gc package. Also I had to symlink x86_64 to the i386 directory to get it to find mkclosure.c. Compiled alright after that. This is on an AMD64 of course.

That symlink won't work. We need to implement make_closure for x86_64. As of right now it's all i386 only. Hopefully fix that this weekend. Other fixes are in progress, which is why the release hasn't happened yet. Always good to have your feedback, though.

As with any release, there is always a laundry list of open issues that you race to close before the release. We've had some significant issue resolutions in the past few days. Given that they don't look hard, the plan is now to implement some of those before the release. So it will be a few weeks more.

Run-time code synthesis --- a systematic way of creating executable machine code at runtime to optimize frequently-used kernel routines --- queues, buffers, context switchers, interrupt handlers, and system call dispatchers --- for specific situations, greatly reducing their execution time.

Now that's damned interesting! :) An OS that self-optimizes at run-time.

That's a cool reference. Thanks! These days, though, it looks like the task of getting another OS up and running - I mean with adequate functionality to interest people - seems like a daunting task. Do you think there is an incremental path to getting these concepts down into current OSes such as linux?

If you have early support for running another OS in a sandbox, then maybe you don't need the exhaustive feature set. If you provide features in your OS that require system-wide architecture - data privacy, safety, roll-back ability, or the optimizations mentioned above - then maybe you can attract the community that will be needed for a more complete OS.

(Edit: In case it wasn't clear - while you asked about migrating e.g. linux to a new architecture, my response is just about an evolutionary path to a new OS.)

It's valid to ask: "why did we do BitC given Cyclone". The answers are that Cyclone has some difficulties with exact data structure representation (fat pointers), and it doesn't have a formally specified semantics. BitC, of course, doesn't have a full semantics either. The difference is that we understand BitC well enough to have a hope of specifying one. We hope. :-)

A more serious issue with Cyclone is that it guarantees dynamic safety rather than static safety. When your pacemaker halts because null pointers are bad for you, how much comfort will that be?

are impossible in bitC I take it? Sounds like you have a static typing system like Haskell.

IBM's PL/I dialects include the following:
PL/S - Programming Language for Systems
PL/AS - Programming Language for Advanced Systems, an enhanced PL/S
PL/DS - Programming Language for Distributed Systems
PL/X - Programming Language eXtended, an enhanced PL/AS
PL.8 - a PL/I derivative developed at IBM Yorktown and currently used for Z series firmware. It consists of about 80% of PL/I.

Bitsavers has several PL/S manuals and the others are described in the IBM Journal of Research and Development.

HAL/S, which is used to program the Space Shuttle's AP-101 computers, is an XPL derivative. XPL was defined in A Compiler Generator by W. M. McKeeman. Gary Kildall's PL/M is another XPL descendant.

Bitsavers also has a manual for HAL/S.

The Multics system ("http://web.mit.edu/multics-history/", "http://www.multicians.org/") was programmed in PL/I (and a bit of assembler). It was one of the first OSes programmed in a high-level language of any kind, and remained in commercial use up until 2000. Also, many design ideas which ended up in Unix started in Multics (since the Bell Labs researchers who created the original Unix had been on the Multics project).

Nitro: A low-level functional language

Interfacing to foreign language data from the Nitro functional programming language

One of the significant weaknesses of most of the modern, type-safe languages is that they have inadequate expressiveness for representation-level data types. For systems programming, data layout is prescriptive rather than descriptive.

High-level Views on Low-level Representations is relevant here, as they describe how to support bit-level data using algebraic constructor forms and pattern matching. However, they don't support bit-level forms on structures larger than a word IIRC, where BitC does.

I guess I should throw this in.