1. 11
  1.  

  2. 2

    You can cut down on a lot of redundancy in those tables by looking at how the instructions are actually encoded. Using sub as an example: if (op >> 3) = 10010b, then the instruction is a sub, and the low three bits tell you the operand. You don’t need 8 separate entries for the same instruction.

    1. 1

      writef("%02xh", b[addr + 1]);

      Please don’t use hex for displaying assembled instructions. It is almost invariably Wrong (on x86, at least). Every disassembler I know of makes this mistake.

      Prefer octal.

      1. 1

        Why octal over hex? It’s eight-bit bytes, after all. (My assembly experiences are on RISCs where the places where args go aren’t nicely aligned for readability anyways usually, so…

        1. 1

          RISCs where the places where args go aren’t nicely aligned for readability anyways usually

          Hence ‘on x86, at least’. (Though it also applies to other archs, like cray.) Because on x86 things are nicely aligned like that. E.G. on z80 in octal, anything with first digit 2 is alu; the second digit determines which alu operation to perform, and the third digit indicates the operand (all alu ops affect the accumulator). Everything starting with 1 is a move, with the second and third digits as the operands. Etc.

        2. 1

          It really depends upon the architecture. Hex is preferable for the 6502, 6809 and VAX. Octal is preferable for the x86 and the 68k. Although I would still like to see addresses for all these in hex, as all these are byte addressable machines.