Audit Finding
Severity: Critical
File(s): opcodes.py, isa_unified.py, test_conformance.py
Problem
The repository contains two completely different opcode numbering schemes that are mutually incompatible:
| Aspect |
opcodes.py (VM executes) |
isa_unified.py (spec) |
| HALT |
0x80 |
0x00 |
| NOP |
0x00 |
0x01 |
| ADD |
0x10 |
0x20 |
| ... |
completely different offsets |
completely different offsets |
This means test_conformance.py generates bytecodes using the ISA spec numbers, but the VM interprets them using the opcodes.py numbers. The conformance test can never pass regardless of implementation correctness.
Impact
- Conformance testing is fundamentally broken — false failures or false passes
- Any external tooling that uses
isa_unified.py to emit bytecodes will produce garbage when run on the VM
- Blocks all integration across the FLUX ecosystem
Suggested Fix
- Preferred: Align
isa_unified.py opcode values with opcodes.py (the VM is the source of truth for what executes)
- Alternative: Create a formal mapping/translation layer between the two namespaces, documented in
isa_unified.py
- Update
test_conformance.py to use whichever numbering is canonical
Related
- Part of the broader ISA spec vs. VM implementation divergence tracked in flux-spec repo
Audit Finding
Severity: Critical
File(s):
opcodes.py,isa_unified.py,test_conformance.pyProblem
The repository contains two completely different opcode numbering schemes that are mutually incompatible:
opcodes.py(VM executes)isa_unified.py(spec)0x800x000x000x010x100x20This means
test_conformance.pygenerates bytecodes using the ISA spec numbers, but the VM interprets them using theopcodes.pynumbers. The conformance test can never pass regardless of implementation correctness.Impact
isa_unified.pyto emit bytecodes will produce garbage when run on the VMSuggested Fix
isa_unified.pyopcode values withopcodes.py(the VM is the source of truth for what executes)isa_unified.pytest_conformance.pyto use whichever numbering is canonicalRelated