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

[Jacob Lifshay]

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.

>
>  (a) when using the CSR tables, the "default" may be over-ridden

we can set it so that the csr tables overrides the 64.

>  (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.

>  (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.

>
> 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.
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). Prefixed 48-bit instructions retain all the
extensibility of prefixing for new extensions.

>
> i would *really* really prefer that two *actual* instructions be used,
> one to do the mv and the other to do the sign/unsigned conversion [or
> that F.SGNetcetc be used].
>
> > The prefixed C instructions are supposed to expand 1:1 to 48-bit
> > instructions.
> > Planning on filling in more later.
>
>  ok cool.
>
> _______________________________________________
> libre-riscv-dev mailing list
> libre-riscv-dev at lists.libre-riscv.org
> http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev
>