2011-12-28
2011-12-28 - Structure Changes
I've added the Libs, list and DOS elements back into the kernel, and wired them in. I've also changed the way that the standard C library features are structured into the kernel. They now have their own virtual directory courtesy of NetBeans. I've also changed the naming convention for the standard function to remove the prefix which I had been using before.
2011-12-05
2011-12-05 - NetBeans and Subversion
Recovering from the flu, I decided to have a look at NetBeans. I have it installed on this new machine, along with MinGW and MSYS, but I haven't gotten around to doing any OS dev work yet.
I looked at NetBeans and poked around with a few test projects, trying to figure out how best to get my structure of OS to work through the IDE. I've come up with the idea that creating a C/C++ Static Library is the best approach, and putting 99% of the OS code into it. That seems to use the ar tool to create a .a file which contains all the .o files. I have then added post-build steps into the project makefile to take this .a file and link it in with my existing start.o to create the binary kernel files as I have before. The makefile also compiles the bootblock. I have set the Project run command to run the Bochs bxrc file (via a batch file) to then fire up Bochs with my OS loaded.
A "quick" install of Apache and Subversion later, and NetBeans is happy to push the code into the source control repository, and I can keep track of changes. All looks good.
Currently, this set of code only contains a few of the previous files, it sets 32-bit protected mode, clears the VGA Mode 3 screen, and displays a title. It's more of a test for the environment. In any case, if this approach works, it will make a very good starting point to re-integrate all of the code and create the modular kernel that should have been working ages ago.
I have sent a copy of the project to Pink to test on his Linux install. He reports that he has been able to get it to build by adding a Debug-Linux configuration into the project and tweaking some settings. We may be able to get a Subversion repository exposed so that it can become a collaborative project, at least from the point of view of being able to get the code and run the progress so far.
I looked at NetBeans and poked around with a few test projects, trying to figure out how best to get my structure of OS to work through the IDE. I've come up with the idea that creating a C/C++ Static Library is the best approach, and putting 99% of the OS code into it. That seems to use the ar tool to create a .a file which contains all the .o files. I have then added post-build steps into the project makefile to take this .a file and link it in with my existing start.o to create the binary kernel files as I have before. The makefile also compiles the bootblock. I have set the Project run command to run the Bochs bxrc file (via a batch file) to then fire up Bochs with my OS loaded.
A "quick" install of Apache and Subversion later, and NetBeans is happy to push the code into the source control repository, and I can keep track of changes. All looks good.
Currently, this set of code only contains a few of the previous files, it sets 32-bit protected mode, clears the VGA Mode 3 screen, and displays a title. It's more of a test for the environment. In any case, if this approach works, it will make a very good starting point to re-integrate all of the code and create the modular kernel that should have been working ages ago.
I have sent a copy of the project to Pink to test on his Linux install. He reports that he has been able to get it to build by adding a Debug-Linux configuration into the project and tweaking some settings. We may be able to get a Subversion repository exposed so that it can become a collaborative project, at least from the point of view of being able to get the code and run the progress so far.
2011-07-13
2011-07-13 - Threads and Processes
A few more tweaks to the Process subsystem today. I've taken an old set of code that I was working on before this issue with Bochs not working came up, and I applied the fixes to make it work in Bochs to it. After a little tweaking, it started to work and tick along correctly.
Tested a few threads as well (the character generator program that I developed previously) and it all seemed to work. There is a slight issue with the display when scrolling which the semaphore should have fixed, but I think it's actually a render issue with Bochs. The semaphore itself tested correctly.
The next step from here is to remove the Sleep(Time) code from the process system and implement a GetPid() function, Sleep(Pid) and Wake(Pid) to allow threads to control one another. The Sleep(Time) will be reimplemented as a separate subsystem which will use its own thread (or even an interrupt handler) to wake a thread up once its timer has expired.
This should then give me the following functions:
The Top command would be modified to display the Pid in the table, and command versions of Sleep() and Wake() will be added to allow thread control for testing and lolz.
Tested a few threads as well (the character generator program that I developed previously) and it all seemed to work. There is a slight issue with the display when scrolling which the semaphore should have fixed, but I think it's actually a render issue with Bochs. The semaphore itself tested correctly.
The next step from here is to remove the Sleep(Time) code from the process system and implement a GetPid() function, Sleep(Pid) and Wake(Pid) to allow threads to control one another. The Sleep(Time) will be reimplemented as a separate subsystem which will use its own thread (or even an interrupt handler) to wake a thread up once its timer has expired.
This should then give me the following functions:
- GetPid(): Returns the current Pid
- Sleep(Pid): Sets the given Pid to sleep
- Wake(Pid): Sets the given Pid to waiting
- Sleep(Time): Sleeps the thread for some time
- TickHandler(): Checks for threads needing waking and wakes them.
The Top command would be modified to display the Pid in the table, and command versions of Sleep() and Wake() will be added to allow thread control for testing and lolz.
2011-07-12
2011-07-12 - Bochs and Threads
Recently I have been looking into Bochs to try to figure out why the multitasking code (which works on physical machines) fails under Bochs.
The discovery was made yesterday that the reason it was failing under Bochs specifically is because Bochs does not start with zero-initialised memory, and that the initialisation code for my multitasking did not clear its variables. What's more is that the compiler assumed that the BSS would be zeroed, and even refused my explicit zero initialisation. This was fixed up and the code got further before crashing.
Last night and today, I was looking into the Bochs debugger and trying to figure out why it seemed that the code compiled on my laptop was causing it to fail even after fixing the above issue. After hours of stepping and deleting code and stepping and disassembling, I could not figure how the EBP register was being overwritten by the EIP value.
Finally, I spotted it. The code I was using (modified from some tutorial code) set up the tasking jump using unnamed registers, and the GCC compiler was choosing its own registers to use. Unfortunately, one of it's choices conflicted with a register I was using. A few tweaks later and the code compiled correctly. Also setting the "clobber" registers to the call made it compile reliably.
This was a particularly difficult issue to track down as each time the code was changed and recompiled, it could have compiled differently, and some changes would "fix" the problem, even though they did not directly affect it. This made the problem intermittent at best.
The discovery was made yesterday that the reason it was failing under Bochs specifically is because Bochs does not start with zero-initialised memory, and that the initialisation code for my multitasking did not clear its variables. What's more is that the compiler assumed that the BSS would be zeroed, and even refused my explicit zero initialisation. This was fixed up and the code got further before crashing.
Last night and today, I was looking into the Bochs debugger and trying to figure out why it seemed that the code compiled on my laptop was causing it to fail even after fixing the above issue. After hours of stepping and deleting code and stepping and disassembling, I could not figure how the EBP register was being overwritten by the EIP value.
Finally, I spotted it. The code I was using (modified from some tutorial code) set up the tasking jump using unnamed registers, and the GCC compiler was choosing its own registers to use. Unfortunately, one of it's choices conflicted with a register I was using. A few tweaks later and the code compiled correctly. Also setting the "clobber" registers to the call made it compile reliably.
This was a particularly difficult issue to track down as each time the code was changed and recompiled, it could have compiled differently, and some changes would "fix" the problem, even though they did not directly affect it. This made the problem intermittent at best.
2011-05-04
2011-05-04 - Delays and Sleep
So, I need to create some form of Timer_Sleep() function that works in a similar manner to my Timer_Delay().
Timer_Delay() currently spinlocks until the designated time ... functional, but not advisable.
Timer_Sleep() has to instead suspend the thread until the allotted time, then wake it up again.
Timer_Delay() currently spinlocks until the designated time ... functional, but not advisable.
Timer_Sleep() has to instead suspend the thread until the allotted time, then wake it up again.
2011-05-03
2011-05-03 - Semaphores
So my first foray into Semaphores didn't work first time. I've implemented a test&set function, and I've created the GetSemaphore() and ReleaseSemaphore() functions which take a pointer to a semaphore and spinlock until it can be gained, and then to release it. I tied this into the String_kprintf() function so that only one thread could be in the function at a time. Instead of a proper lock, the system just locked when it first performed a printf, and presumably infinitely looped.
Ah ha! In copying the code sample for the Intel implementation of test_and_set, I neglected to reverse the operands to the mov instructions, so the stack was being loaded with the values from the registers, not the other way around. Why that would screw up the printing, I don't know.
Ah ha! In copying the code sample for the Intel implementation of test_and_set, I neglected to reverse the operands to the mov instructions, so the stack was being loaded with the values from the registers, not the other way around. Why that would screw up the printing, I don't know.
2011-05-02
2011-05-02 - Multitasking on the Revo
Gotten the new Aspire Revo 3700 wired up in place of the thin client, nice little piece of kit with an integral hard drive amongst other things. I'm ignoring the Linpus Linux for now and have it set to network boot, and it fired up the TFTP branch first time.
Been looking at the multitasking code using the Revo (not that it's any better in this regard than the T61) and trying to track down the problem. Having spent ages sticking in various bits of debugging code and trying to make sense of the results, the solution ends up being stupidly simple ... the stack I was assigning to each thread was too small. One stack would overwrite part of another, then cause it's Interrupt frame to be corrupt, crashing when that thread was next invoked.
With that 'fixed', the threads are ticking over happily. It's currently running maybe 30 character generator threads with a quanta of 10ms to test it. So far no problems except the video routines aren't multi-thread safe.
Been looking at the multitasking code using the Revo (not that it's any better in this regard than the T61) and trying to track down the problem. Having spent ages sticking in various bits of debugging code and trying to make sense of the results, the solution ends up being stupidly simple ... the stack I was assigning to each thread was too small. One stack would overwrite part of another, then cause it's Interrupt frame to be corrupt, crashing when that thread was next invoked.
With that 'fixed', the threads are ticking over happily. It's currently running maybe 30 character generator threads with a quanta of 10ms to test it. So far no problems except the video routines aren't multi-thread safe.
Subscribe to:
Posts (Atom)