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
Masochism?
putting the 'B' in LGBTQ+
But did it support USB, TV tuners, and webcams?
Yes it did! GEOS supported all the existing USB TV tuners and webcams of its time.
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'.
I know you're joking, but when you write straight up assembly all the optimizations are up to you, and the fastest way to schedule instructions can change a lot between CPUs. While it probably isn't awful slow, it's also probably not as fast as a compiler-optimized C-based equivalent would be, and maybe even a Java one.
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!
And most command-line-only Linux distros are still several orders of magnitude larger than Menuet, which actually has a graphical UI. ;)
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.
"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.
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... :-)
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
As someone who writes bootloaders using both C and assembly language there really is very little advantage to using assembly any more. The C compiler gnerates very good assembly code at this point that is very compact if the right parameters are used. At this point it is difficult to exceed what the compiler does in terms of code density and it's a hell of a lot easier and faster to maintain C code than assembly.
In my last bootloader I had to fit a MMC/SD bootloader in under 8K. In that space all of the assembly code fits in the first sector along with the partition table. The assembly code sets up the stack and does some basic CPU configuration and contains the serial port routines just because I had plenty of space. The rest of the bootloader contains all of the SD/MMC driver, FAT16/32 support, CRC32 and more. Note that this is MIPS64 code. The bootloader is able to load the next stage bootloader from a file off of a bootable partition from the root directory, validate it, load a failsafe bootloader if the validation fails and launch the next bootloader, all in under 8K. Having disassembled the output using objdump the compiled code is often better than hand coded assembly since the compiler can often find a smaller sequence of instructions. Not only that, but the compiler can order the instructions better for performance since it knows the CPU pipeline quite well.
You don't need to write in assembly for something to be small, just don't throw in a bunch of unneeded crap.
-Aaron
This post is encrypted twice with ROT-13. Documenting or attempting to crack this encryption is illegal.