Linked by Thom Holwerda on Wed 8th Mar 2006 22:57 UTC, submitted by hidden player
OSNews, Generic OSes Even a small operating system can have big disputes within its community. The lead developer of MenuetOS, an OS written in assembly, has decided to drop all support for the 32bit version of Menuet, focusing development on the 64bit version. However, disgruntled users of the open source operating system are trying to keep the 32bit version alive by starting a special forum for it.
Thread beginning with comment 102686
To read all comments associated with this story, please click here.
by FrankNBeans on Thu 9th Mar 2006 00:01 UTC
Member since:

I've never even heard of this OS, but from reading, I'd imagine it is VERY quick and responsive.

Reply Score: 1

RE: Responsive
by Brendan on Thu 9th Mar 2006 01:28 in reply to "Responsive"
Brendan Member since:

Don't believe the marketting...

Performance depends a lot on algorithms, and can be effected by supporting more features. The actual language used makes little difference (and no I'm not biased - I've been programming 80x86 assembly for a decade).

For 32-bit MenuetOS, IMHO the algorithms used aren't very good (based on what I noticed while running an older version and looking at some of the latest 32 bit kernel source code), but there aren't really any features slowing it down.

I'm not sure about the 64 bit version though - I haven't tried it and it seems to be closed source.

Reply Parent Score: 5

RE: Responsive
by edwdig on Thu 9th Mar 2006 05:57 in reply to "Responsive"
edwdig Member since:

Coding in assembly helped a lot back in the day when a having anything more than a few megabytes of RAM was unheard of. Back then, it was fairly easy to optimize a small loop better than a compiler could. Now CPUs have become so complex that it takes far more work than it's worth to be able to outdo a compiler in most situations.

Code size mattered more back then, and it was easy to write smaller code in assembly, which made larger programs/data sets more reasonable to work with. Memory paging eventually made this much less of a concern.

The other big thing you gained by coding in assembly was you could define better calling conventions for functions. Standard calling conventions for C functions is to pass all variables on the stack, and trash the registers ax, bx, cx, and dx. You can define calling conventions which pass variables directly in registers, or which trash different registers. If you customize the convention to meet the needs of the code in question, you can both gain speed and shrink the code at the same time. This is less of a gain on modern processors which have internal registers with register renaming.

Reply Parent Score: 5

RE[2]: Responsive
by transputer_guy on Thu 9th Mar 2006 06:54 in reply to "RE: Responsive"
transputer_guy Member since:

I would have to agree with this and the 1st poster to mention it as well. Anyone who has been around long enough has already been there done that.

The project sounds interesting & I will follow it more, but the programming definitely takes me back to 1984 and the Inside Mac programming model where some coders such as Andy H could crank out all their apps in 68K asm because the early MacOS was so elegantly thought out (despite the memory handles & coop tasking handicaps).

In those days of tiny asm programming either x86 or 68K, it was well worth doing because every instruction performed in time in a predictable way. You could count clocks, bytes and choose which hand optimization would give better results even unrolling and inlining huge chunks of code. C to asm often gave 10x improvements.

Today that makes no sense and hasn't since the PPro and similar super scaler, out of order cpus made cycle counting irrelevant.

If Menuet has any interesting internals it should be programmed in a higher level language, perhaps BCPL or Lisp or just plain C. Dealing with asm codes isn't going to produce any applications more interesting than those 1984 apps. Which makes me wonder was the browser with the OSNews picture a native browser in asm too?

Interpreters are still a good idea provided the language and infrastructure are well designed, the user is still the limiting factor in keeping any OS busy. Today few books are available for modern x86 coding that can give a predicable model for how the code will actually run. There is a huge problem with the memory wall and true random access across large address spaces makes some "mov" instructions effectively 100s of cycles rather than 1 or so.

Reply Parent Score: 5

RE[2]: Responsive
by Innominandum on Thu 9th Mar 2006 17:48 in reply to "RE: Responsive"
Innominandum Member since:

I disagree. Even today I have taken some publicly published routines demonstrating a technical standard. These routines are supposedly optimized in C. I already have these routines running double or triple of the C ones.

While high level compilers are getting quite good, the output they create is limited by the language itself. High level constructs aren't usually performance friendly. You don't have the same level of control. The only way a modern HLL compiler could join the same league as ASM is by the programmer using a series of labels and goto commands.

In the case where I optimized the "optimized" C code, the implementation I arrived at is not possible to express in an HLL language. Also, code density, instruction choices & scheduling, all still matter. Your mentality is the same one that causes WMP10 to take 10 seconds to sort 5000 songs on my P4 3.0 GHz. My 486 could sort 5000 song names faster than that.

People have been saying HLL compilers can equal ASM for many, many years now and I'm still waiting for it to happen. And if they can, someone's doing something wrong.

Reply Parent Score: 2