On Mar 16, 4:02 pm, Stargazer <spamt...@[EMAIL PROTECTED]
> wrote:
> Hi,
>
> I am writing my own real-time kernel for x86. Now I face something
> really strange (or may be rather it's not; it has been some time since
> I was in the details of x86 microarchitecture).
>
> I measured CPU clocks elapsed between the first assembly instruction
> executed at interrupt's entry point in IDT and beginning of the C code
> of user-defined interrupt handler and the result was a big
> surprise :-) It took about 2500 cycles despite that I have only a
> handful of assembly instructions before a call to user-supplied IRQ
> handler.
>
> A little more testing showed that almost all cycles (2300+) were spent
> at access to a global variable (via ds:[] addressing). Nothing that
> accesses stack memory (push, pop, call, mov) makes a noticeable
> difference. Does anybody have an idea why this happens? I test on
> Celeron 2.8G in protected mode set up for flat model with paging
> disabled.
>
> I can post the code of the interrupt's entry point (until the C entry
> point is called), but it's rather trivial and not long.
>
> Thanks,
> D
What are the min, max and average cycle counts (you need to repeat the
measurement many times)?
What are the numbers on other PCs?
I wonder if it's SMIs. On my Dell Latitude D610 notebook an SMI (or a
short burst of thereof) may take up to ~240K cycles, which is ~150
microseconds at 1.6 GHz; on the old Compaq Armada 7800 notebook it's
only 12K cycles or ~40 microseconds at 300 MHz. Hardware bugfixes and
control are moving into the CPU. :(
Alex
|
