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