[libre-riscv-dev] multi issue

[Jacob Lifshay]

On Thu, May 30, 2019, 16:15 Luke Kenneth Casson Leighton <lkcl at lkcl.net>
wrote:

> On Fri, May 31, 2019 at 12:08 AM Jacob Lifshay <programmerjake at gmail.com>
> wrote:
> >
> > On Thu, May 30, 2019, 16:04 Luke Kenneth Casson Leighton <lkcl at lkcl.net>
> > wrote:
> >
> > > On Thu, May 30, 2019 at 11:58 PM Jacob Lifshay <
> programmerjake at gmail.com>
> > > wrote:
> > >
> > > > we will additionally need to decide which variety of long instruction
> > > > encoding we will support: the encoding in the original spec or the
> new
> > > > encoding proposed by clifford wolf.
> > >
> > >  both, by using the mvendorid-marchid-isamux scheme that i created
> > > last year.  the isamux scheme is identical to that used by PowerPC to
> > > dynamically swap from big-endian to little-endian, generalised.
> > >
> > >  that's if there are any instructions in the extended format that we
> > > actually need.
> > >
> > Our custom 48 and 64-bit instructions will need to fit in the encoding
> > scheme.
>
>  no, it doesn't.  that's what mvendorid-marchid-isamux is very
> specifically designed *not* to be forced to have to conform to.
>
Assuming we have any instructions larger than 32-bits, we will need to
define how they fit into a large instruction encoding, for which we can
pick one of:
1. working with both encoding schemes
2. working with the encoding scheme from the risc-v spec
3. working with the encoding scheme proposed by clifford wolf
4. having a completely custom encoding scheme that's not compatible with
either of the above encoding schemes (without changing the isamux setting)

I think #4 is not a viable option and would prefer #1 if we can accept the
extra decoder complexity and we plan on having isamux support at all.
otherwise, I mildly prefer #3, since that actually has a spec that has
space reserved for custom instructions.

>
> the discussion was documented here:
> https://libre-riscv.org/isa_conflict_resolution/
>
> > > > slots then can be then enqueued into the instruction queue.
> > >
> > that was intended to be the pre-vectorization queue.
>
>  oh ok.
>
>  one trick is to map 16-bit to 32-bit equivalents.  it gives a uniform
> instruction size.
>
I think we should define a custom 64-bit encoding that has the full 7-bit
register fields (maybe leaving space for 8-bit fields as a future
extension) and embeds all supported 48-bit and shorter instructions in it.
the custom 48-bit instructions would then be semi-compressed SimpleV
instructions in the style of the C extension and we would have custom
32-bit instructions that are fully-compressed SimpleV instructions.

This way, all instructions could be decoded to 64-bit instructions of
uniform length, with mostly-uniform register fields, assuming we don't
support 96-bit load-immediate instructions.

>
> l.
>
> _______________________________________________
> libre-riscv-dev mailing list
> libre-riscv-dev at lists.libre-riscv.org
> http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev
>