IDT problems

[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?

[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?

[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?

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

[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:

Code: Select all

for(int i=0 ; i<5521 ; ++i);

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)

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

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

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

[Candy]

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.