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:

  • 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.