[libre-riscv-dev] Instruction sorta-prefixes for easier high-register access

[Jacob Lifshay]

I finished adding all the RV64G base instructions.

URL for convenience:
https://salsa.debian.org/Kazan-team/kazan/blob/master/docs/Prefix%20Proposal.md

On Mon, Jan 21, 2019 at 4:25 AM Luke Kenneth Casson Leighton <lkcl at lkcl.net>
wrote:

> On Mon, Jan 21, 2019 at 11:41 AM Jacob Lifshay <programmerjake at gmail.com>
> wrote:
> >
> > On Mon, Jan 21, 2019, 02:42 Luke Kenneth Casson Leighton <lkcl at lkcl.net
> > wrote:
> >
> > > ---
> > > crowd-funded eco-conscious hardware:
> https://www.crowdsupply.com/eoma68
> > >
> > > On Mon, Jan 21, 2019 at 10:23 AM Jacob Lifshay <
> programmerjake at gmail.com>
> > > wrote:
> > > >
> > > > I pushed a work-in-progress prefix proposal to
> > > >
> > >
> https://salsa.debian.org/Kazan-team/kazan/blob/master/docs/Prefix%20Proposal.md
> > >
> > > looks great;
> > >
> > > elwidth
> > >
> > > 11 64-bit (d)
> > >
> > > can you make that "default" (in both int & fp), so that:
> > >
> > I'm reusing the encoding from ld/st and from fp arith so can't change the
> > order since I'm using the pre-existing fields to encode elmsz.
>
>  part of the pre-existing instruction: ok, yes, so that can't change.
> then we are talking about different things.  the purpose of the
> elwidth in the Reg CSRs is to override the default [pre-existing]
> encoding *and* to indicate that the register file is to be treated as
> a type-casted contiguous SRAM as far as elements are concerned.
>
>  so the "register" (standard register) is merely a convenient address
> pointer into that SRAM, and, crucially, the REMAP "offset" is added to
> that [type-casted] SRAM address, in order to be able to access high
> bytes/halfs/words of 64-bit "registers".
>
>  if an elwidth over-ride is *not* to be included in the prefix, then
> it becomes extremely complex, as there are four cases to consider:
>
> * default, scalar (standard RV behaviour)
> * non-default, scalar (IGNORES HIGH ZERO/SIGN BITS)
> * default, elements (RESPECTS HIGH ZERO/SIGN BITS)
> * non-default, elements (COMPACTS MULTIPLE ELEMENTS INTO 64-bit
> "registers")
>
> if there does not exist an elwidth over-ride, it becomes extremely
> complex software-wise to interact between the vector and scalar
> "worlds".  xBitManip, &'ing, |'ing and shifts all become necessary in
> order to "extract" and place data into and out of vectors: precisely
> the things we wish to avoid doing.
>
>
> > >
> > >  (a) when using the CSR tables, the "default" may be over-ridden
> >
> > we can set it so that the csr tables overrides the 64.
>
>  that's not a good idea.  that changes the meaning of the 16 and 32
> bit opcodes.  as in: you actually have to emit completely the "wrong"
> opcode.
>
>  right now, the opcodes do not actually change "meaning".  that's been
> a critical and fundamental tenet of SV: you *do not* change the
> meaning of the standard RV opcodes.  there's a couple of places where
> that rule is bent a little (BEQ/BNE), however it's not in such a
> drastic way.
>
> > >  (b) the elwidth can be taken from the opcode (and the usual
> > > zero/sign-extension done: this is crucial for LD/ST)
> > >
> > the ld/st elwidth is taken from the opcode. I designed it so ld/st always
> > loads/stores the same width as the register has, so I can reuse the
> > zero/sign bit for the msb of ld_st_kind.
>
>  ... that's changing the meaning of LD/ST *and* changes the encoding.
> i very specifically avoided doing that, as one of the design goals of
> SV, particularly as it complicates the decoder phase (conditional
> decoding, based on the prefix)
>
>
> > >  (c) RV32/RV64 mode can do the "normal" changing that is part of the RV
> > > spec.
> >
> >
> > > the signed/unsigned table is not needed: i did a comprehensive
> > > analysis as part of spike-sv which shows that the sign/zero extension
> > > may be taken from whether the instruction has a ".W" suffix.  dead
> > > simple.
> > >
> > Yup, except I'm using that as elmsize[1], so I need another bit.
>
>  that doesn't make any sense: it's effectively just moving one bit
> from the standard ".W" location into elmsize[1].  and overcomplicates
> the instruction decoder phase:
>
>  if (prefix mode) sign_mode = elmsize[1] else sign_mode = {standard
> location}
>
>
> > > the c.mv sign/unsigned: this makes me nervous (especially after
> > > analysing how complex in the hardware it is to do).  it turns the
> > > processor into a CISC design that effectively requires turning the
> > > instruction into two microcode ops.  and it's element-based.
> > >
> > We can change the conv instruction to only be valid to/from 32-bits.
> >
> > everything in prefixed C is still in flux, so that can change.
> > I think we should establish a working 48-bit encoding and then pick the
> > most commonly used ops, since I'd like prefixed C to be similar to C in
> > that every C instruction expands 1:1 to a 48-bit instruction and C is
> just
> > used to make them smaller.
>
>  that's a really good goal to have, i like it.
>
>  bear in mind though that this absolutely requires a "holistic"
> approach.  i found that one single thing out-of-place or overlooked
> can throw the entire scheme into chaos and require a redesign.
>
>  the point being, there: the prefixed-C *needs* to be considered at
> the same time as the 48-bit version.  they cannot be done separately.
>
>
> > Note that since C is almost entirely used already and basically no new
> > extensions will redefine it, we can redefine the prefixed version of C
> > however we want (basically new 32-bit instructions inspired by C, rather
> > than prefixed C instructions).
>
>  iiinteresting.... i like where that could lead.  let's see how far
> that gets, bear in mind that it means a heck of a lot of compiler
> work.  it basically means creating a fork of gcc and binutils, for
> example.  however what's good is, it's not changing the existing
> standard RV (32-bit or 16-bit) meanings; it's just additions.
>
> l.
>
> _______________________________________________
> libre-riscv-dev mailing list
> libre-riscv-dev at lists.libre-riscv.org
> http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev
>