Slashdot Mirror
MenuetOS, an OS Written Entirely In Assembly Language, Inches Towards 1.0
angry tapir writes "MenuetOS is an open source, GUI-equipped, x86 operating system written entirely in assembly language that can fit on a floppy disk (if you can find one). I originally spoke to its developers in 2009. Recently I had a chance to catch up with them to chat about what's changed and what needs to be done before the OS hits version 1.0 after 13 years of work. The system's creator, Ville Turjanmaa, says, 'Timeframe is secondary. It's more important is to have a complete and working set of features and applications. Sometimes a specific time limit rushes application development to the point of delivering incomplete code, which we want to avoid. ... We support USB devices, such [as] storages, printers, webcams and digital TV tuners, and have basic network clients and servers. So before 1.0 we need to improve the existing code and make sure everything is working fine. ... The main thing for 1.0 is to have all application groups available'"
I would argue that as CPUs get more complex and programs get larger, we have probably passed the point where even the best humans can optimize better in general cases. Short contained tasks sure, but even with infinite time humans have limits on how much they can keep track of in their heads. As the tasks get bigger and bigger one relies more and more on notes and whiteboards and other tools, at which point one is basically just implementing an optimized compiler from scratch and calling it 'by hand'.
Back when I first started, compilers were pretty stupid and basically did a 1-to-1 translation of source code to sequences of assembly language. It didn't take much to do better simply coding assembler by hand.
Somewhere about the mid 1980s that stopped being true. The IBM mainframe Pascal/VS compiler generated heavily-optimized code. It was sufficiently clever in its use of machine resources that it was on par with hand optimization.
The clincher, however, was that it could do this job in seconds, whereas hand-coding would take hours. And if you made significant changes to the algorithms you were coding, it would re-optimize each time. It would have been a total rewrite to get code that tight by hand. And even though we didn't have the insane time constraints that modern-day projects typically have, we didn't have enough time to make it worth doing that even to save expensive mainframe CPU cycles.
Back when I was trying to write games, 20 years ago, I figured out pretty quickly to write the important parts in assembly and the rest in C. But not before I wrote a full screen graphics editor in assembly. That was about 1200 lines of awesomeness that took me about 7 months to write. Fortunately, most of the graphic work carried over to the main game itself. Recently, I did a recreation of that work in C#. What took me over 2 years to do in 1994-95 took me a weekend to do now. My how times have changed.
Ah but that depends. Because it's written entirely in assembly, MenuetOS is so small that the entire thing can fit in the CPU cache: most of it in L1 directly. What it loses in things like pipe-lining & branch prediction it more than makes up in sitting in the cache.
You can also do this with DOS & Windows 3.1 on a modern CPU: an i7 has 8MB of cache, which is more than most PCs c. 1995 had in their entirety.
Why?
Well, I'm not well versed with the MenuetOS, but I've written a few toy OSs; Particular of interest to me is 16bit x86 which retains memory segmentation, and via other modes of operation (such as Unreal Mode enabled via addressing line 20) one can escape the 640K and/or 1MB limit whilst retaining other hardware features. Why go low level? Because programming paradigms are platform dependent. C is a product of its Von Neumann environment, and the dialog back and forth between hardware and software designers over the years has shaped our current methodology and hardware feature-set -- sometimes for the worse, IMO. E.g.: When we sacrificed a whole register and its memory segmentation capabilities to the RAM gods we made position independent code far more inefficient, and things like coroutines, stack smashing protections, multi-dimensional V-Tables for stateful OOP (eg: methods that change functionality depending on an object's "state" field), separate stacks for code pointers and parameter data, heap code pointer isolation, etc. more difficult (or near impossible) to accomplish. Instead of ASM I use a low level compilable and interpretable bytecode language for writing my OSs, and have multiple functional C compilers implemented atop the byte-code language in order to utilize existing hardware drivers -- However, I frequently dive into the machine specific ASM in order to implement and explore new features.
I started doing hobby OS work for fun, but after reading Ken Thompson's On Trusting Trust ACM acceptance "presentation" I decided that it would be a worthwhile project to create and maintain a few machines isolated from the rest of the world which are bootstrapped and programmed entirely by me. I now use them to write my memoirs and for teaching children how to code and build custom hardware and robotics -- The parallel port is very simple to utilize without a massive OS like GNU/Linux in the way...
The better question is why would anyone attempt to implement a POSIX OS today? We have working implementations. That feature set is proven. If we want to make advancements in OSs and hardware architectures we'll have to try doing things in different ways. Some of my OSs are cross platform; In one all programs are compiled down to the bytecode form by the VM ASM, or C compilers. The OS itself translates byte-code into machine code ON INSTALLATION, and gives the option to instead interpret a program if its untrusted (or in development, or self modifying) to contain it in an actual sandbox. On 32 bit x86 with more than one bit worth of execution privileges I'm able to enforce at the hardware level something akin to kernel mode at the application level for applications to isolate themselves from possibly untrusted plugins, and allow transparent lazy linking with emulated bytecode modules and optional JIT translation.
For me the aim isn't to replace GNU/Linux or any mainstream OS. The aim is to explore unexplored problem spaces with the hope that any useful techniques may find their way into mainstream usage. Consider Google's NACL and LLVM. I'm not saying experimental OS projects which pre-date them are responsible for their current capability to compile C into cross platform bytecode and compile it into machine code, but us hobby OS folks HAVE been doing just that for longer than their projects have existed. Our experimental niche OS endeavours occasionally blaze the trail towards new features in mainstream hardware and software. Eg: I'm hoping for code pointer isolation and buffer overrun prevention via dual stack architecture, and for the ARM folks to give us more that 1 bit of privilege level so that secure designs other than Monolithic Kernels can be implemented...
To the other commenter above who thinks "decades-of-practice" will allow optimizing compilers to utilize hardware features that are forbidden or don't exist: Ugh, no. I have decades of experience writing ASM and can write or generate much smaller & more efficient position inde
Yes, you might be surprised, since Borland Delphi is often the most efficient high-level compiler for PCs. It's not that useful anymore (because Pascal has fallen out of favor), but it has unbelievably good optimizers.
Peter predicted that you would "deliberately forget" creation 2000 years ago...
That said, I rarely use assembly in professional software development situations when targeting computers and mobile devices. Before addressing your comment let me add one more thing. Learning assembly is important with respect to making you a better C programmer. I'm not talking about understanding the asm code you see in the debugger. I really am referring to writing C code. C code can be written in architecturally specific manners. The code is still portable, yet more efficient only on a specific architecture. Understanding the architecture and assembly language can allow you to write more efficient C code.
Yeah, outside a few rather narrow cases, ...
That is nothing new, this has been true for decades. You have to go back to Apple II and Commodore 64 days to find a timeframe where assembly was appropriate for general purpose software development. I'm referring to computers, not micro controllers and other such environments.
... modern CPUs have just gotten too complicated to write efficient assembly for.
This is absolutely false. The key to writing good assembly code is not trying to out-compile the compiler, that is a newbie thing to do. The key is to leverage knowledge that can not be transmitted to the compiler, can not be expressed in C. This is where the real win is, this is where assembly can still beat C even after a couple of architectural upgrades.