Mail Archives: djgpp/2002/01/28/00:46:52
On Sat, 26 Jan 2002 11:08:43 CST, Charles Sandmann <sandmann AT clio DOT rice DOT edu> wrote:
>> Could anyone tell me what is the order of delay (in clocks) required for
>> the CWSDPMI server to reflect a hardware interrupt from Real mode to the
>> protected mode handler ?
>
>It depends on the chip you're using. A bunch.
>Say a few thousand clocks.
A couple of thousand clocks wouldn't bother me much (I'm using a 1GHz
P3) - My observation has been that even executing a few I/O instructions
take more time than that - Wonder if my hardware (the chipset) is crummy
- but reprogramming the DMA controller (Basically 8 "out dx,al"
instructions) was taking close to 12 microsecs to execute !! (Timing
using the rdtsc instruction) - whereas I was expecting something like a
max of 300 ns per out instruction.
>> I need to write a Hardware Interrupt handler where latency is very
>> critical. Any suggestion regarding which DPMI server would provide me
>> the best latency figures would also be welcome. (The application need
>> not be portable - and I can specify the environment).
>
>PMODE 1.3 is probably the fastest.
>
>The best thing to do is some tests. If you document it (or provide the
>test programs) I'll add it to a summary somplace.
I wanted to do this, but wasn't very sure how I'd go about it. Would the
following sequence be a sufficient indicator ?
a) Install a protected mode interrupt handler - read the TimeStampCounter
right at the beginning.
b) Install a Real Mode interrupt handler, read the TSC on entry and
chain to the old real mode handler (This I suppose should reflect the
interrupt to the PM handler ?)
c) The time difference of (a) - (b) should give me the mode switch
overhead if the interrupt occurs in real mode ?
[snip]
<Regarding setting up Flat Real mode>
>Anything is possible since the source is freely available :-)
>In CWSDPMI all the mode switch and selector setup is done in mswitch.asm
>so it should be fairly simple to set up one of the selectors to do the
>"unreal" flat mode 32-bit real mode hack. You would need to know about
>the physical to virtual translations with page tables under CWSDPMI.
Thanks, I'll check this out. Physical to Virtual mapping shouldn't be a
problem since I need to anyway have the physical addresses of the
extended memory buffers for setting it up as a DMA buffer. So once I can
get into Flat mode, I hope I wouldn't have problems accessing it using
the physical address.
>PMODE would not need to worry about page table remapping issues, but I
>don't offhand know where to set up the unreal segments there.
Looking at the sources, PMODE seemed to be simpler to modify since it
uses only the GDT. There seems to be a selector named SELREAL, and I
think I'll first try patching its values to limit = 0xFFFFF and
Granularity = 1.
>In any case, if you get it working you can always contribute it.
Will certainly do so.
Thanks for all the pointers.
Regards,
BK
- Raw text -