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'"

Comments

Re:Gotta ask !

[Anonymous Coward]

Because this fool thinks he can write more efficient assembly code than decades-of-practice optimizing compilers can generate.

Re:Gotta ask !

[elfprince13]

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?

Re:Gotta ask !

[Anonymous Coward]

compilers can never optimise better than a human, if you disagree you havent witnessed the demoscene.

Re:Gotta ask !

[aitikin]

Why would someone want to do a rewrite of Minix 20 some odd years ago?

Hello everybody out there using minix -

I’m doing a (free) operating system (just a hobby, won’t be big and professional like gnu) for 386(486) AT clones. This has been brewing since april, and is starting to get ready. I’d like any feedback on things people like/dislike in minix, as my OS resembles it somewhat (same physical layout of the file-system (due to practical reasons) among other things).

I’ve currently ported bash(1.08) and gcc(1.40), and things seem to work. This implies that I’ll get something practical within a few months, and I’d like to know what features most people would want. Any suggestions are welcome, but I won’t promise I’ll implement them

Re:Gotta ask !

[SuricouRaven]

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?

[lil_DXL]

"Pointless" as a tag? Really? Is this Slashdot at all?

Re:Gotta ask !

[roc97007]

*Because someone should remember how to do this?

Re:Cool!

[i kan reed]

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.

Might actually be the case

[PhrostyMcByte]

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.

Re:Might actually be the case

[CastrTroy]

Very much agree with this. The compilers, for the most part, are smarter than people at optimizing code. There is almost no reason to write code in assembly anymore, other than "because we can", which is a fine reason for a "fun" project. However I wouldn't write assembly if I was trying to run a business. Java has the added advantage that it uses Just-In-Time compiling, so there's a lot of cases where Java, or .Net or any other language that uses an intermediate byte-code and actually outperform C.

Re:Might actually be the case

[Anonymous Coward]

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.

Re:Might actually be the case

[Arker]

"The compilers, for the most part, are smarter than people at optimizing code."

No, they emphatically are not. No computer algorithm is any smarter than the people that wrote it (in fact it's always going to be dumber.) If the compiler is better than YOU are at optimizing code, that may well be true and understandable - presumably optimising assembler is not your specialty, after all.

But a competent assembler specialist (someone in the same league, skillwise, with the guys that write the compiler) will beat the hell out of any compiler ever made. There just is no question. He knows every technique the compiler knows, but he is better equipped to know when and where to use them.

Compilers serve many valid purposes. They allow less skilled programmers to still produce a usable product. They allow more skilled programmers to produce a usable product more quickly. They facilitate portability. Plenty of good reasons for them to exist and be used. But beating a competent human at optimisation tasks is not one of them.

"Java has the added advantage that it uses Just-In-Time compiling, so there's a lot of cases where Java, or .Net or any other language that uses an intermediate byte-code and actually outperform C."

I know a lot of people think this, but it's nonsense, as a moments reflection should make clear.

I have no doubt that a poor coder might find JIT improves the performance of his code, but that really doesnt justify the assertion. You would need to show that JIT can actually beat a well written C program, and it wont. It cannot. Absolute worst case, if he has to, the C coder could simply implement a VM and JIT in his program and achieve the same results - and that is a tie. C cannot possibly lose that comparison, the worst it could possibly do is tie.

Re:Might actually be the case

[Anonymous Coward]

By your logic, a chess engine could not be better than the best human chess players, but the opposite is true.

Re:Assembly == SLOW ; JAVA == FAST!

[Guppy06]

If a compiler can't produce better assembly than any one programmer, it's time to get a new compiler.

I mean, that's pretty much the point of upper level languages to begin with.

Re:Cool!

[elfprince13]

And most command-line-only Linux distros are still several orders of magnitude larger than Menuet, which actually has a graphical UI. ;)

Re:Assembly == SLOW ; JAVA == FAST!

[Teancum]

If a compiler can't produce better assembly than any one programmer, it's time to get a new compiler.

I mean, that's pretty much the point of upper level languages to begin with.

Hardly.

The point of high level languages is to improve the productivity of software developers with the full knowledge and recognition that compilers will always do an inferior job... trading off efficiency and memory space for increased throughput of the developer.

That some compiler developers using some languages (notably C) can usually produce software that is within a few single digit percentages of the efficiency of a hand crafted assembly code written by competent and knowledgeable programmers well versed in those respective languages (an important distinction.... you need to compare expert C programmers with expert assembly programmers) for a few benchmark algorithms is besides the point.

Grace Hopper, one of the developers of COBOL, created the programming language for some very different goals than what you mention. Portability (the ability to move from one CPU architecture/operating system to another) was a key component and rationale. The other was to use "understandable" words that supposedly non-programmers could at least in theory be able to read. It is debatable if COBOL actually met those goals. Another very significant goal is to increase the volume of software produced by the individual software developer (mentioned above), and perhaps finally the point of a high level language is to reduce the learning curve for somebody new to computers and software development to be able to become the expert that is needed to get software developed.

I would agree that some compilers need to be tossed out the window in terms of their code efficiency, but you might be surprised at which compilers really can make the cut or not as well.

Re:Assembly == SLOW ; JAVA == FAST!

[mcgrew]

You jest, but wikipedia says it will boot in five seconds on a 90 mHz Pentium FROM A FLOPPY. Is that fast enough for you, javaboy?

Re:Assembly == SLOW ; JAVA == FAST!

[meerling]

If your C is faster than your Assembly, that's because your Assembly is crap.
It's the same way that your Bicycle is faster than your Jet Fighter Plane that is held together by duct tape and you've 'fueled up' with whip cream.

Re:Assembly == SLOW ; JAVA == FAST!

[Teancum]

Yeah, outside a few rather narrow cases, modern CPUs have just gotten too complicated to write efficient assembly for.

That says more about lousy CPU architecture design with bloat and incredible inefficiencies than it says about software developers who can write software for those CPUs. Then again, look up the RISC vs. CISC debates about CPU design and you might be surprised about CPU complexity as well.

Otherwise, most of the CPU complexity that currently shows up is due to the fact that the CPU speed far outstrips the memory bus speed, thus all of the concern about "local" memory caches and pipelined instruction ordering. If you could create a much faster memory bus, CPU designs could be simplified considerably from a software developer POV.

Of course we are still living with the effects of the 4004 design architecture that lives on with the laptop I'm using right now (and is opcode compatible with the 4004 instruction set still capable of being used as a strict sub-set of the opcodes used by my laptop's CPU). That is another reason for much of the added complexity in CPU architecture design, as few if any CPU designers want to abandon the software developed for earlier generations of CPUs as a way to promote their new design. Instead, they tinker on the edges and keep piling new instructions onto the existing heap of instructions and keep making the CPU more and more complex as a new generation of designers is in charge.

Assembly has very little advantage any more

[AaronW]

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