Page 1 of 1
IDT problems
Posted: Fri Dec 10, 2004 4:24 pm
by Invisible Tape
Yeah, my IDT. It's been set up to handle exceptions and the first two interrupts. When i do an asm("int $0"), my division by zero message pops up. When i do int x = 5 / 0, nothing happens. I've done a sti() but it still won't fire on it's own. Another thing is, my keyboard handler works, sort of. When i press a key, my message pops up, but it only works once and i have done the inb(0x60) and outb(0x20, 0x20). This thing's been driving me nuts for the last week. What could it be?
Re:IDT problems
Posted: Fri Dec 10, 2004 4:33 pm
by AR
The deliberate divide by 0 may actually be being caught by your compiler's preprocessor and being stored as 'mov [ x ], 0'. Where abouts is the outb? Is there any possible way that the function calling it could terminate without getting to the instruction?
Re:IDT problems
Posted: Fri Dec 10, 2004 4:49 pm
by Invisible Tape
well i don't think my kbd interrupt handler would terminate early as it is just:
Code: Select all
void keyboard_int(void)
{
int x = inb(0x60);
asm("incb 0xB8000\n\t"
"movb $0xC0, 0xB8001\n\t");
outb(0x20, 0x20);
}
also, i've moved the outb to the top so that's definately not it.
I'm using DJGPP, so i'm not sure if it catches the 5/0 or not, does anyone know?
Re:IDT problems
Posted: Fri Dec 10, 2004 4:53 pm
by IRBMe
I had a problem like this when testing my exception handler. It turned out that the compiler was optimising too well. It saw that the division by 0 didn't actually do anything useful and so completely removed it. Try disassembling the binary and making sure that the instructions are actually there and that they do actually cause a divide by 0. If not, try compiling with no optimisations on. Failing that, try writing that part in asm.
Re:IDT problems
Posted: Fri Dec 10, 2004 5:15 pm
by AR
DJGPP is a GCC port, one of the main goals of GCC is to be the best optimising compiler. Constants should be calculated before compiling so if you have something like:
Code: Select all
#define FOUR 4
for(int i=0 ; i<60*23*FOUR+1 ; ++i);
The processor should convert it to:
So since 5/0 is always 0, it'll just be written out as 0
If you're in Bochs have you tried enabling debug mode on the keyboard and seeing if it dispatches the interrupts beyond the first one? I haven't spent much time working with the keyboard so the only thing I can think of is there may be more than one scancode queued (various keys like Alt have an 'extended key' prefix byte)
Re:IDT problems
Posted: Fri Dec 10, 2004 5:21 pm
by IRBMe
So since 5/0 is always 0, it'll just be written out as 0
since when? And here I was, having sat through 2 years of calculus lectures, under the impression that anything divided by 0 is undefined.
Re:IDT problems
Posted: Fri Dec 10, 2004 5:27 pm
by AR
On a PC it's 0 (or a Divide by 0 exception), its just written as 0 cause that's how it can be best represented. Or it could just refuse to compile altogether.
Re:IDT problems
Posted: Fri Dec 10, 2004 5:41 pm
by Invisible Tape
Thanks, it was the optimization. I took out my -O2 and everything worked fine. It was catching the x = 5/0 and in my keyboard handler, since x was an unused variable, i think it just completely left it out.
Re:IDT problems
Posted: Sun Dec 12, 2004 10:14 am
by Candy
AR wrote:
On a PC it's 0 (or a Divide by 0 exception), its just written as 0 cause that's how it can be best represented. Or it could just refuse to compile altogether.
For integer math, either INT_MAX or 0 are believable answers. For FP math, it probably returns a SNaN or QNaN.