Delta, on Dec 31 2008, 06:51 AM, said:
Overlord, on Dec 30 2008, 06:10 PM, said:
Sik, on Dec 30 2008, 02:31 PM, said:
Overlord, on Dec 29 2008, 11:13 PM, said:
Note I said voluntarily, before the legions of hack coders jump on me.
And OS developers.
I thought most of modern-day OSes were written in C now?
Ideally most of it would be written in C. However, at the very lowest levels of the OS, you'd eventually have to get into assembly because you simply can't directly interact with hardware in the same way you can with assembly. That said, you can create a higher-level C interface over some nitty-gritty asm and have the vast majority of the OS written in C/C++.
This. No matter what, some things are very processor specific, and those things have to be done in assembler because they aren't featured in any high-level language. They're often wrapped into functions, indeed, but still you need
to use assembly, unless you're so crazy you create your own high-level language exclusively for the operating system. But then you're using assembly for the compiler, unless you're even crazier and compile directly into machine language X_X
Overlord, on Dec 31 2008, 12:10 AM, said:
Besides when proramming for very old (and hence slow) hardware trying to achieve for full speed, assembly is the only option. Now, if you try to do that with new hardware...
You're quite correct on the first sentence. The second - it's a bit ehhh. It's like Gentoo users who compile every app for their system - sure, it'll go faster, but is an app starting in 0.98 seconds really noticable over 1.0?
More to my point. There's little point programming in assembly for new hardware both because most likely it won't be noticeable, and actually there are so many different types of technology that what speeds up in one processor may slow down horribly in another one - even if newer. Sometimes it may even hurt (using RDTSC for timing fails miserably in any kind of multiprocessor or multicore enviroment). So no.