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

Assembly == SLOW ; JAVA == FAST!

[Anonymous Coward]

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!

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

[scuzzlebutt]

You keep using this word, "Java". I do not think it means what you think it means.

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

[Anonymous Coward]

There's a reason it was posted as Anonymous Coward!

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

[jythie]

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

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

[arfonrg]

So, what you're saying is that the C compiler is better Assembly coder than you are. I feel your pain on that one.

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:Assembly == SLOW ; JAVA == FAST!

[Anonymous Coward]

Pfffftttt..... Java........ Once they make an OS in PHP, they get all the speed in the world!

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!

[ciderbrew]

These are the words you keep inside when you report to board level.

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

[Anonymous Coward]

Ah but that depends. Because it's written entirely in assembly, MenuetOS is so small that the entire thing can fit in the CPU cache: most of it in L1 directly. What it loses in things like pipe-lining & branch prediction it more than makes up in sitting in the cache.

You can also do this with DOS & Windows 3.1 on a modern CPU: an i7 has 8MB of cache, which is more than most PCs c. 1995 had in their entirety.

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!

[lgw]

So, what you're saying is that the C compiler is better Assembly coder than you are. I feel your pain on that one.

Indeed. I spent 5 years supporting a production commercial OS written entirely in assembly (one of many forks that happened when IBM started licensing the source for their old mainframe OS). Today I let a C compiler do it's job on my personal projects.

Can you write faster code than the compiler - sure you can, though it requires a deep understanding. But that code will be crap unmaintainable code. There was a day when C was called a high level language, and in a meaningful way it still is. You can write good maintainable C code that doesn't look optimized and get nearly-perfect assembly that bears little resemblance to the source.

The worst choice in C is to think you need to help the compiler optimize. Seriously, the compiler doesn't care at all whether you write x = x << 1; x += x; or x *= 2; it sees them all the same, so code the one that makes sense in context.

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.

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

[pigiron]

As long as it is backwards compatible with the 8008 instruction set I'll be happy!

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

[meerling]

I sure hope you're being sarcastic, but the ignorance among people these days, I can't be sure.
Assembly is basically machine language with mnemonics so it's easier for the human to write and can be compiled to run on different processors.
C is a compiled language that is even easier to use for humans, but it has gone out another level of abstraction so something closer to the metal, aka assembly, can out perform it easily if well written. (Crap code is crap no matter what it's written in.)
Java is an interpreted language. It's even further away than any compiled language. It goes through a program that translates it when you run it. Kind of like Basic does. So it has a LOT more crap between it and what the machine actually runs. Again, any cases of Java running faster than C is the programmers fault.

Let's put it this way, it's like having a button in a room that you want an intern to press.
The Assembly language intern is in the room and will press it the moment you call him and tell him.
The C intern is at the door of the room, and is waiting for that call as well.
The Java intern is sitting on your lap, but still won't do anything until you call, at which point he calls his brother, who then has to run down to wherever the room is before he can even see the button much less press it.

Yes, Assembly and C are both compiling languages, but Assembly has the potential advantage since it's a lot closer to the final product for pure speed.
(I said 'potential' because the programmer can screw up anything in a program.)
As to Java, in many ways it's a version of C that has an interpreter.

Now of course, we could try to explain compilers and interpreters and pcode, and a lot of other things to you, but if you weren't making a joke, you aren't even close to being ready for any of that.

In the ancient days, we actually made programs in Basic that ran faster than other peoples C programs. That's because we 'cheated' and inserted hand tuned machine code to handle the usually slow parts. We also wrote a Basic to Machine code compiler that allowed you to choose between speed, resources, or a balanced output. Of course, back then the computers were much more limited and 8k ram was considered good. No way in any hell I'm signing on for a project like that these days!

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

[Anonymous Coward]

What a dumb analogy

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

[PRMan]

Yes, you might be surprised, since Borland Delphi is often the most efficient high-level compiler for PCs. It's not that useful anymore (because Pascal has fallen out of favor), but it has unbelievably good optimizers.

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

[Anonymous Coward]

That says more about lousy CPU architecture design and incredible inefficiencies...

It's actually the opposite.
The architectures (at least away from x86) are pretty good now. x86 still blows chunks and always will.
The big issue with compilers vs. assembly is legacy systems. On the desktop every new CPU needs to run old code faster. If it doesn't it's a failure; P4 for example. The CPUs themselvs are getting much better at executing shitty code streams making much of the optimization process unnecessary. If you know what you're doing you can still hand craft instruction streams that the CPU will execute faster but as I said in an earlier post eerything is memory bandwidth bound now anyway. Fix your memory accesses and your code runs better.

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

[Immerman]

Can fit in cache != will be in cache. On a modern multi-GB system the memory paging index alone is going to dwarf the size of this OS's code. Then there' all the rest of the OS data, plus the even more frequently used application code and data. Certainly shrinking the OS code size drastically will help free up more cache space for other uses, and the most heavily used parts may be able to remain in the cache most of the time, but it's almost a guarantee that most of the time most of the OS code won't be in the cache.

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

[gbjbaanb]

it also says a lot about lousy high-level languages layers on layers in the quest to make developers more productive.

You can code C and get good assembler out of it that is also efficient and fast; or you can code a script language that will not produce decent assembler but will let you code things a lot quicker. I think there's probably a sweet spot between these two extremes but it will shift depending on your work - some people will want the extra power of C++ that still gives you good assembler, while others will go for C# or Java that gives you good productivity.

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

[Arker]

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

You say this as if there were some other way. But when you code in a higher level language, the compiler mechanically translates what you wrote into assembly before handing it off to the assembler to actually generate the object anyway. Compilers have certainly seen a lot of improvement but compiler generated assembler code still tends to be awful, and a good assembler programmer will always be able to beat it if given a chance.

I suspect what has really happened is simply that employers are heavily biased towards cheap and quick, and assembler isnt optimal there. And that in turn has resulted in fewer people learning assembler, making it even harder and more expensive to do things that way, sort of a vicious circle.

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

[Anonymous Coward]

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?

On the next SAT tests:
Java is to C or Assembly as a Floppy is to a Hard Drive.
[ ] true
[ ] false
[x] what is a floppy?
[ ] I want some of what you're having

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

[LynnwoodRooster]

He's using it correctly. Remember the Programmer's Mantra: "It is by caffeine alone I set my mind in motion. It is by the beans of Java that thoughts acquire speed, the hands acquire shakes, the shakes become a warning. It is by caffeine alone I set my mind in motion."

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

[davester666]

Well, the more coffee you drink, the slower everybody else seems, so obviously you are going faster.

It works the same with computers. The more Java you throw at them, the slower everything else seems.

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

[MXB2001]

I run DOS 7.1 on a '99 with 128 MB RAM. That's 1 MB for DOS and 127 for extended memory... :)

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

[Anonymous Coward]

Bo Ard so bored the Board Board, they bored a bore through the floorboard, clear to Boring, Oregon.

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

[jhumkey]

Excellent point. I keep saying we should ask "Am I choosing a language for the 1 hr project, or the 10 year project?"
If its the 1 hr project (lets say to port data from one proprietary DB format to another) . . . write it in anything, Java, C, Haskell, APL . . . I don't care. You need it quick, not efficient, then will throw it away.
But if we're going to be Mostly Running it for 20 years (and less so modifying it) . . . like say for an OS . . . then . . . efficiency beats all. (Doesn't eliminate expand-ability and maintainability . . . but beats them to first place consideration.)
And, under ideal circumstances . . . its gonna be hard to beat Assembler. (Slower to market . . . perhaps . . . but faster for you the next 20 years as you run it.)

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

[westlake]

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.

Common Business-Oriented Language

The goal was a program that could be read and audited by corporate accountants and integrated into systems and practices that in some cases dated back centuries.

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

[slack_justyb]

What you speak of is a direct consequence of Intel holding its monopoly over everything. So while there may be a slight technical challenge, there is a much larger political challenge.

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

[neurojab]

And, under ideal circumstances . . . its gonna be hard to beat Assembler. (Slower to market . . . perhaps . . . but faster for you the next 20 years as you run it.)

You may be right, but I wouldn't bet on that. First of all, it's not unheard of for a CPU architecture to die in 20 years, but that aside: It would be interesting to take an x86 assembler program written 20 years ago and run it on modern hardware, then perform the same experiment with a C program recompiled with a modern compiler.

The 20 year old assembly program would be optimized for a 20 year old CPU architecture (and essentially running in backward compatibility mode), whereas the C program would be optimized for the current architecture. I'd wager you'd see far greater improvement moving to the modern CPU in the C program. Whether it would be faster than the assembly program would depend on what it did, but I would think that in many cases the C program would be faster, even if the assembly program smoked it 20 years ago.

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

[LWATCDR]

Even if discount the nasty ISA of the x86 there is still the problem of instruction scheduling. I would love to see some benchmarks of minuetOS vs say Linux.What an OS is written in is less import than performance.

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

[nogginthenog]

My 7Mhz Amiga 500 would boot up pretty fast from a floppy, and the OS was written in a mixture of C, Assembler and BCPL.

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

[Teancum]

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.

Common Business-Oriented Language

The goal was a program that could be read and audited by corporate accountants and integrated into systems and practices that in some cases dated back centuries.

It was also so non-programmer managers could at least pick up a piece of code and be able to read it with at least something resembling some understanding of what was being written. Having something like:

MULTIPLY SIX BY PI GIVING RESULT

is certainly much easier to read than

MOV 3.14159,C
MOV 6,X
MUL X,C
MOV C,$0ADB

although the C equivalent of:

return 6 * PI

certainly seems even easier.

My point though is the design goals of high level languages has many primary goals, and the issues of compiler efficiency is very much secondary or even tertiary in terms of what it is supposed to be accomplishing. Often those goals are at substantial odds against producing efficient code in the first place, in terms of being executed quickly on the target CPU.

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

[Anonymous Coward]

So you want the Java Media Desktop http://en.wikipedia.org/wiki/Java_Desktop_System, Sun's go you covered, without a hint of irony even.

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

[cfalcon]

WHERE ARE MY MOD POINTS

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

[Teancum]

I would dare you to take a 20 year old program in any language and have it run successfully on any current computer without having to do some substantial tweaking or putting that computer into some sort of historical mode of operation. In most cases I would dare you to find the source code for that 20 year old software as well, as my experience in such situations is that binaries alone are what survives. Most examples I can think of also run on 20 year old hardware (or at least the basic hardware architecture is 20+ years old too).

Come to think of it, I was developing software in Windows 3.1.1 for Workgroups about 20 years ago. I actually do have some of that software sitting around on some very old CD-ROMs of that software too, and some fragments of the source code that I wrote too. Getting it to run is a real challenge, and the default installer program most certainly doesn't work as I've had to tweak things just to get it to work at all in Windows XP (I won't even try Windows 8).

Yeah, assuming that the compiler doesn't barf out with some of the compiler flags, exceptions, API library calls, or other various problems that would come from trying to recompile that old software, you would most certainly be able to get a modern compiler to be able to target the current generation of CPU architecture and do a better job as opposed to simply running those 20 year old binaries. It may be possible to recompile some of Linus Torvalds' original source code for the first version of Linux too, but just imagine the problems you would face trying to get that to actually run?

No doubt there are some standard libraries of code that are in core operating systems that have stood the test of time and work much better in current generations of compilers, but I dare say you are also comparing apples and oranges here too. In many cases, those libraries were in fact the test cases which the compilers were built around, so of course they would be able to keep compiling some of those older code examples. Regardless, all of those examples, inline assembly inserted into the middle of a C program, and other examples of older code would all have some significant and continued maintenance done over the past couple decades or it would be treated as abandonware and become a major engineering effort just to get it recompiled in the first place.

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

[Guy Harris]

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

Well, you have a crappy laptop then. Most laptops out there have a CPU with an instruction set such that assembler-language code for the Intel 8080 could be mechanically translated to assembler-language code for that instruction set (although the machine codes were not compatible), although the instruction set in current CPUs have been at least extended significantly to a 32-bit version and, in most cases, to a 64-bit version.

(I.e., you've confused the 4-bit 4004 with the 8-bit 8080 and you've confused "similar instruction sets to the extent that you can mechanically translate assembler-language code" with "superset of the same instruction set".)

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

[sjames]

I would say that COBOL fell short of "anyone can program" by a wide margin, mostly because even if you could just describe the algorithm in detail in natural language, most people just don't have the mindset necessary for the task. Even with an expert system asking questions for clarification, many would be reduced to silently waving their hands in frustration unable to describe the low level details at all.

OTOH, it was a lot more comprehensible to a lot more programmers (or potential programmers) than assembly language (which had only recently replaced patch cords and plug boards). Unfortunately, as an early attempt at a higher level language, it gets in the way of a good programmer almost as much as it helps, but as I said it was a very early effort and is to be commended for it's accomplishments however limited.

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

[TangoMargarine]

Or somebody could work on a compiler to efficiently convert a high-level language into something lower that already maps well to assembly...

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

[TangoMargarine]

So compared to Java, basically assembly, assembly, and more assembly.

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

[Miamicanes]

The P4 was epic fail across the board... it was slower at old code, and STILL slower with new code. Even if you hand-tweaked code specifically for Netburst architecture, random spew running on any PIII would toast the best optimized code crawling on a P4.

The Pentium 4 (and Netburst architecture) had exactly one purpose: cheap gigahertz for Intel's marketing department to advertise. It's the reason why a 1.6 GHz Pentium M (which was for all intents and purposes, a 1.6GHz Pentium III Xeon with hyperthreading and power management) completely toasted even 3GHz Pentium 4 CPUs, and a big part of the reason why AMD completely spanked Intel for a couple of years despite having CPUs that were half the nominal speed of Intel's.

The Pentium 4 will forever be remembered as an unloved artifact of Intel's descent into Microsoft-like insanity. Fortunately, we had AMD standing by to give us a consequence-free superior alternative, so Intel had no choice but to throw in the towel on Netburst and become sane again quickly. Unfortunately, OS X is tied to Apple's overpriced hardware, and Linux is far from being an effortless & transparent alternative to Windows (*), so the best we can hope for is that Windows 8.1 will be followed by Windows 9 and Windows 7XPE (available in Professional and Enterprise versions only), with 7's UI, but Windows 8's performance improvements backported, and and Metro just overlaid on top of IE12.

(*) Just to name one issue that's always annoyed me with Linux... its mouse ballistics. No, seriously. Regardless of what I've tried, it's just never seemed *right* compared to Windows. It doesn't matter which mouse I use, or what I set its parameters to be... I just can't precisely replicate Windows mouse ballistics under Linux, and always feel like I'm fighting with the mouse.

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

[Anonymous Coward]

Yes, I am going to listen to someone with the name "Tea 'n' Cum".

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

[Miamicanes]

Well... that depends. A compiler could theoretically do a better job of precisely applying memory-barrier instructions and pre-optimizing code for a specific CPU to maximize its ability to run from cache. In reality, this is a use case that almost never applies, because the only time anybody allows the compiler to hard-optimize code enough for it to matter is when they're trying to benchmark a new Intel CPU using Intel's compiler and allowing it to push that one specific CPU as hard as it can possibly be pushed (even if the same optimizations would be harmful to code performance on other models).

Likewise, a lot of compiler optimizations do things that would be unmaintainable and ugly in assembly, like unrolling loops and generating spaghetti code that caches well, but would be unreadable to a human.

The one thing compilers have always sucked at, though, is compact code. And oddly, that's starting to matter now, even though we have gigabytes of ram. Relatively speaking, DDR3 system ram is almost as slow relative to L1 cache as magnetic tape was relative to SRAM back in the 70s. The hit from having to go out and fetch bytes from main system RAM is now HUGE. Speculative execution and multiple cores & pipelines help, but only in situations where the computer is busy trying to do a dozen things at once anyway. Do something with a single core that involves lots of random-access ram fetching, and even an i7 will slow to a crawl.

Now... in theory... it might be possible to hand-tweak a build of MenuetOS for a specific processor like the i7, using assembly opcodes almost nobody who isn't a compiler-writer even knows exist to semi-deterministically set up execution from the 4 cores, laying out the code and data so it can all run entirely from cache. And maybe even a chunk of the OS executing directly on the GPU. If someone could pull off a stunt like that... good god. Your 3GHz i7 would execute with the performance of a theoretical 16GHz i7, once you got it tweaked to the point where everything ran 100% out of cache and never had to wait for slow main memory access.

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

[maxwell demon]

The point of high level languages is to improve the productivity of software developers

That is one point of high level languages. Another point is that you don't have to rewrite your whole code from scratch just because you're using a different processor on your next machine.

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

[maxwell demon]

It would be interesting to take an x86 assembler program written 20 years ago and run it on modern hardware, then perform the same experiment with a C program recompiled with a modern compiler.

I bet the C program from 20 years ago would have some micro-optimizations which back then saved a few cycles, but which obfuscate the code for modern optimizers, so that the tweaked code is actually slower than straightforward code.

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

[dbIII]

The P4 was epic fail across the board

It was so bad that I had a 70 year old former transmission systems electrical engineer (so nothing below thousands of volts) rant at me for hours about how bad it was when it came out. When a guy who graduated from University before the transistor went on sale can see a dozen holes in microprocessor design then you've got a problem.
I really should retire the last netburst machine I've got but it has a lot of drive bays and freebsd can still do stuff with it.

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

[flargleblarg]

I would dare you to take a 20 year old program in any language and have it run successfully on any current computer without having to do some substantial tweaking or putting that computer into some sort of historical mode of operation.

10 PRINT "HELLO, WORLD!"
20 END
RUN
HELLO, WORLD!

Yup, still works without any tweaking!

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

[dbIII]

I would dare you to take a 20 year old program in any language and have it run successfully on any current computer without having to do some substantial tweaking or putting that computer into some sort of historical mode of operation.

The old *nix "xv" image viewer still works if it's a static binary from 20 years ago. An ex-IBM guy I know mentioned some even older MSDOS game called "Alley Cat" that works on 32bit win7 (not sure about Win8).

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

[grumpyman]

As an academic exercise I in fact did implemented a rudimentary java interpreter in java way back in school when it was 1.0 lol.

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

[thestuckmud]

If your C is faster than your Assembly, that's because your Assembly is crap.

You are kidding yourself if you think you can write programs in assembler that run faster than the equivalent in C. Look at what my compiler generates for the C statement "return x/372;" with 64 bit ints on x64:

movslq %edi, %rax
imulq $738919105, %rax, %rax
movq %rax, %rcx
shrq $63, %rcx
sarq $38, %rax
addl %ecx, %eax
popq %rbp
ret

Your only practical approach as a human writing this in assembler is to use the slower 64 bit divide instruction. Puzzling out optimizations like this is a job much better suited for a the code generator in a compiler.

This is just one example among many arithmetic tricks of the trade. Register allocation and loop unrolling are two more low level optimizations that are no fun. At least not for me. I'd rather write the program in C, profile it, optimize my algorithms, and only then consider rewriting inner loops in assembler. Actually, I'd rather write the program in a proper modern programming language, and speed up its inner loops by rewriting them in C/assembler.

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

[Anonymous Coward]

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.

Actually, you're both full of shit. Outside of vector extensions, popular modern CPUs execute much the same instruction set as they did 10 or 20 years ago (notable exception / new development: ARM64). The only things which have changed, from a programmer's point of view, are cache hierarchies, execution timings, prediction miss penalties, etc. And for the prospective assembly hacker, in a sense things are better than they ever have been: the modern CPUs (particularly Intel's) are so good at doing scheduling that mostly what you need to do is figure out a minimal set of instructions with a minimal and properly blocked cache footprint and minimal register spills. The CPU will usually take care of the rest. It's no longer as necessary to understand every part of the pipeline in detail to get close to max theoretical throughput.

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

The idea that the x86 is descended from the 4004 and that this influence shows up in any part of its design is nonsense. I suppose you're believing that because Intel named its early CPUs 4004, 8008, 8080, 8085, and 8086 (the last being the first x86 CPU), there must be a very close family relationship between them all? In truth, you can make three groups out of those: the 4004 (the 4-bitter) by itself, the 8008/8080/8085 (8-bitters), and the 8086 (16-bit).

Even just a little bit of wikipedia'ing will tell you that the 8008 was not a derivative of the 4004. It was a separate project which actually began before the 4004 project. And if the 4004 had any influence on x86, you'd expect x86 to have at least a trace left over of the 4004's 4-bit (nybble) word size. It has none; like all modern CPUs the x86 is a byte-addressed machine.

As for the relationship between the 8-bit and 16-bit groups, there is one, but it's not as close as you claim. There was no binary compatibility; 8086 machine code (opcodes etc) was a new design. 8086 was designed to be (very) loosely compatible at the assembly source code level. It wasn't even perfectly compatible at that level, just designed such that you could run a mechanical translator program on your 8008/8080/8085 source and it would spit out valid 8086 assembly, which you then might have to tweak a bit to get a working program. Also, this was more a convenience feature than something you'd want to rely on: the translated code would use the 8086 as if it were only an 8-bit CPU, so it was seldom anything like optimal.

(Now, you want an example of how legacy does actually show up in x86? Look at the assembly-visible register names. The 8086 has a name for each 8-bit segment of its 16-bit registers, and the lower halves are the same as 8008/8080/8085 register names.)

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

[Teancum]

That is a terrible example. Besides, if you want to do that in something like Visual BASIC it would be more like:

MsgBox("Hello, World!")

or something similar. Like I said, it would need to be seriously updated if you are going to be using current compilers. Indeed most versions of BASIC that I've seen that aren't historic compilers, hence have also been optimized to be running on the current generation of computers, don't even use the PRINT command.

As I said, it would need some substantial tweaking if you are using the current generation of compilers. If you are using compilers written that targeted the machines of 30 years ago, yes that might still work (again putting the computer into a historic backward compatible mode too). Then again, the argument in the GP post would also be rendered invalid because the compiler would be targeting that same kind of CPU architecture that he was criticizing the hand generated assembly was targeting.

As I said elsewhere in this general thread about MenuetOS, compilers and assemblers which targeted the 4004 CPU still work at the opcode level with the current generation of Intel (and compatible) chips as well as several other offshoots. That is hardly optimized for the current generation of CPUs though.

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

[Teancum]

The old *nix "xv" image viewer still works if it's a static binary from 20 years ago. An ex-IBM guy I know mentioned some even older MSDOS game called "Alley Cat" that works on 32bit win7 (not sure about Win8).

MS-DOS games are run under a virtual environment that tries to mimic DOS and is what I call putting the computer into an historic mode of some sort. It is a "walled garden" where that software is not really running on the native hardware, and MS-DOS API calls as well as "standard" (as much as existed at the time) practices for I/O are intercepted and routed through the Windows drivers instead in a software sleight of hand. Yes, it works, but that software does not run natively within Windows 7. That virtual environment of course has limitations.

Furthermore, you can simply use VMware or something similar to create a virtual environment for most computers. I've seen Atari 2600 games (the original console made by Atari in the 1970's) run in Windows and even USB versions of the original game controllers if you want to go for authenticity.... and it even slows down the CPU cycles so the games play at "normal speed" of 1 MhZ CPU clock rate that they were designed for. I've also seen a VAX and PDP-11 emulator running on a PC, not that software written for those computers would even remotely be considered targeted for modern CPUs.

I stand by what I wrote above. Source code written for computers of 20 years ago will not work with the current generation of compilers without some significant tweaking and updating of the code. It won't be impossible and the core algorithms might even be worth hanging onto, but there still will be some major differences (likely with the I/O if anything). It will also look incredibly dated even if you get it to run.

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

[Phoghat]

Where are my goddam moderator points when I could really use them

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

[Mr Z]

I'm not sure why you think x86 is at all opcode compatible with the 4004. It's not even opcode compatible with the 8085. (You could translate 8085 code to 8086 with a special translator, but it wasn't guaranteed to be perfect.) The 4004 had a very weird instruction set, actually. Probably had something to do with the fact that you had to manually manage the memory bus and chip selects from the CPU, as opposed to more generic memory busses found on, well, just about anything outside the microcontroller world that talks to a JEDEC memory.

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.

This is the infamous memory wall, and lets face it, no processor vendor has figured out how to bypass physics and "just make memory faster." The problem was identified as far back in the 1940s, long before Intel even existed or Shockley's team at Bell Labs had invented their transistor. Consider this quote from Von Neumann himself:

Ideally one would desire an indefinitely large memory capacity such that any particular ⦠word would be immediately available. ⦠We are ⦠forced to recognize the possibility of constructing a hierarchy of memories, each of which has greater capacity than the preceding but which is less quickly accessible.

A. W. Burks, H. H. Goldstine, and J. von Neumann
Preliminary Discussion of the Logical Design of an Electronic Computing Instrument (1946)

But hey, I'm sure you've got some ideas. Why not get some VC money and make the next processor that will beat them all?

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

[Mr Z]

Ok, maybe not 20 years old, but 17 years old. Software I wrote in 1996 is still used today to verify chips built in the team I'm in at work. And that code compiles just fine. I haven't developed actively on it in about 14 years. No substantial tweaks to keep it current, either. I don't think it will compile as a 64-bit executable, but given that even Firefox is available as a 32-bit executable by default tells me that that's not a "historical" mode.

I was speaking with a team at work. They're talking about finally replacing some 30+ year old code in their code base with more modular, modern code. Sure, the whole package around it has continued to evolve, but some pieces date back to the first Reagan Administration. High level languages made that sort of continuity possible.

Now granted, the team whose code I'm referring to is a compiler team. Maybe, just maybe, they put more faith in compiled high level languages than your average programmer. ;-) But, their work on high level and low level optimization has paid off again and again. We have a kick ass compiler, and I say that as a hard-core assembly programmer whose job was to set the bar them. (I don't expect a compiler to beat me on assembly code I spent a month on. But, I expect a programmer using C/C++ with intrinsics and directives to get to 95% faster than I could in hand-coded assembly. That last 5% is what we call "diminishing returns," folks.)

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

[Mr Z]

Your argument only makes sense if you fix the target platform, compiler and compiler options for the comparison. In fact, it's trivially provably correct: If the compiler beats my assembly code, I can simply replace my own assembly code with the assembly code the compiler generated and force a tie.

However, that misses the point: I can write the fastest possible assembly for a given platform, but it might not be the fastest way to do something on a different (but compatible) platform. But the C code, without modification, could potentially beat my unmodified assembly code when compiled for that other platform. The compiler has the flexibility to tune its output for the target, while my assembly code is fixed for one target. And if you include platforms with a different underlying assembly language, the C code wins by default because my assembly code doesn't even run.

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

[Mr Z]

And probably the bigger point: The compiler will apply its smarts to the entire program. You're likely to not give a crap outside the few most important pieces. When you look at code quality across the entire application, who do you think will win?

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

[flargleblarg]

That is a terrible example.

It was meant tongue-in-cheeck.

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

[flargleblarg]

s/cheeck/cheek/ Too much coffee tonight; forgot how to English properly.

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

[mister_handy]

Yo dawg, I heard you liked Java...

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

[RockDoctor]

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

For general purpose CPUs, that may be true. For more specialised devices (possibly GPUs, other application-specific processors such as DSPs ... and lots of other cases), then the reduced complexity of the instruction sets may well reverse the equation.

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

[Amiralul]

Knock-knock.
Who's there?
(pause for 5 seconds)
Java!

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

[gbjbaanb]

not really possible - the point of such high level languages is that the levels of abstraction involved in such things are quite large. So to reduce this to something that can be turned into efficient assembly requires the abstractions be simplified, which effectively means turning the high level language into a lower level one.

Its just another of life's compromises.

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

[TangoMargarine]

Well, it all gets translated down to machine code in the end, so obviously it's feasible. I never said it would be easy...

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

[Anonymous Coward]

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?

Of course finding a machine with a FLOPPY will take MUCH MUCH Longer.

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

[Unknown Lamer]

You've never used Common Lisp, eh? One of the great parts of the language is that you can just grab 20 or 30 year old code off of the Net and have it Just Work (tm).

Of course, that might be because Common Lisp was 40 years ahead of its time.

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

[Anonymous Coward]

> Of course, that might be because Common Lisp was 40 years ahead of its time.

Or, it might be because Common Lisp is so arcane, nobody has successfully created any variants!

Gotta ask !

[amalcolm]

Why?

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 !

[NotFamous]

Gotta answer: 'Cause.

Re:Gotta ask !

[Anonymous Coward]

Boredom?

Re:Gotta ask !

[Anonymous Coward]

Everyone needs a hobby.

There's no other explanation.

Re:Gotta ask !

[jimbodude]

Why not?! The fact that it fits on a diskette means that a lot of bloat must have been cut out, leaving functionality. This means faster (and potentially better) software that uses the system's resources more efficiently.

Re:Gotta ask !

[pmontra]

To learn new things? Learning is stuff that matters.

Re:Gotta ask !

[SJHillman]

Why not?

If we asked Why? about every project out there, software and otherwise, we'd be stuck with a whole lot of unanswered questions.

Re:Gotta ask !

[poet]

Outside of the hobby aspect of it, there could be a real future in lower end devices.

Consider the resources that Android takes up. If you have something that is this small, efficient and presumably stable and you need to build out a lot of very small factor devices (phones, ereaders, tablets, medical equipment) something like this would be a very good thing.

Re:Gotta ask !

[Anonymous Coward]

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

Re:Gotta ask !

[SJHillman]

And he's probably right, assuming he's a reasonably skilled coder.

It's the difference between a factory-made mass-produced "good enough for most uses" product and an artisan-made hand-crafted "best of the best" product.

Re:Gotta ask !

[SJHillman]

There's already a pretty big market of embedded devices running Linux or FreeDOS... and who's to say that another competitor couldn't offer yet another, better option?

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 !

[Horshu]

Read Michael Abrash.

Re:Gotta ask !

[Anonymous Coward]

No, maybe it's just fun for him. What the hell is wrong with that?

Re:Gotta ask !

[amalcolm]

Don't get me wrong ... I think it's amazing that someone had the stamina to take the project so far. I do wonder if you really need to go THAT far to prove a point or learn sufficient about hand coding in assembler. Each to his own, I guess

Re:Gotta ask !

[plopez]

Masochism?

Re:Gotta ask !

[Anonymous Coward]

Because

* It's fun?

* They can?

* They want to?

* To learn something?

Sounds like a rationale for doing drugs. Or having sex. Not sure which of those two /.ers get to experience.

Re:Gotta ask !

[Bill_the_Engineer]

Why not? Assembly programming is a skill and for some an art. It's like asking a sculptor why he does what he does. It's not like we need to justify any project.

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.

Re:Gotta ask !

[Anonymous Coward]

Oh, come on. CPU and GPU speeds have for years already been such that demos just aren't impressive to spectators anymore. They may be artistic but nobody looks at a PC demo anymore and wonders how the fuck they managed to squeeze so much out of the hardware when a fucking visualization plugin for a media player can look equally sophisticated when it uses physics acceleration and just acts as cool shit on the screen when you happen to glance that way whilst listening to music and doing something else.

Re:Gotta ask !

[roc97007]

*Because someone should remember how to do this?

Re:Gotta ask !

[ShieldW0lf]

So they're easier to carry, there is no good reason and because you have no choice in the matter, respectively.

Re:Gotta ask !

[Anonymous Coward]

Why? WHY? In a world where http://en.wikipedia.org/wiki/AAlib, ttyquake, http://www.jfedor.org/aaquake2/, and aalib output for mplayer (http://www.mplayerhq.hu/DOCS/HTML/en/aalib.html) exist, you question the existence of a mere operating system?

Re:Gotta ask !

[fisted]

because

cc -x c - <<'X' && ls -l a.out
#include <stdio.h>

int
main(void)
{
printf("hello world\n");
}
X

-rwxr-xr-x 1 fisted users 7318 Nov 15 17:25 a.out*

Re:Gotta ask !

[Anonymous Coward]

No it isn't. That point of view was valid in the 80s. It's complete nonsense now. Unless assembly language magically makes your caches bigger or your memory faster it matters not one iota whether you spend 3 or 4 cycles performing some calculation. Fast code now means cache-aware code, and you ain't gonna be writing your best cache-aware code if you're also pissing around doing register colouring and instruction scheduling "perfectly" instead of 99% perfectly like a compiler does, so you can spend 199 cycles waiting for memory instead of 198.

Re:Gotta ask !

[arfonrg]

You've never seen my Assembly... You would take that statement back!

Re:Gotta ask !

[jythie]

I would argue that as CPUs get more complex and programs get larger, we have probably passed the point where even the best humans can optimize better in general cases. Short contained tasks sure, but even with infinite time humans have limits on how much they can keep track of in their heads. As the tasks get bigger and bigger one relies more and more on notes and whiteboards and other tools, at which point one is basically just implementing an optimized compiler from scratch and calling it 'by hand'.

Re:Gotta ask !

[fisted]

It's written in portable assembly, right?

Re:Gotta ask !

[clarkkent09]

They better get it perfect the first time cause this thing will be impossible to maintain for anybody else and possibly for the original developers too. Forget it, there is no practical use for it, it's just a hobby (not that that's a bad thing).

Re:Gotta ask !

[Java Pimp]

Neither. That's why we write things in assembly.

Re:Gotta ask !

[Anonymous Coward]

There's such a thing as premature optimisation ...

Re: Gotta ask !

[stokessd]

And security, who is going to write malware for that? Iran needs this controlling the centrifuges.

Re:Gotta ask !

[Anonymous Coward]

Why not?!

The fact that it fits on a diskette means that a lot of bloat must have been cut out, leaving functionality. This means faster (and potentially better) software that uses the system's resources more efficiently.

Do you mean that the system can wait for user input more efficiently? Since it's not like there's an abundance of resource-hungry applications for this OS that would benefit from it. And unless he develops a compiler which can compile apps written for a more popular platform as-is, there never will be. In theory you have a point but in practice it's like saying that cleaning railroad tracks by hand makes trains more energy-efficient. True but the more cost-efficient solution to get more performance is to pay for better hardware and not the man months the work takes.

Re:Gotta ask !

[Anonymous Coward]

The question is whether these small, cheap devices that presumably are not powerful enough to use something like OpenWRT would actually use a x86-compatible chip as opposed to, say, PIC or AVR.

Re:Gotta ask !

[ebh]

SWEET16

Re:Gotta ask !

[tlhIngan]

Consider the resources that Android takes up. If you have something that is this small, efficient and presumably stable and you need to build out a lot of very small factor devices (phones, ereaders, tablets, medical equipment) something like this would be a very good thing.

The issue is though that powerful CPUs are getting really cheap. Devices that don't need such power are finding themselves embedded GHz-class processors because that's the lowest end available that has sufficient power.

There's a gap between the 8-bit microcontrollers and the GHz-class processors these days, and it's widening - mostly because the cheapest SoCs are sporting high end cores and interfacing with really cheap RAM. Cheap enough that the mid-range ARM9s and ARM11 cores didn't save you a whole lot of money, and pretty much got squeezed out of the market.

Really. Check out the processors in the eReaders these days - they're easily hitting 800-1GHz in speed just to drive the e-ink display because that's the most cost-effective SoC. And they're swimming in 256MB+ in RAM, and really, the entire functionality takes just a tiny fraction of available resources.

Ditto with TVs - when the video processing SoC sports quad cores and all that, tossing in "smart tv" features is trivial because the power is there and there are few more moderate video processors.

Re:Gotta ask !

[Anonymous Coward]

I'm a Sadist, you insensitive clod! A masochist could never accomplish anything worthwhile in assembly language.

Re:Gotta ask !

[elfprince13]

Yeah, that too.

Re:Gotta ask !

[Anonymous Coward]

Big O motherfucker do you speak it!?

Re:Gotta ask !

[RabidReindeer]

Back when I first started, compilers were pretty stupid and basically did a 1-to-1 translation of source code to sequences of assembly language. It didn't take much to do better simply coding assembler by hand.

Somewhere about the mid 1980s that stopped being true. The IBM mainframe Pascal/VS compiler generated heavily-optimized code. It was sufficiently clever in its use of machine resources that it was on par with hand optimization.

The clincher, however, was that it could do this job in seconds, whereas hand-coding would take hours. And if you made significant changes to the algorithms you were coding, it would re-optimize each time. It would have been a total rewrite to get code that tight by hand. And even though we didn't have the insane time constraints that modern-day projects typically have, we didn't have enough time to make it worth doing that even to save expensive mainframe CPU cycles.

Re:Gotta ask !

[Anonymous Coward]

Yes, if this were 1993 and there was no such thing as a GPU, this would use the system's resources marginally more efficiently.

As it is with this and most other niche operating systems, the major compute resource is completely idle while the CPU spends a huge proportion of its time performing dumb-as-bricks blit operations just to get a GUI to display.

But I'm sure it has the fastest idle loop in history.

Re:Gotta ask !

[minstrelmike]

Like with entropy, the savings just get moved.
Now you've got to spend days trying to find a disk drive.

The researchers plan to add networking capability within the next 13 years, once they decide it's not just a temporary fad.

Re: Gotta ask !

[Anonymous Coward]

Some of us write code for processors with 512 bytes of program memory and 32 bytes of data memory. Self contained complete processors that cost a few cents each in volume.

No we don't code it in c++.

Re:Gotta ask !

[Anonymous Coward]

or restoring old cars, or hand crafted wood or metal work or really basically any hobby.

Re:Gotta ask !

[dfghjk]

That is NOT why optimizing compilers were invented.

Re:Gotta ask !

[segmond]

Yes they can. Try making use of a CPU with 8 cores and writing your threaded application in assembly. Someone with a compiler in a higher level language will kick your ass back and forth. The simpler the arguement the truth your argument holds, but as CPUs get more complex. Nope! Look at how difficult game programmers found it to program for the PS3 Cell architecture. Try having them write an entire game in assembly. Ha!

Re:Gotta ask !

[Peter Simpson]

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?

* he's following in the great Finnish tradition of writing your own OS... :-)

Re:Gotta ask !

[umghhh]

there is a point at which a thing is small enough to cause problem with transport as you have to attach it tosomething so that the flow of air does not bring the fucker away.

Re:Gotta ask !

[Ngarrang]

Why not? We have Windows Notepad, so why the need for anything other text editor? We have Microsoft Word, so why code ABIword? Why not create an entirely new OS in assembly? Because it can be done. We climb mountains for no better reason that because it is there.

Re:Gotta ask !

[war4peace]

I have to agree on that. While I always thought ASM is great, its greatness isn't universal. At any rate, *this* language will be better than *that* language for *this* specific task/project.

e.g. industrial robot programming, where you need to obtain maximum of speed and precision fit within minimum output size (e.g. 4 KB of storage, be it ROM, EEPROM, whatever) - that's where ASM shines. On the other hand, if you want to build an operating system, ASM will be better in less than 10% of the entirety of the OS; everything else is more efficient to build in a higher level programming language. That's because you have to consider time spent programming the stuff versus overall savings (time saved).

Re:Gotta ask !

[VortexCortex]

Why?

Well, I'm not well versed with the MenuetOS, but I've written a few toy OSs; Particular of interest to me is 16bit x86 which retains memory segmentation, and via other modes of operation (such as Unreal Mode enabled via addressing line 20) one can escape the 640K and/or 1MB limit whilst retaining other hardware features. Why go low level? Because programming paradigms are platform dependent. C is a product of its Von Neumann environment, and the dialog back and forth between hardware and software designers over the years has shaped our current methodology and hardware feature-set -- sometimes for the worse, IMO. E.g.: When we sacrificed a whole register and its memory segmentation capabilities to the RAM gods we made position independent code far more inefficient, and things like coroutines, stack smashing protections, multi-dimensional V-Tables for stateful OOP (eg: methods that change functionality depending on an object's "state" field), separate stacks for code pointers and parameter data, heap code pointer isolation, etc. more difficult (or near impossible) to accomplish. Instead of ASM I use a low level compilable and interpretable bytecode language for writing my OSs, and have multiple functional C compilers implemented atop the byte-code language in order to utilize existing hardware drivers -- However, I frequently dive into the machine specific ASM in order to implement and explore new features.

I started doing hobby OS work for fun, but after reading Ken Thompson's On Trusting Trust ACM acceptance "presentation" I decided that it would be a worthwhile project to create and maintain a few machines isolated from the rest of the world which are bootstrapped and programmed entirely by me. I now use them to write my memoirs and for teaching children how to code and build custom hardware and robotics -- The parallel port is very simple to utilize without a massive OS like GNU/Linux in the way...

The better question is why would anyone attempt to implement a POSIX OS today? We have working implementations. That feature set is proven. If we want to make advancements in OSs and hardware architectures we'll have to try doing things in different ways. Some of my OSs are cross platform; In one all programs are compiled down to the bytecode form by the VM ASM, or C compilers. The OS itself translates byte-code into machine code ON INSTALLATION, and gives the option to instead interpret a program if its untrusted (or in development, or self modifying) to contain it in an actual sandbox. On 32 bit x86 with more than one bit worth of execution privileges I'm able to enforce at the hardware level something akin to kernel mode at the application level for applications to isolate themselves from possibly untrusted plugins, and allow transparent lazy linking with emulated bytecode modules and optional JIT translation.

For me the aim isn't to replace GNU/Linux or any mainstream OS. The aim is to explore unexplored problem spaces with the hope that any useful techniques may find their way into mainstream usage. Consider Google's NACL and LLVM. I'm not saying experimental OS projects which pre-date them are responsible for their current capability to compile C into cross platform bytecode and compile it into machine code, but us hobby OS folks HAVE been doing just that for longer than their projects have existed. Our experimental niche OS endeavours occasionally blaze the trail towards new features in mainstream hardware and software. Eg: I'm hoping for code pointer isolation and buffer overrun prevention via dual stack architecture, and for the ARM folks to give us more that 1 bit of privilege level so that secure designs other than Monolithic Kernels can be implemented...

To the other commenter above who thinks "decades-of-practice" will allow optimizing compilers to utilize hardware features that are forbidden or don't exist: Ugh, no. I have decades of experience writing ASM and can write or generate much smaller & more efficient position inde

Re:Gotta ask !

[Anonymous Coward]

Sadism too?

Re: Gotta ask !

[Immerman]

>No we don't code it in c++.

Damn straight, something that basic requires... BASIC. (sorry flash-backs to dabbling with BASIC-stamp based robotics in college)

Re:Gotta ask !

[Anonymous Coward]

You mean C code?

Re:Gotta ask !

[Anonymous Coward]

Nope. Former PS3 SPU assembly programmer here. It takes skills and an attention detail. I've written great gouts SPU assembly. The SPU is a crappy architecture for sure, but I've done 5+ SPU coordinated assembly code.

Re:Gotta ask !

[Megol]

Bullshit. Thinking that caches are the only thing that matters just indicates that you are clueless when it comes to optimization (and most likely much more too). But also when it comes to caching assembly language programmers tend to generate tighter code leading to less instruction cache misses.

Most instruction scheduling is done by the processor, it's a "new" thing called OoO or out of order execution. The rest is trivial.

Register coloring is a funny way to describe register allocation, normally a coloring algorithm isn't used by assembly language programmers as it just isn't useful. Register allocation is needed yes however a linear scan algorithm combined with (learned) heuristics is probably closer to what real programmers use. The performance difference is in the noise anyway. BTW standard register coloring isn't optimal for x86.

Re:Gotta ask !

[jythie]

*nod* and often when one is developing such industrial applications, the CPUs themselves are simpler and more predictable in design. This is esp the case when you are working on stuff that actually needs to count cycles for real time behaviors.

Re:Gotta ask !

[dargaud]

xplain to me how a human can optimize by hand a 70-stage execution pipeline with branch predictions ? Impossible. On the other hand the compiler has the specs of the processor and knows how many nops to place between instructions.

Re:Gotta ask !

[EETech1]

Aren't they all:
JMP PC-1
?

Re:Gotta ask !

[Anonymous Coward]

I got it on good authority that some of us occasionally do both.

Re:Gotta ask !

[Anonymous Coward]

He said learning...

Re:Gotta ask !

[Megol]

"Xplain" to us all which processor have a 70 stage execution pipeline and requires nops? I sure don't know of any.

Re:Gotta ask !

[Anonymous Coward]

Because they have spent 13 years on it. There was little value brought by extra efficiency of this time consuming process 10 years ago, today there is none (other than the personal enjoyment they get from doing it). Sure it is compact, but compared to a modern OS, it does virtually nothing.

Re:Gotta ask !

[Anonymous Coward]

You just attach it to other useful things, so a decrease in size enables you to increase the utility.

Re:Gotta ask !

[varmfskii]

Statically link that and see how much worse it becomes.

Re:Gotta ask !

[Anonymous Coward]

Compilers can never optimize better than the *best* humans, operating without time constraints.

On one hand a retard could beat a good compiler by endless trial and error, on the other hand a compiler could be written to do the same running in an endless compile/test loop.

Re:Gotta ask !

[unixisc]

Another question I have is 'which'? Would the entire x86 instruction set be supported? For the x64, which ones would be? After all, Intel adds a few instructions depending on the processor generation, so for the closed source x64, which one would it be?

Re:Gotta ask !

[Crimey McBiggles]

Oh snap! (for the uninformed, this is a reference to how Linux came to be).

Re:Gotta ask !

[fisted]

*mutters something about the C Abstract Machine*

Re:Gotta ask !

[TangoMargarine]

because you have no choice in the matter

Some philosophy gives suicide as the other side of the choice.

http://en.wikipedia.org/wiki/Absurdism

Re:Gotta ask !

[maxwell demon]

Compilers can never optimize better than the *best* humans, operating without time constraints.

Well, at least the "working without time constraints" part seems to apply here. Although I guess if you were to tolerate compile times measured in days per source file, compilers could also do much better optimizations ...

Re:Gotta ask !

[Anonymous Coward]

Michael Abrash is brilliant, but a lot of what he wrote about optimization is dated now. For one thing, you don't have exclusive control of the machine. For another, the CPU speeds have increased so much that the difference is often negligible. An optimization that might have cut execution time from 5 seconds to 1 second in 1995 may now be a difference of a millisecond vs. half a millisecond.

Still, he has some timeless wisdom to offer.

1) the best optimizer is between your ears - find a better algorithm before hand-coding assembly.
2) know where optimization is most effective and optimize the bottlenecks out
3) know when to stop - if further optimization would be pointless (i.e. unnoticeable to the user) then don't bother

Re:Gotta ask !

[dbIII]

Try making use of a CPU with 8 cores and writing your threaded application in assembly

No point bringing that up, it seems like 95% of all programmers can't write a threaded application in anything (including ones young enough to have grown up with a dual core handheld Nintento game). Multiple CPUs are ubiquitous but so many progammers are acting like it's still 1992.

Re:Gotta ask !

[dbIII]

Really. Check out the processors in the eReaders these days

If they are doing anything with PDF they need all that grunt. The "entire functionality" takes everything it's got and still shows the user a bit of lag every now and again. For plain text and simple epub the first generation of ereaders is still plenty.

Re:Gotta ask !

[c0lo]

The true masochist codes in Malbolge.

Re:Gotta ask !

[Anonymous Coward]

Polly: "What't the point in being alive?"
Basil: "Beats me... stuck with it, I guess."

Re:Gotta ask !

[Anonymous Coward]

I think you've got that backwards... a lot of functionality was cut out, leaving room for an idiot who refuses to acknowledge that the compilers are way better than he is. He needs to have a good cry and get over it.

Re:Gotta ask !

[Anonymous Coward]

Yet another contradiction from the religious fuckers!
"God gave you free will!"
"You will spend eternity in heaven or hell!"
Where's the choice to cease existing? Obviously, either there is no free will, or there is no "life after death". Life before death is much cooler, anyway.

Re:Gotta ask !

[Anonymous Coward]

Probably the Shitanium. All dose NOPs! All dose hamboigahs!

Re:Gotta ask !

[ShieldW0lf]

because you have no choice in the matter

Some philosophy gives suicide as the other side of the choice.

http://en.wikipedia.org/wiki/Absurdism

"A live body and a dead body contain the same number of particles. Structurally, there's no discernible difference. Life and death are unquantifiable abstracts. Why should I be concerned?"

Re:Gotta ask !

[Anonymous Coward]

qubes-os.org/

Re:Gotta ask !

[Anonymous Coward]

Depends on how you define efficient. I don't know a single assembler geek that can't shave code to be smaller and faster than compiled.

Still, thirteen years is pretty inefficient. Bordering on self-abuse. In both senses of that phrase.

Re:Gotta ask !

[Man Eating Duck]

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.

And even most PC demos today are coded in high-level languages like C++. The guys writing space-constrained demos (64K and less) will turn to assembly. But on the PC you generally can't beat the compiler performance-wise, and in the few cases where you might have squeezed out a couple of percents better performance your time will be better spent polishing your effects.

Source: I discussed this with one of the coders in Andromeda, who has experience both from the Amiga and PC scene.

Technically everything is written in assembly

[Anonymous Coward]

We just trust that compilers know what they're doing.

Re:Technically everything is written in assembly

[Anonymous Coward]

By that technicality, it's actually written in machine code, not assembly

Re:Technically everything is written in assembly

[Anonymous Coward]

Naah, on modern CPUs it's written in Microcode...

Re:Technically everything is written in assembly

[Anonymous Coward]

Technically everything is written in assembly

It's been decades since I've seen a compiler which went through an assembly language stage.

By that technicality, it's actually written in machine code, not assembly

Correct.

Naah, on modern CPUs it's written in Microcode...

Also correct.

In the end it's all NAND gates.

Re:Technically everything is written in assembly

[Anonymous Coward]

It's been decades since I've seen a compiler which went through an assembly language stage.

You haven't seen GCC in decades?
> gcc -v tmp.c
[snip]
c:/devel/mingw-w64/bin/../libexec/gcc/x86_64-w64-mingw32/4.7.1/cc1.exe ... -o ...\Temp\ccQPcuzk.s
[snip]
c:/devel/mingw-w64/bin/../lib/gcc/x86_64-w64-mingw32/4.7.1/../../../../x86_64-w64-mingw32/bin/as.exe ... -o ...\Temp\ccE9vXJY.o ...\Temp\ccQPcuzk.s
[snip]
c:/devel/mingw-w64/bin/../libexec/gcc/x86_64-w64-mingw32/4.7.1/collect2.exe ...

Re:Technically everything is written in assembly

[maxwell demon]

In the end it's all NAND gates.

Of course that's barely the end. NAND gates are made of transistors and resistors.
But in the end, it's all nothing but quarks and electrons, bound together and moving in various combinations and patterns, interacting via strong force (gluons) and electromagnetic force (photons).

Re:Technically everything is written in assembly

[Ford Prefect]

But in the end, it's all nothing but quarks and electrons, bound together and moving in various combinations and patterns, interacting via strong force (gluons) and electromagnetic force (photons).

Actually, below that it's mostly Perl.

Re:Technically everything is written in assembly

[jeremyp]

I've read the whole thread and this is the first post off which I can legitimately hang an obligatory XKCD reference.

Finally a fast OS

[Anonymous Coward]

Now can I run Firefox on it to play online games while playing zeroconf-shared music?

That's not the most important thing

[Anonymous Coward]

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.

Re:That's not the most important thing

[ihtoit]

I have a (n opened) box of virgin Verbatims and two Dell USB floppy drives (not to mention a Mitubishi IDE LS-120 which also reads floppies!), somewhere around I've also got a still shrinkwrapped box of 20 Sony DSHD disks.

Re:That's not the most important thing

[HoldmyCauls]

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.

Re:That's not the most important thing

[drinkypoo]

I keep an LS120 in my desktop PC just in case. Guess how many times I've used it.

I did use the Sony USB floppy once. So I consider that two dollars well spent at a yard sale

Re:That's not the most important thing

[roc97007]

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.

Re:That's not the most important thing

[Anonymous Coward]

but does it come with reversi?

Re:That's not the most important thing

[sl4shd0rk]

here ya go...

http://www.newegg.com/Product/Product.aspx?Item=N82E16821121001

http://www.amazon.com/Verbatim-3-5In-1-44MB-Pre-Fmt-10Pk/dp/B0000511BI/

Re:That's not the most important thing

[medv4380]

I'm not even sure if my Motherboard will accept a Floppy drive, or do I have to go looking to see if anyone makes SATA floppy drives.

Re:That's not the most important thing

[ihtoit]

got a pile of tape drives as well, they've come in useful (you'd be surprised at the number of people who have tapes but somewhere along the way they've "lost" the hardware...). One I wouldn't mind getting my stickies on is a PlusDeck MK.I - the IDE model, which had a high speed option (read/write a C60, both sides at once, in about 90 seconds!). I don't know why they dropped the high speed option for the II or record facility on the IIc... but for now, I'm making do with an ever dwindling supply of portable cassette decks as I burn through them ripping my mixtapes and conference audios (I got bloody millions of 'em!).

Re:That's not the most important thing

[Immerman]

Show some consideration!

Sure they haven't been used in years, but do you have any idea how much paperwork has to be filed in order to throw out those perfectly good floppy discs?

Re:That's not the most important thing

[roc97007]

Yes. Probably the easiest solution would be for someone to steal them. Except that nobody wants them.

Re:That's not the most important thing

[dbIII]

A USB one set me back a full $19 two months ago and I've got about twenty ordinary floppy drives on my workbench. Finding a new motherboard with the interface could be a bit tricky though. Software can throw up some challenges, in linux the floppy disk driver module doesn't load by default these days so last time I had to read a disk in for someone I ended up looking up how to do it (though it was utterly obvious in hindsight - the module name is "floppy").

Cool!

[elfprince13]

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.

Re:Cool!

[Lawrence_Bird]

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!

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

Re:Cool!

[SuricouRaven]

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

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:Cool!

[shaitand]

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 instance a cluster node that dynamically grabs it's parameters from the network on boot. Or a wrist watch, or an alarm clock, or a washing machine.

Re:Cool!

[Lawrence_Bird]

Thank you for a better explanation of what I was alluding to.

Re:Cool!

[i kan reed]

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?

Re:Cool!

[Anonymous Coward]

Indeed, people have completely forgotten. Which is why we don't have HPC clusters, wristwatches, alarm clocks and washing machines anymore, and only ever see PCs....

Point being, who is the "people" you speak of? Engineers know and use as appropriate.

The rest of computer users didn't forget. They simply used to not use computers.

Re:Cool!

[shaitand]

"Without basic tools to do so, how are you going to get software on your Operating System?"

You'd likely build an image with a more general purpose system that had tools on it then flash or network boot. The question would make more sense if I was building something rather than pointing out that the term "operating system" used to refer to a basic system that managed resources to simply programming (the operating system) rather than the more modern idea that an "operating system" is the software set that allows a human to operate the computer.

It's even more confusing because operating a computer back in the day was often synonymous with programming one.

Re:Cool!

[shaitand]

"Point being, who is the "people" you speak of? Engineers know and use as appropriate."

Fair enough and a computer engineering course on operating system design is going to teach design principles for a kernel. But the general population, even the general technical population, certainly isn't using the word this way. It's at the core of the whole Linux vs GNU/Linux debate.

As hardware becomes more and more powerful even wristwatches, alarm clocks, and washing machines are often running cli interfaces now. So the concept gets more and more difficult to explain.

I can beat that

[Anonymous Coward]

I was running GEOS on my C64 25 years ago! Last time I checked, it was all written in assembler, and it was an OS.

Re:I can beat that

[SJHillman]

But did it support USB, TV tuners, and webcams?

Re:I can beat that

[NonUniqueNickname]

But did it support USB, TV tuners, and webcams?

Yes it did! GEOS supported all the existing USB TV tuners and webcams of its time.

Re:I can beat that

[Anonymous Coward]

Did UNIX in 1986? I guess that means it wasn't an OS.

Re:I can beat that

[arfonrg]

+1 Virtual Mod point to parent

Re:I can beat that

[SJHillman]

I never said it wasn't an OS, I was just pointing out one of the things that would make this more of an accomplishment.

Re:I can beat that

[Anonymous Coward]

"this" what? GEOS?

In theory this could be awesome

[Anonymous Coward]

.. assuming that they could bring it up to par with modern operating systems (which of course is a gigantic leap of faith) .. in theory it could be the leanest OS EVER created.

Re:In theory this could be awesome

[SJHillman]

A lot of the bloat in modern OSes comes from having to support a wide range of hardware - it's one of the reasons Linux can scale down to run on a tiny embedded system if you strip out that hardware support and other unneeded features (such as a fancy UI). You might even find that it doesn't scale well onto higher-end systems.

Not open source

[Anonymous Coward]

Well 32 bit is but 64 bit isn't... Lame.

Re:Not open source

[TheRealMindChild]

It was written in assembly. Decompile it. BAM, source code

Re:Not Open Source

[jones_supa]

The original source code is still probably "more open source" as it has appropriate names of labels, comments, and other stuff.

Re:NOT OPEN SOURCE

[Anonymous Coward]

How can there be a non-open-source ASSEMBLY program? It is not like they will use an optimizing assembler?

Re:Not open source

[grumbel]

Against the license:

Menuet64 Copyright (c) 2005-2013 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.

[...]

Re:Not open source

[nurb432]

Having the source isn't the same as it being open.

You can steal the source to windows.. but that doesn't change the fact its closed source. Its a licensing issue, not availability.

Re:NOT OPEN SOURCE

[maxwell demon]

By the license explicitly disallowing to disassemble the machine code.

Re:Not open source

[jeremyp]

Well just get the 32 bit version and recompile it for 64 bit.... .... oh, wait...

Seriously, 13 years?

[Anonymous Coward]

Microsoft, Apple and Google update their OS about every year or two. If MenuetOS took 13 years to get to version 1.0, how long would it take them to release a bug fix? Is there a guarantee of a hot fix in 7 years or your money back?

Re:Seriously, 13 years?

[lil_DXL]

It's an open source project, all it takes to speed up development is that more people get involved in it. Almost all of the code of MenuetOS was written by the same guy (who also holds a regular job, according to google), that's the main reason why it took so long. The C compiler included is also the work of a single programmer... guess we could call this kind of software as "vanity software"

Re:Seriously, 13 years?

[Anonymous Coward]

Agreed. It astounds me that a hobby project doesn't have the resources to match the deadlines of corporations worth hundreds of billions of dollars.

Re:Seriously, 13 years?

[Anonymous Coward]

Well, the credits only lists 5 people.(one of them only wrote the floppy driver) And I doubt it's a full time job for any of them.

Re:Seriously, 13 years?

[Anonymous Coward]

Is there a guarantee of a hot fix in 7 years or your money back?

Yes, you can get a full refund of the purchase price.

Potential uses?

[Anonymous Coward]

What could I potentially use this sort of OS for? In what environment would it be pretty handy to have? Or is this a sort of a cool kids thing where it exists just because it can?

Re:Potential uses?

[SuricouRaven]

Embarrassing the creators of all the OSs that take five minutes to reach desktop.

still around?

[Anonymous Coward]

I thought this thing was done years ago. Good to see it going though and a great example that modern operating systems don't have to be written in C.

Does it run on Raspberry pi?

[Anonymous Coward]

hmmm probably not... x86...

This is cool but...

[Anonymous Coward]

It is entirely a 'cause we can project. It is a misnomer that assembler is faster than C code in practice. Most compilers and optimizers can take advantage of modern hardware's (i.e. x86's) continuing changing architecture. Things that were fast on core2duo may be slower on core i7, and they may have introduced new operations to do XYZ faster still.

Not to mention that securing asm is a nightmare, very very time consuming. Even their '13 years' isn't enough.

Re:This is cool but...

[Wootery]

Not to mention that securing asm is a nightmare, very very time consuming. Even their '13 years' isn't enough.

Indeed, but C doesn't have a great track-record either.

I suspect Menuet's minimalism would be a great point in their favour when it comes to security. I doubt security is that high up their list though. Not to mention that practically speaking, they're not worth anyone's time to attack.

Assembly language

[Anonymous Coward]

funny, I was just reading about high level assembly, Art of Assembly Language http://www.plantation-productions.com/Webster/

Nice to see some geeks are still experimenting with assembly language. I haven't heard much about assembly language since I have graduated from college about 10 years ago. Thanks for posting the link.

Lame

[plopez]

Real Programmers write assembly language operating systems on punch cards.

Re:Lame

[roc97007]

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

Re:Lame

[lil_DXL]

Real programmers use a magnetized needle and a steady hand

Re:Lame

[laejoh]

Maybe they do now, in this decadent era of Lite beer, hand calculators, and “user-friendly” software but back in the Good Old Days, when the term “software” sounded funny and Real Computers were made out of drums and vacuum tubes, Real Programmers wrote in machine code. Not FORTRAN. Not RATFOR. Not, even, assembly language. Machine Code. Raw, unadorned, inscrutable hexadecimal numbers. Directly!

Re:Lame

[Anonymous Coward]

Assembly and punch cards are for sissies. I used to write bit codes and burn them into PROMs using toggle switches. Very straight forward: set address bus with a row of toggles, set data bus with another row of toggles and push a button to burn the word into the PROM. If you make a mistake, just throw the PROM into the trash can and start with a new one from the beginning. Those were the good old times! Teaches you to write compact code and not make any mistakes.

Re:Lame

[minstrelmike]

headline: Buggy Whip 2.0 released.

Re:Lame

[gaudior]

Hexadecimal?! Luxury! We had to code ones and zeros, on clay tablets.

Re:Lame

[Anonymous Coward]

Real programmers use butterflies. http://xkcd.com/378/

Re: Lame

[Anonymous Coward]

Real programmers write machine code with diode arrays, wire cutters, and solder.

Re:Lame

[Capt.DrumkenBum]

You had zeroes?!?!?!?!?
We had to substitute the letter O

Re:Lame

[Bacon Bits]

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 "mature" and is no longer considering enhancement requests or bug fixes... they all get marked WONTFIX with the comment "working as designed". Unfortunately the original code is extremely convoluted and seems deliberately obfuscated, so it's not really possible to fix the numerous bugs and errors in the system even if a build environment can be replicated.

Worst of all is the toolchains used... it's like the worst case of "not invented here" and "feature creep" ever. Space-time and matter-energy libraries reference each other recursively to create the atomic system, and then he uses that to create biology programs that are self-replicating and self-evolving, which in turn have their own applications. No wonder reality is so screwed up. It's worse than that Linux VM running in JavaScript.

Re:Lame

[Anonymous Coward]

I prefer cosmic rays, less risk of stabbing myself with the needle

Re:Lame

[maxwell demon]

You had clay tablets? Luxury. We had to carve ours in stone.

Re:Lame

[dbIII]

I always find this sort of chest beating amusing since I was mucking about with the 6502 and Z80 for about three years with machine code before I even got access to a compiler. Even now I still have a lasting impression that an assembler makes everything so much easier.

Re:Lame

[Anonymous Coward]

We used Haskell on ours.

More modern programming language?

[Anonymous Coward]

Does the OS come with a more modern application programming language than assembler, such as Forth? I'd like to use it, but fear of having to learn assembler keeps me away from it. So it would be good to have a modern programming language such as a nicely threaded Forth interpreter or a simple LISP system implemented on top of this ... for the rest of us, who are afraid of assembler.

Re:More modern programming language?

[roc97007]

Assembler really isn't that hard. My first three years as a programmer were assembly language only for embedded applications. It's like anything else -- you memorize stuff and after awhile you see every problem as a list of assembly instructions. Later, using C seemed like cheating, in a way.

Re:More modern programming language?

[Anonymous Coward]

I actually liked assembly better than C. There were fewer commands to remember, and you just had to keep track of everything. It actually ran very fast on my old computer as well.

Apple should be hiring a bunch of assembly programmers and rewriting some code in assembly for better performance...

Gotta ask !

[Anonymous Coward]

Why bother making electronics small?
Why bother looking for dark matter?
Why bother existing?

Why? Because the universe exists, that is why.

Pointless?

[lil_DXL]

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

Re:Pointless?

[Anonymous Coward]

Is this Slashdot at all?

Yes, but not as you know it.

I wonder ...

[PPH]

... how many developers cheated. Coded their module in C or C++ and ran it through gcc with the -S switch.

Re:I wonder ...

[DigitAl56K]

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?

Re:I wonder ...

[GodfatherofSoul]

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

Not Open Source

[Anonymous Coward]

MenuetOS isn't open source. The web page mentions the (dead?) 32bit version is GPL, but the 64bit version is release under a non-free license:
http://www.menuetos.net/m64l.txt

Changing definition of Kernel

[canadiannomad]

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.

Re:Changing definition of Kernel

[Anonymous Coward]

What's all this "we" stuff? You haven't done anything.

Re:Changing definition of Kernel

[canadiannomad]

Touché

Re:Changing definition of Kernel

[Bite The Pillow]

This is not a kernel, nor is it the core of an operating system. This is a full operating system which supplies what you need, out of the box, to accomplish stuff. The kernel plus the core plus bundled stuff. That's what comes with MenuetOS.

This has nothing to do with defining a basic operating system. This is making one smaller so it gets out of the way of the stuff you want to run - including the stuff bundled with the OS.

Re:Changing definition of Kernel

[canadiannomad]

Fair enough, I assume that comes out of my lack of understanding about how MenuetOS is designed/architected. I kinda assumed it was kinda monolithic in its assembled form... I am probably wrong on that point.

so....

[smash]

"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 interesting research project, and is no doubt likely to be quite a lot faster than any other multi-user OS, those are some MASSIVE trade-offs, especially with regards to security and stability.

Re:so....

[smash]

and just on that.... you can increase speed by throwing hardware at the problem. you can't increase security or stability by doing that.

Re:so....

[Anonymous Coward]

Perhaps not, if you take into account that the vast majority of all OS users do all of their daily tasks from one account, which also happens to be the administrator account ...

Re:so....

[unixisc]

Re-reading the Menuet page, I'm not sure how much is multi-user tied to multi-processing, multi-threading or pre-emptive multitasking, but MenuetOS has the latter 3. They also mention ring3 protection.

Re:so....

[unixisc]

At home, I have different user accounts for different family members. There are times I've even given myself different user accounts w/ different privilege levels, depending on what I need where.

Re:so....

[maxwell demon]

and just on that.... you can increase speed by throwing hardware at the problem. you can't increase security or stability by doing that.

That's not true. If you throw a big hammer (obviously hardware) at your system, you can make it very secure. Well, it won't work any more, but it is well known that only a switched-off system can be perfectly secure, and the hammer treatment ensures that the system will never be switched on again.

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

[Em Adespoton]

There's another reason for this too... today's CPUs are designed to recognize some standard compiler instruction chains and shortcut them -- so if you hand-code those instructions, the CPU will have to take your instructions literally, whereas if you use the manufacturer's compiler (or a common compiler such as provided by GNU or MS), the CPU will often recognize the expensive routines and optimize them for you in the pipeline.

That said, if the assembler actually knows the cpu they're targeting, they can take advantage of these pipeline shortcuts as well. But it won't be portable unless they duplicate a lot of the logic that goes into compilers in the first place -- at which point, you're adding an extra layer that's going to take more time/space.

Re:Might actually be the case

[NewWorldDan]

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.

Re:Might actually be the case

[Joce640k]

Very much agree with this. The compilers, for the most part, are smarter than people at optimizing code.

I wouldn't say they were smarter than good assembly programmers but they do a good enough job and they allow you to refactor your code much more easily than when you use assembly language.

Tweaking your code and data structures can give more of a speed boost than having tight inner loops but assembly language makes it very difficult to fiddle with code in this way. The equivalent of changing a couple of lines in a C++ header file on a large program might create a week's work in assembler.

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

[Anonymous Coward]

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.

Re:Might actually be the case

[NJRoadfan]

Try telling that to Steve Gibson....

Re:Might actually be the case

[Anonymous Coward]

I have never seen a case where Java outperforms C... Ever.

Re:Might actually be the case

[Anonymous Coward]

Compilers written by people are never smarter than "people". They are smarter than a "person". This is because the compiler represents the accumulated progress of all of the people that have worked in its creation.

This also means that a new, unknown optimization might be discoverable by a person that can, for a time, make that person's code faster than a compiler's. Then that person should add it to the compiler, allowing everyone's code to be faster. In theory.

Re:Might actually be the case

[Megol]

There's another reason for this too... today's CPUs are designed to recognize some standard compiler instruction chains and shortcut them -- so if you hand-code those instructions, the CPU will have to take your instructions literally, whereas if you use the manufacturer's compiler (or a common compiler such as provided by GNU or MS), the CPU will often recognize the expensive routines and optimize them for you in the pipeline.

That said, if the assembler actually knows the cpu they're targeting, they can take advantage of these pipeline shortcuts as well. But it won't be portable unless they duplicate a lot of the logic that goes into compilers in the first place -- at which point, you're adding an extra layer that's going to take more time/space.

I think you are mistaken here. Yes some Intel processors optimize some instruction patterns however those same patterns are those that are used by assembly language programmers too. Some examples of this is fusing together some comparison instructions followed by a conditional branch. Any assembly programmer not using that pattern isn't optimizing for performance either by ignorance or intention (=size optimization). Now these patterns have been used since the Pentium Pro was released so it isn't a recent change.

Somewhat more esoteric is the detection and special handling of CALL x; x: POP EAX type patterns. Here one calls the next instruction (labeled x here) causing the processor to push the return address onto the stack which then is then stored into the EAX register by the POP instruction. Intel processors detect this pattern and avoids treating it as a branch instruction leading to faster execution.

Other than those two examples I can't recall anything not exposed to assembly language programmers - in fact those kind of rewrites _are_ exposed to programmers if they'd bothered to read the manuals.

Re:Might actually be the case

[PRMan]

I have. It's very simple. Because of JIT, a Java or .Net compiler can optimize more easily for multiple CPUs or additional instruction sets (such as 3DNow/MMX) and also to use all the registers in 64 bit automatically but store in the heap or stack on 32-bit. All of that would be difficult to do in a single C program and could easily lead to the Java or .NET program outperforming C.

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]

2) Why write assembly language
No, one does not write assembly language for "fun"

Yes, I do write asm for fun.

Re:Might actually be the case

[Anonymous Coward]

JIT, profiling, etc. are cheating. I.e., it proves compiler did not understand enough to generate good code until it measured the execution.

Re:Might actually be the case

[Anonymous Coward]

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

[citation needed]
Ever heard of JIT compiler and run-time profiling/optimization? C doesn't optimize past the compiler (or link-time optimizer). Java does it at runtime, so it can include all static analysis C does and then more.

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:Might actually be the case

[Anonymous Coward]

I have. It's very simple. Because of JIT, a Java or .Net compiler can optimize more easily for multiple CPUs or additional instruction sets (such as 3DNow/MMX) and also to use all the registers in 64 bit automatically but store in the heap or stack on 32-bit. All of that would be difficult to do in a single C program and could easily lead to the Java or .NET program outperforming C.

But... but... GENTOO!

Re:Might actually be the case

[WaffleMonster]

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 substantially less than outcomes where reliability and performance are required why is the market not running to high level languages if the compiler is king?

Re:Might actually be the case

[Anonymous Coward]

It is simple a matter of formula.

x = time to compile C
y = time to run C

z = time to compile jit
x' = time to jit java/net/python (usually happens once per code run sometimes many if something changes)
y' = time to run java/net/python

if y > x' +y' then yes you will out perform

x and z never really enter into the picture as those are a one time function done by the developer or at first runtime (depending on your language and its runtime environment).

Now if x'+y' is less than y that means one of two things. Either my C compiler stinks. Or the java code has more information. Or both.

All of that would be difficult to do in a single C program
Utter hogwash. Your compiler is not good enough then. For example the intel msvc compiler is known to emit two code paths. One for intel cpus and one for other cpus. This means at runtime the path of code can change. Usually by the use of lookup/jump tables. It is trivial to lookup a cpu model. What you do with that information is different and could easily be baked into a C program. It is usually time and memory constraints that limit you doing this. Even with JIT you basically are doing many mini compiles and just emitting the correct cpu set for your cpu.

Java is just a language. As is C. I could in theory write a JIT C. That does not mean JIT is better. It is just a way of shipping more portable os agnostic items (in theory, practice has shown differently).

Most good optimization comes from picking better algs than fiddling the compiler settings. Fiddling the compiler settings (jit vs static run is just a variation of that) usually only yields 3-10% performance. For example ASM tuning is usually just picking better instructions than the compiler did and picking a better scheduling of them. You tweaked the algorithm.

This AC put it best http://tech.slashdot.org/comments.pl?sid=4449941&cid=45434751 In practice it is more about scheduling of scarce resources and finding ways to move it into parallel steps as much as possible.

Re: Might actually be the case

[Anonymous Coward]

Bah! C/C++ = fail. Assembly is for pussies. Why not write in native machine code like the rest of us men!

Re: Might actually be the case

[Anonymous Coward]

Bazinga!

Re:Might actually be the case

[TangoMargarine]

I should really get back on top of that "assembly scripting" project I was making for fun, if for no other reason than to watch programmers' eyes twitch when I mention it.

Re:Might actually be the case

[Arker]

Chess is of course a slightly different situation.

The chess algorithm cannot literally be 'smarter' than the people that wrote it (they are perfectly capable of doing the same thing it does) but a computer can still execute that algorithm faster - it can do calculations that would take the human days to accomplish in seconds. In time to actually use those calculations to choose a move.

Similarly, a compiler can produce reasonably optimised output MUCH faster than a human programmer. Never denied it.

Re:Might actually be the case

[Bite The Pillow]

Why are you arguing about speed when the project goals are about having a small OS with few layers?

The goal is to have your code go fast due to minimal layers, and apparently to have an ASM-friendly environment. The entire design could be accomplished in C, but it is in ASM because people who write an ASM friendly OS from scratch are probably interested in writing ASM.

Once you have a C library and can compile things like Quake (screenshots are on the homepage), equivalent code should run faster on MenuetOS compared with Linux or Windows. It's not guaranteed, because you can customize your OS to some extent. But to generalize, most things should respond more quickly on Menuet than an equivalent OS without code changes.

Faster is a side effect of design, and language choice is a side effect of the OS purpose.

Re:Might actually be the case

[Anonymous Coward]

1 million plus this.

Re:Might actually be the case

[Anonymous Coward]

Assembly language programming is fun and forces you to stretch your mind. At university I developed a 32KB operating system on a single 2.88MB diskette using nothing more than pencil, paper, and MS-DOS DEBUG. It was an interpreted operating system with a small kernel and interpreter written in assembly language.

Re:Might actually be the case

[dbIII]

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.

Re:Might actually be the case

[Anonymous Coward]

Would you care to substantiate those claims that somehow JIT compilers generate faster code that traditional compilers? I've NEVER see C# or Java code run faster than native C. NEVER.

Re:Might actually be the case

[Anonymous Coward]

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.

Then the win would go to java by far in that case as development time for the c program would so far exceed java that the java program would likely have ceased to be useful for busines purposes before the c program even was in a usable state. We're talking about writing equivalent programs here, writing a VM from scratch to execute code to find the first 2000 prime numbers vs writing a java application to find the first 2000 prime numbers is going to see the java program completing its operation well before the actual code to run on the new vm is even started on. Apples and oranges here says yes a JIT'd java program may very well outperform an equivalent C program when it is being written for unknown hardware where compile time optimizations could help.

Re:Might actually be the case

[cryptizard]

But that is the same situation you have with compilers. Making the most optimized assembly code involves complex calculations of instruction scheduling which a computer can do much better than a human. It is the same reason the people at Intel don't hand-code circuits any more: computers can do the computational intensive work of optimizing it better.

Re:Might actually be the case

[Anonymous Coward]

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

Quantity has a quality all it's own. You're smarter than a programmable calculator, but a programmable calculator is going to to be able to do large calculations faster than you can. Find the 100th prime number that ends with 23? You'll be there for a long time

A similar thing enters in programming. The machine can think about optimizations for a _lot_ longer than you can. It's not just about "smart", its about who can work the longest, who makes the fewest stupid mistakes due to attention lapse, and who can keep track of the most detail. Machines (compilers) are good at all those things.

Re:Might actually be the case

[flugi]

Note that in your first statement, you are reacting to this:

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

And then you say:
"But a competent assembler specialist (someone in the same league, skillwise, with the guys that write the compiler)[...]"

Put it together: there are a whole lot of programmers, and there are a handful of skilled assembler specialists. So if you take a random coder, and force him to code in assembly, your chances to gain performance is damn small.

Although you are trivially right about the skilled people, the statement you answered was not about them, that's why it says "for the most part".

There is a common misconception which says "if it is too slow, code it in assembly", which should sound like "if it is too slow, learn CPU tweaking for two decades, and then code it in assembly" :) In the old 8bit or 8086 days, without SSE+FPU, pipelines, cache coherence and branch predictors, assembly coding was a pretty straightforward business, the coder could do nice things by keeping things in registers, and knowing basic idioms as XOR AX AX, and in the same time compilers were tuned to create the binary fast, there were little time for optimization. Basic knowledge was enough to create faster code than compiler.

Re:Might actually be the case

[Grishnakh]

Why would it not be possible for a C or C++ compiler to do the same thing? The multiple CPU thing could be a problem since C/C++-compiled code typically isn't targeted at a specific system, but it certainly could be specified, couldn't it? And for additional instruction sets, that's been common for ages; with gcc, it's always been possible to optimize for specific CPUs, not just i386. And with the multiple-CPU thing, isn't the OS supposed to handle scheduling of processes and threads automatically anyway, taking advantage of extra cores?

13 Years to 1.0?

[Anonymous Coward]

So obviously their development cycle is much faster than HURD!

Re:13 Years to 1.0?

[Anonymous Coward]

Almost as fast as Duke Nukem Forever. Hopefully it turns out better.

JUST SO YOU KNOW: !! MS-DOS: ASM - AMIGA: C

[Anonymous Coward]

And we all know how much better one was over the other !!

I will not digress to the "asm coders spend time with bits not algorithms" !!

I will not digress to the "asm coders cannot flip a switch and update the binary for a new CPU" !!

I am not now nor have I ever been a member of the communist party !! Not that there is anything wrong with that !! Like being gay !! That is the way your cards were dealt !!

The only Secure OS..

[Anonymous Coward]

At least,there is a guarantee that this OS will be secure and without any backdoor. Simply because there is no compiler to inject it, so no chance for nasty hidden traps. Who knows, maybe in the following years this OS will became the only secure OS at all....

Re:The only Secure OS..

[Thiez]

Not this compiler-inserted backdoor crap again... Look, an assembler could insert a backdoor as well. And any of the developers could insert a backdoor. Did you read the entire source code? Even if you did, do you think you could find a cleverly hidden backdoor?

Besides, all you need to do to get rid of the hidden compiler backdoor (assuming there is one) is write your own compiler, use it to compile the suspected compiler, then use the generated compiler to compile itself, and presto, the backdoor is gone. Writing an interpreter instead of a compiler is also an option. Since you only need to do this whole process once, your compiler doesn't need to do any smart optimization and it's acceptable for the whole process to take some time (a week? a month? who cares).

NOT OPEN SOURCE

[Khyber]

"MenuetOS is an open source"

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

Why do it?

[GodfatherofSoul]

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.

Re:Why do it?

[PuckSR]

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.

Re:Why do it?

[GodfatherofSoul]

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

What a...

[wonderboss]

What a senseless waist of human life.

Re:What a...

[Anonymous Coward]

I bet his waist is more sexy than yours.
(You show first.)

Re:What a...

[diegobolanos]

Everybody is free to do what he/she thinks is worth for. I do agree with you that this effort is stupid, because from college we experience that assembly code ("real control" of the machine) can be faster an more efficient. But at a very very (f*****g) very high cost. I can think of this guys 13 years ago thinking like: "Dude, I can't live thinking that people don't know that assembly code can run better than anything, I will spend any time is necessary to prove it". Sad thing is they are trying to prove something we all know.

Re:What a...

[Anonymous Coward]

"waist"... LOL.

American?

Re:What a...

[Dystopian Rebel]

a senseless waist of human life

Kardashian is working on this too?

Re:What a...

[wonderboss]

http://www.youtube.com/watch?v=vJhq9eq_eJg

Those crazy Finns and their Operating Systems

[Anonymous Coward]

Who knows what they do next!

Re:Those crazy Finns and their Operating Systems

[jones_supa]

Yup. I guess it deserves a mention that just like Linux, MenuetOS also comes from Finland and is lead by a guy called Ville Turjanmaa.

Re:Those crazy Finns and their Operating Systems

[Anonymous Coward]

Who knows what they do next!

Write an OS in BrainFuck?

steve gibson born again?

[Anonymous Coward]

This reminds me of GRC, Steve Gibson's company that produced disk utilities for recovering data and IIRC possibly even fixing broken pre-IDE disk drives. He boasted that all his software was written in super fast assembly language for maximum performance!!!

Comment removed

[account_deleted]

Comment removed based on user account deletion

real gain

[diegobolanos]

It all depends in the definition of "performance" that you want to establish. If performance for this projects means just "raw machine cycles used in specific task", then yes we all know assembly will outperform anything (given you have huge amounts of resources, like time and money) BUT if you define performance also by "results obtain VS resources spend" then you will never win using assembly code.

LincolnLogOS, an OS written entirely in linoln log

[selectspec]

LincolnLogOS is an open source, GUI-equipped, wooden operating system written entirely in Lincoln Logs that can fit on any play room floor (if you have one big enough). 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 forts and buildings, which we want to avoid. ... We support USB devices, such storages, printers, webcams and digital TV tuners, and have basic network clients and servers. So before 1.0 we need to improve the existing forts and buildings and make sure everything is working fine. ... The main thing for 1.0 is to have all application groups available.

yes change it

[globaljustin]

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

thank you...

i imagine some of the commeters above freaking out when they read that statement...I admit I learn alot from reading the 'assembly sucks C is better' but the context of the discussion is *exactly* the kind of purely theoretical, ignore the user abstract computing model that causes our industry so much trouble. Its the tendency for programmers to ignore the *user* in the equation completely b/c humans have too much complexity and uncertainty (for the nerd mind)

it the core problem of our industry, IMHO

let me repeat...I *love* the /.'ers who obviously know what they are talking about who, on comments for stories like this, debate the most abstract minutiae of coding for *efficientcy*

but it becomes a Moebius Downward Spiral of rhetoric at some point...i say have the discussions, but always remember that the human part of the equation is **the only reason the computer exists** up above there's actually a comment above where the guy talks about how 'true computing' doesn't even have a user! WTF

think about what MenuetOS will allow the **user** to do....and on what machine....

this OS concept, the concept that an OS Kernal should be built from the ground up for ***how the user will use it*** is the way to the future for our industry.

Choose your own adventure, drinkypoo

[Cajun Hell]

Guess how many times I've used it.

"Help! Help!" she cried.

Most of them all just walked by, ignoring her. She might be jaw-droppingly gorgeous 36-24-36 redhead with pouty lips in a light dress, but she was clearly crazy, waving that weird plastic thing around. "You!" she urgently growled, as she seized a suited man's lapels. "Can you help me read this? It's the only copy!" This looked like a successful man, so surely he could afford a decent computer, right?

He blushed. He wanted her, and maybe could use it to get her back to his place, but the lie would eventually come out. And this woman had just the sort of sincere bearing, that he knew the lie would be punished, not accepted. He sighed. He glanced at the disc again, just to make sure what he was seeing, and sighed. "No. Sorry. What is that, anyway?"

She let go, and cast her glance around the crowd.

And that's when it happened: Drinkypoo. The moment she saw him, she knew. This was the one. She didn't even have to ask, because she knew. But she decided to ask anyway, so that he could have the pleasure of saying yes and offering to help. It would be the first of many pleasures that he would experience.

"Can you read it? There are some really important files from the 1990s on here. I've got to have them. I'll do anything, Drinkypoo. Anything."

There was a time when Drinkypoo would have grinned nervously, or asked followup questions. But by now, he knew the story. He didn't want to hear the story anymore; he just wanted the reward. Drinkypoo didn't so much as even glance at the disk. Why so many unbelievable hot women always had invested in LS120s and floppies to store their critical records, he didn't know. Maybe some freak effect of a one-shot Imation advertising campaign, long ago. No one even really knew why, for sure; they just knew that a shitload of the drives had somehow ended up in the possession of that demographic.

He squinted and recalled his depleted inventory. That blonde with the 1.4MB floppy from two nights ago. "Got to stop at the drugstore on the way. C'mon," he replied. She stuffed the disc into her purse for safekeeping and they walked to his car.

Half an hour later, at his place, she sat on the couch, nervously clutching her purse containing the precious disc. Drinkypoo sauntered over, and held out the glass of rye bourbon on ice. "Here, relax. Everything's going to be okay." She sighed with relief, set her purse upon the coffee table, accepted the glass and sipped. "Thanks."

"You can't imagine what this means to me," (though Drinkypoo actually knew very well), "I need those files so badly." She reached for his belt buckle for a brief moment, but paused. "First things first, though, I suppose."

Drinkpoo shrugged. What did it matter to him? It would all work out the same. This was going to be fun no matter which order things occured. "Sure." He walked over to the computer desk and nudged the mouse, waking it up from sleep, casting monitor light across the room. "Let's have the disc."

She smiled, and reached into her purse, pulling out a .."

[CHOOSE YOUR OWN ADVENTURE:

1) .. gun.

2) .. Zip or Jaz disc.

3) .. 3.5" floppy or LS120 disc. (Drinkypoo, it will cost you 0.01 BTC for me to write this version.)

]

Re:Choose your own adventure, drinkypoo

[TangoMargarine]

You, sir, just made me glad that I'm still reading Slashdot.

Re:Choose your own adventure, drinkypoo

[der_pinchy]

reminds me of:
http://slashdot.org/~FictionalAccount/journal

Re:Choose your own adventure, drinkypoo

[maxwell demon]

I'm for option 4: A 5.25" disk. You know, the ones which actually were floppy.

Re:Choose your own adventure, drinkypoo

[Anonymous Coward]

He squinted and recalled his depleted inventory. That blonde with the 1.4MB floppy from two nights ago. "Got to stop at the drugstore on the way.

IT'S 1.44 MB YOU INSENSITIVE CLOD!

Re:Choose your own adventure, drinkypoo

[Anonymous Coward]

I choose 2) .. Zip or Jaz disc.

Re:Choose your own adventure, drinkypoo

[jeremyp]

Please let it be a DLT cartridge

Re:Choose your own adventure, drinkypoo

[Anonymous Coward]

Ah, the Jaz disc, because sometimes Zip wasn't enough fun.
You missed Syquest though. You shouldn't forget Syquest.

Open source?

[CurryCamel]

From the license: http://www.menuetos.net/m64l.txt

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.

For an OpenSource OS written in assembly, that 3rd clause is a bit strange.

(yes, yes, I did notice that the 32bit version is more traditionally open-source-licensed...)

Re:Open source?

[unixisc]

I noticed that the 32-bit version is under GPL2. Did they consciously decide that GPL2 was preferable, or did they just not get to update the license to GPL3?

Another thing - the whole idea of GPL & open source is that one can see the source code, but if the source code is in assembly, that typically gives one no information about why things are happening e.g. why do we move the contents of register A to B, or why do we push & then pop a stack. In higher level languages, it would be more obvious that one is creating a new Window, but that would not be obvious here. So what's the point of applying an FOSS license to something that might as well have been coded in machine language?

Re:Open source?

[Anonymous Coward]

There are such things as "comments", "meaningful labels" and "macros with descriptive names" in Assembly sources which are generally missing from machine code.
Something like this might be not very useful:
mov ebx, [4001024h]
push ebx
push dword 0
mov eax, [400102ch]
sub eax, ebx
push eax
push dword [4001020h]
push dword 123h
int 40h

But this just might:
; Window origin and extents
mov ebx, [leftPane.x]
push ebx
push dword 0
mov eax, [rightPane.x] ; Fill all space to the left
sub eax, ebx
push eax
push dword [paneHeight]
SYSCALL GUI_CREATEWINDOW

Asm faster despite architecture changes ...

[perpenso]

I know for a fact that my C code is faster than my Assembly code... since the time I lost track of all CPU pipelining and stuff, while compilers only got better at optimizing. When they release version 1.0, it will probably have to be run on a emulator, perhaps in a quantum computer.

Some assembly code that I wrote was faster than C from current compilers over several major architectural changes of x86. The percentage by which they were faster decreased, yet after 3 architecture changes I was still 10% faster with the original assembly.

The key to writing good assembly code is not trying to out-compile the compiler, that is a newbie thing to do. The key is to leverage knowledge that can not be transmitted to the compiler, can not be expressed in C.

Re:Asm faster despite architecture changes ...

[Jorl17]

Could you elaborate on that kind of knowledge? I'm genuinely interested.

Re:Asm faster despite architecture changes ...

[perpenso]

These may be dated. Don't solve a problem only in asm, solve it in C and asm. Compare the two again whenever a cpu architecture or a compiler has a major update. Plus you want the C so you can port the code to a different architecture. That said ...

You might know your data is organized in a way that makes SIMD instructions helpful. Even if a compiler supports vectorization it will be somewhat limited in what it can do compared to the assembly programmer. A compiler may offer intrinsics but when doing so you are really programming at the assembly level not the C level, the intrinsics are pretty much a shorthand for inline assembly.

Wanting a function to return multiple values, trivial in assembly where multiple registers can be used. C requires memory variables.

Dealing with arithmetic overflow, trivial in assembly. Undefined in C.

Fixed point math where the source operands are of different sizes than the result of the operation, trivial in x86 assembly. C wants everything to be the same size.

There may be compiler specific extensions for some of these but they generally don't compare well with assembly.

written entirely in assembly

[rossdee]

Not very portable then

Re:written entirely in assembly

[unixisc]

Would have been an issue 10 years ago, but today, except for ARM & Power, everything else is all but dead. Besides, optimizing an OS using the latest instructions in x64 sounds interesting (granted, that part is closed source - for now at least)

If this was a Richard Stallman Project

[Anonymous Coward]

"So that I can continue to use computers without dishonor, I have decided to put together a sufficient body of assembly-only software so that I will be able to get along without any software that is compiled."

(As always, though, bathing is optional.)

Re:If this was a Richard Stallman Project

[unixisc]

I doubt that he would approve, given his opposition to intermediate formats like Bytecode, ANDF or object code. Assembly code would be just as problematic.

Re:If this was a Richard Stallman Project

[Anonymous Coward]

Perhaps you're thinking of object code. Assembly code, in contrast, is source code. I thought he was all in favor of source code, as long as it's open (er, excuse me, "free".)

Efficient assembly is still quite doable ...

[perpenso]

Let me start off by saying I started with assembly on the Apple II. I always liked assembly, I always like seeing things at the architectural level. I've written a bit of assembly over the years for various CPUs. Every once in a while I write some assembly code to better learn a new CPU and sometimes just for fun. Strange ... yeah, I will admit that.

That said, I rarely use assembly in professional software development situations when targeting computers and mobile devices. Before addressing your comment let me add one more thing. Learning assembly is important with respect to making you a better C programmer. I'm not talking about understanding the asm code you see in the debugger. I really am referring to writing C code. C code can be written in architecturally specific manners. The code is still portable, yet more efficient only on a specific architecture. Understanding the architecture and assembly language can allow you to write more efficient C code.

Yeah, outside a few rather narrow cases, ...

That is nothing new, this has been true for decades. You have to go back to Apple II and Commodore 64 days to find a timeframe where assembly was appropriate for general purpose software development. I'm referring to computers, not micro controllers and other such environments.

... modern CPUs have just gotten too complicated to write efficient assembly for.

This is absolutely false. The key to writing good assembly code is not trying to out-compile the compiler, that is a newbie thing to do. The key is to leverage knowledge that can not be transmitted to the compiler, can not be expressed in C. This is where the real win is, this is where assembly can still beat C even after a couple of architectural upgrades.

Re:Efficient assembly is still quite doable ...

[Anonymous Coward]

I always liked assembly, I always like seeing things at the architectural level.

I'm not sure what level of "architecture" you are talking about. An assembly language usually reveals relatively little about the architecture underlying the CPUs that execute the code generated by the assembler. In a brand new CPU architecture when there were no instruction set compatibility requirements, the instruction set may hint at the underlying CPU architecture to someone who is knowledgeable about CPU architectures. However, as technology changes and compatibility requirements are introduced, the link becomes more and more tenuous.

An instruction set is to a CPU as the user's manual is to a car.

Re:Efficient assembly is still quite doable ...

[perpenso]

I always liked assembly, I always like seeing things at the architectural level.

I'm not sure what level of "architecture" you are talking about. An assembly language usually reveals relatively little about the architecture underlying the CPUs that execute the code generated by the assembler.

That is a very modern x86 centric view. Even so we still have an "instruction set architecture" (ISA) in the modern x86 case. This ISA limits the underlying hardware architecture's (micro-ops) view of the software's intent. We still have the case where optimizing at the ISA level can also improve performance at the micro-op level. Furthermore understanding the underlying micro-op architecture can help to write more efficient code at the ISA or C level. This level is not documented but a little is known about it. More importantly the architecture of a CPU is not limited to the micro-ops. We still have caching and other things to consider.

Re:Efficient assembly is still quite doable ...

[Guy Harris]

Even so we still have an "instruction set architecture" (ISA) in the modern x86 case. This ISA limits the underlying hardware architecture's (micro-ops) view of the software's intent. We still have the case where optimizing at the ISA level can also improve performance at the micro-op level. Furthermore understanding the underlying micro-op architecture can help to write more efficient code at the ISA or C level. This level is not documented

...and it can (and, I suspect, does) differ from one generation of x86 processor to another.

Re:Efficient assembly is still quite doable ...

[perpenso]

Even so we still have an "instruction set architecture" (ISA) in the modern x86 case. This ISA limits the underlying hardware architecture's (micro-ops) view of the software's intent. We still have the case where optimizing at the ISA level can also improve performance at the micro-op level. Furthermore understanding the underlying micro-op architecture can help to write more efficient code at the ISA or C level. This level is not documented

...and it can (and, I suspect, does) differ from one generation of x86 processor to another.

Yes, but while the percentage of improvement may have decreased the originally assembly language was still faster after three cpu generations. At least in the last major piece of assembly that I wrote. At each new cpu generation, and compiler upgrade, I would retest the c and asm implementations.

Even *if* the asm implementation had gotten slower than the c implementation after three cpu generations it may still have been the way to go. Apps are sometimes optimized for the minimum system requirements not the latest and greatest hardware.

Re:Efficient assembly is still quite doable ...

[Mr Z]

I personally find it more valuable to periodically examine the compiler output, and understand if there are particular idioms in my code which lead to bad code generation. For example, when I'm constructing a particular set of abstractions (say, a C++ template library), can the compiler peel them back and give me efficient code?

I still write assembly code when I need to (especially on small embedded systems, or on the Intellivision), but most of the time I just don't have the time. Also, most code's performance just doesn't matter. My time truly is the limited resource. I've had to learn that perfect is the enemy of good, and so to pick my battles wisely.

MenuetOS is impressive, but I doubt I would ever be able to use it, because I won't ever have the subset of peripherals, motherboards, etc. required to run it. And, because its development is entirely in assembly code, I suspect hardware will continue to change faster than it does.

I remember the last time I bet on an assembly-written horse (WordPerfect). It was the fastest, it was solid, and it got trumped, hard, when the world changed faster than it could.

I just had a thinko...

[knarf]

Great, I thought, a lightweight, compact OS complete with GUI that strives to be fast, secure and robust. I know just the application for something like that: mobile terminals! Just port it and...

  [pop]

Ahw shucks, it is written in x86 assembly. Porting it essentially comes down to rewriting the thing. Yes, you could machine-port the thing, ending up with code constructions which work great on x86, not so much on arm. A compiler would produce better assembly from C source than that.

Re:I just had a thinko...

[unixisc]

If that's what you need, why not just use something like Minix? Yeah, that too is x86 only right now and being developed on ARM, but since it's written in C, one can independently try porting it to whatever other platform there is that may work for one. What CPUs did you have in mind?

alt.religion.emacs begs to differ

[Anonymous Coward]

Religion about tools is just silly.

Smite him, minions!

Giving the compiler hints can be useful ...

[perpenso]

The worst choice in C is to think you need to help the compiler optimize. Seriously, the compiler doesn't care at all whether you write x = x << 1; x += x; or x *= 2; it sees them all the same, so code the one that makes sense in context.

Historically helping the compiler, giving it hints, is in fact a good way to get superior code out of a compiler. For example consider 4x4 matrix multiplication. Do you use nested loops or just unroll it manually? Compilers tend not to fully unroll all the nested loops. The compiler may do better scheduling on fully unrolled non-looping code. Do you create temporary variables to preload a row or column, or do you just access each variable in memory directly? The former may generate better code on a RISC architecture and the later on a CISC architecture. These are the sort of things I think of when referring to helping the compiler, giving it hints. When that mythical smart compiler arrives that is able to figure out the preceding on its own, it will simply ignore your hints, the hints will do no harm. Until this mythical compiler arrives, the hints may help.

BTW, I agree with your sentiment in the context of the example you offer. Besides being useless, I've also seen people introduce bugs by making such "optimizations". Replaced the subexpression "x * 2" with "x << 1" in a larger expression and you may have changed the order of evaluation of the overall expression and are doing an erroneous calculation. "<<" has a different operator precedence that "*".

Re:Giving the compiler hints can be useful ...

[Anonymous Coward]

I used to think that too, but I'm not so sure now, with things like loop reordering for better locality of reference and auto-vectorization I'm inclined to try and have good data layouts and let the compiler deal with the details.

Re:Giving the compiler hints can be useful ...

[Mr Z]

For example consider 4x4 matrix multiplication. Do you use nested loops or just unroll it manually? Compilers tend not to fully unroll all the nested loops. The compiler may do better scheduling on fully unrolled non-looping code.

Ironically, a vectorizing compiler would prefer you give it the loops instead. If you gave it any hints at all, it should be regarding pointer aliasing (ie. the C99 restrict keyword, for example), pointer alignment and minimum trip counts if any of the loops have variable trip counts. Manually unrolling makes its job much, much harder, usually.

Do you create temporary variables to preload a row or column, or do you just access each variable in memory directly? The former may generate better code on a RISC architecture and the later on a CISC architecture.

If you provide good pointer aliasing qualifiers, I'd hope both produce about the same regardless of CISC or RISC with modern compilers, instruction schedulers and register allocators.

These are the sort of things I think of when referring to helping the compiler, giving it hints. When that mythical smart compiler arrives that is able to figure out the preceding on its own, it will simply ignore your hints, the hints will do no harm. Until this mythical compiler arrives, the hints may help.

When was the last time you used the register keyword in C and it had a meaningful effect? Depending on which aspect of the code you consider, the "mythical" compiler you refer to may be less mythical than you think.

Look up the history of the Stepanov Benchmark as it applies to C++ programs, for example. It was once a hot topic among C++ compiler writers, because it exposed how awful C++ abstractions were to run time. Now most compilers ace it, sometimes producing faster code with the C++ abstractions than the C baseline they're measured against.

I hope it's faster now than it used to be.

[speckman]

I experimented with this several years ago, and I was surprised at how slow it was. Hopefully this has improved. It was written in asm, which should be fast, of course, but it seemed like they erased all of those gains with klunky system/gui stuff. Nevertheless, very exciting!

QNX?

[cryoknight]

Anyone remember the QNX Floppy OS
http://www.youtube.com/watch?v=K_VlI6IBEJ0 -- They released this in 1999

They've been making incredibly compact embedded OS's for years, that should really be what the mobile phones use.

Congrats to the Menuet peeps for making a more modern OS that compact!

Re:QNX?

[unixisc]

You might want to check Blackberry - they use QNX as their OS. It's also the basis of Cisco's IOS

Re:QNX?

[laptop006]

It's only the core of IOS-XR, and in fact will be gone in the next release (which will share a Linux core with NX-OS and IOS-XE)

Privilege levels in MinuetOS?

[unixisc]

Can't people program for Ring0-3 in assembly? I dunno about MinuetOS, but if they did, couldn't they have allowed various privilege levels for the different parts of code that were written? Use Ring0 only for a handful of routines, put the rest of the kernel stuff into ring 1, device drivers into ring 2 and other userland in ring 3??

Floppy Disk?

[Cloudy Wheat Beer]

What is this "floppy disk" mentioned in the summary? It sounds weird, a disk thats floppy? how odd.

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

The one OS that doesn't have an NSA backdoor?

[Larry_Dillon]

Seriously, I tried Menuet a few years ago. It's crazy fast on even ancient hardware.

It just needs a couple of killer apps.

Impressive

[Anonymous Coward]

I am posting this comment using the MenuetOS
browser (running on VirtualBos). It is amazing
that it fits on a 1.44MB floppy image.

Re:Impressive

[Bob Fr]

Oops - didn't mean to be anonymous. (Is there a way to edit my original comment to remove the anonymity)?

Re:Impressive

[Bob Fr]

OK -- replied to the wrong post and can't fix it. So much for trying to figure out this UI.

Blablabla my code is faster than yours

[Anonymous Coward]

If you consider it efficient to write anything in assembly it can only mean one of 2 things :

  your code is executed billions of times daily. hence the ratio (timeSpentRunning*users / timeTowrite) is so huge that it is worth spending a huge amount of time writing in assmebly.

  OR your time is worth shit. i.e : machine time is worth more than your time. Personnaly I write code than runs on anything from PC to clusters and I have never encoutered a case where writing in assembly would be economically sensible (over C\C++ + python + java + whatever). this case exist, but they are rare.

  TL;DR : Interesting project for many reasons and i'm sure they have a lot of fun. Doesn't mean assembly zealots are right when they say it is "efficient" to write assembly code.

IBM OS for mainframes was 100% assembly language .

[porky_pig_jr]

for a long time, till they came up with PL/S. The typical mainframe environment was COBOL or PL/I for application programming, assembly language for system and utilities.

Portability

[manu0601]

Writing code in assembly means giving up on portability. Is it wise to bet on x86 in 2013?

We have to remember that in the early ages, Unix had its success because it was written at 98% in a high level language, which was an innovation at that time

Personal definitions don't matter

[dbIII]

Sorry kid, the "beige box is the hard drive" bullshit doesn't trump what's in the technical dictionaries or the textbooks.
Microsoft LOST when they tried to convince the Judge that a web browser was part of an operating system instead of a userspace application but PR and opportunism has succeeded in convincing a pile of "beige box is the hard drive" losers that gut feel trumps accepted definitions.

insert condescending statment also i hate M$

[globaljustin]

'sorry kid'?

listen old timer, i don't think we disagree on anything...this isnt' about some antitrust lawsuit where M$ used some bullshit argument

i hate M$....don't bitch at me for shit Microsoft did

Here is why

[dbIII]

You are using Microsoft's definition that the Judge rejected instead of the textbook one. You have swallowed the bullshit argument and are attempting to propagate it. That is why I am being condescending, because by using a "personal definition" you are clearly only pretending to know what you are writing about and doing it badly enough that it's obvious that you do not. Thus a communications failure since it's mindless noise just pretending to be signal.

I disprove you every day

[dbIII]

In my workplace we run a suite of geophysics programs of which many parts are compiled from source code that has not been touched for twenty years.

show me

[globaljustin]

You are using Microsoft's definition that the Judge rejected instead of the textbook one

bullshit...put up or shut up

I want links **to both** the M$ judge and the 'textbook one'

Links to both and then copy my original comment...when you lay out all three side by side, then list where mine is like the 'judge's' then we can talk

otherwise you haven't made any evidence for a claim & this conversation is past over...you're projecting your hate of M$ on me dumbass...i'm on your side

don't expect a response unless you post links to both things you are comparing my comment to

Modern OS Development

[Anonymous Coward]

It is a crazy thing to do, because assembly is so close to the hardware, and code generators can be so efficient, but look at all the OS development being done today, mostly it's a version of Linux, Unix or Windows. Even Apple is based on Unix. There are some specialized OSs, like cell phones.

...it felt like Flynn

[DrStoooopid]

...yes, it was definitely Flynn. ...END OF LINE.

Artisinal or Paleo OS?

[Anonymous Coward]

I can't help but be amused though more by the comments.It's as if no one remembers the feat of moving beyond assembly language in the 60's and 70's.

You mean you've never heard of it?

[dbIII]

It's got nothing to do with "hate of MS" but is instead a parallel example of this bullshit "beige box is the hard drive" shit with personal definitions based on gut feel.
Why should I reply with links to someone who is just making up their own personal definitions anyway, it's not going to stop you doing it and get you looking up the textbook definition instead is it?

Also, how can you possibly have never heard of MS declaring that a web browser was an integral part of the OS and the Judge telling them to fuck off with that stupid lie (at length and with more civil words) - you are on a site like this so you would have heard of it so why should I bother tracking down a link to something you've already heard about?

Re:You mean you've never heard of it?

[Anonymous Coward]

That guy very much reminds me of APK! I'm scared...