[libre-riscv-dev] multi issue

[Luke Kenneth Casson Leighton]

On Fri, May 31, 2019 at 12:35 AM Jacob Lifshay <programmerjake at gmail.com> wrote:
>
> 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

 isamux=0,1 (or 2, or 3, or however many)

> 2. working with the encoding scheme from the risc-v spec

 isamux = 0

> 3. working with the encoding scheme proposed by clifford wolf

 isamux = 1

> 4. having a completely custom encoding scheme that's not compatible with
> either of the above encoding schemes (without changing the isamux setting)

 really does not work.

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

 isamux is, honestly, best avoided.  it's not really supposed to be
used for dynamic instruction-set switching (in the middle of a
function call for example), although in theory that's exactly what it
can be used for.

 it's really intended to stop the fights over instruction encoding
space, and for emergency specification modifications that would
otherwise wreak absolute havoc (basically destroy) the RISC-V
ecosystem and all confidence in its longevity.

 if you know of the compiler hell-on-earth in the fight over
instruction meaning in powerpc with respect to altivec and SSE both
using the same opcode space, which caused vendors to just say "screw
this, we're not going to bother with powerpc at all", you'll know
exactly why i came up with the isamux scheme.

> otherwise, I mildly prefer #3, since that actually has a spec that has
> space reserved for custom instructions.

 and would require going to a 64-bit encoding plus having to spend the
time (and money) doing yet another redesign, delaying the project yet
further.

 honestly at this stage i am inclined to completely ignore clifford's
proposed encoding scheme, not least because it will take at least
12-18 months to review and be ratified.

 which would make the need for isamux redundant, and we can - and
should - absorb the entirety of the 48 and 64 bit encoding space.

 if we're going with the 48 bit plan we need as many bits as prefix as
we can possibly get.

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

 that still leaves out predication, VL, and all the other features
that you and i spent several weeks designing and reviewing.

 that's also after i spent *several months* on the first revision of SV.

 we still have to look at how to reduce application size (I-cache
usage) by way of some sort of prefixing scheme, where the prefixing
(per register) applies for up to N instructions [truncated on
branches].

 that's a much higher priority than going back to the drawing board
*again* at this very late stage.

 and we still have to design the C version of SV, fitting into a
32-bit opcode [or decide whether to go with the
prefixing-that-applies-for-up-to-N-instructions-including-RVC-instructions]

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

 we have an awful lot else to get done: unless there is a clear and
present benefit to supporting 96 bit instructions, which can be
demonstrated - very quickly - to provide a *significant* code-size
reduction or other immediate benefit, i'm disinclined to recommend
spending the time on instruction lengths beyond 64 bit.

l.