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?
Oh wait...
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...
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.
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 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.
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?
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.
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...
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.
Can't put one past you, can they.
Dewey, what part of this looks like authorities should be involved?
I also had to create slides for a presentation for my degree, but that doesn't make it academic.
Citation massively needed. I've poked around briefly in the Quake source code and found nothing like this (although it does make some use of coroutines). And, even if true, the fact that it contains its own threading implementation and doesn't require anything more than the OS than timer interrupts does nothing to counter the grandparent's point. Quake has been ported to Java and, even with the software renderer, ran well several years ago on a then-modern CPU, so it's hardly an example of something particularly demanding on either the CPU or the OS.
I am TheRaven on Soylent News