[Libre-soc-dev] efficient decoding algorithm for variable-length instructions

[Luke Kenneth Casson Leighton]

---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68

On Fri, Nov 27, 2020 at 9:59 AM Jacob Lifshay <programmerjake at gmail.com> wrote:
>
> On Thu, Nov 26, 2020, 12:32 Luke Kenneth Casson Leighton <lkcl at lkcl.net>
> wrote:
>
> > my biggest concern is that, knowing how long it's going to take, and
> > knowing *in advance* that a single EXTNNN *does not have enough bits*
> > to do *one* of P48 or P64, let alone share them all.
> >
>
> I never said put all 48 and 64-bit instructions in the same PO

ah ok, sorry misunderstanding

> (Primary
> Opcode), 48-bit instructions are in 1/2 of PO 0 (the other half is 32-bit)
> and SVP64 is in 1/2 (or less if we don't need it) of PO 1, shared with the
> Power v3.1 64-bit instructions.

no, no, no and no again.  we... cannot... share... v3.1... with....
SV... POs.  i have said it three times now.

1) the decoder complexity is simply too great,
2) there are not enough bits
3) we need the ENTIRETY of the available space - not "some subset
portion which happens not to conflict with v3.1B 64-bit"
4) the risk is too great that the OPF will want to add additional
prefixing into EXT001.

we do not know what IBM is planning for the future over the next 20+
years with EXT001 and the absolute last thing we need to be doing is
to start a fight with a multi-billion-dollar long-established company
over encoding space.

trying to do so is political suicide as well as technically
unfeasible, limiting for our goals and needs, insufficient for our
needs and severely restricts the top-end  speed of multi-issue designs
due to the complexity it adds to the decoder.

there *are* no upsides to this idea. it should have been clear the
first time that it should have been dropped on the first time that i
went through the analysis.


> >
> Some preliminary calculations show that, even assuming we can only use 1/4
> (? have to double check -- I know about 1/2 is available) of PO 1 (uses 8
> bits for opcode, leaving us 24-bits to play with), and assuming the 32-bit
> suffix is completely unmodified, we still have plenty of space:
> (ignoring load/store ops for now)

no we do not! i have said this at least 4 times now!  it is 27 bits
and that is the bare minimum!
please review again the page:
https://libre-soc.org/simple_v_extension/sv_prefix_proposal/

48 bit:
       Encoding 17 16 15 14 13 12 11:7

this is 11 bits (17 downto 7 inclusive).

64 bit: adds another 16 for a total of 27.

this is the total bitlength required and i have spent the ENTIRE past
15 months planning based on the assumption that we will be going with
these

i have not contacted NLnet to request additional budget for any
redesign of these original encodings

i have not planned at any time for a redesign of these original encodings.

if i had, i would have started that *15 months ago* and you would have
seen messages about it as i went through the redesign.

please understand and accept: we *do not have time or resources for a redesign*


> Instructions with 2 reg fields and wide swizzle:
> (2 bits for register field extension + 1 bit for vector/scalar) * 2 regs
>  + 2 bits for elwidth
>  + 2 bits for subvector length
>  + 3 bits for predication (sufficient for both CR and int reg predicate
> schemes)
>  + 11 bits for wide swizzle on 1 reg (only 6^4 combinations for 4 elements
> that can be one of xyzw01 -- 6^4 = 1296 < 2^11)
> = 24 bits

none of these include setting of the Vector Length (VL, MVL).  none of
them include extending the 7-bit register numbers to greater accuracy
that the SV-P48 encoding doesn't cover.

section 9
https://libre-soc.org/simple_v_extension/sv_prefix_proposal/

64-bit Instruction Encodings

VLtype.

we need *27 bits* for SV-P64 and 11 for SV-P48 otherwise that entire
page has to be abandoned and we add 3-4 months onto the timeline,
which jeapordises the entire project.

l.