Why is it needed after modifying code?
Data-store visibility does not automatically make new instructions visible to the instruction-fetch path; FENCE.I is the local synchronization point.
FENCE.I
RISC-V FENCE.I Instruction Details
Instruction ManualI-typeSynchronize instruction and data streams; ensure subsequent instruction fetches observe prior data stores (for self-modifying code and JIT)
Instruction Syntax
fence.i
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.
ZifenceiCache & Sync
Instruction Behavior
FENCE.I (opcode=MISC-MEM, funct3=001) from the Zifencei extension synchronizes instruction and data streams. Instruction fetches initiated after FENCE.I will observe any prior data stores to instruction memory. Essential for self-modifying code, JIT compilation, and dynamic code generation. Unlike FENCE (data ordering), FENCE.I is specifically for instruction-data serialization.
Quick Understanding & Search Notes
FENCE.I synchronizes prior data stores with subsequent instruction fetches on the current hart, so self-modified or generated code can be seen by later instruction fetches on that hart.
FENCE.I is not the ordinary data-memory ordering FENCE; it targets the instruction-fetch path.
It only guarantees the local hart; multi-hart code updates require synchronization on the other harts too.
Common Usage Scenarios
Self-modifying Code
Understand this scenario with real code like «fence.i # sync instruction fetch with prior data stores».
JIT Compilation
Understand this scenario with real code like «fence.i # sync instruction fetch with prior data stores».
Dynamic Code Generation
Understand this scenario with real code like «fence.i # sync instruction fetch with prior data stores».
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
FENCE.I only synchronizes inst-data for the local hart, not other harts/devices
Requires Zifencei extension; illegal instruction on unsupported systems
Self-modifying code or JIT must execute FENCE.I before executing new instructions
FAQ
Does it flush TLBs?
No. Address-translation synchronization uses SFENCE.VMA or related privileged invalidation sequences.