eBPF ISA compatibility
- Idea
- Draft
- Review
- Accept
- Implement
- Active
Decision brief
Why this proposal matters
This SIMD introduces instruction set architecture (ISA) changes to make the sBPF virtual machine compatible with the latest existing version of eBPF ISA generated by its LLVM backend. It reverts past ISA changes, modifies the encoding of existing instructions and brings new instructions to the Solana virtual machine.
Proposal at a glance
What changes
- JEQ32_IMM -> opcode = 0x16 -> pc += offset if dst as u32 == IMM as u32
- JGT32_IMM -> opcode = 0x26 -> pc += offset if dst as u32 > IMM as u32
- JGE32_IMM -> opcode = 0x36 -> pc += offset if dst as u32 >= IMM as u32
Stakeholder map
Who is affected
Builders & client teams Medium impact
Programs containing the instructions mentioned in this SIMD must have the 0x03 value in the e_flags field of their header.
Action may be requiredValidators & operators Impact unknown
No proposal-specific evidence was found for this group.
Action requirement unknownUsers & stakers Impact unknown
No proposal-specific evidence was found for this group.
Action requirement unknownGovernance & ecosystem Impact unknown
No proposal-specific evidence was found for this group.
Action requirement unknownExact source revision
Full proposal document
6cc17538e266Summary
This SIMD introduces instruction set architecture (ISA) changes to make the sBPF virtual machine compatible with the latest existing version of eBPF ISA generated by its LLVM backend.
It reverts past ISA changes, modifies the encoding of existing instructions and brings new instructions to the Solana virtual machine.
Motivation
The eBPF target on the Rust compiler emits code by default for eBPFv1, whose
only incompatibility with the Solana virtual machine is the callx
instruction. Aiming to prioritize Solana programs and decrease their CU
consumption, we want to be compatible with at least the current eBPF version
(v3), which brings in new instructions. In order for that to be possible, we
must modify our virtual machine to support eBPF integrally.
Dependencies
This proposal depends on the following previously accepted proposals:
SIMD-0178: SBPF Static Syscalls
SIMD-0189: SBPF stricter ELF headers
This SIMD requires static syscalls which requires stricter ELF headers.
New Terminology
The set containing these new instructions will form an sBPFv3 program.
Detailed Design
ELF Identification
Programs containing the instructions mentioned in this SIMD must have the
0x03 value in the e_flags field of their header.
JMP32 instruction class
The JMP32 instruction class utilizes 32 bit wide operands for the same operations as the JMP class.
The following opcodes must be allowed in the verifier and the virtual machine must implement the behavior described below for each one of them.
JEQ32_IMM-> opcode =0x16->pc += offset if dst as u32 == IMM as u32JGT32_IMM-> opcode =0x26->pc += offset if dst as u32 > IMM as u32JGE32_IMM-> opcode =0x36->pc += offset if dst as u32 >= IMM as u32JSET32_IMM-> opcode =0x46->pc += offset if (dst as u32 & IMM as u32) != 0JNE32_IMM-> opcode =0x56->pc += offset if dst as u32 != IMM as u32JSGT32_IMM-> opcode =0x66->pc += offset if dst as i32 > IMM as i32JSGE32_IMM-> opcode =0x76->pc += offset if dst as i32 >= IMM as i32JLT32_IMM-> opcode =0xa6->pc += offset if dst as u32 < IMM as u32JLE32_IMM-> opcode =0xb6->pc += offset if dst as u32 <= IMM as u32JSLT32_IMM-> opcode =0xc6->pc += offset if dst as i32 < IMM as i32JSLE32_IMM-> opcode =0xd6->pc += offset if dst as i32 <= IMM as i32JEQ32_REG-> opcode =0x1e->pc += offset if dst as u32 == src as u32JGT32_REG-> opcode =0x2e->pc += offset if dst as u32 > src as u32JGE32_REG-> opcode =0x3e->pc += offset if dst as u32 >= src as u32JSET32_REG-> opcode =0x4e->pc += offset if (dst as u32 & src as u32) != 0JNE32_REG-> opcode =0x5e->pc += offset if dst as u32 != src as u32JSGT32_REG-> opcode =0x6e->pc += offset if dst as i32 > src as i32JSGE32_REG-> opcode =0x7e->pc += offset if dst as i32 >= src as i32JLT32_REG-> opcode =0xae->pc += offset if dst as u32 < src as u32JLE32_REG-> opcode =0xbe->pc += offset if dst as u32 <= src as u32JSLT32_REG-> opcode =0xce->pc += offset if dst as i32 < src as i32JSLE32_REG-> opcode =0xde->pc += offset if dst as i32 <= src as i32
callx encoding
The encoding of callx must change so that the register containing the address to jump to is in the destination register.
callx-> opcode =0x8d-> pc =dst
Stack frame gaps
The virtual machine feature of stack gaps must be disabled for sBPFv3 programs.
Alternatives Considered
We have considered diverging from the eBPF standard by introducing new opcodes and creating specific instructions to the Solana environment. We discarded such an approach to be compatible with the existing LLVM eBPF code generation.
Another consideration was bringing new eBPFv4 instructions to the Solana environment. They are a superset of eBPFv3 and does not conflict with it, so any additions may be included in the future without a breaking change.
Impact
These changes permit a straightforward management of the compiler toolchain, permitting the usage of most of existing upstream tooling.
Security Considerations
None
Evidence graph
Related proposals and rollout
One or more sources are unavailable.
Upstream review record
Upstream discussion & review
One or more sources are unavailable.
Provenance
Evidence & technical details
Rollout or chain data, source revisions, freshness and integrity. 3
Provenance
Evidence & technical details
Rollout or chain data, source revisions, freshness and integrity.SIMD
Deployment Status
Feature Gate not yet created
Exact source revision
Sources & integrity
- Proposal document pinned_commit_blob
6cc17538e26601e65beca89bbfa761e755720956 - simd-document document · stale · Oct 29, 2026
6cc17538e26601e65beca89bbfa761e755720956
One or more sources are unavailable.
One or more sources are unavailable.
simd.watch community discussion · SIMD-0377
Powered by Giscus · Sign in with GitHub to comment
Community comments load when this section approaches the viewport.