Software Interrupt Odyssey

So, I had a few nasty bugs while dealing with software interrupts.

The first one arose with my code triggering a data abort exception once the software interrupt handler was finished. It took me a little bit of thinking to figure this one out, but what was happening requires a bit of a technical and detailed explanation:

When you enter the software interrupt mode, your stack pointer changes. Each different mode that the CPU supports has their own stack pointer for security purposes. Therefore, when you are finished in the mode, you have to switch the mode back, but you also most likely have to manipulate your stack pointer (as all the registers are saved since they are modified in your mode handler). You need to do the mode switch and register restore in one operation, which basically reloads all the registers and jumps back to where you were before the mode handler was set off.

My implementation of this operation failed to take into account that the mode could be switched during the operation, and if so, the stack pointer cannot be modified. Therefore, what was happening was that the stack pointer was being returned in an incorrect state, and a "data abort exception" was happening as a result.

The other bug occurred in my rendering code; it was also data aborting because the stack pointer was invalid. What was happening in the end was that my rendering code was actually modifying an instruction that was to be executed, which was telling it to modify the stack pointer more than it needed to be modified! Another bug that took a few minutes to find, but once I saw the modified instruction, I knew exactly what the problem was.

However, my software interrupt handlers are still very up in the air. I'm not entirely sure what parameters each one take, how they take them, plus how they return their results. I'll figure this out somehow, but for now it's a bit hacked together, which isn't a good thing and needs to be taken care of.

When programming, odd bugs like the data aborts happen all the time. They're the type of bugs that can really throw off your tempo and rhythm and force you into a debugging session with an unclear understanding of when it will end. The best solution to this is to simply not let it disrupt your tempo, but rather adapt your tempo to the task at hand and just focus on solving it, solving it well, and being willing to change whatever needs to be changed.

I'm heading off to Europe in a few hours, so I'll most likely update this blog when I get back on November 14th.