Behind Menuet, an OS Written Entirely In Assembly

From the license... by damburger · 2009-08-19 01:37 · 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?

Re:From the license... by damburger · 2009-08-19 01:43 · 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?
Re:From the license... by __aaxwdb6741 · 2009-08-19 02:49 · Score: 5, Insightful

You are all incorrect in assuming that legalese (should|can|does|will) make any sense from a technical point of view.
Re:From the license... by yesteraeon · 2009-08-19 02:53 · 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*.
Re:From the license... by GreatBunzinni · 2009-08-19 03:00 · Score: 4, Interesting

If you had read the article you would know that they adopted FASM as their language/compiler, which offers features such as macros. As soon as you are producing source code files to be processed by programs whose work goes beyond simply mapping your instructions to machine code then we are no longer talking about assemblers. As soon as your code starts relying on features such as macros, libraries and other high-level abstractions then we have entered firmly in compiler country. After all, just because you name something as "assembly" it doesn't mean that the step between writing code and generating object code doesn't have a lot of abstraction in between. Just think of HLA for example.

--
Slashdot, fix your code or at least hire someone who is competent at it to do it for you.
Re:From the license... by GIL_Dude · 2009-08-19 03:17 · 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?
Re:From the license... by norminator · 2009-08-19 03:17 · Score: 4, Funny

I had to use butterflies:

I opened my hands and let the delicate wings flap once. The disturbance ripples outward, changing the flow of the eddy currents in the upper atmosphere. These cause momentary pockets of higher-pressure air to form, which act as lenses that deflect incoming cosmic rays, focusing them to strike the drive platter and flip the desired bit.

*shamelessly stolen from XKCD

Stupid license. No thanks. by Desler · 2009-08-19 01:40 · Score: 4, Insightful

Menuet64 Copyright (c) 2005-2009 Ville Turjanmaa

1) Free for personal and educational use.
2) Contact menuetos.net for commercial use.
3) Redistribution, reverse engineering, disassembly or decompilation prohibited without permission from the copyright holders.

Probably won't gain much steam with a license like that. Enjoy your obscurity and 3 users.

Re:Stupid license. No thanks. by damburger · 2009-08-19 01:49 · 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?
Re:Stupid license. No thanks. by Desler · 2009-08-19 02:09 · Score: 4, Insightful

No software got popular with such a restrictive licence! Heaven forbid they give it away free for personal use, all the most popular OSs are free for all!
The only non-free OSes that have have actually been used by more than 5 people actually provided more features than "Can play a 13 year old game fast".

(I don't disagree with you that it might seem a pointless licence, depending on what their plans for it are, but I don't think this has much relevance to popularity.)
Actually it does. Since this is clearly not a commercially viable OS the only segment of the population that might possibly use it would be tinkerers in the FOSS crowd, but they are going to be turned off by the license. There is really no viable reason to run the OS if you aren't allowed to tinker with the source code.
Re:Stupid license. No thanks. by ae1294 · 2009-08-19 03:44 · Score: 4, Insightful

Probably won't gain much steam with a license like that. Enjoy your obscurity and 3 users.
SO what?
At least the they are doing something interesting... Maybe they will find someone who needs a really small and quick OS that is hacker-unfriendly. I'd personally love to see ATM machines running something like this instead of Win2k and XP....
If by some oddball chance they can make some money off their hobby more power to them... Anyone who can code a OS in ASM is ok in my book and you got no room to judge them just because they are covering all their bases. I mean do you really not think some company wouldn't come and grab up all their work and laugh after spitting in these guys faces?

Not the best choice of languages by Anonymous Coward · 2009-08-19 01:40 · 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.

Re:Not the best choice of languages by damburger · 2009-08-19 01:54 · Score: 4, Funny

You are right of course. What they need is some kind of software tool that can automatically and quickly generate code optimized for any new hardware that comes out. Rather than code in the particular assembly language of the processor of the day they could write out their algorithms in some kind of abstract, human readable script, which the aforementioned tool would then convert to assembly language.
Why has nobody thought to create such a useful tool for these poor chaps??

--
If we can put a man on the moon, why can't we shoot people for Apollo-related non-sequiturs?
Re:Not the best choice of languages by jnaujok · 2009-08-19 02:05 · 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.
Re:Not the best choice of languages by Desler · 2009-08-19 02:16 · 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.
Re:Not the best choice of languages by TheRaven64 · 2009-08-19 03:39 · Score: 4, Insightful

Which encryption routines are these and what architecture are they written for? The fastest encryption routines I'm aware of are written in GLSL which is not just compiled, it's compiled to bytecode then JIT-compiled by the driver when the program is loaded! The second fastest use dedicated crypto hardware, via (C) ioctl() functions calling a driver, which is written in C. Oh and:

For well over a decade this meme has been out there and for well over a decade there has been continual performance improvements to those compilers.
Just because version n+1 of a compiler is better than version n of a compiler doesn't mean that version n isn't better than a human. Maybe you can do cross-module function specialisation in your head, but the rest of us aren't so lucky.

--
I am TheRaven on Soylent News
Re:Not the best choice of languages by adisakp · 2009-08-19 04:10 · 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.

That's just dumb. And kinda cool. by localman57 · 2009-08-19 01:41 · 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.

They should... by oldhack · 2009-08-19 01:42 · Score: 4, Funny

Man, they should, like, totally port that to ARM. ;-)

--
Fuck systemd. Fuck Redhat. Fuck Soylent, too. Wait, scratch the last one.

"it can even fit on a floppy disk"... by martas · 2009-08-19 01:43 · Score: 5, Funny

*blink*

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

--
weinersmith

Not that amazing by jdunn14 · 2009-08-19 01:46 · Score: 4, Interesting

For a more impressive feat, check out the Synthesis kernel written back in 1988. Also written entirely in assembly, and as stated in the linked wikipedia entry, that OS kernel was the "mother of all self-modifying code." It actually handled things like thread scheduling by generating a custom assembly snippet to jump to the correct point in the next thread to execute.

http://en.wikipedia.org/wiki/Self-modifying_code#Alexia_Massalin.27s_Synthesis_kernel

Followup to Menuet by halfdan+the+black · 2009-08-19 01:48 · Score: 5, Funny

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

Re:It's not FOSS? by Anonymous Coward · 2009-08-19 01:52 · 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

Kolibri: a Menuet offshoot by dargndorp · 2009-08-19 01:57 · Score: 4, Informative

Since all links in the article submission seem to be slashdotted, an offshoot of Menuet OS named KolibriOS is located at http://www.kolibrios.org/?&lang=en.

Re:Kolibri: a Menuet offshoot by MBGMorden · 2009-08-19 03:34 · Score: 4, Informative

Kolibri is a fork of the 32-bit Menuet OS which WAS GPL. When Menuet went proprietary then community forked the GPL version.

--
"People who think they know everything are very annoying to those of us who do."-Mark Twain

Fast due to assembly or fast because it's minimal? by Walter+White · 2009-08-19 02:00 · 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.

obsolete technology by gsslay · 2009-08-19 02:01 · 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?

Re:That's just dumb. And kinda cool. by timeOday · 2009-08-19 02:02 · Score: 4, Interesting

Interestingly, their homepage does not tout execution speed as a motivation: "Menuet has no roots within UNIX or the POSIX standards, nor is it based on any operating system. The design goal has been to remove the extra layers between different parts of an OS, which normally complicate programming and create bugs." It sounds to me more like they are fed up with all the clutter and layers of abstraction in a modern OS and want to see what happens if you start with a clean slate. Then again, without open source, the aesthetic appeal of this "clean" approach is limited.

Re:That's just dumb. And kinda cool. by hey! · 2009-08-19 02:13 · Score: 4, Informative

I agree. Every time I've ever profiled code, I've been amazed at how much time is spent in such tiny portions of the code.

It's an interesting exercise though. I've only done a little assembler, but my thoughts were that if I did more of this I could get pretty good at it. The trick in any kind of programming is to learn to express *ideas*. I learned several different programming paradigms over the course of my career, and while I'm doing OO like everyone else these days, having tried functional programming makes me a better programmer.

I could imagine doing non-trivial systems in assembler, but mainly if the problem domain and its solutions are very well understood. When you see that 1% of your code is taking 99% of your execution time, you *could* tighten that code and get an immediate payback, or you could try understand the problem better in order to find a more efficient algorithm. If you can improve your algorithms, that's almost always going to be a bigger win.

We've been making essentially modern operating systems (virtual memory, process scheduling etc.) for a long time. If you just wanted to implement the textbook approaches for everything, and didn't care about architecture portability, it seems pretty feasible for a couple of guys to make a reasonably credible OS in assembler, provided they knew their OS stuff and were very good assembly programmers. Obviously the C with assembly for tight loops approach is a quicker path to a usable system, but the fact that they're assembly enthusiasts probably means they'll get more benefit out assembler where it is most useful and less benefit out of C where assembler is least useful than a sane programmer would. And it's always worthwhile to demonstrate the limits of conventional wisdom.

SInce you work in embedded systems, I don't have to tell you that upgrading your processor in six months isn't always an option.

--
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.

networking by james_shoemaker · 2009-08-19 02:15 · Score: 4, Interesting

Too bad it doesn't have wireless networking support, it looked to be the perfect thing to make older notebook computers useful.

No by hasbeard · 2009-08-19 02:16 · Score: 4, Funny

No, a floppy disk is what you get when you leave a DVD in the back window of your car on a hot day.

Ehhh..... by OwnedByTwoCats · 2009-08-19 02:17 · 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.

Re:It's not FOSS? by arndawg · 2009-08-19 02:18 · 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.

Re:Yes! by Just+Some+Guy · 2009-08-19 03:22 · Score: 4, Funny

Can't put one past you, can they.

--
Dewey, what part of this looks like authorities should be involved?

Slashdot Mirror

Behind Menuet, an OS Written Entirely In Assembly

34 of 419 comments (clear)