Vol. 3C 36-39

INTEL® PROCESSOR TRACE

The processor-internal Last IP state is guaranteed to be reset to zero when a PSB is sent out. This means that the 
IP that follows the PSB with either be un-compressed (011b or 110b, see Table 36-18), or compressed against 
zero.
At times, “IPbytes” will have a value of 0. As shown above, this does not mean that the IP payload matches the full 
address of the last IP, but rather that the IP for this packet was suppressed. This is used for cases where the IP that 
applies to the packet is out of context. An example is the TIP.PGD sent on a SYSCALL, when tracing only USR code. 
In that case, no TargetIP will be included in the packet, since that would expose an instruction point at CPL = 0. 
When the IP payload is suppressed in this manner, Last IP is not cleared, and instead refers to the last IP packet 
with a non-zero IPBytes field.
On processors that support a maximum linear address size of 32 bits, IP payloads may never exceed 32 bits 
(IPBytes <= 010b).

Indirect Transfer Compression for Returns (RET)

In addition to IP compression, TIP packets for near return (RET) instructions can also be compressed. If the RET 
target matches the next IP of the corresponding CALL, then the TIP packet is unneeded, since the decoder can 
deduce the target IP by maintaining a CALL/RET stack of its own.
A CALL/RET stack can be maintained by the decoder by doing the following:
1. Allocate space to store 64 RET targets. 
2. For near CALLs, push the Next IP onto the stack. Once the stack is full, new CALLs will force the oldest entry off 

the end of the stack, such that only the youngest 64 entries are stored. Note that this excludes zero-length 
CALLs, which are direct near CALLs with displacement zero (to the next IP). These CALLs typically don’t have 
matching RETs. 

3. For near RETs, pop the top (youngest) entry off the stack. This will be the target of the RET.
In cases where the RET is compressed, the target is guaranteed to match the value produced in 2) above. If the 
target is not compressed, a TIP packet will be generated with the RET target, which may differ from 2).
The hardware ensure that packets read by the decoder will always have seen the CALL that corresponds to any 
compressed RET. The processor will never compress a RET across a PSB, a buffer overflow, or scenario where Pack-
etEn=0. This means that a RET whose corresponding CALL executed while PacketEn=0, or before the last PSB, etc., 
will not be compressed.
If the CALL/RET stack is manipulated or corrupted by software, and thereby causes a RET to transfer control to a 
target that is inconsistent with the CALL/RET stack, then the RET will not be compressed, and will produce a TIP 
packet. This can happen, for example, if software executes a PUSH instruction to push a target onto the stack, and 
a later RET uses this target.
When a RET is compressed, a Taken indication is added to the TNT buffer. Because it sends no TIP packet, it also 
does not update the internal Last IP value, and thus the decoder should treat it the same way. If the RET is not 
compressed, it will generate a TIP packet (just like when RET compression is disabled, via 
IA32_RTIT_CTL.DisRETC). For processors that employ deferred TIPs (Section 36.4.2.3), an uncompressed RET will 
not be deferred, and hence will force out any accumulated TNTs or TIPs. This serves to avoid ambiguity, and make 

Table 36-18. FUP/TIP IP Reconstruction

IPBytes

Uncompressed IP Value
63:56

55:48

47:40

39:32

31:24

23:16

15:8

7:0

000b

None, IP is out of context

001b

Last IP[63:16]

IP Payload[15:0]

010b

Last IP[63:32]

IP Payload[31:0]

011b

IP Payload[47] extended

IP Payload[47:0]

100b

Last IP [63:48] 

IP Payload[47:0]

101b

Reserved

110b

IP Payload[63:0]

111b

Reserved