programmerjake at gmail.com
Fri Dec 18 23:49:50 GMT 2020
On Fri, Dec 18, 2020, 15:35 Luke Kenneth Casson Leighton <lkcl at lkcl.net>
> * tidied up some tables, shrank their width so they don't scroll when
> * 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
> * 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
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.
More information about the Libre-soc-dev