Linked by Hadrien Grasland on Fri 28th Jan 2011 20:37 UTC
OSNews, Generic OSes It's recently been a year since I started working on my pet OS project, and I often end up looking backwards at what I have done, wondering what made things difficult in the beginning. One of my conclusions is that while there's a lot of documentation on OS development from a technical point of view, more should be written about the project management aspect of it. Namely, how to go from a blurry "I want to code an OS" vision to either a precise vision of what you want to achieve, or the decision to stop following this path before you hit a wall. This article series aims at putting those interested in hobby OS development on the right track, while keeping this aspect of things in mind.
Thread beginning with comment 460187
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[4]: Machine language or C
by Alfman on Sat 29th Jan 2011 20:22 UTC in reply to "RE[3]: Machine language or C"
Alfman
Member since:
2011-01-28

The majority should definitely be coded in a high level language.

In the days of DOS TSRs, we wrote in assembly because the code had to be small and efficient.

Even to this day it's often easy to beat a compiler's output simply because it is restrained by a fixed calling convention. In x86 assembly language, I am free to stuff values where I please. A variable can be stuffed into segment registers, a function returning boolean can use the "zero flag". This eliminates the need to do "cmp" in the calling function.

In my own assembly, I can keep variables intact across function calls without touching the stack. To my knowledge, all C compilers use unoptimized calling conventions by design so that separately compiled object files link correctly.

Of course above I'm assuming that function call overhead is significant, YMMV.


However, all this optimization aside, looking back on TSRs I wrote, it takes a long time to familiarize oneself with code paths again. This is true of HLL too, but even more so with assembly. It is crucial to comment everything in assembly, and it is equally crucial that the comments be accurate.

Low level assembly is just not suitable for code that is meant to developed over time by many people. Besides, it's not portable, and cannot benefit from new architectures with a simple recompile.

Off the top of my head, the bootloader and protected mode task management are the only things which really require any significant assembly language.

Reply Parent Score: 1

RE[5]: Machine language or C
by WereCatf on Sat 29th Jan 2011 20:34 in reply to "RE[4]: Machine language or C"
WereCatf Member since:
2006-02-15

Even to this day it's often easy to beat a compiler's output

I quite doubt that. There's been plenty of discussion of this and the general consensus nowadays is that it's really, really hard to beat atleast GCC's optimizations anymore. Though, I admit I personally have never even tried to ;)

Reply Parent Score: 2

RE[6]: Machine language or C
by stestagg on Sun 30th Jan 2011 00:10 in reply to "RE[5]: Machine language or C"
stestagg Member since:
2006-06-03

I have tried it, just for fun. I even used some example assembly provided by AMD, optimised for my processor for parts of it, but could only get up to about 80% of the gcc performance.

Reply Parent Score: 2

RE[6]: Machine language or C
by Alfman on Sun 30th Jan 2011 03:23 in reply to "RE[5]: Machine language or C"
Alfman Member since:
2011-01-28

"Even to this day it's often easy to beat a compiler's output"

"I quite doubt that. There's been plenty of discussion of this and the general consensus nowadays is that it's really, really hard to beat atleast GCC's optimizations anymore."

I feel you've copied my phrase entirely out of context. I want to re-emphasize my point that c compilers are constrained to strict calling conventions which imply shifting more variables between registers and the stack than would be possible to do by hand.

I'm not blaming GCC or any other compiler for this, after all calling conventions are very important for both static and dynamic linking. However it can result in code which performs worse than if done by hand.

As for your last sentence, isn't the consensus that GCC output performs poorly compared to other commercial compilers such as intel's?

I would be interested in seeing a fair comparison.

Edited 2011-01-30 03:37 UTC

Reply Parent Score: 1