Stargazer wrote:
>> ...
>>> 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 ****d IRQ (just EOI and IRET) takes about 200 cycles, if measured in
>> an unproteced environment (ie: my OS where all code run with PL0).
>> One big cycle loss is in the PL-transition, especially if hardware
>> task-switches are in use.
> I use "classical" monolithic embedded OS model: both OS and
> application run on PL0, no PL switches, no address spaces (CR0.PG=0)
> and TSS are not used.
> 200-300 cycles is what I get without that "inc" instruction.
this 200..300 cycles is what I'd expect and often measure,
I really haven't got an explanation for this one..
* if paging is disabled.
* if I/O-permission isn't involved
* if stacks weren't swapped
* if no PL transitoins occure
* If no WBINVD or SMC is used within your code
then it should perform within the expected few hundred cycles.
perhsps it's a re-entrance issue like I mentioned in the other post?
__
wolfgang
|
