Being the start of a new year, I figure what better "time" to write the C library time.h functions.
Although, the other idea of adding a SetTransform() to the Video Driver interface to allow the code to set a 2D transformation matrix to allow subsequent plots and whatnot to be scaled is inspired.
I've separated out the definitions for the DOS driver interface and created a file for the Video Driver interface. Unlike previous incarnations of this, I have added the same Context approach as other drivers use so that multiple displays on one adapter (or multiple adapters of the same type) can be handled easily.
2012-01-01
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.
Subscribe to:
Posts (Atom)