Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Categories

Nested and/or concurrent interupt calls...

What would happen if an interupt attempted to call another interupt (other then itself)? Would the inner interupt return to the outer interupt correctly? If so, would the outer interupt return to the original call location correctly?



Ok, about the PIT: If the system is in a long interupt routine and the PIT fires off INT 8, what happens?



Are interupts automatically disabled when one is already executing?



Does CLI just disable hardware interupts or all of them? Another words, if I did:

CLI

INT 20

STI

Would INT 20 execute?



If you set a function-pointer (C/C++) to an interupt's point of entry, and call the pointer, will the IRET instruction in the called interupt return to the calling precedure the same way RET would in a normal function?



Ok, thats all of them regarding interupts I guess.



-Robert


Comments

  • : What would happen if an interupt attempted to call another interupt (other then itself)? Would the inner interupt return to the outer interupt correctly? If so, would the outer interupt return to the original call location correctly?



    Depends. Many interrupts will call other interrupts for further servicing. However, some interrupts are non-entrant. So, you must be carefull on the ISV's you call. For example, typically calling BIOS screen routines wihtin a chained INT 21h service is okay. While calling an INT 21 Disk Service routine may cause major problems.



    :

    : Ok, about the PIT: If the system is in a long interupt routine and the PIT fires off INT 8, what happens?



    Don't know.



    :

    : Are interupts automatically disabled when one is already executing?



    No.



    :

    : Does CLI just disable hardware interupts or all of them? Another words, if I did:

    : CLI

    : INT 20

    : STI

    : Would INT 20 execute?

    :

    : If you set a function-pointer (C/C++) to an interupt's point of entry, and call the pointer, will the IRET instruction in the called interupt return to the calling precedure the same way RET would in a normal function?

    non-maskable and software interrupts are not inhibited by CLI.

    "There is one minor difference between how the 80x86 processes hardware interrupts and other types of

    interrupts - upon entry into the hardware interrupt service routine, the 80x86 disables further hardware

    interrupts by clearing the interrupt flag. Traps and exceptions do not do this. If you want to disallow

    further hardware interrupts within a trap or exception handler, you must explicitly clear the interrupt flag

    with a cli instruction. Conversely, if you want to allow interrupts within a hardware interrupt service

    routine, you must explicitly turn them back on with an sti instruction. Note that the 80x86's interrupt

    disable flag only affects hardware interrupts. Clearing the interrupt flag will not prevent the execution of a

    trap or exception."



    Nop, this is not cool. An interrupt saves a bunch of extra stuff and will produce a different stack entry to the ISR. So, an IRET will tell the CPU to pop the extra stuff. The return address will be crapped out with a normal call to an ISR. You could however, jump to an ISR from an ISR, which is okay.



    :

    : Ok, thats all of them regarding interupts I guess.

    :

    : -Robert

    :






  • : Ok, about the PIT: If the system is in a long interupt routine and the PIT fires off INT 8, what happens?

    :

    : Are interupts automatically disabled when one is already executing?

    Hardware generated interrupts cli at the beginning, all others don't, implicitly.



    : Does CLI just disable hardware interupts or all of them? Another words, if I did:

    : CLI

    : INT 20

    : STI

    : Would INT 20 execute?

    Yes, cli only blocks hardware interrupts. The reasoning is if hardware interrupts are blocked then you can't do anything asynchronously (you can't be interrupted).

    :

    : If you set a function-pointer (C/C++) to an interupt's point of entry, and call the pointer, will the IRET instruction in the called interupt return to the calling precedure the same way RET would in a normal function?



    INT xx

    is simply a pushf(d) then a far call. So if you want to simulate and interrupt just do...



    xor ax, ax

    mov es, ax

    pushf

    call FAR PTR es:[interrupt_number*4]



    and therefore IRET is simply...

    popf

    retf



    so if you want use a function that returns void and takes no parameters you'd simply



    asm pushf

    INTfunc();



    or if you want you couuuld pass the flags as a parameter like...



    //No pushf needed now

    INTfunc(short flags);



    though I would recommend the first way



    ANON is right in saying that some ISRs are non-reentrant, ie they will not work correctly if they interrupt themselves.



    For example, none of the DOS interrupts are re-entrant.



    See ANON's article for some sections I purposely left out since they were already discussed.


  • can the PIT be run at 10 Hz

    or would it be better to use the functions provided by time.h in C









    : : What would happen if an interupt attempted to call another interupt (other then itself)? Would the inner interupt return to the outer interupt correctly? If so, would the outer interupt return to the original call location correctly?

    :

    : Depends. Many interrupts will call other interrupts for further servicing. However, some interrupts are non-entrant. So, you must be carefull on the ISV's you call. For example, typically calling BIOS screen routines wihtin a chained INT 21h service is okay. While calling an INT 21 Disk Service routine may cause major problems.

    :

    : :

    : : Ok, about the PIT: If the system is in a long interupt routine and the PIT fires off INT 8, what happens?

    :

    : Don't know.

    :

    : :

    : : Are interupts automatically disabled when one is already executing?

    :

    : No.

    :

    : :

    : : Does CLI just disable hardware interupts or all of them? Another words, if I did:

    : : CLI

    : : INT 20

    : : STI

    : : Would INT 20 execute?

    : :

    : : If you set a function-pointer (C/C++) to an interupt's point of entry, and call the pointer, will the IRET instruction in the called interupt return to the calling precedure the same way RET would in a normal function?

    : non-maskable and software interrupts are not inhibited by CLI.

    : "There is one minor difference between how the 80x86 processes hardware interrupts and other types of

    : interrupts - upon entry into the hardware interrupt service routine, the 80x86 disables further hardware

    : interrupts by clearing the interrupt flag. Traps and exceptions do not do this. If you want to disallow

    : further hardware interrupts within a trap or exception handler, you must explicitly clear the interrupt flag

    : with a cli instruction. Conversely, if you want to allow interrupts within a hardware interrupt service

    : routine, you must explicitly turn them back on with an sti instruction. Note that the 80x86's interrupt

    : disable flag only affects hardware interrupts. Clearing the interrupt flag will not prevent the execution of a

    : trap or exception."

    :

    : Nop, this is not cool. An interrupt saves a bunch of extra stuff and will produce a different stack entry to the ISR. So, an IRET will tell the CPU to pop the extra stuff. The return address will be crapped out with a normal call to an ISR. You could however, jump to an ISR from an ISR, which is okay.

    :

    : :

    : : Ok, thats all of them regarding interupts I guess.

    : :

    : : -Robert

    : :

    :

    :

    :






Sign In or Register to comment.