Mail Archives: djgpp/2001/09/03/23:30:12
> > Quick recommendations without a lot of analysis:
> > 1) Try hooking instead of chaining (hook is faster)
> > 2) Try getting rid of the disable/enable calls (in wrapper?)
> > 3) If all else fails let's look at wrapper code details
>
> 1) Will try if #2 does not solve. I would hate to hook just in case
> another card is utilizing the same IRQ (like video or something). Or am I
> misinterpreting your hook idea?
If you chain, it will end up calling the original handler (which in this
case is the default one DPMI provides - which reflects the interrupt to
the DOS/BIOS real mode handler). It adds quite a bit of overhead
and mode swaps to reflect back to the real mode handler. This puts a
limit on your interrupt frequency, and allows each one to take much longer,
so you can end up with nested interrupts. Chaining is safer but much
slower. Many devices don't work properly sharing interrupts - so if you
are sure you aren't sharing it's better to not chain.
> 2) Currently testing. I removed disable/enable calls from all of my ISR's
> and it seems to be working. Just curious, but any ideas why? Am I
> overriding some enable function in the DPMI wrappers by doing the enable
> early?
The wrapper keeps interrupts disabled and only enables them on the final
exit. It isn't reentrant (actually it tries to be, by ignoring the
interrupt, but failures happen). By enabling interrupts early you allow a
second interrupt to overwrite the first one's stack, so the first one
returns to the wrong place. We need to fix the wrappers to recognize when
they are already on their own stack and completely test the nested-ness.
It's an ugly fix (gopint.c) - hand codeded assembler that must do address
fixups at run time. I'm not exactly sure what's needed. It may be
because of interrupts inside the chained handler... Some day...
> Thanks yet again, and I am once again truely impressed by the DJGPP/CWSDPMI
> team.
Glad this seemed to fix it.
- Raw text -