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!"
Anybody remember GEOS?
That's another OS that was written entirely in assembly... by the time they finished, Windows had ALL of the marketshare...
This sounds incredibly cool, but with all these new OS'es popping up like QNX, AtheOS, and my alltime favorite BeOS. The only problem is, that theres too many showing up, and too little support for them. Sure, this is a great example of what you can do with Assembly, but are you gonna make a full fledged OS out of it? Is anyone working on a brand new OS that they think will actually go someplace? Personally, i'm still holding out that BeOS doesn't sink like the Titanic..
--
Insert Witty Sig Here
An operating system in assembler? Bah! Such high level languages are tools for the weak, macros be damned! You know what I have to say about that? Reminds me of an old joke by Alan Turing : 11100101010100100111010100101010010100101001111 ? 10011010100111011100001 !!! HA!
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?
What crazy reasoning drives a project to write something complicated and difficult in a lower-level language than the current best practice?
The only thing I can think of is the idea that it will be leaner and faster, which are seriously misguided notions given the trend of faster and faster hardware. What we care about now are scalable algorithms, stable and robust kernels and drivers, and appropriate abstractions to allow easy extensions. All of these are made easier by high-level languages. They are made more difficult by machine language.
What I'd like to see is a powerful kernel mostly written in a very high level safe language like O'Caml or even Java. That would be a feat with some important consequences.
...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.
...does that mean it'll be a pain in the ass to fix "LENGHT" to "LENGTH" in the editor picture on the website?
but seriously, this is pretty sweet. i'm going to load it up at work tomorrow.
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
From the GPL: "The source code for a work means the preferred form of the work for making modifications to it."
Guess that means he has to distribute the C version, too.
ok then your [sic] infringing on my copyright! Could you as [sic] me next time before STEALING my comments for your own?
Well.. just a thought..
:)
Was trying to think of maybe how this would be good for anything other than rootdisks and novelty value.. and then i started thinking.. well.. 44-khz stereo sound, workable gui, MIDI support..
I can't get the thought out of my head that something-- maybe not this specific OS, because this specific OS is tied to the x86, but maybe something patterned on the same general system design-- like this would maybe be actually useful as an embedded OS for a sampler.
Am i just completely on crack, or would a sampler/synthesiser with a small lcd screen and an os like this one be as cool as it seems to me it would be?
Then again, any really cool stuff you could do with such a system-- say, letting you program your own midi synths in realtime-- would *demand* that it have an interpreter for something more high-level than assembly built in, and doing, say, a LISP/Python interpreter in an environment written wholly in assembly could maybe get messy. Maybe we'd rather have an OS written in LISP in our samplers....?
Oh, the hell with it. Forget i brought it up
Irritable, left-wing and possibly humorous bumper stickers and t-shirts
Write it in VBScript. You can create the first OS that can be installed and redistributed by clicking an e-mail attachment.
Ok, most of the responses to this so far have been "assembler doesn't give you that much improvement" , "assembler is a bad way to do things if you're trying to do them The Right Way".
:)
Well, why can't he use asm? If I want to write an OS is BINARY that's a cool-ass hack, even if it is not The Right Way to do it. Come on guys, give the guy a break... he did something *awsome* and something probably 98% of us can't do (I know I certainly can't) and he should be credited for that. I'm not saying that this OS is something that should be taught in OS design courses, but it's still very very VERY cool
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.
An OS from Finland? Does this come from the frozen small hellhole next to North Pole? Do they even have electricity there? World domination? Yeah right. Won't happen in a million years!
...said people 10 years ago and went on with their life. Boy, were they wrong.
Never underestimate an OS that comes from Finland.
You could get the asm out of the binaries, but it would lose all formatting, comments, macros, separation into different files, and various other things. It would be *very* hard to read; not at all the "preferred form of the work for making modifications to it."
main(c,r){for(r=32;r;) printf(++c>31?c=!r--,"\n":c<r?" ":~c&r?" `":" #");}
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
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.
You know, maybe that's true if you have a genuine 80386 or -486 chip, but with the "Family 6" of Intel processors (p 2, 3, and 4), customized compilers produced by the manufacturer know WAY more about the particular branch predicting and out of order dispatch, to name just 2, than any novice ASM hacker.
The problem is we don't really deal with the fundamental instruction set of the processor anymore. The intel family 6 and the AMD K6 and 7 are super-pipelined beasts which re-implement the x86 instruction set by basically having a front-end block transform those macrocodes into custom micro-ops.
So you probably still CAN produce faster code with an assembler than, for instance, "gcc -o2," but you'd better have the block diagram for the processor sitting around to guide you, and that's not exactly a task for the novice. And I'd still be willing to bet that your margin over a manufacturer's custom compiler would be razor-thin, at best.
Plus, there is also the inherent "beauty" of well-designed ASM code that most high level languages will never reproduce.
Well, that's an aesthetic choice, and I'll let you have it, but I'll take the inherent "beauty" of well-commented C code any day.