Behind Menuet, an OS Written Entirely In Assembly 419
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."
It's not FOSS? (Score:4, Insightful)
It's free as in beer, AFAICT, but not open. That seems strange to me.
Stupid license. No thanks. (Score:5, Insightful)
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.
Not the best choice of languages (Score:5, Insightful)
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.
Re:From the license... (Score:4, Insightful)
Yeah I wonder about why they chose that particular license. I mean it's not a commericially viable product, and if it's meant to spur research and development then why not chose some sort of free software license.
Re:From the license... (Score:3, Insightful)
Re:Stupid license. No thanks. (Score:5, Insightful)
Re:That's kinda cool. (Score:3, Insightful)
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.
Re:From the license... (Score:3, Insightful)
Just because a thing is easy to do does not mean one automatically has some right to do it.
Fast due to assembly or fast because it's minimal? (Score:5, Insightful)
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.
Re:Stupid license. No thanks. (Score:2, Insightful)
No software got popular with such a restrictive licence! Heaven forbid they give it away free for personal use, all the most popular OSs are free for all!
(I don't disagree with you that it might seem a pointless licence, depending on what their plans for it are, but I don't think this has much relevance to popularity.)
Re:Not the best choice of languages (Score:5, Insightful)
Having written in assembly on 8048, 8051, 8086 and DEC Vax boxes, I can tell you right now that debugging most of that code was a lot easier than chasing down the side effect from some array overwrite on leaked memory from a third-party library that you didn't even know was being linked into your code.
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.
Go look at the assembler that some of these compilers produce. It's frightening to see the amount of overhead they cost on even simple assignment operations. I saw one compiler (Microsoft's Visual C++) that took a simple x=10; in C++ and turned it into 15 assembly language operations that, had it been coded by hand, would have been one MOV statement. The compiler turned it into conditional conversions for type, did some byte order and range checking on it (for a hard assign to a constant -- rolls eyes) and then finally did the same MOV AX, 0x0a that you would have coded by hand.
Re:Not that amazing (Score:2, Insightful)
Re:From the license... (Score:4, Insightful)
I think only a few of the responders have a firm grip on the distinction between decompilers and disassemblers.
The true distinction is not on the input to these programs, but instead on their output. You can feed a good decompiler some white noise and still get some high level source code.
Re:Stupid license. No thanks. (Score:5, Insightful)
No software got popular with such a restrictive licence! Heaven forbid they give it away free for personal use, all the most popular OSs are free for all!
The only non-free OSes that have have actually been used by more than 5 people actually provided more features than "Can play a 13 year old game fast".
(I don't disagree with you that it might seem a pointless licence, depending on what their plans for it are, but I don't think this has much relevance to popularity.)
Actually it does. Since this is clearly not a commercially viable OS the only segment of the population that might possibly use it would be tinkerers in the FOSS crowd, but they are going to be turned off by the license. There is really no viable reason to run the OS if you aren't allowed to tinker with the source code.
Re:Not that amazing (Score:4, Insightful)
Wow, this thing must have been fun to debug and maintain. And also, must be a challenge to optimize current generation CPUs for, with separate data and instruction caches... No wonder it never gained traction.
Yeah, I read somewhere that that was the reason everybody's given up on the Synthesis techniques today. A shame, in a way, as it was a really cool system.
Re:That's kinda cool. (Score:4, Insightful)
What's academic about writing an OS in assembly?
Re:Not the best choice of languages (Score:5, Insightful)
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.
The GP never made that claim.
Re:What! (Score:2, Insightful)
but i am ..
copied from the linked page
~~ snip ~~
Modern operating systems are written predominately in high-level languages like C and C++. Menuet, however, is written entirely in assembly language: a symbolic representation of machine language. These days many programmers have minimal if any contact with assembly language, but that hasn't deterred the Menuet development team and the result is a slick, compact and super-quick
operating system.
Two of the Menuet developers, Ville Turjanmaa and Madis Kalme, took time out to talk to PC World Australia about what inspired them to undertake the daunting task of writing the operating system, the current state of the OS and future plans for it.
Firstly, what inspired the creation of MenuetOS? Most people would consider writing an entire operating system in assembly language to be a pretty audacious project.
Ville: The original idea for assembly OS came a few years ago when I was browsing the Internet and came across to a page which used a scripting language. And even with my relatively new computer, the short script executed quite slowly. So it seemed like there will always be the need to create a language which uses the last cycles from a new CPU. So I decided to go to the other extreme
end and just use assembly as much as possible.
Can you give me some idea of the backgrounds of the core developers? Do you have people contributing from outside the core team?
Madis: My passion has always been assembly language. As a teenager I started with some programmable calculators where ML [machine language] was the only way to go. Compared to that, assembly is really a breeze and such an elegant way to program.
Menuet
Ville: We come from different countries and with different backgrounds, but most of us core developers have a university background. I've used different programming languages during the last 30 years. From BASIC and Pascal, to C and assembly. And yes, there are people contributing from outside the core team; the MP3 player is one such contribution.
What aspect of Menuet are you most proud of? Are there any parts of the OS that were particularly challenging to code?
Madis: I am very excited about the GUI part because most hobby operating systems go as far as implementing only a command-line type of OS, but with a true-colour, VESA-supported GUI, it differs from all of these and therefore its ideal for games and small graphical demos. The 64-bit register extensions helped me to make a register-only line and circle routines and these I consider my
"u-achievements" that I can be proud of. "Challenging to code?" - I will let Ville answer that
Ville: As for the actual coding, I'm most pleased with pre-emptive scheduling and USB support. Maybe we have also made a small difference to mindsets about what can be done with assembly language.
What next for Menuet? Do you have a timeline for getting to version 1.0? Are there any features coming up that you're especially proud of?
Ville: We need to add new drivers and improve existing applications. Other than that, there are one or two completely new features I'd like to add before hitting the 1.0 mark.
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
Ehhh..... (Score:5, Insightful)
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.
Re:From the license... (Score:3, Insightful)
Tiny User Base. So there's no incentive to be a developer for the platform. Doesn't support UNIX/POSIX standards, so it's not easy to port existing software to the platform. Freely available OSs have orders of magnitudes more users and developers, and far more reference material making them easier to learn. Who cares about fitting on a 1.4 MB floppy when 1 GB USB drives are practically free?
Re:Stupid license. No thanks. (Score:4, Insightful)
Re:Kolibri: a Menuet offshoot (Score:3, Insightful)
How is KolibriOS "based on" Menuet, given than the former is GPL, and the latter is under a proprietary license? Their history page seems empty, and the only description I found on their page is in Russian, which I'm not good in.
Re:Not the best choice of languages (Score:3, Insightful)
Assembly is best for optimizing limited sections of code where your specific domain knowledge can allow you to make optimizations the compiler wouldn't know about. It makes sense in those situations, and that's it. Writing an entire, non-trivial application (or OS in this case) is a waste of time since
And most importantly, for everything except the most critical number-crunching algorithms your app deals with, any performance edge you may gain against a compiler will be so minuscule as to not matter.
Re:From the license... (Score:5, Insightful)
You are all incorrect in assuming that legalese (should|can|does|will) make any sense from a technical point of view.
Re:Stupid license. No thanks. (Score:3, Insightful)
Truthfully, though neat as a "Gee whiz" type of thing, I just don't see much practical application for Menuet.
I recall hearing the same arguments regarding Linux and 386BSD back in the early 90's.
Re:From the license... (Score:5, Insightful)
Re:From the license... (Score:4, Insightful)
I played with Menuet a year or so ago, and it is very impressive how much they've squeezed into such a small space. It boots almost instantly with a responsive GUI and a number of applications. It's not so impressive, however, when you compare it to something like RiscOS, which did the same thing on a 25MHz ARM2 with 1MB of RAM, or comparable operating systems of the time. It does highlight how poor an effort DOS was (although it requires protected mode, so won't run on anything before an 80386), but I think we already knew that.
Re:Stupid license. No thanks. (Score:4, Insightful)
Re:Not the best choice of languages (Score:2, Insightful)
None of the CPUs you mentioned have those features.
Re:Not the best choice of languages (Score:1, Insightful)
In assembler, everything is in front of you.
Spoken like someone who never coded more than a page in Assembly. For larger stuff the right wording would be:
Everything is behind you and waiting to kick you in the ass.
You don't have to worry about side effects? There is no local scope, so in fact everything you do has side effects. When writing Assembly you have to take care of these side effects, which is usually done using push&pop.
This is especially dangerous when you optimize the code. Like when using functions. Usually one pushes every register that function touches at the begin and pop that at the end, so the caller doesn't have to worry about that. Or the caller pushes everything he wants to preserve and pops that after the call. Both are good calling conventions to remove the side effects of a call. Bit both are not optimal. Optimal is to push&pop only those registers that are needed and actually used. But with this a simple change in the function can cause havoc accross your whole code base.
Actually this is also a scenario where compilers perform very well. When the compiler decides to inline a function it takes care of optimal register usage.
Re:That's kinda cool. (Score:4, Insightful)
I also had to create slides for a presentation for my degree, but that doesn't make it academic.
menuet 32-bit is Open Source (Score:2, Insightful)
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.
Re:Not the best choice of languages (Score:5, Insightful)
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.
Just because version n+1 of a compiler is better than version n of a compiler doesn't mean that version n isn't better than a human. Maybe you can do cross-module function specialisation in your head, but the rest of us aren't so lucky.
Re:Stupid license. No thanks. (Score:5, Insightful)
Probably won't gain much steam with a license like that. Enjoy your obscurity and 3 users.
SO what?
At least the they are doing something interesting... Maybe they will find someone who needs a really small and quick OS that is hacker-unfriendly. I'd personally love to see ATM machines running something like this instead of Win2k and XP....
If by some oddball chance they can make some money off their hobby more power to them... Anyone who can code a OS in ASM is ok in my book and you got no room to judge them just because they are covering all their bases. I mean do you really not think some company wouldn't come and grab up all their work and laugh after spitting in these guys faces?
Re:Not that amazing (Score:3, Insightful)
Re:Quake? (Score:4, Insightful)
Re:Fast due to assembly or fast because it's minim (Score:3, Insightful)
Re:From the license... (Score:3, Insightful)
Re:Stupid license. No thanks. (Score:3, Insightful)
At least the they are doing something interesting...
What is interesting or novel about this? There have been numerous OSes written in assembly language. That was pretty much what you did before C came along and even for quite some time after wards. Secondly, writing an OS kernel in assembly was a project that many people did while in school making this pretty mundane to be honest.
I mean do you really not think some company wouldn't come and grab up all their work and laugh after spitting in these guys faces
Since no company stole the work during the years while it was under the GPL, I see no reason why they would have had to worry about it enough to change the license for that reason. Secondly, why would some company want to steal an OS that has little to no features when they could just incorporate the code from a BSD instead?
Re:Should have used Java (Score:3, Insightful)
Re:Not the best choice of languages (Score:3, Insightful)
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 [...]
...start from scratch when someone rolls out a different chip design that obsoletes all your assumptions or when you learn a new optimization technique. I'd much rather write at a higher level and let new versions of the compiler handle updated architectures, and automatically adjust all my old code whenever their optimizers improve.
Re:Not the best choice of languages (Score:3, Insightful)
Well I guess the compilers/CPU architecture have advanced enough that some of your old experience doesn't apply anymore.
Re:Am I hearing you correctly? (Score:3, Insightful)
All of this is just the normal software cycle - hopefully you start with a good design that represents the problems at hand at the time. But eventually the requirements change and the original design becomes insufficient, or outright irrelevant, or muddled by refactoring by people with different designs in mind (or outright hacking), until eventually you get a strong urge to chuck the whole thing and start over - which is what they are doing.
Re:Stupid license. No thanks. (Score:1, Insightful)
Jesus, hundreds of comments all tripping over each other in their clever and insightful notice of the word "disassemble".
Here's a wild theory: the license is copy-pasted.
Re:Stupid license. No thanks. (Score:3, Insightful)
Or you could pop a quick email off explaining what you want to do, and get permission.
Re:From the license... (Score:3, Insightful)
Correct. And then we're also talking about information that can't be recovered by decompiling binaries, so the point is moot.
Once you're done debugging, you don't need the symbol tables any more, yes? We may need the comfort of rich commentary and maintainability, but the system really only needs the instructions, opcodes, addresses, literals and data in the binary code to work. [Decompiled|Disassembled] stripped binaries are very hard to make sense of.
In the olden days, we obscured code by renaming variable and constant names with some variation of "I"'s and "1"'s and "O"'s and "0"'s. Not as effective as adding the "strip symbol table" switch to the compiles, but far more fun, which mattered then. "O000O01I = o0oo0OI1" and variations were good for inducing headache. We took DRM into our own hands in those days.
Ahh, to be a sadistic, bastard developer again. I miss that.