Please create an account to participate in the Slashdot moderation system


Forgot your password?
Operating Systems Open Source

MenuetOS, an OS Written Entirely In Assembly Language, Inches Towards 1.0 372

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'"
This discussion has been archived. No new comments can be posted.

MenuetOS, an OS Written Entirely In Assembly Language, Inches Towards 1.0

Comments Filter:
  • by Anonymous Coward on Friday November 15, 2013 @12:03PM (#45433555)

    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!

    • by scuzzlebutt ( 517123 ) on Friday November 15, 2013 @12:11PM (#45433673)
      You keep using this word, "Java". I do not think it means what you think it means.
    • by PhrostyMcByte ( 589271 ) <> on Friday November 15, 2013 @12:33PM (#45433995) Homepage
      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.
      • by CastrTroy ( 595695 ) on Friday November 15, 2013 @01:02PM (#45434377) Homepage
        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.
        • by Anonymous Coward on Friday November 15, 2013 @01:22PM (#45434627)

          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.

        • by Anonymous Coward on Friday November 15, 2013 @01:32PM (#45434751)

          Three points:

          1) Compilers vs Humans
          You have to start by doing an apples-to-apples comparison. Yes, many developers these days are ignorant of low level details about assembly language, and would therefore not produce assembly code that is as good as what comes out of a compiler. But that is because the compiler isn't built by your standard run-of-the-mill code monkey. They are built by people who truly understand the issues involved in creating good assembly language. So you need to compare assembly created by a compiler vs assembly created by someone who is at least as skilled as the people who created the compiler. In such a comparison, the humans will generate more efficient code. It will take them much longer (which is one of the two reasons why we have compilers and high-level languages), but they will generate better code.

          2) Why write assembly language
          No, one does not write assembly language for "fun" - there are specific business reasons to do so. Replacing inner loops in performance-critical loops with hand-coded assembly language is a common example. Most major database companies have a group of coders whose jobs are to go into those performance-critical sections and hand tune the assembly language. Would I try to write a GUI using assembly language? No, because it simply isn't that performance sensitive. Choose the tool that fills your needs. Religion about tools is just silly.

          3) Out-perform C
          No. Given coders of equal skill, all of the common high-level languages (Java, C, C++, etc) are identical in terms of CPU-intensive performance. That's because the issue is more one of selecting the correct algorithms and then coding them in a sane manner. It is demonstrable that Java can *never* be more efficient than a corresponding C program because one could always write a C program that is nothing more than a replacement for the standard Java JVM (might be a lot of code, but it can be done).

          The place that one starts to see differences in performance is in the handling of large data sets. Efficiently managing large data sets has much more to do with management of memory. Page faults, TLB cache misses, etc have significant performance impacts when one is working on large data sets. Java works very hard to deny the developer any control over how data is placed in memory, which leaves one with few options in terms of managing locality and other CPU-centric issues related to accessing memory. C/C++ gives one very direct control over the placement and access of objects in memory, hence providing a skilled developer the tools necessary to exploit the characteristics of the CPU-CACHE-RAM interaction. It is laborious, to be sure, but C/C++ allows for that level of control.

          So it all boils down to what one is implementing. If I were implementing a desktop application, I would probably use Java. The performance demands related to memory management are typically not very great and Java's simpler memory management paradigm streamlines the development of such applications (not to mention the possibility at least of having one implementation that runs on multiple platforms). If I were implementing a high volume data management platform, I would use C++ because the fine grain control of memory management provides me the necessary tools to optimize the data-intensive performance.

        • by Arker ( 91948 ) on Friday November 15, 2013 @03:10PM (#45436017) Homepage

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

          • by dbIII ( 701233 )
            I would argue instead that the compilers are more patient than people. They put in the optimisation work that most people don't put in the time to do. That is why the first rough shot at doing something without careful planning can end up with code that is slower than something written in a higher level language and compiled.
        • 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.

          I keep hearing the arguments but I don't see the fruits. I expect Java and .Net apps to run slow and take up irrational amounts of memory for what they do and I am rarely disappointed. I expect the handful of ASM function libraries we use to significantly outperform c code and they always do.

          If these high level languages are so great where are the commensurate outcomes in real life? Where are the cutting edge Java and .Net games? Browsers? Operating systems?

          In cases where the developers time is worth

      • by NewWorldDan ( 899800 ) <> on Friday November 15, 2013 @01:14PM (#45434523) Homepage Journal

        Back when I was trying to write games, 20 years ago, I figured out pretty quickly to write the important parts in assembly and the rest in C. But not before I wrote a full screen graphics editor in assembly. That was about 1200 lines of awesomeness that took me about 7 months to write. Fortunately, most of the graphic work carried over to the main game itself. Recently, I did a recreation of that work in C#. What took me over 2 years to do in 1994-95 took me a weekend to do now. My how times have changed.

    • by mcgrew ( 92797 ) * on Friday November 15, 2013 @01:39PM (#45434853) Homepage Journal

      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?

  • by Anonymous Coward on Friday November 15, 2013 @12:07PM (#45433621)

    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.

    • by HoldmyCauls ( 239328 ) on Friday November 15, 2013 @12:25PM (#45433853) Journal

      Just tried it in Virtualbox, and it has made strides since I last tried it some years ago. Some notes:
      Select "Other/Unknown (64-bit)" in the Operating System type drop-down, unless you specifically download the 32-bit version.
      Add a floppy controller and add the image as a floppy disk attached to that. Delete the other controllers that are present by default, unless you have a specific reason not to (like listening to your outdated music on disc from within MenuetOS, or loading a WAD or PAK file for Doom/Quake).
      Does not work with my work MacBook's iSight camera (afaict).
      Boots in 5 seconds, and I'm thinking of ways to demonstrate it to students at the schools where I work.

    • Apparently my company still stocks floppy disks. There's still a bunch in the supply cupboard, even though you can search all the cubes on this floor and not find a single drive. Someone really needs to update the order inventory.

  • I've been watching this project for ages, and I'm excited to see it slowly maturing. Quite a bit of fun to play with if you have some time to kill.
    • 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.

      • Re:Cool! (Score:4, Insightful)

        by i kan reed ( 749298 ) on Friday November 15, 2013 @12:29PM (#45433921) Homepage Journal

        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.

        • Re:Cool! (Score:5, Insightful)

          by elfprince13 ( 1521333 ) on Friday November 15, 2013 @12:50PM (#45434227) Homepage
          And most command-line-only Linux distros are still several orders of magnitude larger than Menuet, which actually has a graphical UI. ;)
        • Some of us remember the operating system being the software that operates the system, not the software that lets YOU operate the system. Back in the day of monolithic kernels being the norm the kernel WAS the OS. The shell (graphical or cli) was just an application that utilized the operating system.

          People have gotten so used to the idea of a computer being a general purpose machine they've forgotten that you could just run a kernel and application set that requires no human interaction software at all. For
          • Thank you for a better explanation of what I was alluding to.

          • Without basic tools to do so, how are you going to get software on your Operating System? Could we automatically boot to floppy like an Apple ][? What do you even want?

      • And an ever-growing array of utility software. What OS is complete without a media player, web browser and Minesweeper?

  • by plopez ( 54068 ) on Friday November 15, 2013 @12:23PM (#45433823) Journal

    Real Programmers write assembly language operating systems on punch cards.

    • It's been awhile, but I thought we wrote Fortran on punch cards. It's possible my memory is going.

    • Real programmers use a magnetized needle and a steady hand
    • Real programmers engineer trees to grow punch cards with self-evolving code already punched on them.

      I suppose this means that, yes, God is a real programmer. I think that makes perfect sense. The source code for everything is perfectly available (MIT license), but there's no documentation and there are no comments in the code at all. In particular, the build environment is completely left as an exercise for the user. The original developer has been so silent for so long he clearly considers the code "ma

  • Pointless? (Score:2, Insightful)

    by lil_DXL ( 3432951 )
    "Pointless" as a tag? Really? Is this Slashdot at all?
  • ... how many developers cheated. Coded their module in C or C++ and ran it through gcc with the -S switch.

    • I wouldn't consider comparing a manually written routine to what GCC outputs cheating. If you have an optimizing compiler available to you, why not learn its tricks so that you can write better code yourself?

    • I have no knowledge, but I'd imagine the optimizations from a compiler would have a tell-tale signature.

  • by canadiannomad ( 1745008 ) on Friday November 15, 2013 @12:31PM (#45433957) Homepage

    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.

  • by smash ( 1351 )

    "With other operating systems it could take weeks to get to know to internal workings of the OS. In MenuetOS you simply could draw a pixel anywhere on the screen if you wanted to without worrying about device contexts and bitmaps etc." It's good for prototyping, he adds.

    i.e., from the sounds of it, it is not multi user, and everything runs with superuser privileges. It is written entirely in assembly language which adds another level of complexity for the programmer to deal with.

    Whilst it sounds like an

    • by smash ( 1351 )
      and just on that.... you can increase speed by throwing hardware at the problem. you can't increase security or stability by doing that.
  • by Anonymous Coward on Friday November 15, 2013 @12:41PM (#45434111)

    So obviously their development cycle is much faster than HURD!

  • by Khyber ( 864651 ) <> on Friday November 15, 2013 @01:00PM (#45434345) Homepage Journal

    "MenuetOS is an open source"

    Not the x64 version, which is the version that's actually worth a shit.

  • Because assembly programming is really fun. It's challenging and it's a pretty unique experience for most of us who rarely touch systems at that low a level.

    • by PuckSR ( 1073464 )

      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.

      • Well, "technically" I dabble in electrical engineering every time I flip on a light switch. I think my point was pretty clear.

  • What a... (Score:2, Funny)

    by wonderboss ( 952111 )

    What a senseless waist of human life.

  • by AaronW ( 33736 ) on Friday November 15, 2013 @05:29PM (#45438081) Homepage

    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.


Loose bits sink chips.