Yeah, but it's a damn pretty proof of concept, right?
Bisqwit, maybe you should take a leap at it? I recon you have some experience in impossible programming languages, eh? =)
Writing an OS in asm makes absolutely no sense (and has made absolutely no sense for over 30 years; perhaps in the early 70's it made sense because there were no other options, but that hasn't been the case for a long, long time.) There are several reasons for this:
1) Asm, no matter how much it is enhanced with preprocessor macros and such, is a very rigid and non-modular language. After all, you are writing CPU opcodes directly, and CPUs are not designed for modularity. This makes writing and managing large projects a nightmare, greatly increases the chance (and severity) of bugs, and many other problems.
2) There's no speed nor size advantage to speak of, when compared to modern higher-level language compilers. It might have been an issue in the 70's and 80's, but it hasn't been so for a long, long time. Making the size/speed argument in favor of asm makes little sense. (It could make sense if you are writing an OS for an embedded system with very little RAM, especially if that system in question has poor compiler support, but this OS is targetted at PCs.)
3) It's not portable. Just count the number of systems to which Linux and NetBSD have been ported (in fact, the slogan for the latter is "Of course it runs NetBSD"). Why is this so? Certainly not because they are written in asm.
4) And even more importantly, and related to the same thing as the previous point: It becomes stagnant. The OS might be optimal for the system it was written for at the time, but it will quickly become more and more suboptimal as new processors are released. The OS cannot take advantage of optimizing compilers, which are always updated to take advantage of new CPU designs. Consider that, for example, an OS written in asm for the 80386 (and highly optimized for that system) would be significantly more inefficient in a modern PC than an OS which has been compiled from a higher-level language and optimized for the latter.
Bisqwit, maybe you should take a leap at it? I recon you have some experience in impossible programming languages, eh? =)
In fact I experimented with MenuetOS less than a week ago. I was surprised to see you posted about it around the same time. Coincident?
A big problem with MenuetOS is that officially it supports one development tool only: Fast Assembler (FASM).
There is a libc implementation for MenuetOS from years ago and a gcc cross-compiler, but I could not get them working for Linux-hosted compiling. The original author used djgpp-hosted compiling. That someone, or someone else has used them anyway to compile DOSBox, ScummVM and some other programs for MenuetOS. Just that they are ancient versions, relatively speaking. DOSBox v0.61 for instance. Given that DOSBox (which uses SDL) works, FCEUX (which uses SDL) should also work.
The kernel API is very different from posix; for instance, the OS does not implement relative filesystem paths at all. This may pose a significant challenge for porting certain applications.
Hmm, interesting. It appears that the main applications for such a system would be local low-performance media serving or, which actually does sound intriguing, emulation that takes advantage of the absence of various OS hindrances (which often affect input and output processing in a mildly negative way).
(Also, I believe it's "assembly", not "assambler"...)
Warp wrote:
Edit: I think I understand now: It's my avatar, isn't it? It makes me look angry.
Warp, I'm pretty sure you didn't understand the creators' intent. Read the front page.
And what exactly is this intent? The only thing related to something like that I can see on the front page is:
The design goal, since the first release in year 2000, has been to remove the extra layers between different parts of an OS, which normally complicate programming and create bugs.
What does this have to do with asm? You can achieve the exact same goal with any language you can write an OS with (most typically C). Making it in asm only complicates things unnecessarily, as I already commented.
It's a common misconception that the operating system is somehow a "hindrance", an extra overhead on the system that slows down programs, and thus a program that is run directly, without any OS whatsoever, will be much more efficient and fast. There's also a relatively common misconception that writing a program in asm will automatically make the program faster. (This latter misconception might originate from the 80's, when interpreted BASIC and asm were usually the only alternatives in home computers.)
An OS might consume some additional RAM which, technically speaking, is away from the application. However, in modern PCs that's only a small fraction of a typical basic setup (yes, even with Windows Vista, although that is more memory-hungry than most). However, modern operating systems do no consume significant amounts of CPU time which would be away from applications. Basically the only thing an OS does most of the time is task switching, and that's a very light operation (I'd estimate that it typically takes only a fraction of a percent of CPU time). Bypassing the OS completely would not speed up the application basically at all.
In fact, in many cases it can be the opposite: It may even be that the OS helps the application run faster, as ironic as that might sound. Not necessarily in terms of CPU time (although there might be some situations where it helps even with that, especially in modern multicore CPUs), but with most other hardware, most prominently the display hardware and I/O. The thing about the OS is that it has hardware drivers, and these drivers are usually optimized for the hardware in question (being usually written by the manufacturers of the hardware in question).
For example, thanks to the display driver (which ultimately can run thanks to the OS) the application will run much faster when displaying graphics on screen (be it 2D or 3D). Without such a driver the application would have to use some generic "standard" implementation which will inevitably be a lot less efficient than the highly-optimized implementation provided by the hardware-specific driver. (Also, there's no universal standard to use very high resolutions or 3D acceleration, so any generic implementation would not work with a big bunch of existing hardware.)
The OS can also help with I/O. It can, for example, provide buffers, caches and other types of optimizations which are fine-tuned for a specific type of I/O hardware, and which could be hard to support on a per-app basis. The I/O thus becomes typically much faster.
So, ironically, operating systems typically make applications run faster, not slower.
Well, in any case, the fact is MenuetOS has been written entirely in asm and that the author holds an asm-favorable idea.
We are not defending that idea here. We are just reporting that the author thinks that way. So, Warp, while we can appreciate your fierce desire for correctness and facts, your apologetic/rebuttal oriented attitude is slightly misaimed here and as always, it upsets people because it is not easily distinguishable from attempting to start a fight.
Thank you for the analysis regarding the role of the operating system in application efficiency.
Bisqwit, maybe you should take a leap at it? I recon you have some experience in impossible programming languages, eh? =)
In fact I experimented with MenuetOS less than a week ago. I was surprised to see you posted about it around the same time. Coincident?
Cool. I knew that you would take a pitch at it as an interesting thing, more or less. :)
I just came across it while browsing around at work somehow. Not sure why really. Probably bumped into it while googling around. I just thought it was a very cool project, yet crazy as hell given all the facts about OS's in general, computer architectures, and compilers.
Of course it is very sub-optimal to develop for this type of system, and extremely time consuming. Hence we don't see a fully functional commercial OS built on this theory and practice. I still think that the point being made is awesome as a proof of concept, and I like that some people are still so eager to optimize most stuff them selves, instead of letting compiler routines do the business for you.
In my opinion, this is a true art form somehow, and I really cheer the enthusiasm for this.
In my opinion, this is a true art form somehow, and I really cheer the enthusiasm for this.
Writing directly in asm is indeed a dying artform (and has been for a long time). Nowadays it's needed mostly when developing compilers (rather obviously) and for certain very primitive embedded systems (although even that's a dying artform, as most embedded systems, even very simple ones, tend to have at least a C cross-compiler or similar). Very small amounts of it is needed when developing the kernel of an OS and some of its components (because there are certain things that cannot be done directly with a higher-level programming language).
The most amazing asm projects are probably the 4k demo compos. I haven't followed the demoscene for a long time, so I don't know how strong this category is nowadays, but I'm assuming it's still going on in one form or another. (There are some more obscure compos for even smaller demos, such as a 256-byte compo or the like. Pretty much forces you to use asm.)
It is not only a dying artform though.
There are some projects for which assembler optimizations are extremely important and beneficial. x264 is one of them. I cannot find it right now (the best I could find is this), but there was a page that explained how exactly assembler optimizations help x264 gain speed by a significant factor.
And it's not just because of the use of SIMD. From what I have read, even if you use the SIMD extensions of GCC (xmmintrin.h and friends), chances are that handwritten asm code ends up being faster. And vice versa, for large functions, chances are that at some point a compiler will do bad register alloction decisions and spill where it need not. This is especially true if the code contains large switch-case statements, where it is very difficult for a compiler to see which registers can be preserved across the switch-case and which ones cannot. Or so I hear, anyway.
Related: http://x264dev.multimedia.cx/archives/category/assembly
Joined: 2/28/2006
Posts: 2275
Location: Milky Way -> Earth -> Brazil
yep, Warp being inflexible again
to clarify:
Assembly:
High level language
Assembly might possibly lead to greater final achievements, but it demands a lot more time and effort.
Also you know that just because an OS is coded in a popular language,that doesn't mean it can be magically ported exactly as it is to another system... they still need to remake a lot of stuff to fit the new hardware.
"Genuine self-esteem, however, consists not of causeless feelings, but of certain knowledge about yourself.
It rests on the conviction that you — by your choices, effort and actions — have made yourself into the
kind of person able to deal with reality. It is the conviction — based on the evidence of your own volitional
functioning — that you are fundamentally able to succeed in life and, therefore, are deserving of that success."
- Onkar Ghate
Bisqwit wrote:
Yeah. Being pedagogic is to teach someone in a very good way, such as illustrating a thing that might in the first place appear as very abstract to people, and I found those images to be in such a way some how, which I found funny.
I used to be a tutor for a broadcasting company, and we used a lot of those kinds of things to illustrate for our customer support how certain techniques worked, or how a system was connected to our customers equipment. :)
Joined: 11/4/2007
Posts: 1772
Location: Australia, Victoria
Ooh! That makes sense! Thanks a lot for the explanation, matey!
Man, what is it with these Swedes/Finnish being far better with English than 'native' speakers? :p
No idea about that one Flygon. Not entirely true in your statement of course. :)
One thing I have noticed though is when people use translation tools, ending up with far more advanced words than needed, sort of. Words which I have never heard native speakers used at all.
I see this mainly as I am in Peru right now, and they use Google translate a lot, either messing things up badly, or utilizes funny/advance words.
Man, what is it with these Swedes/Finnish being far better with English than 'native' speakers? :p
For a foreign speaker, in order to communicate in a languge you have to learn it and know it.
For a native speaker, it kind of comes for free because the baby mind absorbs it unconsciously, and the person never learns to appreciate it, so they go where the fence is low.
That's a theory of the minute anyway.
High level language
Assembly might possibly lead to greater final achievements, but it demands a lot more time and effort.
Also you know that just because an OS is coded in a popular language,that doesn't mean it can be magically ported exactly as it is to another system... they still need to remake a lot of stuff to fit the new hardware.
