[Libre-soc-dev] svp64

[Luke Kenneth Casson Leighton]

On 12/15/20, Jacob Lifshay <programmerjake at gmail.com> wrote:
> I updated the WIP svp64 spec to add an alternative CR register naming
> scheme that is more consistent with the integer/fp register naming
> scheme. Vectorized instructions would count CRs in SVCR* order, the
> initial CR register is TBD but could be CR0 or still CR6.

starting from just above the callee saved (CR5) would, using vertical
increments, mean that scalar CR0 and CR1 were not overwritten for at
least VL=25.

> I also added
> a spec for how the SV CRs would map to SPR fields.

ok yes this is needed.  the mapping of naming, how the SPRs relate, is
however still not clear.  SVCR_NN_MM i am completely unable to tell
what the relationship is to a linear numbering of CRs from 0 to 63.

i find i am looking at a confusing table of 64 entries that tell me
nothing about how to implement them.

thus in the predication table, without that relationship clearly
expressed, CR[i] is meaningless.


> Also, I responded to some of the things on the svp64 discussion page.

and, whoops, reverted the table which i'd deliberately split, to
indicate that the MSB should be removed, as described in the TODO that
i had added above it.

i do not think it is a good idea to allow mixing of INT and CR
predication for Twin Predication.

thus there only need be one mode select bit and 1x 3 bit fields or 2x
3 bit dields, the mode bit applying to both.

still TODO, an algorithm describing how the names are derived.
INT_NN_MM needs an explicit formula showing how the name relates to
the ssequential regs GPR[0..127] and the same for FPR and the 4 64 bit
CRs.

it needs to be made explicitly clear, because this is a specification.

i get the c++ pseudocode: it however doesn't make clear how the linear
numbering relates to FPR_NN_MM

l.