Slashdot Mirror
Behind Menuet, an OS Written Entirely In Assembly
angry tapir writes "MenuetOS is an operating system written entirely in assembly language. As a result it's extremely quick and compact (it can even fit on a floppy disk, despite having a GUI). It can run Quake. Two of the developers behind MenuetOS took time out to talk about what inspired them to undertake the daunting task of writing the operating system, the current state of Menuet and future plans for it."
Are you sure they wrote the entire thing in assembly language?
If we can put a man on the moon, why can't we shoot people for Apollo-related non-sequiturs?
does it run linux?
Does it run Linux?
Oh wait...
It seems their webserver isn't written in assembler.
©God
It's free as in beer, AFAICT, but not open. That seems strange to me.
Menuet64 Copyright (c) 2005-2009 Ville Turjanmaa
1) Free for personal and educational use.
2) Contact menuetos.net for commercial use.
3) Redistribution, reverse engineering, disassembly or decompilation prohibited without permission from the copyright holders.
Probably won't gain much steam with a license like that. Enjoy your obscurity and 3 users.
In today's multi-level cache, highly pipelined CPU environment, hand optimized assembly is not usually the best choice when compared to a good compiler. It's easier for bugs to hide, and small mistakes can cost way more than any possible optimization is going to buy you.
The article is slashdotted, so I'll post a thought without RTFA. I do embedded firmware for a living; assembly programming is part of my job. But unless you have to fit all of your software into a $.42 micro, there's no reason to write all your software in assembly. Typically, you get most of your performance gains by rewriting 5% or less of the software in assembly [Citation needed... :-)]. As for the rest, go with C or higher for maintainability and portability.
6 months from now, a new processor revision will provide enough marginal performance to make up for not coding the other 95% in assembly.
That said, this is a monumentally cool achievement, if academic.
Man, they should, like, totally port that to ARM. ;-)
Fuck systemd. Fuck Redhat. Fuck Soylent, too. Wait, scratch the last one.
*blink*
is that some kind of new super-awesome flexible organic flash memory?
weinersmith
For a more impressive feat, check out the Synthesis kernel written back in 1988. Also written entirely in assembly, and as stated in the linked wikipedia entry, that OS kernel was the "mother of all self-modifying code." It actually handled things like thread scheduling by generating a custom assembly snippet to jump to the correct point in the next thread to execute.
http://en.wikipedia.org/wiki/Self-modifying_code#Alexia_Massalin.27s_Synthesis_kernel
I think I might work on a sequel...
Build a 747 with nothing but stone knives and bear skins...
Hard drive makers, you have my eternal gratitude.
I agree, the major advantages of assembly for that other 95 percent would be negated by a good C or higher compiler that will probably write more efficient and faster binaries than most programmers could using assembly.
I don't get it: why is running Quake an impressive feat? That's pretty much the epitome of a program which doesn't need to be multitasked with anything else.
The "entire" OS isn't written in Assembly (Quake and I think the web browser were not. As a matter of fact, there is a C runtime lib at http://menuetlibc.sourceforge.net/). But certainly the core bits are. The choice for Assembly was to keep the design uncomplicated, not for performance.
"When life gives you lemons, don't make lemonade. Make life take the lemons back!" -- Cave Johnson
...does it run Linux?
The point was to write an OS in assembly, so all of your analysis is irrelevant.
It's monumentally cool, and academic. The point wasn't to have a portable OS, and assembly can be very maintainable if structured correctly.
If they wanted a lightweight, portable OS they would have chosen a different language.
It seems that it is being bashed around here a bit, but I applaud it. They are taking a 'back to basics' approach while implementing modern functionality of a slick GUI.
Since all links in the article submission seem to be slashdotted, an offshoot of Menuet OS named KolibriOS is located at http://www.kolibrios.org/?&lang=en.
I don't think it's dumb, maybe overkill would be a better term. You want the stuff that is frequently used (e.g. the kernel, device drivers, etc.) to be fully optimized and totally bug free. There's no reason for it be 100% assembly. They could have just as easily written most of the UI code with C/C++ then optimized the lower level code with assembly. The work would get done faster and it would have more useful features.
I have to wonder if it is small and fast because when writing in assembly it is easier to resist the urge to add features. Todays compilers are pretty good and can produce pretty tight binaries. However, you can write (and debug) a lot more code in a given time using a high level language.
(it can even fit on a floppy disk, despite having a GUI)
Excellent, but if we're going to measure these things in obsolete technology;
- How many parchments would I need to copy it?
- Could my team of monks transcribe it in its entirety before the Feast of All Hallows Eve?
- If the Germans intercepted a morse transmissions of it, how long would it take them to crack the code and scupper our plans to retake mainland Europe?
Interestingly, their homepage does not tout execution speed as a motivation: "Menuet has no roots within UNIX or the POSIX standards, nor is it based on any operating system. The design goal has been to remove the extra layers between different parts of an OS, which normally complicate programming and create bugs." It sounds to me more like they are fed up with all the clutter and layers of abstraction in a modern OS and want to see what happens if you start with a clean slate. Then again, without open source, the aesthetic appeal of this "clean" approach is limited.
You could fit zillions of virtual Menuets in one single computer...
If it was true that optimizing 5% was enough to get big performance gains in an OS i wonder why most recent ones are slugs on lead diet? Its not all about pure CPU performance, much is about disk and memory footprint which is where i suspect most of the gains lies in using assembly programming. The same routine for altering a picture in Windows might perform just as well as the same routine in for eg. Its just that everything else in a modern OS is written in high level language and the overhead makes it really noticable in the end. Compare reading a floppy into memory to reading and storing 16GB in memory and you get the picture.
HTTP/1.1 400
it can even fit on a floppy disk, despite having a GUI
Those of us who still remember floppy disks should also remember that having a GUI with an OS that fits on a floppy is nothing new. For the most recent example, see the QNX floppy demo. (Was QNX written in assembly?)
I agree. Every time I've ever profiled code, I've been amazed at how much time is spent in such tiny portions of the code.
It's an interesting exercise though. I've only done a little assembler, but my thoughts were that if I did more of this I could get pretty good at it. The trick in any kind of programming is to learn to express *ideas*. I learned several different programming paradigms over the course of my career, and while I'm doing OO like everyone else these days, having tried functional programming makes me a better programmer.
I could imagine doing non-trivial systems in assembler, but mainly if the problem domain and its solutions are very well understood. When you see that 1% of your code is taking 99% of your execution time, you *could* tighten that code and get an immediate payback, or you could try understand the problem better in order to find a more efficient algorithm. If you can improve your algorithms, that's almost always going to be a bigger win.
We've been making essentially modern operating systems (virtual memory, process scheduling etc.) for a long time. If you just wanted to implement the textbook approaches for everything, and didn't care about architecture portability, it seems pretty feasible for a couple of guys to make a reasonably credible OS in assembler, provided they knew their OS stuff and were very good assembly programmers. Obviously the C with assembly for tight loops approach is a quicker path to a usable system, but the fact that they're assembly enthusiasts probably means they'll get more benefit out assembler where it is most useful and less benefit out of C where assembler is least useful than a sane programmer would. And it's always worthwhile to demonstrate the limits of conventional wisdom.
SInce you work in embedded systems, I don't have to tell you that upgrading your processor in six months isn't always an option.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
What's academic about writing an OS in assembly?
There's two guys taking on the (nowadays) unheard of task of writing an Assembly OS, and all people go on about is that you can run Quake on it? WTF ... The last Assembly-OS I used (well, to a big part anyway) was my trusty ol' Amiga ... and it ran circles around many systems that came later with more CPU power ...
Too bad it doesn't have wireless networking support, it looked to be the perfect thing to make older notebook computers useful.
No, a floppy disk is what you get when you leave a DVD in the back window of your car on a hot day.
Ehhh. The whole effort doesn't impress me. There are/were Linux distros that fit onto a floppy. OSs were written in Assembly for years.
If they can demonstrate that "remov[ing] the extra layers between different parts of an OS" simplifies programming and eliminates bugs, then they'll have something interesting. And they can have a flame war with the microkernel folks, who assert that separating the OS into separate parts that are independent and can be thoroughly tested simplifies programming and eliminates bugs.
Abstractions have a purpose; they make it easier to think about things. There are no "Files" or "Folders" (or "Directories", for those of a Unix persuasion) on your hard drive; there are only a sequence of blocks. The Operating System provides the abstraction of files. Various protocols and their implementations then provide an abstraction that "Files" and "Folders" on remote machines are just like "Files" and "Folders" on the local drive.
If abstractions make life complicated for the OS developer, but easier for the user, is it a win? It depends on whether the OS has more developers or users.
Given that most assemblers are macro assemblers, I'd imagine that disassembly doesn't give the original source code back. You get an equivalent source code, but it might be considerably harder to read (depending on macro usage, obviously).
HAND.
You're supposed to RTFA before posting??
There has already been an operating system written in assembly language, which fit on a floppy disc, despite having a GUI.
It was called the Macintosh operating system. (and no, it was not written in Pascal, despite having Pascal calling conventions)
Typically, you get most of your performance gains by rewriting 5% or less of the software in assembly [Citation needed... :-)].
I think you mean Amdahl's Law (that speeding up or parallelizing one task will only produce a speedup limited by the relative time consumed by that task compared to the rest of the code.)
I do think that writing good, efficient C code (for instance) will get you most of the way there -- and in that case, your argument is right. There's still something to be said for developing something like this just for art's sake, though. Why do people admire handcrafted Swiss watches, when they can get a perfectly good timepiece for a few bucks down at the Wal-Mart? Craftmanship, and the skill it implies, are impressive to those of us who know what is involved.
Perhaps (if they could open up the code, and if it has very good documentation), they could use it as an example of how to get things done quickly in assembly. Once you get into the assembly mindset, it *is* fun to figure out a way to run a loop in 2/3 the instructions (allowing your robot to control 24 servos instead of 16, with the same $5 microcontroller).
Paleotechnologist and connoisseur of pretty shiny things.
QNX from mid 90ies was an OS that would fit on a 1.44Mb floppy although not written entirely in assembly.
Among features were win95ish gui, webbrowser, PPP dialer, TCP/IP stack.
I think you're right! Now, what might one call such a tool? A... "compiler" maybe?
HAND.
<ref>Donald Knuth, in "Structured Programming with Goto Statements". Computing Surveys 6:4 (December 1974), p. 267: "Experience has shown [...] that most of the running time in non-IO-bound programs is concentrated in about 3% of the source text".</ref>
Victims of 9/11: <3000. Traffic in the US: >30,000/y
What's academic about writing an OS in assembly?
Actually writing an OS in assembler on a 680x0 was part of my engineering degree. Also had to write a real time multithread scheduler.
Tesla was a genius. Edison however was a overrated hack who liked to torture puppies.
Quake and the web browser are applications, not part of the OS.
"People who think they know everything are very annoying to those of us who do."-Mark Twain
Writing large programs in assembly language is almost impossible, you have to get it perfect first time because refactoring assembler code is next-to-impossible.
eg. Small changes in the base data structures (eg. change a data type) mean you have to go through and change every instruction which references that data, and since there's no type-checking in assembler you can easily miss some and the assembler won't tell you about it.
With a compiled language you can change the data type and you're done.
This argument also explains why C++ is better than C. C++ and OO methodology makes writing large programs MUCH easier than using C and procedural code. With C code you have to keep an awful lot more knowledge in your head at any give time and it's easy to forget things in C that can be done automagically in C++.
No sig today...
academic = It's admirable on an intellectual level but not useful to the outside world.
No sig today...
If they wanted speed, they should have written the kernel in Java.
The very latest JVMs use clever "Just-In-Time" compilation techniques to dynamically re-write the code in real time, without any performance loss what-so-ever, typically giving speed-ups in the order of 50,000% compared to C, C++ and even the very best hand-crafted machine-code from assembler professors.
Typically, you get most of your performance gains by rewriting 5% or less of the software in assembly [Citation needed... :-)].
That sounds about right. I think I might have heard it quoted first by Abrash (in saying that '90% of the speedup comes from optimising 10% of the code' or somesuch) but I'm sure cavemen sat looking at antelope and going "if we put effort into this 10% of the chase we can take the antelope down 90% faster".
Rampant carbon sequestration destroyed the Dinosaurs' tropical paradise. I'm here to help repair the damage.
I guess now is not the right time to announce my OS written entirely in Javascript. It can already play the Bill Gates Pie in the Face game.
Knuth doesn't mention assembly.
I had to write a basic kernel in assembly during my degree.
So I guess that counts as academic.
If alternative OS's are created everyday so one doesn't have to use Windows on their PC, then why in (insert your deity's name here) name do developers insist on imitating the Windows GUI?
It's like saying, "Gee I can't stand the engine in that car, but I sure do love that hot pink base paint, green floral pattern, and crushed red velvet interior"
When I started out assembly programming the 6502 as a kid, I didn't have the cash for an assembler, so I coded with pencil and paper, hand assembled to machine code, and entered byte by byte.
Kids these days...
Of course, what I wrote was a lot closer to Hello World than a GUI OS. :-)
Is it just my observation, or are there way too many stupid people in the world?
The original OS died from license suicide. Kolibrios continues the original OS under an open license.
The "entire" OS isn't written in Assembly (Quake and I think the web browser were not.
How does this get modded informative? Has Slashdot readership sunken so low that the average geek on here doesn't even understand that Quake and a web browser are not parts of the OS?
I was looking around for a floppy today because I wanted to make a boot disk, and I realised that, not only did I not have one, I also didn't know where I could get one, or even when the last time I've seen one was...
I also had to create slides for a presentation for my degree, but that doesn't make it academic.
Hey tards, you do know the 32-bit version is open-source, don't you? Go examine that. But, I bet none of you who are criticizing it being in assembly can even read ANY assembly.
The main gain is the size of the OS, it fits on a floppy! That may cope with some specific industrial needs.
Besides, I'd have made a few routines in ASM then used a good old C program for the rest.
Slashdot, fix the reply notifications... You won't get away with it...
Of course, if they had to integrate Quake with the OS parts, then wouldn't the OS also fall under the GPL like the quake source?
It depends on how one defines "integrate". If "integrate" just means porting to its API, then porting a GPL app to MenuetOS doesn't bring the operating system under GPL any more than porting it Windows. Both GPL versions 2 and 3 have an exception for linking to an operating system's System Libraries.
Wow, it's been since Windows 1.x that I've seen a GUI that looked like it was written in assembly. How retro.
Assuming of course the 1% of the code monopolizing execution time is part of your algorithm (and a part you can improve in the HLL) and not in the 'overhead'. It should go without saying that you are also assuming the cause of the bottleneck is poor algorithms and not a quirk of the compiler or libraries you've linked.
Interestingly, their homepage does not tout execution speed as a motivation: "Menuet has no roots within UNIX or the POSIX standards, nor is it based on any operating system. The design goal has been to remove the extra layers between different parts of an OS, which normally complicate programming and create bugs."
Layers complicate programming and create bugs? Really? As in, "the whole modular programming thing is just a fad"? If these guys can actually honestly claim that they program better in the big ball of mud paradigm, they must be super-geniuses, and trying to collaborate would be impossible for the normal geek anyway.
I would not say 'todays' compilers are any better than older ones. They have more optimizations. But that is at a cost. Even with say an 'new' compiler like from vs2008 you ended up with 7k just for 1 main without a printf saying hello world. In a COM/EXE you could do that with asm in DOS in less than 50 bytes and have the hello world. Now you probably could get that down to 2-3k if you strip it. I have also seen gcc and visual studio (most of them) produce awful code. Many times if you know what the compiler is doing you can rewrite your code to force it to produce the correct ASM. But that takes work too.
ASM has its place that is for sure. But these dudes wrote a whole OS in it which is impressive. Sounds fun. They probably end up with a faster OS just simply because they can optimize right when they write it. They know which registers are free and can be trashed... While a compiler has to look ahead and figure it out and usually guess wrong. The person writing it would already know. The best optimizer is usually the thing holding our ears apart. Most of the time these days it is not needed as much. Also they can use ASM commands a compiler would never emit. Compilers tend to write fairly generic code and only use a subset of the x86 language. Would I write this way? No. I have other things to do and my code is 'fast enough' to get them done.
The one implies the other. It is very hard to write large, structured, maintainable, assembly code. If your goal is to write structured, maintainable, assembly code then you end up with small and simple code out of necessity.
I am TheRaven on Soylent News
The choice for Assembly was to keep the design uncomplicated
Then, so much for 50 years of programming paradigms intended to get a handle on the complexity of software design. I would guess an examination of the code will show it is not spaghetti and that they did at least structure it, and kept code and data separate. And if they did that, then like everything else done in assembler they did the programming paradigms by hand, which seems a bit silly. Keeping the design uncomplicated doesn't seem a plausible reason for assembler.
Perhaps what they're getting at is higher level languages are too dogmatic and wasteful in their implementations of programming paradigms. For instance, I really don't see anything wrong with multiple entry points for a subroutine, though forbidding that by omission has been canon. We certainly have multiple exit points, why not multiple entry? And indeed, a big use of multiple exit points is to dodge around another of the limitations of Structured Programming, that being how to exit from the interior of nested loops without having to wastefully check the same condition at each loop. Yet somehow the cycles saved by allowing multiple entry points isn't worth the trouble. What was the most recent language that had provision for multiple entry points? PL/1?
Intellectual Property is a monopolistic, selfish, and defective concept. It is "tyranny over the mind of man"
I got into Machine Language (not assembly) for a while once and wrote the "bare minimum" machine language (just writing the bytes at sector zero of a virtual bosch HD.)
I recall there was a simple character repeater (print the character the user typed on the terminal) that was like 3 bytes of machine language, something else interesting I could do in 13 bytes, and I could get the machine into 32-bit protected mode in about 35 bytes.
After a while it wasn't too hard to think in Machine language, the assembler symbols weren't really necessary. I recall thinking how cool it would be if I got good enough at it that I could read my own binary as if it were source, so long as I followed consistent patterns (not talking about reading compiler output).
Good times.
No, that's not academic, that's community college.
Chill guys, MenuetOS is not at all a new project - I wonder how it made it to /. homepage *now* - maybe, slow news day (or years, perhaps)? :)
It's been under development since (pre?) 2005.
Also, for all the FOSS fans, the 32-bit version is available under GNU GPL, although, doesn't seem to be maintained anymore (last update being from Aug, 2007):
http://www.menuetos.org/stuff32.htm
The first table on that page gives you kernel + apps sources.
Really, should be fast because of both. It should be more optimized, and therefore smaller while doing task in a more direct (less polluted) path.
Just harder to program in than higher level programs.
I think you can get around this problem, maybe, by creating an 'image' of a floppy disc, then either burning it to a CDROM (using mastering software that knows how to make a bootable CDROM from an image file), or writing it to a usb flash drive?
AmigaDOS from the mid-80s was an OS that would fit on a 880K floppy, and didn't have to be written in assembly to do it.
Among the features were a Macish (unnecessarily so, IMHO) GUI, real-time multitasking, and ... they hadn't invented the web browser yet, that came later. It would run in 256k of RAM but wasn't really happy with less than 512k. That's kilobytes, not megabytes.
Developing a new system today, everyone assumes they're working on an *existing* system with resources and tools. How do you think people bootstrapped systems together in the bad old days? And that's why some of the early stuff took so long, and the pace of change is so much faster now - there's an entire infrastructure available today that was a fantasy when I was in school. Assembler was the course that separated the serious majors from . . . normal people. :-)
Michael Abrash's Graphics Programming Black Book is a great book to really understand the philosophy behind assembly optimizations.
"For well over a decade this meme has been out there and for well over a decade there has been continual performance improvements to those compilers"
For close to a century now, cars have been getting continual performance improvements, and continual efficiency improvements. Does this mean I can run faster than a car?
That said - I have no problem with the idea that there are situations in which hand crafted assembly code will be faster than compiler optimized code. However, most programmers today will not be able to do that, or even identify that it could be done in a given situation. I would bet that the majority people who are paid to write code today have never even written a line of assembly for any architecture.
The Calgary Unix Users Group got a fine presentation over a decade ago on QNX, a real-time oriented OS that was waved about on a floppy at the meeting. According to Wikipedia, the "earlier" versions fit on a floppy, so perhaps no longer true...but the exact size is not that relevant with the floppy itself dead as a doornail.
http://en.wikipedia.org/wiki/QNX
The thing about QNX is that it is a Unix, POSIX-compliant, no less; and in contrast to Menuet being closed, QNX was recently freed up.
Kudos on the assembler work, though... the great Steve Gibson (http://en.wikipedia.org/wiki/Steve_Gibson_(computer_programmer) )
would be pleased
Typically, you get most of your performance gains by rewriting 5% or less of the software in assembly [Citation needed... :-)].
I agree, even without the cite. However, keep in mind that this is in reference to application layer software, not OS layer software. Your OS is going to be doing all kinds of stuff all the time that needs to run as fast as absolutely possible in order for your application layer to have a better slice of the pie.
There is not a good excuse for using anything other than assembler to write the Kernel and hardware drivers, because ANY wasted cycles impacts all other software on the system.
It was called DOS.
I am amazed that in this day and age of bloated EVERYTHING, that someone would write a operating system WITH a GUI and be able to put it on a floppy. I didn't think anyone knew assembler anymore. I thought it died with ADA and FORTRAN.
Kudos to these guys !
Every time you call tech support, a little kitten dies.
Wow, so the criterion to have a great OS is to run Quake?
Windz is great then
The 32-bit version of Menuet was released under the GPL, but the 64-bit version uses a non-open-source licence that is free for "personal and educational use". Why did you decide to licence the 64-bit version differently? Has this had any impact on encouraging people to join the effort?
Ville: With a completely new type of open source project, people seem to have strong opinions about what direction to take. Even up to a point when time is actually spent more with disputes than doing the actual coding. And when that happened, I decided to concentrate more on the original path of Menuet with the 64-bit version and with a new type of license. However, I don't have anything against open source or possibly opening up the Menuet64 source later. But with the current licence, I'd say the people are a bit more committed and willing to put more effort in to a new feature.
You shouldn't call their licence choice stupid without knowing their reasoning, at least.
So it's written in assembly, has a GUI and boots from a floppy? Yup, Apple did it (Mac OS was written in 68k assembly up to System 6)
And no offense but Mac OS 6 looks like it had a more sophisticated GUI than that, colour depth aside.
You just got troll'd!
Mark my words: in five years from now we'll have Menuet on the desktop everywhere!
-- Cheers!
I think you need to chill with us then, because 1) This article is not about the debut of the OS, it is about the "Behind Minuet" interview, which is not exactly the same thing; and 2) Slashdot covered the real debut much earlier than even 2005 (check the date on the article) - http://developers.slashdot.org/story/01/09/05/2248252/MenuetOS-Debuts
I think is this a significant problem with hand-written assembler. The programmer will attempt to give the code structure and simplicity to improve understandability and maintainability, but a compiler will attempt to produce the optimal code regardless of how readable it is. For example, it will unroll loops and move fragments around and sacrifice space for speed. For the bulk of the code, a good C compiler will likely produce faster code than hand assembly.
How about releasing the latest MAME for Menuet instead?
For a sec, I thought someone had resurected the Minnesota Internet Users Essential Tool! I used this for years until I switched over to the Mutt :-)
It reeks of piss and shit.
This may just be the alcohol talking, but man, assembly really gives me a headache!!!
Or like publicly playing covers of simple songs? Or redrawing a simple logo and using it for your own purposes? The copyright is still there. Without the license, you wouldn't (legally) be able to do ANYTHING with this.
That's a straw man argument if ever I did hear one. Both of the examples you cited involve using someone else's copyrighted material to make money, whereas disassembling a program image is much more akin to looking under the hood of your car to see how it works. Clearly, looking under your car's hood is not a copyright infringement, nor should it be - although there are undoubtedly lots of people who would love to be able to impose such ridiculous limitations, and yet more who falsely believe they already have.
The HX DOS Extender for MS-DOS was written 100% using assembly. It is a Win32 compatible API layer for DOS. Source code is available.
Granted, it just thumps to 16-bit BIOS calls, but it does make for interesting study.
C code can be written in such a way that there is virtually no loss in performance over assembly and way more maintainable. I tuned some bitblit operations a long time ago to some graphics chips that were withing 1% of the assembly code performance.
Hopefully it has more than just "Load reg 1 with 0" comments. (hmmm... hopefully it has comments)
What was the most recent language that had provision for multiple entry points? PL/1?
The earliest standardized versions of "C". The entry keyword was removed after awhile. It had provisions, but was never implemented. I guess there just wasn't a real world need.
The design goal has been to remove the extra layers between different parts of an OS, which normally complicate programming and create bugs."
So long as you have a very limited target platform that's doable. The two most important layers are between user & system mode and IRQ processing. The former can be eliminated in "real time" versions in Linux[1], there's nothing you can do about the latter.
I applaud these guys for coming up with competition - Competition Is Good. I don't agree with their approach - Assembly Is An Inefficient Use Of Resources. Close sourcing their 64 bit kernel also seems sort of stupid especially with such a target niche audience and lessons learned in the last four decades.
[1] I can talk about Linux, I think I'm still under NDA regarding the System V/386 Unix kernel.
Haskell is very powerful in its elegance, but it was created to be - and is mostly used for - academic and research purposes. True, the IO Monad allows you to interact with the physical world, but it's seen by many purists as a kludge (unfair, but that's how it is), and I wouldn't want to touch metal with it. Even if you could work around these hypothetical concerns, it's still a fairly niche language and would be very difficult to maintain on a larger scale - there just isn't a big enough interested and skilled community to do it yet.
It's a grand idea, to be sure, but I would think Haskell is the last language you'd pick for an OS. First we need some elegant & powerful, competitively capable Haskell apps. If you can get a suite together that demonstrates the language's potential versatility, then you might have a case for coding some of the higher-level OS stuff.
Meta will eat itself
I also work with large amounts of assembly code for a living.
I've noticed that (mediocre) embedded compilers may generate poor code because many developers write code without thinking about how it would actually be assembled.
I've seen cheap compilers not handle the following type of code well:
for(i=0;i1000;++i)
{
a[i] = b[i+1];
}
Although the processor may have instructions that perform an indirect read and auto-increment in a single cycle, a little arithemetic can fool the compiler into not using that instruction. This leaves the developer with two choices: (1) Rewrite the routine in assembly [and spend 1-2 days unrolling and pipelining loops by hand, etc]. (2) Be a bit more clever and help the compiler out:
b2 = &b[1];
for(i=0;i1000;++i)
{
a[i] = b2[i];
}
The compiler may look at that loop and do the right thing (and use a single instruction that reads and auto-increments versus using several instructinon to read the array element, do arthmetic on the pointer (which can require several instructions on some architectures), and then update the pointer. With such code, the compiler will generate code no worse than a highly skilled person (with some extra time) would have done.