KThunder wrote:
many assembly coders nowadays know all about caches etc and how to code specifically for them. knowing exactly how the actual pipelines work etc can result in speedups. there are several emulator coders and c/inline coders who do this extensively. see emulators.com for one.
Be serious (again). When coding an operating system you really don't want to be bothered with this stuff. This is bitfscking at its best. Operating systems are about ideas how to cope with conflicting issues like fast access to limited resources, stability, driver support, and scalability. Not about optimising the code to fit the pipeline architecture for a very specific CPU.
if you know how a specific pipeline runs and how much cache you have etc you can code for that. you can also order memory accesses and instuction streams around the architecture.
This is a boring and painstaking task best done by a optimising compiler. These are peephole optimisations, and humans will have a really hard time beating the compiler. The compiler can generate quite good to very good code for any CPU at the flick of a switch; humans will find that very hard.
You seem to be stuck in the state when slapping 'assembly' on a product made it 'better' and 'more optimised' and 'faster'. Compilers have evolved. Humans have not.
people think they have billions of instuctions per second now so who cares about optimization you can write a program quickly and not worry about code size or speed. i mean we all have a gig of ram at least right?
No, you've got that all wrong. It depends on your design specifications. If you want to code a tiny lightweight OS, there's nothing stopping you. Multiple such designs exist. But going assembly doesn't mean it's lightweight. It just means you have too much time on your hands to be able to
code such a complex system. If the developers had gone C, the system would have
at most taken two floppies instead of one, and now I'm being exceedingly harsh on the compiler.
thats how you end up with operating systems that take up gigabytes of space on a hard drive and take several minutes to fully load.
No, that's feature creep. Tons and tons and tons of extras a tiny handful of people expect out of the box from the computer. A googol of drivers is included for the most exotic types of hardware. A kazillion graphics, sounds, fonts, helpful documents, compatibility programs and what-not are included. And so forth, und so weiter.
The kernel files of any 'big' OS are really not big. I believe Windows 2000's kernel is about 700 KB or thereabouts. My Linux kernel is about 900 KB.
that is what this thread is about, someone wants a small efficient os that loads very quckly and does what he needs and thats it. not a gargantuan chunk of code that loads a hundred libraries and apps and protections and other crap that he doesnt need. if you just want to send a simple email to a freind or something xp is way way overkill
Aye. But
my statement was that coding MenuetOS in assembly is a waste of time, as the exact same performance would have been obtained by going C. Take a look at
SkyOS, for example. Same idea, but
lightyears ahead of MenuetOS.
Back on topic of the original thread: perhaps SkyOS isn't such a bad idea for the OP. It is actively developed, very fast, has nice features, is perfectly usable, has a small footprint, and so forth. I might investigate it in the future.