Page 2 of 2
Re: IDT in assembly.
Posted: Mon Nov 07, 2011 12:58 am
by sandras
berkus wrote:Not unless you enable them usually. If you just want to run without interrupts but be able to catch exceptions, define first 32 slots. If you enable more - add handlers appropriately.
Yeah, I've made an IDT and added handlers for the first 47 interrupts.
berkus wrote:It doesn't hurt to have the full IDT filled with locations of "unexpected sh*t happened" handlers just for easier debugging.
I guess I could handle that unexpected sh*t through GPF too?
Re: IDT in assembly.
Posted: Mon Nov 07, 2011 2:02 am
by Combuster
Sandras wrote:Even though this sort of confirms my thoughts, I would still like to hear your opinion on the subject. Could interrupts above 47 fire?
Yes, you need 32 for the architecture and a further 16 for the typical PIC configuration. You typically need the 49th (at int 0x30) for your system call minimum.
And then there's the stuff like APIC timers, non-PIC interrupt controllers and message-signalled interrupts that push the limit much further if you want.
Re: IDT in assembly.
Posted: Mon Nov 07, 2011 2:43 am
by sandras
Combuster wrote:And then there's the stuff like APIC timers, non-PIC interrupt controllers and message-signalled interrupts that push the limit much further if you want.
I see. Didn't know about those. Anyway, that's for the future. I think the next thing in my list is physical memory management. I'll try not to rely on tutorials this time, as this is simply working with the memory, no chip programming involved, since I'm not looking into paging.
Anyway, this might go a little bit of topic, but I had a question about hlt unanswered. Let me illustrate first.
let's say I have code like this and the kernel entry point is entry().
Code: Select all
entry:
call initidt
call initpit
hang:
hlt
int 1
jmp hang
And I get output like this.
tick: 1
received interrupt: 1
tick: 2
received interrupt: 1
tick: 3
received interrupt: 1
...
It seems, that when an interrupt is fired from the PIT, the processor resumes from where it left off when it executed hlt. Why is that? Isn't it supposed to stall and only execute ISRs upon receiving interrupts?
Re: IDT in assembly.
Posted: Mon Nov 07, 2011 2:47 am
by Combuster
HLT simply means stop save power until an external event has been raised. Interrupting a HLT statement ends its effect.
Re: IDT in assembly.
Posted: Mon Nov 07, 2011 3:16 am
by sandras
I see. Thanks for the help, everyone. : )