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."
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.
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
Because it would be like banning you from remembering (not even speaking) dialogue you remember from a movie. Its inane.
If we can put a man on the moon, why can't we shoot people for Apollo-related non-sequiturs?
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.
Too bad it doesn't have wireless networking support, it looked to be the perfect thing to make older notebook computers useful.
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...
Also, since when do you have to write your program/os in only one language?
Game developers mix their code all the time. C++ for the main part/glue, assembly for the tight loops and things that need speed-ups, and a (maybe compilable) scripting language like Python or Lua for, well, scripting (bots, map events, rules, etc).
I'd write an OS in Haskell for the main part, and assembly or C++ for the really low level or very speed-dependent stuff.
Any sufficiently advanced intelligence is indistinguishable from stupidity.
If you had read the article you would know that they adopted FASM as their language/compiler, which offers features such as macros. As soon as you are producing source code files to be processed by programs whose work goes beyond simply mapping your instructions to machine code then we are no longer talking about assemblers. As soon as your code starts relying on features such as macros, libraries and other high-level abstractions then we have entered firmly in compiler country. After all, just because you name something as "assembly" it doesn't mean that the step between writing code and generating object code doesn't have a lot of abstraction in between. Just think of HLA for example.
Slashdot, fix your code or at least hire someone who is competent at it to do it for you.
I realize this doesn't actually defeat your point, but still, to quote Linus' newsgroup post introducing Linux, "It is NOT portable (uses 386 task switching etc), and it probably never will support anything other than AT-harddisks, as that's all I have :-(."