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 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.
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.
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.
Quake is a highly parallel program with dozens or hundreds of threads running at once just to support its physics, AI, and player control operations. The original DOS version brought its own threading library (compiled in); as Quake was written on more modern OSes and ported to DOS, the original implementation used OS calls while the DOS version used an application-level thread manager.
Support my political activism on Patreon.
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?
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.
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.
<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.
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.
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.
you fool! Java's 50,000% speed increase in respect to C, C++ will never overcome the benefits of programming in FORTRAN!
Real programmers program in FORTRAN! It is the perfect and most complete programming language! FORTRAN is simultaneously the language of the future AND the past!
Anything C can do, FORTRAN can do better AND automatically! FORTRAN will take us to new heights as a human race!
FORTRAN will make your computer do work before you even think 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.
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.
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
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
I know this is being sarcastic, but if you are doing huge amounts of number crunching you are better off writing it in FORTRAN as it will be faster.
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!
Whoosh. The point of doing number crunching in FORTRAN is that FORTRAN does not reorder expressions. This is critical to maintain accuracy in certain computations.
Who cares how fast it is if you come up with the wrong answer?