Slashdot Mirror
MenuetOS Debuts
Eugenia Loli-Queru writes: "OSNews is hosting an interview with Ville Turjanmaa, the creator of the Menuet Operating System. Menuet is a new, 32-bit OS under the GPL and it fits to a single floppy (along with 10 or so more applications that come as standard with the OS). It features protection for the memory and code, it has a GUI running at 16.7 million colors (except with 3Dfx Voodoo cards), sound at 44.1 khz stereo etc. And the most important and notable feature? The whole OS was written in 100%, pure 32-bit x86 assembly code!"
Ville Turjanmaa: Parts of Linux was rewritten in assembly and the speed gain was 10-40%. That will give an idea.
I don't mean to flame here, but one of the first things you learn in a computer architecture class is to "make the common case fast." The parts of Linux that were rewritten in asm that improved performance by 10-40% were most likely primitives that were executed hundreds of times a second - like bcopy() and maybe some parts of the VM subsystem. Ville's response draws no distinction between rewriting bcopy() in asm, and rewriting printk() (which is slow, but rarely executed) in asm. Unfortunately, I see no point in rewriting them both if it's not necessary. Sometimes it matters but often it doesn't.
The space advantage to hand-optimized asm is clear, but the cost in portability and time almost certainly outweighs it. I really don't see what this OS offers that Linux doesn't have.
-all dead homiez
From the FAQ:
And the benefit of asm coding is that if you make a mistake in programming, you notice it immediately. You dont get warnings, things just wont work.
Anyone else have serious doubts about this thinking?
...to those of you who ask "How many OS'es do we need?"
Think about when linux first came out, and everyone said "How many frickin' OS'es do we need? We've already got DOS, MacOS, and Unix (variants, etc.)"
New OS'es are good for the market, people! They provide a fresh perspective on the way things should be done and facilitate ingenuity and competition. They may not all become famous or provide new tools or inventions to the OS market, but some of them do - and that's exactly why we need 'em.
In that light, i must say i've yet to see someone bitch "Jesus, how many different types of cars do we need?"
"It is seldom that liberty of any kind is lost all at once." -David Hume
The speed up achieved by writing the whole OS in assembly isn't much. you just can't compare it saying parts of linux was written in assembly and that got 10-40% speedup. That doesn't mean it'll scale up in propotion.
Turjanmaa doesn't even have an estimate on how much speed up he's achieved. but my guess would be not more that 10% over linux. cuz the most accesed part of linux is already in assembly, so you won't have huge speedups.
Actually, if you had a couple of years of experience (ie non-university) CompSci or EE under your belt then you'd realize just how correct the original poster is.
Saying that it simply won't work and therefore is easier to debug is foolish on a grand scale. If anything, writing in assembly code gives you FAR more failure modes because you don't have a compiler which is running at least some sanity checks on your code. If anything, you'll find that it is higher level languages that "won't work" and assembly code that will do something obscurely weird when you trash the wrong memory address.
If there is anyone humiliated, it should be the previous poster who obviously has no idea about the complexity added in writing something directly in assembly rather than a higher level language. All you end up doing is trading portability for increased development time. There is even no guarantee that the code will run faster - C compilers are pretty good these days and can do magical things with intrinsic functions with superscalar scheduling.
To sum it up, YES!! You are not 100% correct. You are actually 100% incorrect.
Fear: When you see B8 00 4C CD 21 and know what it means
MenuetOS has been floating around for a while now. I briefly looked at the website a while ago, it looks tres cool, but I don't know much about it. Even without knowing the details, I can say that for a hobby project, this is a staggering accomplishment. As well, there other operating systems in development that are 100% ASM, Unununium comes to mind. http://uuu.sourceforge.net/
:)
The fact that the operating system was made in ASM is bringing up the low-level language versus high-level language war. I will admit that Linux and MenuetOS aren't really comparable. But ignoring differences, the end result: MenuetOS makes Linux look MEGA bloated, slow, and laughable. You guys should be taking 2nd, 3rd, and 4th looks at QNX RTP, BeOS, and AtheOS. This should serve as a big kick in the ass for you all Linux-fans. It's really nothing "that great." Sure it's free, but you sacrificed quality.
People claim that C compilers can generate code that is similar to what an ASM programmer is capable of. This is not true. A well-planned and pain-stakingly optimized C program can approach a novice ASM programmer. But this is almost never the case. Plus, there is also the inherent "beauty" of well-designed ASM code that most high level languages will never reproduce.
Anyway, I could go on forever. If you want to address anything I said, I am ready prepared for retaliation.
Sure, there's a plethora of other OS choices these days, but a small, efficient, graphically based OS would lend itself very nicely to the embedded / handheld market.
Sure Linux is cool, but once you slap X on top of it, it's not nearly as efficient on slow machines.
Who knows... you could have a Menuet based PDA or phone next year.
MadCow
I used to have a sig, but I set it free and it never came back.
What about the (IMHO) famous programmer Steve Gibson, author of Spinrite (sorry /.ers, may be before your time) who writes all his stuff in assembler? His utilities and more would easily be fit onto a floppy disk - even though some use the Windows API (AFAIK). This dude is a guru to anyone using and appreciating the x86 platform! When MFM hard drives were all we had, he provided us a way to keep them working well beyond the MTBF the manufacturers had planned (or promised). A purist beyond belief - and a blowhard in rhetoric, (if you check out his website), yet, a genius in assembler (we're not worthy!)(sorry; tried for a link and was overwhelmed)
Can you say "change my interleave without FDISK first?"
This guy rules! Don't forget him! He's at least as important as Peter Norton. Maybe more...
db
Cig:
ôô
The point here is not whether it is "proper" to code an OS in assembly - it's been done for years. The point is that if one is to write an OS nowadays, and they choose to do it in all asm, they are doing it for the sake of doing it.
100% asm does NOT buy them improved coding efficiency or improved maintenance or debugging (I've yet to meet an asm coder who can write as much as fast as a mediocre C programmer). What 100% asm does, is make them feel special. That sounds derogatory, but it's not.
Chances are that the world doesn't need a new OS. Chances are that he didn't do anything revolutionary or groundbreaking. Chances are that he will never make a red cent off his OS. Chances are he had a great time doing it.
I've written an OS from scratch. It's hard. My OS is nothing special or groundbreaking, heck it barely DOES anything. Did I do it? yep. Did I have fun? yep. Did I learn a lot? yep. Did I do it in 100% asm? nope. I'm not that good at asm, and truth be told, I don't care THAT MUCH. I like C. C is a good language for an OS.
If this guys likes writing and debugging asm, then more power to him. But let's not mistake this for a decision about "properness" or even pure efficiency. He did it beacuse he felt like it.
If you have a high degree of control, it does not necessarily mean you will make proportionately more errors if you know what you are doing.
Knowing what you are doing is actually most of the problem with assembly coding. Remembering where on the stack you threw things, figuring out calling conventions, string handling, collection classes and other icky stuff that if you have a decent C++ compiler with a nice STL library you are going to be far more efficient. I admit there are plenty of times I drop down from C++ into assembly for debugging of a program, but very rarely to actually write code (why isn't there a 'bitwise rotate' operation in C?).
To be honest, I find it easier to debug an ASM program.
How complex a program are we talking here? I'm used to working on projects that are in excess of 100,000 lines of C++ code. That easily translates to well over a million lines of assembly and probably closer to ten million once template expansion has taken place. I defy anyone to take a non-trivial program and say that the ASM code is easier to debug than the C code - of course using an IDE which allows you to view variables, stack traces, commented assembly and edit and resume the program on the fly helps a lot.
You write the code, you know what precisely what is going on.
I debate that of any programmer - especially in assembly. The limited syntax and complete lack of any high level data structures make it a nightmare in the end.
C compilers can (depending on the programmer) generate some really impressive, logical, clean code - but not usually something that can compete with an ASM programmer.
Ah, but the point is that fast assembly code is neither logical nor clean. You deliberately move loads up the instruction stack, precompute results that you may not use for many cycles, drop stores in (for zeroing memory) now and again when you have a pipe free and do it all differently depending on your target architecture (P5, P6, K7, P4 etc.) If you have a chance, look at the output of Intel's VTune compiler at some stange with all the optimizations turned on - you'll find the assembly unintelligible but faster than you thought possible.
Just curious - are you talking strictly x86 here or do you believe that this is valid across all CPU architectures? Have you any real plans to try to write faster code than a compiler can on IA64 - if so, I'd be interested on hearing your strategies.
Fear: When you see B8 00 4C CD 21 and know what it means
kudos to the pure hacker soul that made the 100% asm OS. all praise to him. i am impressed.
what hurts me, on the other hand, is the justification for it: faster code. i see a lot of badly written code in my professional life - and a sizeable portion of it suffers from one of two related syndromes:
1 - the "i am super-smart" syndrome. people think they are super smart and to prove it they write code that is very hard to understand. the gain is sometimes a loop that gets executed n - 1 instead of n times.
2 - the "early optimization" syndrome. the common but false conception that a program is fast if all it's part are really fast. never mind that there may be another solution with fewer parts.
both syndromes lead to error prone code: code that is both hard to get right in the first place and hard to debug later on. my current strategy of dealing with bugs in code like this is to completely throw it out and rewrite it. good code is simple, or, to paraphrase einstein, good code is as simple as possible, but not simpler.
the other experience with slow vs fast code i have is that slow code is always - yep, 100% of the time - the result of bad design. so using asm will not fix the problem.