RVOPcode
Home/Instructions/NTL-PALL
NTL.PALL

RISC-V NTL.PALL Instruction Details

Instruction ManualR-type HINT (ADD x0, x0, x3)

Zihintntl all-private-cache non-temporal locality hint for the immediately following explicit memory-access target instruction.

Instruction Syntax

ntl.pall
Operand Breakdown
This is a R-type HINT (ADD x0, x0, x3)-format instruction. Confirm operand positions based on the assembly syntax.
ZihintntlMicroarch HintsCache & Sync
Related Search Terms
ntl.pall instructionRISC-V ntl.pallntl.pall syntaxntl.pall encodingprivate cache levelsntl.pall Zihintntlntl.pall cache hint

Instruction Behavior

NTL.PALL is a Zihintntl non-temporal locality HINT encoded as ADD x0, x0, x3. It indicates that the explicit memory accesses of the immediately following target instruction do not exhibit temporal locality within the capacity of any level of private cache in the memory hierarchy. The hint changes no architectural state and does not alter the architecturally visible effects of the target instruction; implementations may freely ignore it. NTL affects all memory-access instructions except Zicbom cache-management instructions, and it can also apply to Zicbop prefetch hints.

NTL.PALL Decode Animation

Decodes the ADD fields and shows target-instruction conditions and architectural boundaries.

ntl.pall
31..25
24..20
19..15
14..12
11..7
6..0
0000000
funct7
00011
rs2=x3
00000
rs1=x0
000
funct3
00000
rd=x0
0110011
OP
instruction
ntl.pall = 0x00300033
opcode
0110011 -> OP/ADD encoding
fixed fields
funct7=0000000, funct3=000, rd=x0, rs1=x0, rs2=x3
target
explicit memory access
hint
may hint that this access has no exploitable temporal locality in the any private-cache level
architectural state
NTL and the target instruction's architecturally visible effects are unchanged; the implementation may ignore the HINT

This animation shows only NTL architectural semantics from the unprivileged ISA; it does not infer a specific cache hierarchy, allocation policy, timing, or performance result.

Quick Understanding & Search Notes

NTL.PALL is a non-temporal locality prefix HINT that describes expected reuse of the next explicit memory access, without changing that access's architectural semantics.

The four NTL variants differ only in cache-level scope: P1, PALL, S1, and ALL.
If the target instruction traps, the official recommendation is not to apply the NTL to the first instruction in the trap handler.
RISC-V Unprivileged ISA Manual: Zihintntl non-temporal locality hints

Common Usage Scenarios

Cache & Hints

Understand this scenario with real code like «ntl.pall».

Concurrency & Multi-core

Understand this scenario with real code like «ntl.pall».

Performance

Understand this scenario with real code like «ntl.pall».

Pre-Use Checklist

Syntax Check
  • Confirm the current instruction format is R-type HINT (ADD x0, x0, x3).
  • Confirm the operand order matches the example.
Semantic Check
  • Ensure the destination register usage is compatible with the calling convention.
  • Confirm this is not the lower-level form of a pseudo-instruction expansion.

Pitfalls / Common Confusions

It applies only to the immediately following target instruction; later memory accesses are not governed by this NTL prefix.
This is a HINT and may be ignored; it must not be used as a correctness, synchronization, or consistency mechanism.
The official text discourages following NTL with an instruction that does not explicitly access memory; doing so has no architecturally visible effect but may reduce performance.
NTL does not affect Zicbom CBO.CLEAN/CBO.FLUSH/CBO.INVAL, but can affect other explicit memory accesses and prefetch hints.

FAQ

Does NTL.PALL change the result of the next load/store?

No. It does not alter the architecturally visible effects of the target instruction.

Can NTL.PALL be ignored by an implementation?

Yes. It is a HINT, so software cannot rely on it for performance or correctness guarantees.