[J-core] Instruction set diagram.

Rob Landley rob at landley.net
Mon Nov 18 01:13:00 UTC 2019


Did I send this graphic to the list already? This is a picture of the
instruction set diagram that we printed out as a big laminated poster, and then
marked up with whiteboard markers to indicate instruction groups and attributes,
looking for patters to help us rewrite the instruction set decoder more
efficiently. (The work we've been doing on the "staircase".)

Each instruction bit pattern has 4 parts: the left 4 bits are the instruction
"line", the next 4 are "Rn", the next 4 are "Rm", and we've just been calling
the last 4 the "last 4". Usually the way these instructions work, Rn is the
register written to and Rm is read from. Single register instructions always use
Rn, and some single register instructions (ones with red dots at the left side
of the Rn column), call bits 11-8 "Rm" because they read from the register
instead of writing to it.

The green line along the far left edge of the table means this row of
instructions is a one register instruction parsed "Rn Fx", I.E bits 15-12 and
3-0 indicate which insturction row this is, bits 12-9 indicate the register to
operate on, bits 8-5 say which column the instruction is within the row. (Really
bits 6 and 5 since there are only 4 positions across, bits 7 and 8 are currently
ignored.)

Blue along the left edge means it's a 2 register instructin parsed "Rn Rm MD",
those are instructions operating on 2 registers: bits 15-12 and 3-2 select the
instruction row, bits 12-9 say which first register to use and bits 8-5 say
which second register, and then bits 1 and 0 say which column across the
specific instruction is.

There are several more bit patterns, usually having to do with "disp" or "imm"
fields in the instruction: that's "displacement" and "immediate", I.E. a
constant is encoded in the instruction using some of the bits, generally with a
fixed shift applied to it (instruction displacements are <<1 because 16 bit
instructions, load byte isn't shifted, load short is shifted 1 because
sizeof(short), load int is shifted 2 because sizeof(int), etc.

The numbers written in blue next to each instruction are the number of clock
cycles that instruction takes, if there's no number is a 1 clock instruction.
We're looking at what we can do to make them fewer clocks. (We already cleaned
up one in the earlier pass, we have plans for some others already.)

The green highlight over an instruction row means we've already collated that
together in the staircase. (Not sure we're going much farther down that path,
the optimizer's already finding most of the benefit there, we might actually
undo it again, but it was educational.)

The red highlights mean "this instruction does not fit the pattern of
instructions around it at was clearly retrofit, patched into empty space when
they needed an instruction. We did it for CAS.L, Hitachi did it for TAS.B, and
CMP/EQ #imm:8,R0, SLEEP, and RTE do not belong where they are in the table. (I
mean we're stuck with them, but they're special cases that will probably stay
parsed as "staircase" code if we make a new more efficient microcode table with
what we've learned.)

What else... The ones with _two_ red dots on the Rn line are jump/branch
instructions which are basically the same thing except with/without test.

The light blue dot on the 0001 and 0101 line are disp 8, and the only
instructions that are NOT Rn+Rm or Rn+Fx when bit 15 is 0 are those two and the
0111 line (which is Rn and 16 bit immediate value). All the OTHER ones using
imm/disp have bit 15 set, and everything with bit 15 set has some kind of
imm/disp value in the insruction (the remaining question is size of the imm/disp
field).

There's more family grouping on the right edge, poke me if I should try to
explain that. :)

Rob
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 1571282524547.jpg
Type: image/jpeg
Size: 183599 bytes
Desc: not available
URL: <http://lists.j-core.org/pipermail/j-core/attachments/20191117/88b09370/attachment-0001.jpg>


More information about the J-core mailing list