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.
compilers can never optimise better than a human, if you disagree you havent witnessed the demoscene.
There's already a pretty big market of embedded devices running Linux or FreeDOS... and who's to say that another competitor couldn't offer yet another, better option?
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
A lot of the bloat in modern OSes comes from having to support a wide range of hardware - it's one of the reasons Linux can scale down to run on a tiny embedded system if you strip out that hardware support and other unneeded features (such as a fancy UI). You might even find that it doesn't scale well onto higher-end systems.
Masochism?
putting the 'B' in LGBTQ+
Likewise.. and it illustrates just how bloated "modern" OS have become. Then again, the generally accepted definition of "OS" seems to have changed to include things such as desktop and window managers.
Real Programmers write assembly language operating systems on punch cards.
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.
"Pointless" as a tag? Really? Is this Slashdot at all?
*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.
People want their operating system to let them operate their computer. Conveniently. You can certainly still get command-line-only linux distros if you care, and you're the kind of technology specialist who might get utility out of that.
cc -x c - <<'X' && ls -l a.out
#include <stdio.h>
int
main(void)
{
printf("hello world\n");
}
X
-rwxr-xr-x 1 fisted users 7318 Nov 15 17:25 a.out*
CLI paste? paste.pr0.tips!
If we are starting to believe that the core of an operating system should include a full GUI, video and mp3 playback, audio, USB, network, etc. for the least possible battery use, then this is a really cool way to go.
Why waste the resources? Just cause we can?
If we are to rethink what a basic operating system of today ought to have right out of the box from the first nanosecond, then I'm sure there is a lot of reengineering that would happen to any Linux or Windows kernel.
Hmm, the humour and sarcasm seem to have been be lost on you.
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'.
It's written in portable assembly, right?
CLI paste? paste.pr0.tips!
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!
So obviously their development cycle is much faster than HURD!
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.
Well, technically we all "touch" systems at this level, we just don't realize we are doing it. Learning/Using Assembly is like learning/using arithmetic instead of using a calculator. It is very handy and gives you a core appreciation for what is happening in complex problems, however most professionals just plug it into a computer rather than do it because it becomes too cumbersome at a certain level.
Yes they can. Try making use of a CPU with 8 cores and writing your threaded application in assembly. Someone with a compiler in a higher level language will kick your ass back and forth. The simpler the arguement the truth your argument holds, but as CPUs get more complex. Nope! Look at how difficult game programmers found it to program for the PS3 Cell architecture. Try having them write an entire game in assembly. Ha!
------ Curiosity killed the cat. {satisfaction brought it back | it didn't die ignorant | lack of it is killing mankind
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... :-)
I have to agree on that. While I always thought ASM is great, its greatness isn't universal. At any rate, *this* language will be better than *that* language for *this* specific task/project.
e.g. industrial robot programming, where you need to obtain maximum of speed and precision fit within minimum output size (e.g. 4 KB of storage, be it ROM, EEPROM, whatever) - that's where ASM shines. On the other hand, if you want to build an operating system, ASM will be better in less than 10% of the entirety of the OS; everything else is more efficient to build in a higher level programming language. That's because you have to consider time spent programming the stuff versus overall savings (time saved).
...gis sdrawkcab (usually not responding to ACs; don't bother posting as AC)
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
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.
The worst choice in C is to think you need to help the compiler optimize. Seriously, the compiler doesn't care at all whether you write x = x << 1; x += x; or x *= 2; it sees them all the same, so code the one that makes sense in context.
Historically helping the compiler, giving it hints, is in fact a good way to get superior code out of a compiler. For example consider 4x4 matrix multiplication. Do you use nested loops or just unroll it manually? Compilers tend not to fully unroll all the nested loops. The compiler may do better scheduling on fully unrolled non-looping code. Do you create temporary variables to preload a row or column, or do you just access each variable in memory directly? The former may generate better code on a RISC architecture and the later on a CISC architecture. These are the sort of things I think of when referring to helping the compiler, giving it hints. When that mythical smart compiler arrives that is able to figure out the preceding on its own, it will simply ignore your hints, the hints will do no harm. Until this mythical compiler arrives, the hints may help.
BTW, I agree with your sentiment in the context of the example you offer. Besides being useless, I've also seen people introduce bugs by making such "optimizations". Replaced the subexpression "x * 2" with "x << 1" in a larger expression and you may have changed the order of evaluation of the overall expression and are doing an erroneous calculation. "<<" has a different operator precedence that "*".
Well, "technically" I dabble in electrical engineering every time I flip on a light switch. I think my point was pretty clear.
I swear to God...I swear to God! That is NOT how you treat your human!
Against the license:
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.