Mixing data and op-codes seemed like an unpleasant consequence of the way I had earlier proposed writing op-codes. Besides that, parsing the op-code would take some bit-masking at a minimum, which although fast, still takes a cycle. We're trying to minimize cycles as much as possible and come as close to an effective operation speed of 5MHZ as we can.

When I woke up this morning a new plan was in my mind. Instead of having pointers to the constants held in another array as a second 8-bit instruction that we'd have to keep track of in the Program Counter, why not build a table of 256 commands that already included the combinations of <SRC> and <DST> built in? That way, we could evaluate where to send data extremely quickly. This blows up the number of directly addressed commands, but I think we can fit a few Constants and a few Labels in there and maintain this scheme.

The biggest bloat is going to be in the number of instructions needed for MOV <SRC> <DEST>. We have 5 available sources and each of those has 4 available destinations (we will ignore the fool who wants to move ACC to ACC). Then, we will need an additional code for every single Destination for every single CONST we allow to be assigned. If we allow 16 CONST definitions, our OP-CODE count for MOV jumps to 36. Honestly, 16 is probably more CONST than are needed per node, but I don't want to limit the user very much if we can avoid it.

This scheme allows a 1-to-1 parity between the number of OP-CODES we have in compiled code and the number our users type into the screen. This allows JMP commands to work on a 1-to-1 basis without inspecting the array. Binary table coming soon.