benefit of writing kernel in c++

[lemonyii]

hi,
i'm considering what benefit i can get from c++ for my kernel, and i'm working on things like STL now. i'm not very good at c++ yet.
as my kernel is still less than 30 files(including header files), i'm considering to rewrite it in C++, if i can get enough benefit from it
the first benefit i have thought is that i can get my code more clear with class. but there is a problem, the constructor, i have to call it before my kmain() for global variables.
and the second, STL. but it seems that i can't use it in kernel, for that it will have to allocate some memory dynimically(i dont know if i've misunderstood it).
third, i can declare temperory variables where i need them.
fourth, and the most important. what if i hope to write an object-oriented kernel? what properties can i use in kernel mode? what i care most is memory allocating, as STL, "new" and some other implicit place will all do it so ofter.

say, what can i get from c++ , in spide of the cost of rewriting my kernel?

added:
my microkernel is one with messager, thread level scheduler, and phys page alloc/free. all other parts are in independent space, communicating through messages of 64 bytes.

thank you,
lemonyii

[Karlosoft]

Hi,
Well my kernel is written in C++ but I can say that it doesn't matter the language. All you write in C++ could be translated in C, Assembly, or any other language. It's more important which compiler do you use than the language itself.

Developing an os in C++ could be faster for the programmer, but *usually* not for your CPU.
The major part of compilers adds instructions or doesn't do some optimizations.

[fronty]

The major part of compilers adds instructions or doesn't do some optimizations.

Luckily you can use a sensible compiler which adds instructions for no reason and does the same optimizations as C compiler, like GNU's C++ compiler.

[Creature]

My kernel is also written in C++.

the constructor, i have to call it before my kmain() for global variables

Partially true, but it is possible to call it right at the start of kmain, or at any time in your kernel, depending on when you need these global variables (see the C++ articles).

say, what can i get from c++ , in spide of the cost of rewriting my kernel?

You might lose some performance, depending on which C++ features you use. But it is possible to write a C++ kernel (or a prorgam) that performs almost as fast as a C program, taken that you don't use some of the features. Some of the key bottlenecks (well, just performance degraders really) are:

• Virtual functions - At runtime some functions may have to be resolved so the right ones are called (it's hard for the compiler to predict what the outcome is going to be).
• Exceptions - Although you're going to have these turned off when writing your kernel anyways. It is possible to implement support for this, but I wouldn't advise it. It causes extra instructions to be inserted on the stack so stack unwinding is possible. And the claims "It won't be slow unless I explicitely use throw/try/catch" are false AFAIK. The compiler has to keep track of what functions were called when so it can backtrace through the stack if necessary.
• RTTI (Run-Time Type Identification) - Allows you to know the type of variables at runtime. Anything that is done at runtime and not at compile-time may slow down your code (type checking is usually done at compile-time). It is unlikely that you'll need this. Even if you do, there are workarounds to it.

Of course, you can stay away from all these bottlenecks (use --no-rtti with --no-exceptions to disable the last two and avoid using the first one). But there are some good points as well (of course, these are relative to whether you need them and if you care for them):

• Access to classes (basically structures that have variables set to private by default, unless stated otherwise).
• Structures are extended with class-like attributes (access modifiers such as public, private and protected).
• Structures/Classes can have member functions, operator overloads, (multiple) inheritance, etc.
• Practically any function can be overloaded (multiple functions with the same name, but different argument types).
• References - Basically the same as pointers (AFAIK equally fast). Pointers can be null, references can't. They also allow you to directly access a variable as if it were a pointer. The downside is you can't directly see from the use of a variable that it's a reference (pointers have specific syntax, like p->var, (*p) = x, etc. while references have the same syntax as usual variables.
• Default arguments for functions in their declarations, e.g. void foo(int var = 5) allows you to execute foo() and foo(7).

There are probably more disadvantages and advantages, but I guess these are some of the most notable ones.

Hope this helps.

[Solar]

I would use C++ anytime, if for nothing else than namespaces, function / operator overloading, classes, and type safety.

None of which will cost you a single additional opcode in your binary

Beyond that, tradeoff country begins. Virtual functions and templates are nice, but not for free. Still, there is usually no way to implement their functionality in C in a way that's nearly as efficient as in C++, so if you need them, use them.

Other stuff - RTTI and exceptions - require support code. Personally, I drew the line there, because I didn't want to spend more time "setting up" than strictly necessary. If I hadn't stopped my project, I guess my yearning for exceptions would have gotten the better of me, though.

The STL... I don't really see the benefit there. The STL is great for user-space application development, but a bit too involved for kernel work IMHO. (It requires quite some previous work to get a full STL running - like memory management and file I/O interfaces - and there is a lot of stuff going on behind the scenes of the STL that most STL users are not aware of which could bite you in kernel space. Keeping this lib under the kind of strict control necessary for kernel work requires a pro. I am not sure I could do it.)

You can get quite far with "lookalike" interfaces (like a kout object printing stuff to screen with overloaded operator<<() without actually being an ostream object).

[Solar]

You can provide static and stack memory allocators for some things for the time before you have real malloc working - which is easy thanks to STL design.

Exactly what I meant with the "pro" statement: Do you have an idea how many professional C++ coders haven't even heard about STL memory allocators? You and I could probably pull it off, but I would not suggest this thing easily to anyone whom I don't positively know to be a C++ grok.

[lemonyii]

thanks for you fast reply. and i will think about all these in my bed, because it will be TOMORROW 7 minutes later in my country, and i will check the post 12 hours later.
and how should this be done:

Partially true, but it is possible to call it right at the start of kmain, or at any time in your kernel

i tried a sample

Code: Select all

class A{
public:
       A(){
           cout<<"constructor"<<endl;
       }
       int b;
};
A a;
int main(){
    cout<<"main"<<endl;
    a.A::A(); //nor can a.A() pass compiling
    while(1);
    return 0;
}

should i call the symbol generated by compiler? if so, what's the symbol of this sample generated by gcc?
i'll have to undertake it tomorrow, oh, it's 0'o clock today now!

thank you,
lemonyii

[Owen]

• Exceptions - Although you're going to have these turned off when writing your kernel anyways. It is possible to implement support for this, but I wouldn't advise it. It causes extra instructions to be inserted on the stack so stack unwinding is possible. And the claims "It won't be slow unless I explicitely use throw/try/catch" are false AFAIK. The compiler has to keep track of what functions were called when so it can backtrace through the stack if necessary.
• RTTI (Run-Time Type Identification) - Allows you to know the type of variables at runtime. Anything that is done at runtime and not at compile-time may slow down your code (type checking is usually done at compile-time). It is unlikely that you'll need this. Even if you do, there are workarounds to it.

Lies. Exceptions and RTTI cause absolutely no performance overhead compared to code built without them. When GCC says it has "zero cost" exception handling, it means it. Now, exceptions and RTTI imply runtime overhead when used; but their existence doesn't cause overhead in and of itself.

[smoothCoder]

In the end, the question is how comfortable you feel with the language. This determines your overall efficiency as a programmer and the joy you get from writing code.

I agree totally. I am faster writing ASM code than C. I see it more clearly when "only one" thing ocurr in one line of code. In C, one have much actions coded in the same line, and I consider this more mnemonic than ASM. And is easyer for me to debug an code when I see what exactly happen and when exactly(not ever the case of C).
And OOP?-my opinion is that an OS developer should not use OOP, he should leave the OOP for the application developers in the very last stage of the final (User-end) OS product. By definition OOP is the slower choice.

[Creature]

• Exceptions - Although you're going to have these turned off when writing your kernel anyways. It is possible to implement support for this, but I wouldn't advise it. It causes extra instructions to be inserted on the stack so stack unwinding is possible. And the claims "It won't be slow unless I explicitely use throw/try/catch" are false AFAIK. The compiler has to keep track of what functions were called when so it can backtrace through the stack if necessary.
• RTTI (Run-Time Type Identification) - Allows you to know the type of variables at runtime. Anything that is done at runtime and not at compile-time may slow down your code (type checking is usually done at compile-time). It is unlikely that you'll need this. Even if you do, there are workarounds to it.

Lies. Exceptions and RTTI cause absolutely no performance overhead compared to code built without them. When GCC says it has "zero cost" exception handling, it means it. Now, exceptions and RTTI imply runtime overhead when used; but their existence doesn't cause overhead in and of itself.

The user indicated with his last code sample that he was using GCC, but he never said he was using GCC for his kernel as well. Even if he is, not all compilers (and their versions) handle exception handling the same way. Note also that this "zero cost" exception handling comes at a price: it may take away the problem of having extra overhead when no exceptions are called anyways, but if they are, it will AFAIK give you an additional performance penalty (even worse than the original penalty, if I read the manuals correctly).

Also, if I implied RTTI had the same 'problem' (overhead even if not used) as exceptions, I may have incorrectly formed my post, since I was only referring to exceptions.

PS: I was not aware of the "zero cost" exception handling, thanks for your post.

[Owen]

• Exceptions - Although you're going to have these turned off when writing your kernel anyways. It is possible to implement support for this, but I wouldn't advise it. It causes extra instructions to be inserted on the stack so stack unwinding is possible. And the claims "It won't be slow unless I explicitely use throw/try/catch" are false AFAIK. The compiler has to keep track of what functions were called when so it can backtrace through the stack if necessary.
• RTTI (Run-Time Type Identification) - Allows you to know the type of variables at runtime. Anything that is done at runtime and not at compile-time may slow down your code (type checking is usually done at compile-time). It is unlikely that you'll need this. Even if you do, there are workarounds to it.

Lies. Exceptions and RTTI cause absolutely no performance overhead compared to code built without them. When GCC says it has "zero cost" exception handling, it means it. Now, exceptions and RTTI imply runtime overhead when used; but their existence doesn't cause overhead in and of itself.

The user indicated with his last code sample that he was using GCC, but he never said he was using GCC for his kernel as well. Even if he is, not all compilers (and their versions) handle exception handling the same way. Note also that this "zero cost" exception handling comes at a price: it may take away the problem of having extra overhead when no exceptions are called anyways, but if they are, it will AFAIK give you an additional performance penalty (even worse than the original penalty, if I read the manuals correctly).

PS: I was not aware of the "zero cost" exception handling, thanks for your post.

The only compilers that I know of which don't follow the common C++ ABI are GCC 2 and earlier, MSVC and SunStudio for Linux. All of those would be rather odd choices

And yes, it makes thrown exceptions very expensive. Guess what? Exceptions are supposed to be exceptional.

[lemonyii]

The user indicated with his last code sample that he was using GCC, but he never said he was using GCC for his kernel as well. Even if he is, not all compilers (and their versions) handle exception handling the same way.

in fact i've never used any other complier in my real programming. and i dont care the speed of exception:

And yes, it makes thrown exceptions very expensive. Guess what? Exceptions are supposed to be exceptional.

who cares about the speed when the kernel comes to troubles, some of which will make it crashed?

Lies. Exceptions and RTTI cause absolutely no performance overhead compared to code built without them. When GCC says it has "zero cost" exception handling, it means it. Now, exceptions and RTTI imply runtime overhead when used; but their existence doesn't cause overhead in and of itself.

yeah, (i think) if we really have to do similar jobs like RTTI or exception handling, we cannot do it much faster if we do it some other way. if we replace RTTI with a TYPE field in the front of all structs, it seems still a lot of cost.

C++ Bare Bones article on wiki explains how to call static object constructors before your program runs. In your place I would read the wiki from start to finish THROUGH.

yeah, but it was 0'o clock today at that time, i'm not made of steel, i have to read it in my dream. but now i'll read it soon.

thank you,
lemonyii

[lemonyii]

what is ___gxx_personality_v0 on linking?

[Creature]

what is ___gxx_personality_v0 on linking?

I believe it is part of GCC's exception handling mechanism. Using --no-exceptions should fix it. An alternative is to implement support for exceptions yourself.

[Colonel Kernel]

what is ___gxx_personality_v0 on linking?

http://stackoverflow.com/questions/3290 ... ity-v0-for