Some confusing results. Just by changing the compiler, my kernel function seems to work - at least on one computer. I'm going to have to investigate this a bit further, because the changes don't seem to work on the second computer. There are slight differences in the emulator versions (Bochs) as well as slight changes in the code. In any case, the real test is trying it on real hardware - hopefully this weekend I will have some time. In the meantime, my next goals are to port stdlib (and of course fill in any missing kernel functions along the way) and then to get a disk running. I have a floppy driver, but that is obsolete hardware these days. I need to write a proper ATA driver (or maybe SATA). But first I will get stdlib started (at least as far as I can before I need file access).

tools

Well I ran into some problems with my code. Turns out that the same kernel function I was calling from kernel mode crashes when called from user mode. I couldn't figure it out for the longest time - until I thought about the differences I have between kernel mode and user mode. Turns out that the root of the problem is two-fold. First of all, I am using a segmented memory model, which not a lot of people do these days. It's a great feature of the chip, and I'm glad iNTel left it in. But of course, the compiler I'm using doesn't know how to generate code using segments. That's fine when I'm running in kernel mode, because my segments start from 0x0 and run the full 4GB, so they really don't come into play. But when I switch over to user mode, all of a sudden my stack segment and code segment have different bases. So my poor compiler (GCC 3.4.6) is generating a DIV instruction which takes the code segment as a default, and generating an address for a variable which is on the stack! This would work fine in any case where the code segment happened to be equal to the stack segment (which is 99% of the code out there today). But when they are different, the compiler just doesn't know how to differentiate between the heap and the stack, and gives me the wrong address. I guess it was lucky that I got a divide by zero exception so it was easy to spot. It could have been a lot worse.

So now my next task is getting my tools up to speed so my user mode code works! That means getting GCC to understand segments. Today I completed the first step - adding KOS as a new target OS to GCC. That sounds palpable - except for the horrible lack of documentation to GCC. Sure, they go into detail on all kinds of useless things [http://gcc.gnu.org/onlinedocs/gcc-3.4.6/gccint/index.html#toc_Target-Macros], but where's the step-by-step on how to add a new target? Ok, maybe that's too much to ask. But how about a listing of the files I need to edit? Thanks to the guys on OSDEV [http://wiki.osdev.org/OS_Specific_Toolchain], this task moved from possibly months of painful searching, to about 2 weeks (an hour here and there of course) of playing around. That tutorial was a real life saver. I mean - my interest here is to write a new OS, not play around with these tools until I happen across the correct configuration to do what I need!

Enough for now - I now have a ported, cross-compiling binutils 2.18 and GCC 4.3.3. Now for the real challenge for which there is no tutorial (hmm, maybe I should look again) - getting GCC to understand that I have different segments! The theory is simple - each time an (assembly) instruction is generated that can accept a segment override prefix (for example, div) I want to give the prefix for either the stack (SS) or the heap (CS) depending on where the variable in question is coming from. This requires understanding a bit more about GCC internals, but it is a bit more into the realm of understanding the compiler tree, rather than which files I need to edit (which I actually find easier). So good luck to me - if it works, you will hear about it here.

First Post

This is my first post for the KOS blog. Let's see how this turns out.

I needed a place where I could put all my updates in the development of the OS. I've run into some interesting problems over the past few years, and the solutions were not always easy. Hopefully if someone else runs into the same problems, they will be able to get some ideas from how I solved things.