Slashdot Mirror

← Back to Stories (view on slashdot.org)

Behind Menuet, an OS Written Entirely In Assembly

Posted by Soulskill on from the keep-it-simple dept.

angry tapir writes "MenuetOS is an operating system written entirely in assembly language. As a result it's extremely quick and compact (it can even fit on a floppy disk, despite having a GUI). It can run Quake. Two of the developers behind MenuetOS took time out to talk about what inspired them to undertake the daunting task of writing the operating system, the current state of Menuet and future plans for it."

18 of 419 comments (clear)

  1. From the license... by damburger · · Score: 5, Funny

    3) Redistribution, reverse engineering, disassembly or decompilation prohibited without permission from the copyright holders.

    Are you sure they wrote the entire thing in assembly language?

    --
    If we can put a man on the moon, why can't we shoot people for Apollo-related non-sequiturs?
    1. Re:From the license... by damburger · · Score: 5, Informative

      That would be disassembly, which they already mentioned separately as being prohibited. Putting "Point one" and "Point two" in front of clearly incorrect statements doesn't improve anything.

      --
      If we can put a man on the moon, why can't we shoot people for Apollo-related non-sequiturs?
    2. Re:From the license... by __aaxwdb6741 · · Score: 5, Insightful

      You are all incorrect in assuming that legalese (should|can|does|will) make any sense from a technical point of view.

    3. Re:From the license... by yesteraeon · · Score: 5, Insightful

      So if I find a book lying in the street can I pick it up and read it, or do I need to call the publisher to get a license? I think you're overstating the scope of copyright just a *tad*.

    4. Re:From the license... by GIL_Dude · · Score: 5, Funny

      That must have sucked when they had a heap overflow. Someone could also step on them and seriously flatten the stack. I guess if there were too many, you could always throw the exceptions at someone, huh?

  2. Not the best choice of languages by Anonymous Coward · · Score: 5, Insightful

    In today's multi-level cache, highly pipelined CPU environment, hand optimized assembly is not usually the best choice when compared to a good compiler. It's easier for bugs to hide, and small mistakes can cost way more than any possible optimization is going to buy you.

    1. Re:Not the best choice of languages by jnaujok · · Score: 5, Insightful

      Spoken like someone who's never coded in Assembly. While I almost never touch assembly any more, there's very little fact in your statement. In assembler, everything is in front of you. There's no need to worry about what the libraries are doing, or whether the call to some function is going to cause side effects or something you didn't intend, or whether some compiler quirk is going to make your code take ten times longer to run.

      Having written in assembly on 8048, 8051, 8086 and DEC Vax boxes, I can tell you right now that debugging most of that code was a lot easier than chasing down the side effect from some array overwrite on leaked memory from a third-party library that you didn't even know was being linked into your code.

      Writing in a compiled language is easier, faster, and usually has a better set of pre-written functionality, but never, ever claim that it's going to be more optimized. Even with pipelining updates from the compilers that help the look-ahead caches on the CPU, there's very few times that hand-coded assembler isn't going to be faster.

      Go look at the assembler that some of these compilers produce. It's frightening to see the amount of overhead they cost on even simple assignment operations. I saw one compiler (Microsoft's Visual C++) that took a simple x=10; in C++ and turned it into 15 assembly language operations that, had it been coded by hand, would have been one MOV statement. The compiler turned it into conditional conversions for type, did some byte order and range checking on it (for a hard assign to a constant -- rolls eyes) and then finally did the same MOV AX, 0x0a that you would have coded by hand.

      --
      Life, the Universe, and Everything... in my image.
    2. Re:Not the best choice of languages by Desler · · Score: 5, Insightful
      Actually his points are quite valid. It is not a good choice to write everything in assembly when the speedups you gain in most places is not worth the amount of time and effort you spend in hand-optimizing the code. And considering how many bugs I've seen in people's asm code that they didn't spot till later his second point is also true.

      Even with pipelining updates from the compilers that help the look-ahead caches on the CPU, there's very few times that hand-coded assembler isn't going to be faster.

      The GP never made that claim.

    3. Re:Not the best choice of languages by adisakp · · Score: 5, Informative

      Writing in a compiled language is easier, faster, and usually has a better set of pre-written functionality, but never, ever claim that it's going to be more optimized. Even with pipelining updates from the compilers that help the look-ahead caches on the CPU, there's very few times that hand-coded assembler isn't going to be faster.

      As CPU's become more complex, this is less and less true. For example, even on the PS2, they created a tool called VCL that preprocessed assembler for you for maximum usage of registers, unrolling, and pipelining. It generated better optimized code than 99% of of coders out there could do on their own and at a fraction of the effort to seriously fully optimize pipelined assembler -- not to mention the asm code was much more maintainable since with handrolled manually pipelined code you may have to re-optimize everything if you change a single register or just a few instructions. Also, things like the auto-unroll and auto-register-assignment a were huge time saver (it could unroll a loop NX and allocate NX registers to interleave SIMD operations to hide latencies).

      That's not to say that a really great ASM programmer wouldn't do better than VCL, but he would have to work much much harder. You'd have to track all the registers yourself, remember the pipelining rules and latencies for every single instruction, be willing to experiment with unrolling every loop and counting cycles between unrolled (with prologs/epilogs) and normal versions, know all the possible instruction swaps, synchronize the integer and vector pipelines manually, try nearly all possible instruction orders, etc. Certainly an average assembler programmer wouldn't do as well.

  3. That's just dumb. And kinda cool. by localman57 · · Score: 5, Interesting

    The article is slashdotted, so I'll post a thought without RTFA. I do embedded firmware for a living; assembly programming is part of my job. But unless you have to fit all of your software into a $.42 micro, there's no reason to write all your software in assembly. Typically, you get most of your performance gains by rewriting 5% or less of the software in assembly [Citation needed... :-)]. As for the rest, go with C or higher for maintainability and portability.

    6 months from now, a new processor revision will provide enough marginal performance to make up for not coding the other 95% in assembly.

    That said, this is a monumentally cool achievement, if academic.

  4. "it can even fit on a floppy disk"... by martas · · Score: 5, Funny

    *blink*

    is that some kind of new super-awesome flexible organic flash memory?

    --
    weinersmith
  5. Followup to Menuet by halfdan+the+black · · Score: 5, Funny

    I think I might work on a sequel...
    Build a 747 with nothing but stone knives and bear skins...

  6. Re:Stupid license. No thanks. by damburger · · Score: 5, Insightful

    More to the point, the prohibition on disassembly makes it impossible to independently verify their claim it was written in assembly language without violating their license, and that claim is central to the idea of this being an interesting research project.

    --
    If we can put a man on the moon, why can't we shoot people for Apollo-related non-sequiturs?
  7. Re:It's not FOSS? by Anonymous Coward · · Score: 5, Informative

    for anyone wanting to tinker - it had been forked before they closed it
    http://wiki.kolibrios.org/
    http://www.kolibrios.org/?p=SVN&kind=dir&loc=/kernel/trunk

  8. Fast due to assembly or fast because it's minimal? by Walter+White · · Score: 5, Insightful

    I have to wonder if it is small and fast because when writing in assembly it is easier to resist the urge to add features. Todays compilers are pretty good and can produce pretty tight binaries. However, you can write (and debug) a lot more code in a given time using a high level language.

  9. obsolete technology by gsslay · · Score: 5, Funny

    (it can even fit on a floppy disk, despite having a GUI)

    Excellent, but if we're going to measure these things in obsolete technology;

    - How many parchments would I need to copy it?
    - Could my team of monks transcribe it in its entirety before the Feast of All Hallows Eve?
    - If the Germans intercepted a morse transmissions of it, how long would it take them to crack the code and scupper our plans to retake mainland Europe?

  10. Ehhh..... by OwnedByTwoCats · · Score: 5, Insightful

    Ehhh. The whole effort doesn't impress me. There are/were Linux distros that fit onto a floppy. OSs were written in Assembly for years.

    If they can demonstrate that "remov[ing] the extra layers between different parts of an OS" simplifies programming and eliminates bugs, then they'll have something interesting. And they can have a flame war with the microkernel folks, who assert that separating the OS into separate parts that are independent and can be thoroughly tested simplifies programming and eliminates bugs.

    Abstractions have a purpose; they make it easier to think about things. There are no "Files" or "Folders" (or "Directories", for those of a Unix persuasion) on your hard drive; there are only a sequence of blocks. The Operating System provides the abstraction of files. Various protocols and their implementations then provide an abstraction that "Files" and "Folders" on remote machines are just like "Files" and "Folders" on the local drive.

    If abstractions make life complicated for the OS developer, but easier for the user, is it a win? It depends on whether the OS has more developers or users.

  11. Re:It's not FOSS? by arndawg · · Score: 5, Funny

    Imagine what today's world would be like if Linus had gotten pissed when people started working with the Linux Kernel.

    I'm guessing the population in the western world would be higher.