Page 2 of 3

Re: How many C++ kernels?

Posted: Sat Jun 09, 2007 3:10 am
by Solar
Twitch wrote:And if so how did it change the design of the kernel aposed to a C kernel?
I wrote what could be called a "Multiboot barebones" - a kout global object used by a main() to print the values from the multiboot data structure, nothing more.

The beauty of "cout << whatever" was a clear winner in my book, because you didn't have to do any format string parsing or whatnot to make it work, and extending kout with another data type was dead simple, too. I strongly believe similar benefits can be had in many other parts of the kernel.

Another strong point is that, with C++, it becomes quite natural to keep data structure definitions and the code handling those structures together, something that requires a conscious effort to do in C.

And in the end, any good C code I have seen so far is effectively object oriented anyway, so why not use a language that supports this with additional syntactic suggar that doesn't cost you anything (if used correctly)?

Standard disclaimer, your mileage might vary.

Posted: Sat Jun 09, 2007 4:49 am
by senaus
My kernel has always been object oriented, so converting to C++ seemed like a good idea. I don't regret it, everything is so much cleaner with classes. Pure virtual functions are a very powerful concept too, which greatly simplify IO in my opinion.

I've implemented support for new/delete and global objects quite easily. I'd love to have exceptions support, but I don't know where to start!

Posted: Sat Jun 09, 2007 5:40 am
by Tyler
I would consider writing for C++ if someone wrote a linker designed to reduce need for any kludges to get it started. I feel that using the Ctor/Dtor section is a bit irrelevant in OS Development.

I do like Object-Oriented Designs though, especially as you find most OS' built into obviously Classable Chunks, even going as far as having sets of functions with identical prefixes, seems a bit silly to not use Classes.
Kevin McGuire wrote:I would like for you to smoke a bunch of marijuana then come here in the forums and make a post so I can make fun of you for being a idiot.

Oh... wait. That might be the problem already. Huh?
Perhaps it is your problem? You don't seem to be able to concentrate on a post long enough to realise i was making a point about his obviously marketed comments about Alcohol, not about his analogy which was fine. Had i had a problem with the analogy i would have made another one, perhaps that it is more like Water... free of as many additivs as possible, and different around the world.

Also... i don't smoke Marijuana, despite my mothers attempts for me to start, but you don't have to take something to fight against the lies surrounding it. I don't like Windows or Linux, but if you make false comment's about them then i will attempt to enlighten you. You can use your word for me, it will probably just **** it out, but best to get it out there.

id like to do C++

Posted: Sun Jun 10, 2007 1:15 pm
by com1
I started learning C++ first. I definitely think it is easier to manage linked list in C++ than in C. Id like to create a kernel in C++, but i just can't seem to get pre-settings right (-nostartfiles, etc.)

Posted: Sun Jun 10, 2007 7:05 pm
by frank

Code: Select all

-fno-builtin -nostdlib -fno-exceptions -fno-rtti
usually works for me

Posted: Sun Jul 08, 2007 5:45 am
by dushara
eCOS is written in C++. (Though there's a bit of C and ASM in it).

Posted: Mon Jul 09, 2007 1:57 pm
by JJeronimo
AJ wrote:The main reason I actually prefer my c++ kernel over my C kernel is that I like classes. They seem to make everything so much neater [ducksandruns]. *This is purely personal preference*[raisesheadoverparapet].
You can simulate namespaces by carefully stripping and partially linking object files... although, it won't provide you with the neat code look.

JJ

Posted: Tue Jul 10, 2007 12:01 am
by os64dev
Tyler wrote:I would consider writing for C++ if someone wrote a linker designed to reduce need for any kludges to get it started. I feel that using the Ctor/Dtor section is a bit irrelevant in OS Development.
Yeah why do we need global object construction and destruction in OS development. Are you kidding?

Posted: Tue Jul 10, 2007 12:34 am
by pcmattman
os64dev wrote:
Tyler wrote:I would consider writing for C++ if someone wrote a linker designed to reduce need for any kludges to get it started. I feel that using the Ctor/Dtor section is a bit irrelevant in OS Development.
Yeah why do we need global object construction and destruction in OS development. Are you kidding?
Example: global object 'cout', or 'console'

Posted: Wed Jul 11, 2007 2:08 am
by JamesM
The language used for any kind of development is really almost irrelavent as far as performance is concerned, as long as it (a) compiles to native machine code and (b) doesn't require ridiculous amounts of runtime support. It's more about the *algorithms* you choose to implement.
Remember from coding theory that it's the order of an algorithm (e.g. O(log(n)) ) that counts most. The leading constant, which will be what is determined by the language/compiler choice (unless one compiler performs tail recursion->iteration optimisations and one doesn't) doesn't make that much of a difference.

And you don't *need* global objects. They can be useful, but take the following case (as in my OS, but I *do* use global objects ;))

Code: Select all

class Kernel { ... }

GlobalObject1 *myObj1;
GlobalObject2 *myObj2;
Kernel *kernel;

void _main()
{
  GlobalObject1 tmp1(...);
  myObj1 = &tmp1;
  GlobalObject2 tmp2(...);
  myObj2 = &tmp2;
  Kernel tmp3;
  kernel = &tmp3;
  
  kernel->run();
}
The only disadvantage is your 'global objects' must be pointers, but that shouldnt really matter. In this case they are initialised, stored on the stack then the kernel is run. As far as the kernel is concerned those global pointers are initialised.

JamesM

Posted: Wed Jul 11, 2007 2:19 am
by os64dev
@JamesM
This is a dangerous form of programming consider the following code:

Code: Select all

MyObject *  global;

void init(void) {
    MyObject      temp();
    global = &temp;
}

void main(void) {
    init();
    global->someFunction();
}
Though it very obvious that this is faulty programming, as the object is destroyed on exitting init. It is possible with your solution of having pointers to global objects. Furthermore every access to the global object now uses an additional memory dereference, therefore adding code and decreasing performance albeit little. In short if you want global objects then declare them as such. In your case you don't have global objects you have global pointers to objects and that is something different.

Posted: Wed Jul 11, 2007 8:09 am
by JamesM
Furthermore every access to the global object now uses an additional memory dereference, therefore adding code and decreasing performance albeit little
Fair point about the performance penalty. I was suggesting this method as an alternative workaround, not as the best possible solution (As mentioned, I use proper globals myself)
This is a dangerous form of programming consider the following code:
In most cases it would be dangerous. However in an OS it is known that the first and ONLY function that is ever called is _main(). Therefore it is safe to do any pointer initialisation there. Unless the stack gets corrupted or VM space gets changed, it's safe. Again though, it's not optimal and I know it!

JamesM

Posted: Wed Jul 11, 2007 9:56 am
by bluecode
Well, but it is not wise to create them on the kernel stack, because you reuse this stack in every interrupt and syscall and possibly overwrite your objects. It is better to use new/delete then and store this objects on the heap.... but real global objects are still better.

Posted: Wed Jul 11, 2007 10:02 am
by Alboin
Couldn't you just create global variables through static members? Like:

Code: Select all

class test {
	protected:
		static myclass *Instance;
	public:
		static myclass *GetInstance();
};
Then to call it:

Code: Select all

test::GetInstance()->my_func();

Posted: Thu Jul 12, 2007 12:59 am
by os64dev
Thats called the singleton pattern and is one method of having global variables. In a proper C++ environment you should have no global variables only objects and pointers to objects:

Code: Select all

class Kernel {
    APIC * _apic;

    void init(void) {
        _apic = APIC::getInstance();
    }

    void run(void) {
        _apic->doSomeStuff();
    }

    void term(void) {
        //- do the cleaning.
    }
}

void main(void) {
    Kernel * core = new Kernel();

    core->init();
    core->run();
    core->term();
}
Creating objects on a specific location as for the APIC can be done via a Singleton pattern if there is only one. Remember to use the placement new (see wiki) to instanciate the object. As you can see there are no global variables only the root object kernel and its components.