Audit Finding
Severity: Medium
File(s): opcodes.py, isa_unified.py (float instruction definitions)
Problem
The floating-point opcodes use two different encoding formats with no documented rationale:
| Instruction |
Encoding Format |
Registers |
Bytes |
| FADD |
Format E |
fd, fs1, fs2 (3 reg) |
3 |
| FSUB |
Format E |
fd, fs1, fs2 (3 reg) |
3 |
| FMUL |
Format E |
fd, fs1, fs2 (3 reg) |
3 |
| FDIV |
Format E |
fd, fs1, fs2 (3 reg) |
3 |
| FNEG |
Format C |
fs, fd (2 reg) |
2 |
| FABS |
Format C |
fs, fd (2 reg) |
2 |
| FMIN |
Format C |
fs, fd (2 reg) |
2 |
| FMAX |
Format C |
fs, fd (2 reg) |
2 |
Why This Is Problematic
- Implementor confusion: Binary instructions naturally use Format E (3-register), but unary float ops use Format C (2-register) even though they still read one source and write one destination
- Assembler complexity: Every assembler must hardcode which format each float opcode uses, rather than deriving it from the opcode class
- Decoder complexity: The VM decoder must treat FADD-FDIV differently from FNEG-FMAX even though they are all "float ALU" operations
Suggested Fix
- Either normalize all float ops to a single format (preferred: Format E for all, with unused register as 0x00 for unary ops), or
- Document in the spec that unary float ops intentionally use Format C and explain why (instruction density?)
- Add a
format field to each opcode definition so tooling can derive the encoding automatically
Audit Finding
Severity: Medium
File(s):
opcodes.py,isa_unified.py(float instruction definitions)Problem
The floating-point opcodes use two different encoding formats with no documented rationale:
Why This Is Problematic
Suggested Fix
formatfield to each opcode definition so tooling can derive the encoding automatically