RDTSC instruction (System)

RDTSC reads a clock without a system call or a device access. The result arrives split, the high half in EDX and the low half in EAX; GCC 14 and Clang 23 at -O2 compile the __rdtsc() intrinsic to RDTSC followed by shl rdx, 32 and or rax, rdx.

What the counter counts:

On processors with an invariant TSC (CPUID 80000007H, EDX bit 8, the same bit on Intel and AMD), it ticks at a constant rate in every power and sleep state, so the operating system may use it as its clock.
That rate is not the core’s current clock. Intel’s optimization manual notes that on Skylake it runs at the guaranteed (P1) frequency whatever the turbo state, and Intel’s manual recommends the performance counters (see RDPMC) for counting core cycles.
Each logical processor has its own counter, which privileged software can write, so two of them need not agree. RDTSCP also returns a value that the operating system keeps per processor (Linux stores the CPU and node number), so a program can tell whether it moved between two readings.

RDTSC waits for nothing: it may read the counter before earlier instructions finish, and later ones may start before it reads. To time a piece of code on Intel’s processors, surround each RDTSC with LFENCEs: the one before makes the read wait for the code ahead of it, the one after keeps the code behind it from starting early. RDTSCP waits for earlier instructions by itself, so RDTSCP; LFENCE serves at the end. LFENCE does this on AMD’s processors only where it is dispatch serializing, as on Zen 5. To wait for earlier stores as well, Intel’s manual puts an MFENCE before the LFENCE; AMD’s counts MFENCE as serializing on its own.

The operating system can forbid RDTSC outside ring 0 by setting CR4.TSD, which makes it raise #GP there. Under virtualization the guest reads the host’s counter scaled and offset by values the hypervisor sets (TSC offsetting and scaling in Intel’s VMX, the TSC offset and ratio in AMD’s SVM), unless the hypervisor makes RDTSC exit to it.

In the optimization guide

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

Measuring

Core cycles, reference cycles and the TSC: The invariant TSC ticks at a constant rate near the base frequency, so under turbo it measures time rather than core cycles. sources differ
Reading the time-stamp counter: RDTSC runs out of order with its neighbours unless LFENCE (or MFENCE and LFENCE) before it and LFENCE after it hold it in place.
Reading the time-stamp counter: The TSC suits long intervals, not a handful of instructions, whose readings vary from run to run.
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

Every encoding of RDTSC that Intel XED knows, one row per XED instruction form (iform). How to read the notation.

Instruction	Encoding	Requires
`RDTSC` RDTSC	`0F 31`	Base instruction set

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: only CPL 0 may read the
    fault(GP, 0)                 # counter
t = tsc()                        # the count at this moment: time's,
                                 # not an input of the instruction
edx = t >> 32                    # the high half; bits 63:32 of RDX
eax = low(t, 32)                 # and RAX cleared
# 66 and REX.W change nothing. Not serializing: the counter may be
# read before earlier instructions are done, or after later ones
# have started (Intel's manual: an LFENCE before or after orders it)

Run on AMD Zen 5 (EPYC 9645): 3 cases.

Operands

What each form reads and writes, as Intel XED records it: the operands of its syntax, in order, and the implicit ones that the syntax does not name. How to read.

Operand	Kind	Action
`RDTSC`
`EAX`	implicit	write
`EDX`	implicit	write
`TSC`	implicit	read

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.

CPUID requirements and processors of the XED ISA sets above. Alternatives are separated by “or”; processors follow XED’s chip model, whose AMD processors end with Zen 2, and the CPU data of this site for Zen 3 to Zen 6.

ISA set	CPUID	Processors
`PENTIUMREAL` General-purpose System	No CPUID bit: part of the base instruction set.	Every x86-64 processor in XED’s model and Zen 3 to Zen 6

RDTSC