OSDev.org

Hi all,

So recently I have been starting to develop my own kernel. I am quite new into the topic, but like it so far and I am ready to struggle. To set up my build environment, I followed the (probably) well-known Bare bones tutorial on the wiki:

http://wiki.osdev.org/Bare_bones

After some rewrite of the terminal stuff, qemu kept rebooting my kernel without notice (I guess a triple fault). This was because the variable terminal_buffer is not declared as being volatile (and was being optimized away). Isn't it best practice to do that and explicitly let your compiler know that this pointer points to a memory-mapped location? Or is it best practice to not compile with any optimization? I am interested to hear your thoughts on this.

LvdB wrote:This was because the variable terminal_buffer is not declared as being volatile (and was being optimized away).

I doubt that this is what was happening. Usually the volatile keyword is used to tell the compiler that the object might change by effects outside of the program, and thus not to cache the variable. If it was indeed optimized away, I would find that.... questionable.

But adding volatile at that point certainly wouldn't hurt, and make things a bit clearer.

After looking a bit more into this, I see you are right. I did not set up my cross compiler correctly, so I should go back to the drawing table.

The issue is that my compiler is producing vectorized instructions. I do not have much experience with these type of instructions, but explicitly turning these optimizations off (which should not be necessary if I did set up my cross-compiler correct in the first place, but hey) "fixes" the problem.

Thanks for your fast answer! I should again look into the definition of a volatile pointer.

Missing volatile cannot lead to crashes here, but it could totally (if you enable whole-program optimization or mark the variable as static) lead to nothing being displayed as the writes get eliminated.

So yes, the missing volatile is a bug in the tutorial.

Speaking of it, the mixed C/C++ style of the tutorial is very bad in my eyes. Nobody is every going to write source-files (as opposed to header files) in way that ensures that they can be compiled both as C and as C++. Does anyone mind if I remove the C++ parts from the example code and move them to the "Writing a kernel in C++" section?

Absolutely, go ahead. The <header.h> style is deprecated for C++ anyway... and I'd fully expect anyone setting out to write a kernel in C++ to be capable to interface with C code without missing a step.