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

RV32/RV64 Zihintntl 1.0; ntl.pall has no explicit operands. Fixed fields are not selectable source or destination registers.

32-bit ADD HINT: funct7=0000000, rs2=x3, rs1=rd=x0, funct3=000, opcode=0110011; encoding 0x00300033.

Describes only explicit memory accesses of the immediately following target instruction. An implementation may ignore it; target architectural effects are unchanged.

NTL does not affect Zicbom cache management; a non-memory target is discouraged. If the target traps, ignoring the hint is recommended instead of applying it to the first handler instruction.

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 HINT for explicit memory accesses of the immediately following instruction. It does not change the target's architectural effects.

The four NTL variants describe temporal locality at the innermost private, all private, innermost shared, and all cache levels.
If the target instruction traps, the official recommendation is not to apply the NTL to the first instruction in the trap handler.
The RISC-V Instruction Set Manual, Volume I: Unprivileged Architecture — Zihintntl 1.0

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
  • RV32/RV64 Zihintntl 1.0; ntl.pall has no explicit operands. Fixed fields are not selectable source or destination registers.
  • 32-bit ADD HINT: funct7=0000000, rs2=x3, rs1=rd=x0, funct3=000, opcode=0110011; encoding 0x00300033.
Semantic Check
  • Describes only explicit memory accesses of the immediately following target instruction. An implementation may ignore it; target architectural effects are unchanged.
  • NTL does not affect Zicbom cache management; a non-memory target is discouraged. If the target traps, ignoring the hint is recommended instead of applying it to the first handler instruction.

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.