Yep, had to rip up the instruction decode representation, but the new form is simpler to build and to walk. It’s essentially just a direct representation of a decode tree, with a tree of structures; in each structure, the level below is captured as an array of pointers to the decode nodes below. The bottom level, below which there are only instructions, holds a pointer to a single queue of instructions.

We capture the instructions as they arrive, and insert them into the single queue in field order (there’s always a ‘final opocde field’ to define this instruction rather than that, and that’s the field we use to insertion sort on.

Insertion sorting means duplicates are easily found.

Also looked at the error reporting, and tidied that up extensively. The whole thing seems much more robust now - trying it on an increasing number of acrhitectures. In particular, we want an architecture whose instruction set is as close to one-to-one with the abstract architecture implied by the triples - if they were instructions, what would they look like? This lead to a new field type being needed - an ‘operand’, whose definition includes its base register. So now we can represent accumulator machines simply, too.

fields {

// the name of a field, for assembler definition, is the name given here

// the name of a field, for assembler definition, is the name given here

op8[0:7] opcode;// 4 bits of major opcode unsigned value


l_dest[9:15]   opndsel fptr srcdest;

l_src1[16:23]  opndsel fptr src;

l_src2[24:31]  opndsel fptr src;


© kiva design groupe • 2017