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'"
ASSembly language? This OS will run as slow as frozen mollasses.
I want my computer to run FAST!
I want an operating system written in Java, running on a java interpreter written in java [add recursion here].
Java is faster than C, so logically, java must be faster than ASSembly. More java == more speed.
Lets get to it!
Because
* It's fun?
* They can?
* They want to?
* To learn something?
I'm sure there are a few more. Does anyone have not-boring questions?
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
Nah, main thing is to find a working floppy disk and drive.
Why would someone want to do a rewrite of Minix 20 some odd years ago?
"Don't meddle in the affairs of a patent dragon, for thou art tasty and good with ketchup." ~ohcrapitssteve
Compilers can never optimize better than the *best* humans, operating without time constraints. Very few programmers have that level of skill, or the time to spend on the task. That's why optimizing compilers were invented.
*Because someone should remember how to do this?
Oliver's law of assumed responsibility: If you're seen fixing it, you will be blamed for breaking it.
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'.
Neither. That's why we write things in assembly.
Ascalante: Your bride is over 3,000 years old.
Kull: She told me she was 19!
"MenuetOS is an open source"
Not the x64 version, which is the version that's actually worth a shit.
Still waiting on Serviscope_minor to wake up to fucking reality and realize that Jessica Price isn't going to fuck him.
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.
Because * It's fun? * They can? * They want to? * To learn something? I'm sure there are a few more. Does anyone have not-boring questions?
* he's following in the great Finnish tradition of writing your own OS... :-)
As someone who has spent a lot of time optimizing assembly code (17 years in the games industry) I can tell you this:
As the number of CPU registers increases it gets harder to beat the compiler. It's not too hard to better x86 compiler output. It's pretty difficult to improve PPC code.
What assembly optimization gives you is a significantly better understanding of the data flow. Since all CPUs are memory bandwidth bound now knowing where the memory accesses are allows you to restructure the data to make the algorithm more efficient. You also must understand what the compiler is doing to your code so that you can make in access your data as efficiently as possible.
To conclude, you can beat any compiler by hand, so long as you have more information then the compiler has.
Three points:
1) Compilers vs Humans
You have to start by doing an apples-to-apples comparison. Yes, many developers these days are ignorant of low level details about assembly language, and would therefore not produce assembly code that is as good as what comes out of a compiler. But that is because the compiler isn't built by your standard run-of-the-mill code monkey. They are built by people who truly understand the issues involved in creating good assembly language. So you need to compare assembly created by a compiler vs assembly created by someone who is at least as skilled as the people who created the compiler. In such a comparison, the humans will generate more efficient code. It will take them much longer (which is one of the two reasons why we have compilers and high-level languages), but they will generate better code.
2) Why write assembly language
No, one does not write assembly language for "fun" - there are specific business reasons to do so. Replacing inner loops in performance-critical loops with hand-coded assembly language is a common example. Most major database companies have a group of coders whose jobs are to go into those performance-critical sections and hand tune the assembly language. Would I try to write a GUI using assembly language? No, because it simply isn't that performance sensitive. Choose the tool that fills your needs. Religion about tools is just silly.
3) Out-perform C
No. Given coders of equal skill, all of the common high-level languages (Java, C, C++, etc) are identical in terms of CPU-intensive performance. That's because the issue is more one of selecting the correct algorithms and then coding them in a sane manner. It is demonstrable that Java can *never* be more efficient than a corresponding C program because one could always write a C program that is nothing more than a replacement for the standard Java JVM (might be a lot of code, but it can be done).
The place that one starts to see differences in performance is in the handling of large data sets. Efficiently managing large data sets has much more to do with management of memory. Page faults, TLB cache misses, etc have significant performance impacts when one is working on large data sets. Java works very hard to deny the developer any control over how data is placed in memory, which leaves one with few options in terms of managing locality and other CPU-centric issues related to accessing memory. C/C++ gives one very direct control over the placement and access of objects in memory, hence providing a skilled developer the tools necessary to exploit the characteristics of the CPU-CACHE-RAM interaction. It is laborious, to be sure, but C/C++ allows for that level of control.
So it all boils down to what one is implementing. If I were implementing a desktop application, I would probably use Java. The performance demands related to memory management are typically not very great and Java's simpler memory management paradigm streamlines the development of such applications (not to mention the possibility at least of having one implementation that runs on multiple platforms). If I were implementing a high volume data management platform, I would use C++ because the fine grain control of memory management provides me the necessary tools to optimize the data-intensive performance.
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
"Help! Help!" she cried.
Most of them all just walked by, ignoring her. She might be jaw-droppingly gorgeous 36-24-36 redhead with pouty lips in a light dress, but she was clearly crazy, waving that weird plastic thing around. "You!" she urgently growled, as she seized a suited man's lapels. "Can you help me read this? It's the only copy!" This looked like a successful man, so surely he could afford a decent computer, right?
He blushed. He wanted her, and maybe could use it to get her back to his place, but the lie would eventually come out. And this woman had just the sort of sincere bearing, that he knew the lie would be punished, not accepted. He sighed. He glanced at the disc again, just to make sure what he was seeing, and sighed. "No. Sorry. What is that, anyway?"
She let go, and cast her glance around the crowd.
And that's when it happened: Drinkypoo. The moment she saw him, she knew. This was the one. She didn't even have to ask, because she knew. But she decided to ask anyway, so that he could have the pleasure of saying yes and offering to help. It would be the first of many pleasures that he would experience.
"Can you read it? There are some really important files from the 1990s on here. I've got to have them. I'll do anything, Drinkypoo. Anything."
There was a time when Drinkypoo would have grinned nervously, or asked followup questions. But by now, he knew the story. He didn't want to hear the story anymore; he just wanted the reward. Drinkypoo didn't so much as even glance at the disk. Why so many unbelievable hot women always had invested in LS120s and floppies to store their critical records, he didn't know. Maybe some freak effect of a one-shot Imation advertising campaign, long ago. No one even really knew why, for sure; they just knew that a shitload of the drives had somehow ended up in the possession of that demographic.
He squinted and recalled his depleted inventory. That blonde with the 1.4MB floppy from two nights ago. "Got to stop at the drugstore on the way. C'mon," he replied. She stuffed the disc into her purse for safekeeping and they walked to his car.
Half an hour later, at his place, she sat on the couch, nervously clutching her purse containing the precious disc. Drinkypoo sauntered over, and held out the glass of rye bourbon on ice. "Here, relax. Everything's going to be okay." She sighed with relief, set her purse upon the coffee table, accepted the glass and sipped. "Thanks."
"You can't imagine what this means to me," (though Drinkypoo actually knew very well), "I need those files so badly." She reached for his belt buckle for a brief moment, but paused. "First things first, though, I suppose."
Drinkpoo shrugged. What did it matter to him? It would all work out the same. This was going to be fun no matter which order things occured. "Sure." He walked over to the computer desk and nudged the mouse, waking it up from sleep, casting monitor light across the room. "Let's have the disc."
She smiled, and reached into her purse, pulling out a .."
[CHOOSE YOUR OWN ADVENTURE:
1) .. gun.
2) .. Zip or Jaz disc.
3) .. 3.5" floppy or LS120 disc. (Drinkypoo, it will cost you 0.01 BTC for me to write this version.)
]
"Believe me!" -- Donald Trump