RDTSCP

RDTSCP reads the time-stamp counter as RDTSC does, high half in EDX and low half in EAX, and in the same step the low 32 bits of the IA32_TSC_AUX MSR into ECX. It differs from RDTSC in two ways: what it returns in ECX, and what it waits for. The RDTSC page covers the counter itself: its rate, CR4.TSD and virtual machines.

Which processor the reading came from#

The operating system writes TSC_AUX on each logical processor. Linux puts the CPU number in its low 12 bits and the NUMA node above them, so a program can tell whether two readings came from the same CPU and discard a measurement that a migration spoiled: counters of different processors need not agree. Reading ECX in the same instruction matters; a separate query of the CPU number could run on another processor than the reading. The probe pins itself to CPU 0, and Zen 5 returned 0 in ECX, with bits 63:32 of RAX, RDX and RCX cleared; a 66 or REX.W prefix changed nothing, as AMD’s manual says the operand size is ignored. RDPID reads the same number without the counter.

What it waits for#

Intel’s manual says RDTSCP reads the counter only after all earlier instructions have executed and their loads have taken their values, but not after earlier stores are visible, and that later instructions may start before it reads. AMD’s says the earlier instructions retire first. Either way it waits for the code before it, so it fits the end of a timed region; an LFENCE after it keeps the code that follows from starting early, and an MFENCE before it (Intel’s advice) waits for the stores too.

From C#

__rdtscp(&aux) needs no compiler flag. GCC 14 and Clang 23 at -O2 emit RDTSCP, combine EDX and EAX with a shift and an OR, and store ECX to aux. The CPUID bit is 80000001H, EDX bit 27, on both vendors.

Under Intel’s VMX the hypervisor must set the “enable RDTSCP” control for a guest to run it at all, or RDTSCP raises #UD, and RDPID with it (volume 3). AMD’s Zen 5 guide lists RDTSCP, like RDTSC, as microcoded.

In the optimization guide

What the optimization guide says about RDTSCP, a line per claim. Each links to the claim in the guide, with its sources and where they differ.

Measuring

• Reading the time-stamp counter: RDTSCP waits for the code before it but not for the code after it, which an LFENCE after it holds back.
• Reading the time-stamp counter: Every logical processor keeps a TSC of its own, and RDTSCP’s TSC_AUX value shows whether two readings came from the same one.
• Reading the time-stamp counter: CR4.TSD confines RDTSC and RDTSCP to ring 0, and they then raise #GP in user code.
• Setting up the test: A guest’s TSC may be scaled and offset by the hypervisor, and its counters may be fewer.

Forms

Latency and throughput

Operation

What the forms do, in pseudocode that our tests run against results recorded on real processors. How to read.

if CPL > 0 and cr4 >> 2 & 1:     # CR4.TSD, as for RDTSC
    fault(GP, 0)
t = tsc()                        # the count at this moment: time's
edx = t >> 32                    # bits 63:32 of RDX, RAX and RCX
eax = low(t, 32)                 # cleared
ecx = tsc_aux                    # the OS's number of this CPU, read
                                 # with the count, so that a program
                                 # sees whether it moved between two
# waits for the earlier instructions to finish (Intel: but not for
# earlier stores to be seen); later ones may start before it reads

Operands

Flags

None: XED records no flag that the forms test or change.

CPUID and processors

Each form belongs to an XED ISA set. A form can be used when the processor reports every CPUID bit of one of its ISA set's alternatives.