NTL.PALL

RISC-V NTL.PALL Instruction Details

Instruction ManualI-type

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

Instruction Syntax

ntl.pall
Operand Breakdown
Destination rd: general-purpose register receiving the result.
Source rs1: register holding the first operand.
Immediate imm: 12-bit signed value, sign-extended before operation with rs1.
ZihintntlMicroarch HintsCache & Sync

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 the target instruction is not expected to have temporal locality within any private cache level. 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 explicit memory-access instructions except Zicbom cache-management instructions, and it can also affect Zicbop prefetch hints.

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.

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 I-type.
  • 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.