[Libre-soc-dev] svp64

[Jacob Lifshay]

On Fri, Dec 18, 2020, 15:35 Luke Kenneth Casson Leighton <lkcl at lkcl.net>
wrote:

> status:
>
> * tidied up some tables, shrank their width so they don't scroll when
> edited
>
> * prepared for autogenerating tables, reg names and reg profiles
>
> * realised (finally) that the reg names were not those that were designed
> and discussed in detail 18 months ago.
>
> * realised that there is a real quick and dirty way to get binutils
> useable, a 32 bit svp64 0xNNNNNN instruction.
>

we can just use .long in an assembler macro for now...no binutils
modification needed.

>
> * also realised that data-dependent fail-on-first is going to screw us.  it
> is the only operation that *requires* VL to be allowed to be set to zero.
>  data-dependent LDST throws an exception but doea not set VL=0.
>
> * still do not know what the best arrangement for CRs is.
>

I'm for the arrangement that mirrors the register layout I picked for
FP/Int registers.

some of those things, the little tweaks, may not work out.  the
> vertical-horizontal CR naming may be too complex to implement.  and the
> fact that VL is not permitted to be set to zero (because there is not
> enough room in the SPRs to store 7 bits 0-64, only 6 bits to represent
> 1-64), this is a huge pain.
>
> the choices here are: abandon data-dependent ffirst or spend a huge amount
> of time reviewing the SPR layout.  neither are good choices when we are
> under time pressure.
>

I think we should just go with the option that SPRs are relatively cheap,
so we can just allocate 1 spr completely to VL (supporting 0 through 64
inclusive for now), since on future versions we'd want to support VL>64
anyway. This would also improve semantics for when we want to read VL after
a load ffirst or other non-setvl VL-adjustment instruction, avoiding the
need to mask/shift to extract the VL value.

Jacob