This implements the setbc, setnbc, setbcr and setnbcr instructions.
Because the insn_type_t type already has 64 elements, this uses the
existing OP_SETB for the new instructions, and has execute1 compute
different results depending on bits 6-9 of the instruction.
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
This adds logic to do basic decoding of the prefixed instructions
defined in PowerISA v3.1B which are in the SFFS (Scalar Fixed plus
Floating-Point Subset) compliancy subset. In PowerISA v3.1B SFFS,
there are 14 prefixed load/store instructions plus the prefixed no-op
instruction (pnop). The prefixed load/store instructions all use an
extended version of D-form, which has an extra 18 bits of displacement
in the prefix, plus an 'R' bit which enables PC-relative addressing.
When decode1 sees an instruction word where the insn_code is
INSN_prefix (i.e. the primary opcode was 1), it stores the prefix word
and sends nothing down to decode2 in that cycle. When the next valid
instruction word arrives, it is interpreted as a suffix, meaning that
its insn_code gets modified before being used to look up the decode
table.
The insn_code values are rearranged so that the values for
instructions which are the suffix of a valid prefixed instruction are
all at even indexes, and the corresponding prefixed instructions
follow immediately, so that an insn_code value can be converted to the
corresponding prefixed value by setting the LSB of the insn_code
value. There are two prefixed instructions, pld and pstd, for which
the suffix is not a valid SFFS instruction by itself, so these have
been given dummy insn_code values which decode as illegal (INSN_op57
and INSN_op61).
For a prefixed instruction, decode1 examines the type and subtype
fields of the prefix and checks that the suffix is valid for the type
and subtype. This check doesn't affect which entry of the decode
table is used; the result is passed down to decode2, and will in
future be acted upon in execute1.
The instruction address passed down to decode2 is the address of the
prefix. To enable this, part of the instruction address is saved when
the prefix is seen, and then the instruction address received from
icache is partly overlaid by the saved prefix address. Because
prefixed instructions are not permitted to cross 64-byte boundaries,
we only need to save bits 5:2 of the instruction to do this. If the
alignment restriction ever gets relaxed, we will then need to save
more bits of the address.
Decode2 has been extended to handle the R bit of the prefix (in 8LS
and MLS forms) and to be able to generate the 34-bit immediate value
from the prefix and suffix.
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
This adds comments to row_predecode_rom to aid understanding how the
columns in the second half of the table are allocated to different
primary opcodes, and to the insn_code values to assist in locating the
code with a given numeric value. No code change.
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
This rearranges the synchronous process here to avoid setting fields
of pred(i) to zero or INSN_illegal when valid_in is '0'.
Experimentally, on ECP5 this acts like an asynchronous reset rather
than a synchronous reset.
Instead, handle possible indeterminate input for simulation by making
the maj_predecode and row_predecode fields of predec_t be unsigned
rather than insn_code (an enumerated type), and setting them to X when
the input word is indeterminate.
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
This splits out the decoding done in the decode0 step into a separate
predecoder, used when writing instructions into the icache. The
icache now holds 36 bits per instruction rather than 32. For valid
instructions, those 36 bits comprise the bottom 26 bits of the
instruction word, a 9-bit insn_code value (which uniquely identifies
the instruction), and a zero in the MSB. For illegal instructions,
the MSB is one and the full instruction word is in the bottom 32 bits.
Having the full instruction word available for illegal instructions
means that it can be printed in the log when simulating, or in future
could be placed in the HEIR register.
If we don't have an FPU, then the floating-point instructions are
regarded as illegal. In that case, the insn_code values would fit
into 8 bits, which could be used in future to reduce the size of
decode_rom from 512 to 256 entries.
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
Paul Mackerras