Hi all,
I use ClockCycles() to timestamp data in my interrupt-handler.
This does work on CPU’s which support some kind of machine instruction
like RDTSC on a pentium, but does not work on 486 CPU’s.
Well, after a look in the docu, I found out that ClockCycles is not IRQ
save.
Can someone clarify, why the kernel emulation for ClockCycles is not IRQ
save on 486er?
Thanks in advance
Michael
Michael Tasche wrote:
I use ClockCycles() to timestamp data in my interrupt-handler.
This does work on CPU’s which support some kind of machine instruction
like RDTSC on a pentium, but does not work on 486 CPU’s.
Well, after a look in the docu, I found out that ClockCycles is not IRQ
save.Can someone clarify, why the kernel emulation for ClockCycles is not IRQ
save on 486er?
My best guess is because an exception is required to access the kernel’s memory space to build a 64 bit counter from the 16 bit counter of timer 0. Where as when the RDTSC instruction is used the full 64 bits comes from the CPU itself so no exception occurs.
You could make your own for the 486. Just read the value in hardware timer 0 and have your own math for building a 64 bit counter in your app’s memory space.
Evan
ClockCycles() emulation in interrupt handlers was fixed in 6.2.1 patch A (I think)
It should definately work in 6.3.0 and onwards.
What version are you using?
Michael Tasche wrote:
Hi all,
I use ClockCycles() to timestamp data in my interrupt-handler.
This does work on CPU’s which support some kind of machine instruction
like RDTSC on a pentium, but does not work on 486 CPU’s.
Well, after a look in the docu, I found out that ClockCycles is not IRQ
save.Can someone clarify, why the kernel emulation for ClockCycles is not IRQ
save on 486er?Thanks in advance
Michael
Hi,
Colin Burgess schrieb:
ClockCycles() emulation in interrupt handlers was fixed in 6.2.1 patch A
(I think)
It should definately work in 6.3.0 and onwards.What version are you using?
I tested this on a customer system, which runs QNX 6.1.
At the moment I switch off the timestamp feature, if the CPU has no
RDTSC instruction.
If this is working with 6.3.x systems, I could support the
TIMESTAMP-Feature, if the system version is >= 6.3.0.
But I would cause an exception with my isr code.
How much overhead causes the emulation code on isr level?
-Michael
Michael Tasche wrote:
Hi all,I use ClockCycles() to timestamp data in my interrupt-handler.
This does work on CPU’s which support some kind of machine instruction
like RDTSC on a pentium, but does not work on 486 CPU’s.
Well, after a look in the docu, I found out that ClockCycles is not
IRQ save.Can someone clarify, why the kernel emulation for ClockCycles is not
IRQ save on 486er?Thanks in advance
Michael
It causes a call to the timer_value callout to read the current timer value, which
is then added to the emulated cycles counter.
I don’t know just how slow that is, but it can’t be great, compared to the true rdtsc
Michael Tasche wrote:
Hi,
Colin Burgess schrieb:
ClockCycles() emulation in interrupt handlers was fixed in 6.2.1 patch
A (I think)
It should definately work in 6.3.0 and onwards.What version are you using?
I tested this on a customer system, which runs QNX 6.1.
At the moment I switch off the timestamp feature, if the CPU has no
RDTSC instruction.
If this is working with 6.3.x systems, I could support the
TIMESTAMP-Feature, if the system version is >= 6.3.0.
But I would cause an exception with my isr code.
How much overhead causes the emulation code on isr level?-Michael
Michael Tasche wrote:Hi all,
I use ClockCycles() to timestamp data in my interrupt-handler.
This does work on CPU’s which support some kind of machine
instruction like RDTSC on a pentium, but does not work on 486 CPU’s.
Well, after a look in the docu, I found out that ClockCycles is not
IRQ save.Can someone clarify, why the kernel emulation for ClockCycles is not
IRQ save on 486er?Thanks in advance
Michael