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."
That would be disassembly, which they already mentioned separately as being prohibited. Putting "Point one" and "Point two" in front of clearly incorrect statements doesn't improve anything.
If we can put a man on the moon, why can't we shoot people for Apollo-related non-sequiturs?
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.
for anyone wanting to tinker - it had been forked before they closed it
http://wiki.kolibrios.org/
http://www.kolibrios.org/?p=SVN&kind=dir&loc=/kernel/trunk
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 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.
Writing in a compiled language is easier, faster, and usually has a better set of pre-written functionality, but never, ever claim that it's going to be more optimized. Even with pipelining updates from the compilers that help the look-ahead caches on the CPU, there's very few times that hand-coded assembler isn't going to be faster.
As CPU's become more complex, this is less and less true. For example, even on the PS2, they created a tool called VCL that preprocessed assembler for you for maximum usage of registers, unrolling, and pipelining. It generated better optimized code than 99% of of coders out there could do on their own and at a fraction of the effort to seriously fully optimize pipelined assembler -- not to mention the asm code was much more maintainable since with handrolled manually pipelined code you may have to re-optimize everything if you change a single register or just a few instructions. Also, things like the auto-unroll and auto-register-assignment a were huge time saver (it could unroll a loop NX and allocate NX registers to interleave SIMD operations to hide latencies).
That's not to say that a really great ASM programmer wouldn't do better than VCL, but he would have to work much much harder. You'd have to track all the registers yourself, remember the pipelining rules and latencies for every single instruction, be willing to experiment with unrolling every loop and counting cycles between unrolled (with prologs/epilogs) and normal versions, know all the possible instruction swaps, synchronize the integer and vector pipelines manually, try nearly all possible instruction orders, etc. Certainly an average assembler programmer wouldn't do as well.
Damn Small Linux and Puppy Linux work well on older machines. Give 'em a try.
http://www.damnsmalllinux.org/
www.puppylinux.org/
"This post is an artistic work of fiction and falsehood. Only a fool would take anything posted here as fact."
Score: 4, Insightful
Sarcastic moderation on Slashdot? Fuck yes.
I write bullshit
Yes, Synthesis is very cool. Apparently file buffers were handled with on-the-fly code with the buffer pointer embedded within it, and without explicit checks, instead relying on an unmapped page just past the end and a page fault handler to refill the buffer (at least that's how I remember the author explaining it to me). I believe the author is also the one who original wrote the Superoptimizer.