[libre-riscv-dev] uniform instruction format

Luke Kenneth Casson Leighton lkcl at lkcl.net
Mon Jun 17 10:14:38 BST 2019


On Mon, Jun 17, 2019 at 9:47 AM Jacob Lifshay <programmerjake at gmail.com> wrote:
>
> On Mon, Jun 17, 2019, 01:21 Luke Kenneth Casson Leighton <lkcl at lkcl.net>
> wrote:
>
> > ---
> > crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
> >
> > On Mon, Jun 17, 2019 at 8:55 AM Jacob Lifshay <programmerjake at gmail.com>
> > wrote:
> > >
> > > On Sun, Jun 16, 2019 at 11:24 PM Luke Kenneth Casson Leighton
> > > <lkcl at lkcl.net> wrote:
> > > >
> > > > jacob, you missed some questions, which are important to resolve.
> > going
> > > > through the pseudo-code, and also through the RV spec, the format of
> > > > RV48-I-type seems wrong.  the pseudo-code says that it should match
> > exactly
> > > > with RV32-I-Type, which it does not.
> > > >
> > > > also can you clarify if the other potential error that i spotted is or
> > is
> > > > not correct?
> > > the P48FI encoding is correct, the fmt field is the lower 2 bits of
> > > funct7. The underlying format is actually I-type, but the entire
> > > immediate field is used for opcode.
> > > for an example, see the encoding of fsqrt.s on page 66 of Volume I:
> > > RISC-V Unprivileged ISA V20181221-Public-Review-draft.
> > > bit fields:
> > > 31:27 -- funct5 (more opcode)
> > > 26:25 -- fmt (set to S which is 00)
> > > 24:20 -- rs2 (0 for fsqrt.s, which is what makes it I-type instead of
> > R-type)
> > > 19:15 -- rs1
> > > 14:12 -- rm
> > > 11:7 -- rd
> > > 6:0 -- opcode
> >
> > turning the horizontal table entry for P48FI-type around:
> >
> > 31:27   | funct7[6:2] <---- this should be funct5
> >
> it's funct7, since it comes from the same positions as funct7 in R-type.
> fmt is just the 2 lowest bits in funct7.
>
> > 26:25:  fmt
> > 24:20  funct5 <---- this is the one that's not correctly listed
>
> that would be called rs2, but there is no rs2, so I picked func5. feel free
> to rename.

 ... it appears to be a commonly-used artificial construct that's not
given a name.  searching through the riscv ISA PDF for all occurrences
of "funct5" they all have the format of R-Type, with funct7 broken
"artificially" into "funct5 plus 2 extra bits", and funct3 "renamed"
to "RM" (rounding mode).  these require zero change to the R-Type
decoder [they do however require the funct7 field to be *further*
decoded].

hence, strictly speaking, it's still R-Type [with rs2=0 in some cases
e.g. FSQRT]

LR/SC also subdivides R-Type's funct7 into funct5 + aq + rl - again,
an artificial construct that requires no change to the decoder.

> I-type doesn't have an rs2 field, so I guess fsqrt.s is a strange hybrid
> between R-type and I-type, hence why I called it FI-type.

 i think it sensible to stick with the RV conventions and not invent a
type that doesn't exist in RV.  from its name, i was under the false
impression that FI-type is a completely new encoding type that has
absolutely nothing to do with RV, it being completely different from
all other RV encoding types.

> >
> > btw i enabled rst on the libre-riscv.org ikiwiki and put the document
> > here:
> > https://libre-riscv.org/simple_v_extension/sv_prefix_proposal/
>
> was wondering where it was.

 started making enough incremental modifications i was concerned about
losing track.

l.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 2019-06-17_10-07.png
Type: image/png
Size: 26668 bytes
Desc: not available
URL: <http://lists.libre-riscv.org/pipermail/libre-riscv-dev/attachments/20190617/dddeb235/attachment-0001.png>


More information about the libre-riscv-dev mailing list