[libre-riscv-dev] uniform instruction format

[Jacob Lifshay]

On Sat, Jun 15, 2019 at 8:51 AM Luke Kenneth Casson Leighton
<lkcl at lkcl.net> wrote:
>
> https://salsa.debian.org/Kazan-team/kazan/blob/master/docs/Uniform%20Instruction%20Format%20Proposal.rst
>
> deviates too far from RV32, it's unrecogniseable, and would require a
> custom decoder that has nothing in common with an RV32 decoder.
The idea is that it is almost trivial to decode into the operations
that go directly to the internal register file, ALUs, etc. whereas
RV32 and SV48 when combined have different fields in different
positions. Most of the difference in opcodes is combining opcodes that
do the same thing and pretty much the rest is just a bit permutation
(can be done with only wires).

One part I particularly want to keep in the current proposal is that
register fields are 8-bits wide, allowing future extension to treat
the integer and FP registers as a combined register file. Since the
current implementation shares the ALUs between FP and integer
operations anyway (assuming nothing changed while I wasn't looking),
there's not much point in having separate register files, and that
allows (assuming we don't prevent it in the decoder) the compiler to
use the registers more efficiently. In fact, that should make the
compiler a little simpler (since it only has 1 kind of register that
can hold any 64-bit value, FP, int, or pointer), and will definitely
make the decoder simpler (won't have to check for mixed FP/int
registers) and the rest of the implementation shouldn't be affected.
>
> the very very quickly written (1-2 days) format i was expecting is to
> embed the 32 bit standard format(s) into a 64 bit (or greater) field,
> and to have extra bits tacked on in fixed locations for VL, 1 bit fof
> "rs1 is vector or rs1 is scalar", "rs2 is vector or rs2 is scalar" and
> so on.
I chose not to just embed the 32-bit standard format since we will
need 48-bit instructions to fit as well, and they are encoded
differently (at least some of the custom ones) to the standard 32-bit
format. I do have the rs1/rs2/rs3/rd are vector/scalar bits, along
with fields to normalize the element types, so those don't have to be
deduced from the opcodes inside the processor after the instruction
decoder (useful for vectorization to know what register offsets should
be used and stuff).
>
> given that hard-coded wire positions are simply routing with no logic
> required, the actual bit positions do not matter in the slightest.
>
> also we do not need additional immediate bits, as there is no way that
> these can be represented in the original RV32 opcodes.
The idea is that this would be both an internal and external format.
For some of the formats, the extra immediate bits would come from
decoding LUI/ADDI pairs. I have several other pairs encoded as one
instruction, such as call (AUIPC/JALR) and tail (AUIPC/JALR with
different registers). My plan is that all macro-op fusion that we will
have the decoder support will convert to a single 64-bit internal
instructions.
>
> given that this is an *internal* representation that will never make
> it out into an actual assembler, adding extra immediate bits just
> results in extra decode logic that will never be used.
Since these will be externally visible instructions as well, they can
be used by the compiler and for macro-op fusion as outlined above.
>
> l.
>
> _______________________________________________
> libre-riscv-dev mailing list
> libre-riscv-dev at lists.libre-riscv.org
> http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev