Exception Handling in Real Mode

[XStream]

Hey,

I have a feeling that my code is causing a divide error, after confirming it, it made me think that may be I should be putting exception handlers in place for debugging purposes during the boot process. I have been looking through the intel docs but they are so big it is impossible to find anything.

Cheers.

[Pype.Clicker]

it will indeed be a nice thing to have exception handlers at some point. However, you may want to use an emulator like BOCHS to run your kernel and see why the error occured.

An interresting exception handler (that shows where the error occured and what's the register content at that time) takes time to develop. Probably more time that what you're willing to use for that Division Error ...

SideNote: keep in mind that division by Zero is not the only possible error. It could also come trying to perform a division whose result doesn't fit registers.

For instance while using "DIV BX", the processor will divide 65536*DX+AX by BX and the result should fit AX alone. No need to say that with BX=2 and DX>1, an error *will* occur ...

[XStream]

You may have just given me an answer to a question I never yet asked! Wow, you guys are smart.

I have a routine to convert a number to a string, but for some reason my code would just stop on a division. After disabling line by line of code I discovered that if edx was anything other than 0 the code would crash, now I know why.

This will be very handy during further development, thanks a bundle for that one.

Cheers.

[Dreamsmith]

You may have just given me an answer to a question I never yet asked!

Yeah, Pype.Clicker's showing of his psychic algorithms again.

Reminds me of my old time-travel algorithm.

A few years ago, I was working with a hardware engineer on some software to record and analyze the output of the device he was working on. In one particular test version, he spotted a problem. There were certain events it was supposed to graph and analyze, that occur on a semi-random basis. It showed these events alright, but the problem was, it was also showing a change in the data that wasn't in the actual output of the device. Despite the fact that the actual timing of these events was unpredictable, the software was nevertheless consistently showing the spurious change in the data precisely 2 milliseconds before the actual event occured. He wasn't surprised that a spike in data could throw the algorithm off, but he was baffled as to how the effect could preceed the cause by 2ms.

I fixed the problem and told him I'd removed the "look ahead" algorithm from the software, to stop it from reacting to things that hadn't happened yet. ;D

But I digress...