A new release of the 64bit version of MenuetOS has been released, MenuetOS 0.64. “MenuetOS is an operating system in development for the PC written entirely in 32/64 bit assembly language, and released under this license. It supports 32/64 bit x86 assembly programming for smaller, faster and less resource hungry applications.”
I think MenuetOS was one of the first things I saw on OSNews (if it wasn’t the project that led me to OSNews in the first place)… Fitting an entire modern OS, written in assembly of all things, onto a single floppy is a pretty incredible deal. They just don’t make ’em like that any more.
Of course, now there are two; the focus on MenuetOS seems to have shifted to the 64-bit version, and there seems to be active development of a 32-bit fork called KolibriOS. http://www.kolibrios.org/
After K&R finished porting their early UNIX OS from PDP-7 to PDP-11, they vowed never to repeat this effort again. They rewrote UNIX using their brand-new high-level language, called C. The ability to easily port UNIX to different architectures and the ease of development revolutionized operating system design and implementation. UNIX introduced a number of successful design elements, but there’s no question that the most successful of them all was the C programming language.
To this day there exists a need for assembly in operating system implementation, such as context switches and kernel entry points. And there’s certain critical code paths that can benefit from hand-optimized assembly, such as locking routines. But what is the benefit to writing a whole operating system in assembler? A decent C compiler generates highly optimized–and obfuscated–assembly. Hand-coded assembly may be cleaner, but it’s also likely to be less efficient.
Coding only in assembly will tend to produce smaller code. Not only are features much more expensive to implement in assembly, but hand-coded assembly is generally smaller than compiled assembly. However, small code isn’t always fast code. Your average Gentoo ricer will note that exotic CFLAGS produce bigger binaries. Loop unrolling, vectorization, jump tables, etc. are commonly used by compilers, but assembly developers forgo such optimizations in favor of maintainable code.
Speaking of which, the MenuetOS homepage claims that one of their design goals is to eliminate “extra layers” that complicate programming and create bugs. But layers simplify programming, and developing in assembly seems much more error-prone than developing in C. They should be more honest about their trade-offs. They’ve made programming much more difficult and error-prone in order to make their OS smaller and possibly, although not necessarily, more efficient.
Don’t get me wrong, it’s an understandable intellectual exercise. But it’s not as if the goal were to prove that one can develop an OS in assembly. That was well established in the 1960s, and neither assembly languages nor operating systems have changed in such a way since then that would challenge this notion. What has happened in this time period, though, is that higher-level languages have emerged, and operating systems have become much more feature-rich.
When is a project going to come along that understands that the inexorable march of progress demands new language technologies, not a reversion to older ones? If you’re going to develop an OS from scratch, why not use a modern programming language like D?
One problem with your disagreement with the use of Assembly to write an OS is the fact you write as if Assemblers have not improved over the years too.
While I agree it is harder to write complex code in Assembly vs ‘C’ as an example. It is also true that it is a lot easier to write that complex program in Assembly today than it was 20 or more years ago.
Just the fact that they have a handle on writing a 64 bit version to proves that.
I remember having to write helper tools in assembly to do keys jobs before I could write my own programs. Those tools and more are standard now.
Earl, you are terminally confused. MenuetOS is plain assembly. No highlevel macros or clever tools are used (thank God!) Just browse the svn trunk and see for yourself. They are simply excellent assembly programmers.
HOWEVER.
I think their “kernel.asm” is a good indication of why smart people stopped writing operating systems in assembly code 30 years ago. It’s a 120K of *very* hard-to-maintain code that really doesn’t do much functionally. 80% of the code would be wisely delegated to the compiler (faster, and you wouldn’t have to maintain it, and most likely bugfree).
With the typical 5-10 bugs per 1000 assembly line (and these bugs are harder to track down than in C), the red lights should start to blink and bells ought to whistle loud and clear.
“””
While I agree it is harder to write complex code in Assembly vs ‘C’ as an example. It is also true that it is a lot easier to write that complex program in Assembly today than it was 20 or more years ago.
“””
I’ll stand by for MS Assembler Studio 2008, then.
With the advent of synthetic fibers like nylon and polyester, I imagine there are some kickass buggy whips out there, as well.
You make some valid points, but you’re missing something: the fun of making things the way you like
Granted, it might seem like a pain for some of us, but if these guys like to write an OS in pure assembly, I’m all for that. I’m not (too) oldschool, but I find this project absolutely amazing
Keep up the good work!
Edit: typos, what else…
Edited 2007-07-06 02:14 UTC
But layers simplify programming
Subjective. What appears to be simple layers for one programmer can appear as a road block or speed bump to another programmer.
I have done enough programming myself and been around enough other programmers to know that people analyze and attack problems very differently.
They should be more honest about their trade-offs.
Just as you need to be more honest about their advantages.
I am old school and to see this OS written in pure assembly language is amazing!!!!! Good job! Keep it up!
-2501
Yeah i agree, it may be terse, difficult to maintain and a bit obtuse on the reading front but it sure is cool … Bah, bugs … If they can write an OS in pure assembly then they can iron out a few gubs ;-0 …. go on sons !!
Last year I wrote some code to be “fast” from the ground up. Basically I added in some memory pointers for extra optimizatoin. Made the code a bit more complex and I thought, faster.
A few weeks ago I ripped out the extra code and made the implementation much simpler. Turns out the simpler code was faster.
The issue ended up being: The algorithm penalty changed because of hardware. The extra overhead of the pointer structure with the added lookups ended up being a bigger bottleneck than just running the extra instructions. Interesting what 5 years does for hardware.
Anyways, my point being that the added overhead of keeping assembly going likely may follow the same pattern. With assembly being harder to maintain than higher level languages there’s a good likelyhood that they could be hand optimizing themselves into slowness.
Doing things smarter ends up beating out doing it “faster” at least 80-90% of the time, especially when it involves algorithms.
More than 20years ago, it was pretty feasible to optimize C code and rewrite in assembler and get 5-10x speed ups, the reasons were obvious. Compilers were still weak and the code they emitted was obviously bloated. It was almost embarrassing that a link list chain jump could generate 50 opcodes when the hand written asm could be 5 opcodes using just the right 68K codes and address modes not normally used by the compiler. I did that on a major Mac app and got real awesome performance improvements, but I also got stuck, the scope of the project could not advance anymore, too many global dependencies. The compilers then didn’t really handle inline or mixing asm code, it was all or nothing. Then OO came along and c started looking old.
Today x86 compilers are embarrassingly smart and generate code that is mostly better than I could ever dream. Even if I could write better smaller code, that wouldn’t mean it would actually run faster. Processors have evolved to the point that code speed can not be easily estimated by examining the emitted code. What matters is how much real work the code is doing rather than the actual instructions used to do it. Asm can still beat C hands down only by being smarter about what needs to be done, but its very hard to stay on top of it.
In a sense, MenuetOS rewritten in plain C would likely run almost as fast and be 10-20x less readable code base, that would allow much faster algorithms to be tried out. It might even get bloated and take up 2 whole floppies instead of 1. When was the last time anyone used a floppy here?
If all of the stuff that we were told in computer science class was true, then modern software would be smaller, faster, and much more maintainable than it was 20 years ago. At best, only one of the three is true (maintainability). Those wonderful hardware engineers simply made the smaller and faster bits irrelevant so nobody cares that they were told over-generalised falsehoods.
If a bunch of guys want to do something differently then let them and learn lessons from it. Some lessons will be old and others new.
Having been around computers for 30 years; machines now have astonishing specifications and yet the user experience is rarely quick as it should be. These guys are frustrated by that contradiction, and so am I. If they choose to get on and create then fine by me, it beats moaning every time.
Finally, as for assembler performance; if their algorithms are small enough to live within the Level one CPU cache then it will take one heck of a C, C++ or C# compiler to out perform them.
“Finally, as for assembler performance; if their algorithms are small enough to live within the Level one CPU cache then it will take one heck of a C, C++ or C# compiler to out perform them.”
Good compilers are very much cache aware (turn on -O2 and the correct -march — whoo-hoo)
The guys do that because they like assembler.
In linux it is easy to find overbloated multi megabyte console tools doing very simple things.
gnu as – 600KB. Insane (for such a featureless app)!
The whole AmigaOS will fit in this size.
I think the fact that is OS is written in assembly is just plain cool. Congrats to the team for the hard work so far.
My question is this – where is the documentation that describes what the OS does, or can do? I didn’t see it in the very, very short FAQ. I would expect this would be a top link on the web site. Did I miss this?
Thanks.
Taken straight from the front page of their site:
i guess it is all about fun and satisfaction one could obtain when programming an operating system using assembly language. maybe C & C++ could do the job and do it faster, but if it doesn’t makes programmer felt satisfied, wat is the point?
after all, each of us just have one golden ticket on this earth. when times come, everybody must say good bye, so, make sure it is fun !!
That’s for wimps. Real men write their software in pure binary*.
Seriously though, I fail to see the point of this beyond an interesting hobby for bored assembly coders – computers are now powerful enough that they can run highly inefficient, interpreted, managed code more than fast enough for most applications, 250GB+ hard drives can be had for a pittance, and a 1GB USB stick is cheaper than a dozen floppies.
It is certainly impressive though, for what it is.
*IIRC, and I may be wrong, a few small parts of the original Amiga OS were written in straight up binary. Pretty hardcore way to squeeze out some optimisations, but then you need every optimisation you can get on a 7MHz CPU. You don’t however, need them anywhere near as much on a 2.6 GHz Core 2 Duo or an Athlon 64.