Slashdot Mirror
MenuetOS Debuts
Eugenia Loli-Queru writes: "OSNews is hosting an interview with Ville Turjanmaa, the creator of the Menuet Operating System. Menuet is a new, 32-bit OS under the GPL and it fits to a single floppy (along with 10 or so more applications that come as standard with the OS). It features protection for the memory and code, it has a GUI running at 16.7 million colors (except with 3Dfx Voodoo cards), sound at 44.1 khz stereo etc. And the most important and notable feature? The whole OS was written in 100%, pure 32-bit x86 assembly code!"
Anybody remember GEOS?
That's another OS that was written entirely in assembly... by the time they finished, Windows had ALL of the marketshare...
This sounds incredibly cool, but with all these new OS'es popping up like QNX, AtheOS, and my alltime favorite BeOS. The only problem is, that theres too many showing up, and too little support for them. Sure, this is a great example of what you can do with Assembly, but are you gonna make a full fledged OS out of it? Is anyone working on a brand new OS that they think will actually go someplace? Personally, i'm still holding out that BeOS doesn't sink like the Titanic..
--
Insert Witty Sig Here
An operating system in assembler? Bah! Such high level languages are tools for the weak, macros be damned! You know what I have to say about that? Reminds me of an old joke by Alan Turing : 11100101010100100111010100101010010100101001111 ? 10011010100111011100001 !!! HA!
There are ton of pet project operating systems like this. Some simple searching revelas a huge community of these DIY operating systems. :)
Jeremy
x86 assembly? Now that's what I call portability!
Ville Turjanmaa: Parts of Linux was rewritten in assembly and the speed gain was 10-40%. That will give an idea.
I don't mean to flame here, but one of the first things you learn in a computer architecture class is to "make the common case fast." The parts of Linux that were rewritten in asm that improved performance by 10-40% were most likely primitives that were executed hundreds of times a second - like bcopy() and maybe some parts of the VM subsystem. Ville's response draws no distinction between rewriting bcopy() in asm, and rewriting printk() (which is slow, but rarely executed) in asm. Unfortunately, I see no point in rewriting them both if it's not necessary. Sometimes it matters but often it doesn't.
The space advantage to hand-optimized asm is clear, but the cost in portability and time almost certainly outweighs it. I really don't see what this OS offers that Linux doesn't have.
-all dead homiez
From the FAQ:
And the benefit of asm coding is that if you make a mistake in programming, you notice it immediately. You dont get warnings, things just wont work.
Anyone else have serious doubts about this thinking?
my remaining options are perl, tcl or awk.... hmmm.
Hail to the king, baby.
What crazy reasoning drives a project to write something complicated and difficult in a lower-level language than the current best practice?
The only thing I can think of is the idea that it will be leaner and faster, which are seriously misguided notions given the trend of faster and faster hardware. What we care about now are scalable algorithms, stable and robust kernels and drivers, and appropriate abstractions to allow easy extensions. All of these are made easier by high-level languages. They are made more difficult by machine language.
What I'd like to see is a powerful kernel mostly written in a very high level safe language like O'Caml or even Java. That would be a feat with some important consequences.
...to those of you who ask "How many OS'es do we need?"
Think about when linux first came out, and everyone said "How many frickin' OS'es do we need? We've already got DOS, MacOS, and Unix (variants, etc.)"
New OS'es are good for the market, people! They provide a fresh perspective on the way things should be done and facilitate ingenuity and competition. They may not all become famous or provide new tools or inventions to the OS market, but some of them do - and that's exactly why we need 'em.
In that light, i must say i've yet to see someone bitch "Jesus, how many different types of cars do we need?"
"It is seldom that liberty of any kind is lost all at once." -David Hume
The speed up achieved by writing the whole OS in assembly isn't much. you just can't compare it saying parts of linux was written in assembly and that got 10-40% speedup. That doesn't mean it'll scale up in propotion.
Turjanmaa doesn't even have an estimate on how much speed up he's achieved. but my guess would be not more that 10% over linux. cuz the most accesed part of linux is already in assembly, so you won't have huge speedups.
If this is GPLed, where's the source? I couldn't find it. I downloaded the OS and tried it out a bit, and it actually seems quite good. Mind you, without a TCP/IP stack and such, it's pretty useless, of course, but whomever was behind this is clearly pretty good with the assembly. I'd love to see if the code is even remotely maintainable.
If you are having trouble with the link, try this one.
Need to whore me some karma....
Viv
Gmail invites for ip
...does that mean it'll be a pain in the ass to fix "LENGHT" to "LENGTH" in the editor picture on the website?
but seriously, this is pretty sweet. i'm going to load it up at work tomorrow.
Actually, if you had a couple of years of experience (ie non-university) CompSci or EE under your belt then you'd realize just how correct the original poster is.
Saying that it simply won't work and therefore is easier to debug is foolish on a grand scale. If anything, writing in assembly code gives you FAR more failure modes because you don't have a compiler which is running at least some sanity checks on your code. If anything, you'll find that it is higher level languages that "won't work" and assembly code that will do something obscurely weird when you trash the wrong memory address.
If there is anyone humiliated, it should be the previous poster who obviously has no idea about the complexity added in writing something directly in assembly rather than a higher level language. All you end up doing is trading portability for increased development time. There is even no guarantee that the code will run faster - C compilers are pretty good these days and can do magical things with intrinsic functions with superscalar scheduling.
To sum it up, YES!! You are not 100% correct. You are actually 100% incorrect.
Fear: When you see B8 00 4C CD 21 and know what it means
I don't mean to be a "flamer" but, please let us think about this in a broader perspective.
Lately I have been seeing a lot of OS announcements (as may posters pointed out before me) everything from BeOS, to FreeDOS and Linux, et. al. -- and all of those OSs seem to be centered around taking on Windows of the evil M$.
If that is the intention, may I suggest that the OS war is over and that M$ is the clear winner and that any continues battle on this ground is just a step backward.
Lets face it, in few more years, we will care less about the OS and wary more about the user interaction and front-end applications. Even Linus Torvalds realizes this as his new focuse for Linux is now on: Making Linux usable tops Torvalds' list
Karma stuck at 50? Add 2-5 inches.. err.. 2-5x Karmas Count to your pen1es.. err.. Karma all naturally and private
Firstly I've got to say congratz for knocking this one out. But to be honest how many more Operating Systems do we need?
It's not really a matter of need, as in how many Operating Systems do we need to try and push on people's desktops. Instead, it becomes a matter of people trying different methods of OS Development and different design philosophies. Think about it for a minute - if only 4 or 5 groups created all Operating Systems that are out there, it would be unlikely that new ideas in OS development would be fully explored.
You might want to look around and check out all the Operating Systems there are out there that researchers and hobbiests (sometimes there doesn't seem to be THAT much of a jump between the two ;-) have spent tons of time on. Sometimes they are developed just to 'scratch an itch', sometimes they are developed to see an idea all the way to completion to see how well it works out.
Don't knock these guys for trying to develop a new OS - sometime or another the ideas they come up with may end up in Linux, *BSD, etc. (Of course, in the interest of full disclosure, I work with an alternative OS project that somewhat died, and just got resurected this week. ;-)
Davis Ray Sickmon, Jr - looking for something to read? Check out my three free novels at MidnightRyder.org
I'll stick with Penix, thanks.
The Penix system uses interpreted BASIC for "Ease of Modification". Good move in my book. BASIC programmers are plentiful.
Wasting your time since 1997.
From the GPL: "The source code for a work means the preferred form of the work for making modifications to it."
Guess that means he has to distribute the C version, too.
ok then your [sic] infringing on my copyright! Could you as [sic] me next time before STEALING my comments for your own?
I just upgraded my entire company to this OS and we are blazing ahead into the early 90's. Some of my 'less-educated' users are complaining about the lack of support for StarOffice but I'm assuring them that it will come with time. In the meantime I'm working on a Lynx port. I never knew I could get 10% (!!!) improvement on my existing Pentium II 1 Ghz machines!
MenuetOS has been floating around for a while now. I briefly looked at the website a while ago, it looks tres cool, but I don't know much about it. Even without knowing the details, I can say that for a hobby project, this is a staggering accomplishment. As well, there other operating systems in development that are 100% ASM, Unununium comes to mind. http://uuu.sourceforge.net/
:)
The fact that the operating system was made in ASM is bringing up the low-level language versus high-level language war. I will admit that Linux and MenuetOS aren't really comparable. But ignoring differences, the end result: MenuetOS makes Linux look MEGA bloated, slow, and laughable. You guys should be taking 2nd, 3rd, and 4th looks at QNX RTP, BeOS, and AtheOS. This should serve as a big kick in the ass for you all Linux-fans. It's really nothing "that great." Sure it's free, but you sacrificed quality.
People claim that C compilers can generate code that is similar to what an ASM programmer is capable of. This is not true. A well-planned and pain-stakingly optimized C program can approach a novice ASM programmer. But this is almost never the case. Plus, there is also the inherent "beauty" of well-designed ASM code that most high level languages will never reproduce.
Anyway, I could go on forever. If you want to address anything I said, I am ready prepared for retaliation.
Well.. just a thought..
:)
Was trying to think of maybe how this would be good for anything other than rootdisks and novelty value.. and then i started thinking.. well.. 44-khz stereo sound, workable gui, MIDI support..
I can't get the thought out of my head that something-- maybe not this specific OS, because this specific OS is tied to the x86, but maybe something patterned on the same general system design-- like this would maybe be actually useful as an embedded OS for a sampler.
Am i just completely on crack, or would a sampler/synthesiser with a small lcd screen and an os like this one be as cool as it seems to me it would be?
Then again, any really cool stuff you could do with such a system-- say, letting you program your own midi synths in realtime-- would *demand* that it have an interpreter for something more high-level than assembly built in, and doing, say, a LISP/Python interpreter in an environment written wholly in assembly could maybe get messy. Maybe we'd rather have an OS written in LISP in our samplers....?
Oh, the hell with it. Forget i brought it up
Irritable, left-wing and possibly humorous bumper stickers and t-shirts
Of course it doesn't translate to ASCII. Alan Turing died in 1954 and ASCII was created in 1963.
The joke is probably a Turing machine tape anyway. We don't know how to interpret the symbols without the state machine specification to give it context. Many jokes are not funny out of context.
Write it in VBScript. You can create the first OS that can be installed and redistributed by clicking an e-mail attachment.
...so unless you're just trying to impress girls or something, assembly is best left to the half-dozen driver programmers on the planet who still need it...
But if you ARE trying to impress girls, WOW, I can't think of a better -- oh, wait. Nevermind. Someone already found a better way, a webserver coded in PostScript.
I honestly haven't used a floppy in more than 2 years. None of my 3 current systems that are in daily use even have floppy drives installed.
If your definition means extremely well optimized at the expense of long dev time and completely unportable, so be it.
Indy cars have exceptional quality for that particular track; aren't they even optimized for left hand turns? But most people would choose to own a well done street car.
The parallels in dev time and portability say enough.
Infuriate left and right
Actually, GEOS was *purchased* by a zealous group of GEOS users and renamed to NewDeal... www.newdealinc.com
Well, I tried to download the demo, and they aparently are having some MS-SQL problems. Ya know, I'm going to have to play with this a bit - I always liked GEOS the first time around. NewDeal may be worth a look. Unluckly, that's probably all it's going to be worth. :-( I can't exactly see there being much support for it, application wise.
But, you HAVE to love the requirements for running it:
Davis Ray Sickmon, Jr - looking for something to read? Check out my three free novels at MidnightRyder.org
Ok, most of the responses to this so far have been "assembler doesn't give you that much improvement" , "assembler is a bad way to do things if you're trying to do them The Right Way".
:)
Well, why can't he use asm? If I want to write an OS is BINARY that's a cool-ass hack, even if it is not The Right Way to do it. Come on guys, give the guy a break... he did something *awsome* and something probably 98% of us can't do (I know I certainly can't) and he should be credited for that. I'm not saying that this OS is something that should be taught in OS design courses, but it's still very very VERY cool
Sure, there's a plethora of other OS choices these days, but a small, efficient, graphically based OS would lend itself very nicely to the embedded / handheld market.
Sure Linux is cool, but once you slap X on top of it, it's not nearly as efficient on slow machines.
Who knows... you could have a Menuet based PDA or phone next year.
MadCow
I used to have a sig, but I set it free and it never came back.
Or does the link go to an almost-blank page with only a single banner ad flashing at the top? What gives?
An OS from Finland? Does this come from the frozen small hellhole next to North Pole? Do they even have electricity there? World domination? Yeah right. Won't happen in a million years!
...said people 10 years ago and went on with their life. Boy, were they wrong.
Never underestimate an OS that comes from Finland.
All you need to do with emacs is write an extension for it to load as a server in MACH...
Oh wait, then you'd have HURD... nevermind.. ;)
Yes, one day I may actually learn to spell...
If you don't like squeak, try Visualworks. It's a very nice commercial smalltalk that I worked with extensively when I was in grad school.
I've linked to the downloadable non-commercial-development version.
Smalltalk is very addictive once you start using it. I love the flexability that multiple polymorphism (selecting a method based on the name, and the types of all of the arguments, rather than on just the name, and maybe the first argument) offers, as well as the convience of being able to work on the same image from whatever platform (sun, windows, mac) that I happened to have access to.
You could get the asm out of the binaries, but it would lose all formatting, comments, macros, separation into different files, and various other things. It would be *very* hard to read; not at all the "preferred form of the work for making modifications to it."
main(c,r){for(r=32;r;) printf(++c>31?c=!r--,"\n":c<r?" ":~c&r?" `":" #");}
Hell, make it 20 megs of static ram, VGA video, and a 320x240 screen, and you have pocket Doom. And it's the real one, not a bastardized GBA/SNES version.
All I can say is, that's a pretty fucking hardcore patch. Even my keyboard is anti-aliased now.
--
I like to watch.
An operating system in assembler? Bah! Such high level languages are tools for the weak, macros be damned!
Heh. Interesting perspective. I suppose all the nasty compatibility issues imposed by assemblers are all but erased, are they?
Never mind the debugging you'll have to spend with machine language. Assembly has its own issues, of course - mistyped register numbers, wrong hardware addresses, then the usual programming errors you get in any other language. But with machine language, you have to count your zeros and ones very carefully... of course, you'll eschew the bourgeois luxury of hexadecimal, won't you?
:)
I love Assembly. Back in high school, I was ordered to write a program that made a computer play music. Everyone else wrote little Pascal and structured BASIC programs to play Chopsticks on the school's Macs 512s.
I wrote a TMS9900 Assembly program which played Flight of the Bumblebees in three-part harmony with the stepper motors of my TI-99/4A's three 5.25" full-height SSSD diskette drives. Percussion was achieved by toggling the head pad solenoids.
My Computer Studies teacher didn't like it because he couldn't understand it to critique it. But he gave me an A+ anyway, probably because the source code was about 30 pages long.
Ahhh... High school.
While I haven't programmed in Assembly in about ten years, you can check out my resume here, since I'm looking for work!
Fire and Meat. Yummy.
What about the (IMHO) famous programmer Steve Gibson, author of Spinrite (sorry /.ers, may be before your time) who writes all his stuff in assembler? His utilities and more would easily be fit onto a floppy disk - even though some use the Windows API (AFAIK). This dude is a guru to anyone using and appreciating the x86 platform! When MFM hard drives were all we had, he provided us a way to keep them working well beyond the MTBF the manufacturers had planned (or promised). A purist beyond belief - and a blowhard in rhetoric, (if you check out his website), yet, a genius in assembler (we're not worthy!)(sorry; tried for a link and was overwhelmed)
Can you say "change my interleave without FDISK first?"
This guy rules! Don't forget him! He's at least as important as Peter Norton. Maybe more...
db
Cig:
ôô
Why would a dnet client written in asm for this OS be substantially faster than one written in asm for another (non asm) OS? The only speedup would be in calls made to OS functions, and a program that's highly computationally bound isn't going to be making to many of those.
If you want your dnet client to run at its absolute possible fastest, you're best off doing away with the whole OS business in its entirety. A non-multitasking environment such as good ol' DOS would probably be best for that.
It's only software!
Rather than write assembly code targetting for platform X, what do people think of taking a more portable approach and writing a translating assembler which uses basic assembly instructions (jump, load, mul, add, comp, etc.) but translates them into actual platform assembly code which can be turned into native machine code for all supported platforms? Where an instruction (say, 'div') isn't supported by a platform's microcode, it can be implemented using several simpler instructions.
An approach like that should keep things at a low level allowing slim code and fast execution times, but not lock the end product onto a single platform.
Does an assembly product like this already exist? I tried searching freshmeat, but gave up after browsing through several pages of disassemblers, regular assemblers, etc.
I'm fairly confident GEOS came out after the Macintosh. The Mac was released in January of 1984, or at least that's when the Superbowl ad ran. I first saw one at a computer show in the spring of that year.
h tm l
1984 was a pretty important year for Commodore, as it was when the C-64 dominated sales.
I'm fairly certain GEOS was released towards the end of 1984. I remember first seeing it in around that time frame, and I was fairly in tuned with the Commodore scene at the time. (founded local Commodore user group and was friends with a number of magazine authors, etc.)
This history of the GUI sounds about right:
http://pla-netx.com/linebackn/guis/guitimeline.
It talks about GEOS being released in 1985. I think it was early 1985, just before the Amiga launch. It was a pretty big thing at the time.
The Casio Z-7000 was most certainly not the first PDA. First of all the Newton was released before the Zoomer. The term PDA was coined by Apple.
But there were many small handheld computers dating back many years prior to this. Radio Shack, Sharp etc. had handhelds back in '81. The PC-2, etc.
Granted they didn't keep your schedule and contacts, but. The first computer I saw performing that task was the Atari Portfolio in '89. As I recall it was the first handheld that ran MS-DOS and had a small spreadsheet, etc. The father of a friend of mine purchased one, and it was quite cool at the time.
That's not to say GEOS wasn't cool, because it was. GeoWorks for the PC came out at a particularly turbulent time, but I recall it being reasonably popular for a period of time.
Does the term "VM" mean anything to you ? This is why talk of java's portability is non-sensical, java programs only run on a single OS - the java VM. "I can write an OS, first of all, give me an OS..."
Besides, the point of an OS is to manage low level system resources, like registers, cache, memory, devices. You can do the meta-level stuff in a high-level language if you like, but at some stage you're going to have to go low level. Plenty of OS's have been written (as far as possible) in higher level languages than java.
http://rareformnewmedia.com/
It's like MacOS X for the brain. No really, it's the same technology Steve Jobs depends on.
Man, and you thought your terminal had a "visual bell." Yowzah.
I have a positive modifier on Troll. When I mod someone Troll their karma should go UP!
Can you remember the V2 Operating System? It was also posted on Slashdot some times ago. It was very promizing, written in full asm, had a nice GUI, a nice shell, a nice debugging console, etc. A very similar project.
Does anyone know what V2 OS has become nowadays ?
{{.sig}}
"CompSci"?
"EE"
Heh heh.
; -- the corruption of government starts with its secrets. a truly free people keep no secrets. --
If you have a high degree of control, it does not necessarily mean you will make proportionately more errors if you know what you are doing.
Knowing what you are doing is actually most of the problem with assembly coding. Remembering where on the stack you threw things, figuring out calling conventions, string handling, collection classes and other icky stuff that if you have a decent C++ compiler with a nice STL library you are going to be far more efficient. I admit there are plenty of times I drop down from C++ into assembly for debugging of a program, but very rarely to actually write code (why isn't there a 'bitwise rotate' operation in C?).
To be honest, I find it easier to debug an ASM program.
How complex a program are we talking here? I'm used to working on projects that are in excess of 100,000 lines of C++ code. That easily translates to well over a million lines of assembly and probably closer to ten million once template expansion has taken place. I defy anyone to take a non-trivial program and say that the ASM code is easier to debug than the C code - of course using an IDE which allows you to view variables, stack traces, commented assembly and edit and resume the program on the fly helps a lot.
You write the code, you know what precisely what is going on.
I debate that of any programmer - especially in assembly. The limited syntax and complete lack of any high level data structures make it a nightmare in the end.
C compilers can (depending on the programmer) generate some really impressive, logical, clean code - but not usually something that can compete with an ASM programmer.
Ah, but the point is that fast assembly code is neither logical nor clean. You deliberately move loads up the instruction stack, precompute results that you may not use for many cycles, drop stores in (for zeroing memory) now and again when you have a pipe free and do it all differently depending on your target architecture (P5, P6, K7, P4 etc.) If you have a chance, look at the output of Intel's VTune compiler at some stange with all the optimizations turned on - you'll find the assembly unintelligible but faster than you thought possible.
Just curious - are you talking strictly x86 here or do you believe that this is valid across all CPU architectures? Have you any real plans to try to write faster code than a compiler can on IA64 - if so, I'd be interested on hearing your strategies.
Fear: When you see B8 00 4C CD 21 and know what it means
There are a good number of alternative OSes out there, similar to this one. They don't get much attention, however, as they're all (1) short on useful applications, and (2) not Linux. But remember that being UNIX-like is not necessarily the end goal of operating systems, so I'm happy to see alternatives being developed.
As for the negative comments about this OS being written in assembly:
Remember, the rule of optimization has always been "make it work, then make it fast." Low-level OS details--multitasking, memory protection, resource handling, memory management--have been solved problems for 30 years or more. So we know how to make it work; it's okay to focus on making it fast. And, yes, to an experienced programmer with the right mindset, assembly is still faster than C++, everything else being equal. That's just been accepted as a truism, though it was once heresy (much as programmers now accept that object-orientedness is not the panacea that everyone once thought it to be).
MenuetOS Installer Mirror:e t.html
http://www.geocities.com/placebic/2001-09-06-menu
Speak truth to power.
I'm going to write an OS in VB!
with one hand tied behind my back...
The Kruger Dunning explains most post on
Actually, it's unlikely that by the time Moore's law slows done, that hand-coded assembly will be very common at all. Even now, most RISC compilers do a better job than hand-coders unless there are specialized instructions to be taken advantage of or some special knowledge that the coder has that the compiler doesn't.
... architectures.
Take a look at the hardware documentation for the 21264 pipeline or the architecture documentation for the IA-64 and think about how much fun it would be to write reams of hand-coded assembly for them.
If Moore's law slows down, I suspect that we'll see even more work on aggresive optimizing compilers and profile-driven optimization, not on trying to hand-optimize general-purpose code for 16-way issue multithreaded speculative out-of-order
Neat!!! How long until someone writes the first PostScript viruses? :)
This space for rent. All reasonable inquiries will be entertained at proprietors discretion.
But were they graphical? That's the main point. He wrote a graphical OS in ASM.
A deep unwavering belief is a sure sign you're missing something...
It's great that people wish to write applications and operating systems in assembly. They possess a greater knowledge of the hardware layer of the computer than I, and a greater need for the abstract. Given the choice, C is my preferred language. It allows me to concentrate on the application side of things, yet gives me enough low-level control that I can do hardware specific instructions w/o having to enter the assembler.
Assembly has its uses, especially in code optimization, and it will probably never go away for that same reason. It is certainly a "no nonsense" approach to programming, and ideal for embedded applications.
assert(expired(knowledge));
Well, I suppose this guy deserves praise for having achieved something unusual, but as far as I am concerned, this is of the order of building a 50ft Statue of Liberty replica in one's back garden using beer cans. Difficult, possibly absorbing, oddly impressive, and utterly useless.
There are a whole bunch of reasons not to do this.
1. It's not efficient, even in the limited sense "producing code that runs faster than the opposition". On modern architectures, using pure handcoded assembly only tends to have a performance benefit when you know something the compiler doesn't (say, some kind of aliasing relationship among variables in a function) or when you can use instructions that a compiler can't. Rewriting a hot-spot in pure asm is one thing, but trying to beat the compiler overall is quite another. This disparity is even more pronounced in the world of RISC/EPIC... if you doubt me, try beating global register allocation for a function with 200 basic blocks and a thousand live ranges. By hand. Good luck...
2. It's not in the slightest bit portable. Not to other architectures (obviously) - and it's liable to suffer from immense performance problems even moving to other implementations of the same architecture with different latencies and numbers of functional units.
3. It's been done already, ages ago. This is how people used to build operating systems. There are good reasons why they stopped. There is nothing innovative about doing another Commodore 64 operating system almost 20 years after the fact. The constant and strange references to color and sound sort of reinforce this impression, too.
4. It doesn't illustrate any particularly interesting principle. Using a medium-level language (or even a high-level language) to build a toy OS from the ground up allows you to concentrate on OS principles, while still getting down to the bare metal for the code that has to be written in asm. Writing a boot-loader or a well-optimized string copy function is an illuminating task (well, at least the first time you have to write one, anyhow). However, once you are a competant asm programmer, writing merge sort in asm instead of C will teach you nothing about asm or merge sort that you didn't already know. And one could use the time saved to learn the basic principles of optimization, which, based on his remarks about Linux, the author of this system clearly doesn't know.
5. Asm is difficult to write and debug. No compiler to catch obvious errors. This is so obvious to require no discussion.
6. (addressed only to those people who think that this leads somewhere practical - if you merely admire it as a beer-can-Statue-of-Liberty, ignore this one) It'll Never Work. I'm sure it does just fine as a toy system, but a POSIX layer? A TCP/IP stack? Ummn, no. It's simply never going to happen. There are plenty of tiny OS's around on which lean systems could be based, but they were written and designed to be dense and elegant, not to prove some weird point about asm programming.
You're thinking of C. Assembly isn't meant to be portable. The idea of writing assembly code is to tune some very efficiency-critical code for a particular platform.
What portable code would you write, which wouldn't be easier (and probably faster, since the compiler could do more optimization) in C? (Or -- god forbid -- a high level language?)
That's crazy. C absolutely can meet or exceed asm speeds, and high level languages often do the same. The problem is that it's nearly impossible to manage optimized assembly code, so there are some kinds of optimizations (ie, software pipelining) which can only realistically be done by a compiler. Even if speed was the primary concern (and this is rather dubious to begin with), it's not clear that asm would always win.