The object system is used to define opcodes. Methods on these objects (which get instantiated as singletons) then handle assembling and disassembling.
There is a macro defopcode-derived which defines an opcode similar to another one, using inheritance.
There is no reason for the relationship to go one way or the other; it's just "this thing is like that thing, except for this slight difference". The inheritance could basically go in either direction.
Note that defopcode-derived doesn't even have provision in its syntax to specify behavior; the code is 100% re-used. The only thing different about the derived opcode is the instruction mnemonic and the opcode bits. Inheritance is used just to override a number and symbol which are static slots.
Look how I abused inheritance in this assembler (for a Lisp virtual machine):
http://www.kylheku.com/cgit/txr/tree/share/txr/stdlib/asm.tl
The object system is used to define opcodes. Methods on these objects (which get instantiated as singletons) then handle assembling and disassembling.
There is a macro defopcode-derived which defines an opcode similar to another one, using inheritance.
There is no reason for the relationship to go one way or the other; it's just "this thing is like that thing, except for this slight difference". The inheritance could basically go in either direction.
Note that defopcode-derived doesn't even have provision in its syntax to specify behavior; the code is 100% re-used. The only thing different about the derived opcode is the instruction mnemonic and the opcode bits. Inheritance is used just to override a number and symbol which are static slots.