You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Try running the programs multiple times, and watch the value increase, and then try to correlate it with `/proc/cpuinfo` frequency!
12516
12504
12517
-
Good first instruction to learn SIMD: <<simd-assembly>>
12505
+
....
12506
+
while true; do sleep 1 && ./userland/arch/x86_64/rdtsc.out; done
12507
+
....
12518
12508
12519
-
=== x86 RDTSC instruction
12509
+
RDTSC stores its output to EDX:EAX, even in 64-bit mode, top bits are zeroed out.
12520
12510
12521
12511
TODO: review this section, make a more controlled userland experiment with <<m5ops>> instrumentation.
12522
12512
12523
12513
Let's have some fun and try to correlate the gem5 <<stats-txt>> `system.cpu.numCycles` cycle count with the link:https://en.wikipedia.org/wiki/Time_Stamp_Counter[x86 RDTSC instruction] that is supposed to do the same thing:
RDTSCP is like RDTSP, but it also stores the CPU ID into ECX: this is convenient because the value of RDTSC depends on which core we are currently on, so you often also want the core ID when you want the RDTSC.
12538
+
12539
+
Sources:
12540
+
12541
+
* link:userland/arch/x86_64/rdtscp.S[]
12542
+
* link:userland/arch/x86_64/intrinsics/rdtscp.c[]
12543
+
12544
+
We can observe its operation with the good and old `taskset`, for example:
There is also the RDPID instruction that reads just the processor ID, but it appears to be very new for QEMU 4.0.0 or <<p51>>, as it fails with SIGILL on both.
TODO We didn't manage to find a working ARM analogue to <<x86-rdtsc-instruction>>: link:kernel_modules/pmccntr.c[] is oopsing, and even it if weren't, it likely won't give the cycle count since boot since it needs to be activate before it starts counting anything:
0 commit comments