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.
Order by: Score:
Responsive
by FrankNBeans on Thu 9th Mar 2006 00:01 UTC
FrankNBeans
Member since:
2006-01-30

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 UTC in reply to "Responsive"
Brendan Member since:
2005-11-16

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 Score: 5

RE: Responsive
by edwdig on Thu 9th Mar 2006 05:57 UTC in reply to "Responsive"
edwdig Member since:
2005-08-22

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 Score: 5

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

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 Score: 5

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

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 Score: 2

RE[3]: Responsive
by transputer_guy on Thu 9th Mar 2006 22:16 UTC in reply to "RE[2]: Responsive"
transputer_guy Member since:
2005-07-08

For some codes asm can still make a difference sure, and those will be esp common in DSP like codecs where FFTs, DCTs can be done a tad faster and way faster if special MMX like instructions can be got at not available to the regular compiler. I'd assume most media codecs have hand asm tuned cores.

When you get into grunt code that is far from the inner most loop, asm has almost no use period except lowering productivity. I also took a full blown C CAD app and started to optimize into asm, after all the 10x inner loops, I couldn't help myself, just kept going & going like the asm bunny, till the whole thing was asm and 5x smaller than the C version. Still I really only needed to do the inner loops.

It is a shame that sometimes HLLs even C do make it harder to exploit certain optimal asm sequences, switches come to mind, there is always asm{}. The x86 just makes it all so much worse and I don't see AMD64 being much better.

In the embedded space size will matter as well as performance, but for desk top apps, smaller option usually does pretty well also.

Funny you should mention my mentality with 5000 songs on WMP10. I believe that any OS should be able to sort 100K file entries is the blink of an eye as if all the info was already in memory. Lets see, 5000 int values should take On log n time which might be 10.5000.12 or 600K instructions probably < 1ms on any modern PC. String sorting will be a few x slower. In 10s one should be able to radix sort maybe 100M values.

If you are seeing 10s, thats probably a disk based sort, I'd bet the 486 did the same sort in ram, programmers back then had a much simpler model of the world so it was obvious to bring data into ram. So HLLs are not the problem, it keeping data on the disk that is pretty stupid.

I think the real problem we all have is that even with C,C++, OSes & cpus are just too complicated to see all the dumb stuff that gets done at the cycle level. Algorithms always come 1st with an understanding of exactly how that plays on the cpu today rather than Knuths ideal machine of the 60s.

Tree sorting algorithms where node hops supposedly take a few opcodes can today break all the caches and result in 300ns memory stalls each hop, the language makes no difference here.

Performance changes enormously when the problem fits in the caches v never fits in the caches. It would be much nicer to have cpus that have predictable timings no matter how random memory references occur but so far there is no single threaded solution to the Memory wall. It can however be traded for a Threaded wall problem with no memory wall per thread.

Reply Score: 3

RE[3]: Responsive
by edwdig on Fri 10th Mar 2006 00:25 UTC in reply to "RE[2]: Responsive"
edwdig Member since:
2005-08-22

If you're writing code that can use MMX/SSE, C compilers are not very good at generating that code automatically. You can very easily win in those situations by hand writing assembly.

If you're not using SIMD instructions, a C compiler will usually easily outdo your hand coded assembly. The only time you stand a chance at outdoing the C compiler is in tight loops where the C compiler isn't provided with enough information to properly optimize the code. The more information you provide the compiler, the better job you can do. For example, if you have a function that's only used by other functions in the same source file, mark it as static. This will allow the compiler to use optimize across the function calls. Declare things as const when possible and it will further help your optimizations. Help the compiler, and it will gladly help you back.

5-10 years ago I used to write assembly. Primarly 16 bit. I could very easily outdo the compiler then. I was one of those people that never believed the claims of how good compilers are. Nowadays the compilers really impress me, and I'm usually wrong when I try to outsmart the compiler.

That said, if you're still working with more primative CPUs, you can outdo the compiler without too much trouble. I do some GameBoy Advance coding as a hobby. If I try, there are definitely situations where I can create better code than the compiler. Realistically, there aren't many places where I have to.

Reply Score: 2

Performance
by siride on Thu 9th Mar 2006 02:19 UTC
siride
Member since:
2006-01-02

I tried it in Qemu, and it was unusably slow. Win3.1 on my dad's 286 14 years ago was more usable than Menuet in Qemu on my T43. Even though it was running in an emulator, it should have performed much better. Plan 9 was quite usable in the same emulator.

Reply Score: 1

RE: Performance
by helf on Thu 9th Mar 2006 05:30 UTC in reply to "Performance"
helf Member since:
2005-07-06

menuet has never played well with emulators. specially qemu (which, in my experience, plays well with very little...).. if you try it on real hardware, it runs quite fast.

Reply Score: 2

Never understood...
by mattst88 on Thu 9th Mar 2006 02:39 UTC
mattst88
Member since:
2005-08-27

I never understood the reasoning behind closing the 64-bit source. What does he stand to gain by doing so?

Reply Score: 1

RE: Never understood...
by umccullough on Thu 9th Mar 2006 02:53 UTC in reply to "Never understood..."
umccullough Member since:
2006-01-26

Maybe he's reached a point where he'd like to develop a closed-source OS that he can sell as an embedded OS?

Has anyone ever asked him why and gotten an answer? Probably... but I wouldn't know where to find that information.

If you think about it though, a good 64-bit assembly-written OS could have a very nice future in embedded systems... he stands a good chance of profiting from his hobby.

Reply Score: 1

RE: Never understood...
by ronaldst on Thu 9th Mar 2006 04:29 UTC in reply to "Never understood..."
ronaldst Member since:
2005-06-29

I never understood the reasoning behind closing the 64-bit source.

He mentioned something about open sauce...

Reply Score: 1

Shame with war
by Haicube on Thu 9th Mar 2006 07:49 UTC
Haicube
Member since:
2005-08-06

But I wanna just open up another view on all this.

No matter 32bit or 64bit Menuet, it's innovative if you ask me. This guy "Ville" is brilliant. This is one of the true Hobbyist OSes out there. All others seem to struggle for world domination (take this with a huge grain of salt), while this is just about doing something because it's cool. I like that approach.

For anyone interested in ASM I guess this is the best place to look for references these days, especially on the 64bit. Now that everything has become abstract, things like menuet is needed to help future generations to understand what happens in the background when you compile stuff... ASM is a good approach to that.

My take on all of this basically, shame there's a war, look on the bright side of things, 32bit/64bit are both good things for all...

Reply Score: 5

the reason it's closed source...
by Anonymous. on Thu 9th Mar 2006 09:27 UTC
Anonymous.
Member since:
2005-12-04

is that he was pissed off at the kolibri developers for trying to keep 32-bit menuet going when he decided to stop working on it... kolibri actually runs pretty well in qemu, by the way...

Browser: Opera/8.01 (J2ME/MIDP; Opera Mini/1.2.3214; es; U; ssr)

Reply Score: 1

Lettherebemorelight Member since:
2005-07-11

I dont understand. How does keeping the 64 bit source closed stop these kolibri devs from working on the 32 bit version?

Reply Score: 1

umccullough Member since:
2006-01-26

From what I gather, most of the people trying to keep 32-bit version alive simply cannot, or will not buy a 64-bit machine. I guess that maybe Ville (sp?) simply wants the 32 bit version to die but it won't?... Why he wants it to be discontinued and abandoned is yet another mystery... anyone know why he would want this?

Or maybe this is just misinformation.

Reply Score: 1

aaronb Member since:
2005-07-06

I thought it was open? The disclaimer does not give much away !

Menuet 64 - copyright (c) 2005-2006 Ville Turjanmaa
All rights reserved.


THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS, AUTHORS, AND
CONTRIBUTORS ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES,
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
IN NO EVENT SHALL VILLE TURJANMAA OR ANY AUTHORS OR CONTRIBUTORS BE
LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE
OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

Reply Score: 1

Going to be rewritten perhaps
by Ronald Vos on Thu 9th Mar 2006 12:27 UTC
Ronald Vos
Member since:
2005-07-06

The new 32 bit forums have a few interesting posts in the opinions section:
http://meos32.7.forumer.com/viewtopic.php?t=2&postdays=0&postorder=...

A number of users discussing in how much a rewrite of some core MenuetOS parts is necessary. It appears some things could be improved a lot.

Reply Score: 1

another good an bad
by Zedicus on Thu 9th Mar 2006 15:29 UTC
Zedicus
Member since:
2005-12-05

the point of open source is so others can develope it, why would that upset him? i have used an like the 32 bit version. as well as the fact remains that not everyone has a 64bit comp yet. to close source the 64bit version becuz of this is a good reason to not use the 64bit version.

Reply Score: 1

re:
by Zedicus on Thu 9th Mar 2006 17:12 UTC
Zedicus
Member since:
2005-12-05

it doesnt, it stops them from trying to do the same thing with the 64bit code.

Reply Score: 1