Another late night, this time I was working through the Linux Doom source code and implementing header files and prototypes into the libc that it needed, spending quite a bit of time investigating things I didn't recognise.
Oh, by the way, I now have a libc project in the NetBeans project group that implements some of the C library functions. This takes the older implementations of various C functions and combines them together, it also includes any function that are in the kernel but should be in the C library.
The libc project contains the beginnings (if you pardon the pun) of the crt0.o file which sets up the stack, finds kernel functions, opens the stdin, stdout and stderror streams, then calls the program's main() function. It doesn't actually do any of this yet, but the framework is there.
2013-08-31
2013-08-26
2013-08-26 Interrupts and Printf
As part of the ongoing effort to get the Hello World program loading and running, I've been reimplementing the interrupt system. This is needed to allow my OS to reply to the interrupt request which the program makes in order to get the first hook into the kernel.
The interrupt system comprises 48 assembly routines, one for each interrupt, which build a consistent stack frame, then push all the relevant registers of the state to the stack, including the number of the interrupt thrown. A generic C handler for the interrupts is then called which dispatches messages to the various required handlers.
For three days I've been trying to work out why the interrupt number being printed from the interrupt handler wasn't correct. I've put test values in the assembly, added infinite loops, examined the registers in Bochs, even suspended the emulator and examined the memory by hand to check the stack frame. I couldn't find anything wrong except that the wrong values were being printed to the screen.
I finally figured out what was wrong and tested the printf routine itself. It failed the test. Printf is, of course, a variadic function and the actual function itself is actualled called kstdio_printf(). I had created another function called kprintf() which then called it, but I messed up the call so it only passed the format parameter and not all the following parameters :(
Oh well, at least it's all working now.
The interrupt system comprises 48 assembly routines, one for each interrupt, which build a consistent stack frame, then push all the relevant registers of the state to the stack, including the number of the interrupt thrown. A generic C handler for the interrupts is then called which dispatches messages to the various required handlers.
For three days I've been trying to work out why the interrupt number being printed from the interrupt handler wasn't correct. I've put test values in the assembly, added infinite loops, examined the registers in Bochs, even suspended the emulator and examined the memory by hand to check the stack frame. I couldn't find anything wrong except that the wrong values were being printed to the screen.
I finally figured out what was wrong and tested the printf routine itself. It failed the test. Printf is, of course, a variadic function and the actual function itself is actualled called kstdio_printf(). I had created another function called kprintf() which then called it, but I messed up the call so it only passed the format parameter and not all the following parameters :(
Oh well, at least it's all working now.
2013-08-17
Welcome
Welcome
This blog chronicles the design, implementation, development, and (maybe some day) execution of my home-grown operating system with the working title "Atomicity".
I have a host of existing log entries which will be migrated into here and backdated.
Check out the About page at the top for an overview of what this is all about.
2013-08-16
2013-08-16 - Memory Manager, Console, and Hello World
The memory manager, started about 8 weeks ago, has finally been debugged and is working in tests. There were a few issues with pointer handling, and I wasn't updating the memory header sometimes when changing the free list, and I was calculating the block name length differently in two places, but I think that's all sorted.
Another good thing is that the pesky bug with the printf handling of integers has also been fixed (that was really bugging me), I had a signed integer instead of an unsigned integer as the working variable.
Next thing I would like to do is to write an intermediate console. It will read blindly from the keyboard, and write blindly to the screen. It will spinlock itself between operations. It will still have a fixed list of commands. The aim is to create an environment which will support the basic Hello World program above, which will then lead onto the development of the stdin and stdout file functionality. This will then be retro-fitted into the console to create the next version.
The console will have a console invoke function as its entry point. The keyboard handler will have to feed into a buffer. The console will spinlock until the buffer has data to process (similar to how read() will work eventually).
As I discussed previously, the hello world program will make an interrupt call to get the address of the function to be used for finding other functions. From there, the hello world program will find the "write()" system call, and will call it passing 1 (for stdout) and the string data, it will then exit
I've put together a rough skeleton of HelloWorld. The start() method uses assembly to call an interrupt and fetch EAX into a global function pointer for resolve(). It then uses resolve() to find write(), then calls main(). main() then uses write() to output the Hello World string to STDOUT (file descriptor 1).
Now all I need to do is write all the other code to underpin this ...
Another good thing is that the pesky bug with the printf handling of integers has also been fixed (that was really bugging me), I had a signed integer instead of an unsigned integer as the working variable.
Next thing I would like to do is to write an intermediate console. It will read blindly from the keyboard, and write blindly to the screen. It will spinlock itself between operations. It will still have a fixed list of commands. The aim is to create an environment which will support the basic Hello World program above, which will then lead onto the development of the stdin and stdout file functionality. This will then be retro-fitted into the console to create the next version.
The console will have a console invoke function as its entry point. The keyboard handler will have to feed into a buffer. The console will spinlock until the buffer has data to process (similar to how read() will work eventually).
As I discussed previously, the hello world program will make an interrupt call to get the address of the function to be used for finding other functions. From there, the hello world program will find the "write()" system call, and will call it passing 1 (for stdout) and the string data, it will then exit
I've put together a rough skeleton of HelloWorld. The start() method uses assembly to call an interrupt and fetch EAX into a global function pointer for resolve(). It then uses resolve() to find write(), then calls main(). main() then uses write() to output the Hello World string to STDOUT (file descriptor 1).
Now all I need to do is write all the other code to underpin this ...
Subscribe to:
Posts (Atom)