On Mar 19, 12:05 pm, Tim Roberts <spamt...@[EMAIL PROTECTED]
> wrote:
> Stargazer <spamt...@[EMAIL PROTECTED]
> wrote:
> >On Mar 17, 8:44�pm, Cyril Novikov <spamt...@[EMAIL PROTECTED]
> wrote:
> >> Stargazer wrote:
> >> > � �;
> >> > � �mov � � al, CMD_EOI
> >> > � �out � � PIC_MASTER, al
> >> > � �cmp � � ebx, 8
> >> > � �jb � � �fin
> >> > � �out � � PIC_SLAVE, al
>
> >> These 2 OUT's are what takes 2000+ cycles. The reason you see it
elsewhere is
> >> most likely a bug in your measurement code.
>
> >Why would it take 2000+ cycles? interrupt controller is integrated in
> >a chipset which provides pretty fast access.
>
> That is irrelevant. Cyril is quite correct. I/O ****t accesses take
about
> a microsecond, regardless of bus speed or where the ****t is located.
Part
> of this comes from the need to maintain historical compatibility.
> --
> Tim Roberts, t...@[EMAIL PROTECTED]
> Providenza & Boekelheide, Inc.
Don't know if this helps, but on my 1GHz P3 laptop using just the
following code,
RDTSC...
mov al,20h
out 20h,al
RDTSC... produces 450 cycles and
RDTSC...
mov al,20h
out 20h,al
out 0a0h,al
RDTSC... produces 900 cycles.
So it would appear as 450nS and 900nS respectively. Since your
running at 2.8GHz then 900nS would take 2520 cycles. Serializing
didn't seem to make much difference nor running real mode or flat
32bit protected mode. One interesting note was that looping through 5
or more times and taking the final result was 20 cycles slower than
just a single run. 470 & 920.
Chapter 13, Input/Output, in the IA-32 Intel Architecture Software
Developer’s Manual, Volume 1, seems to indicate that "I/O writes to
control system hardware cause the hardware to be set to its new state
before any other instructions are executed". I'm not a programmer so I
may have misunderstood and it's all just coincidence, hopefully
someone will put me right. Thanks for giving me some code to play
with, I'm sad to say it was fun. :)
|
