presently this mapping is stateless, provided by TryInto implementations on OpCode and Instruction (although errors are allowed). another option (requiring major refactoring) would be a separate parser/assembler with its own configuration responsible for the mapping.
Case for Stateless
already implemented
provides a context-free (near) equivalent between opcodes and instructions, which is desirable since the machine reads opcodes from memory but executes on instructions
Case for Stateful
more flexible
some historic CHIP implementation quirks are better modeled at the opcode <> instruction mapping rather than at execution (namely whether 0xBXNN means jump XNN + V0 or jump XNN + VX)
Having our Cake and Eating It
the Instruction was originally intended as a representation of the CHIP instruction set in the type system
however it naturally grew into a superset of it which could easily be mapped to and from human readable text as well as from opcodes and to them where they exist
eventually it might make sense to do options 1 & 2 above: essentially two Instruction type hierarchies, one which closely models the real opcodes, and one which is closer to human language and would play a role in any assembly/CHIP8 scripting language we try to implement
presently this mapping is stateless, provided by
TryIntoimplementations onOpCodeandInstruction(although errors are allowed). another option (requiring major refactoring) would be a separate parser/assembler with its own configuration responsible for the mapping.Case for Stateless
Case for Stateful
jump XNN + V0orjump XNN + VX)Having our Cake and Eating It
Instructionwas originally intended as a representation of the CHIP instruction set in the type systemInstructiontype hierarchies, one which closely models the real opcodes, and one which is closer to human language and would play a role in any assembly/CHIP8 scripting language we try to implement