[Libre-soc-dev] svp64

[Luke Kenneth Casson Leighton]

On 12/15/20, Luke Kenneth Casson Leighton <lkcl at lkcl.net> wrote:
> On 12/15/20, Jacob Lifshay <programmerjake at gmail.com> wrote:
>> On Mon, Dec 14, 2020, 20:02 Luke Kenneth Casson Leighton <lkcl at lkcl.net>
>> wrote:
>>
>>> 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 thought it was obvious
>
> not at all :)
>
> specifications are weird.  you have to step down at least 50 IQ
> points.  anything that requires "logical deduction" to work out is a
> red flag.  it's quite tedious, yet is critically important, so needs
> huge amounts of patience.
>
>
>
>> for(size_t i = 0; i < VL; i++) {
>>     if(CRs[(start_cr + i) % 64].lt) {
>>         rt[i] = ra[i] + rb[i];
>>     }
>> }
>
> brilliiant.  perfect example.  i added it to the page.
>
> ok so this now lets me know how you are redefining CRs: as
> "horizontally" numbered and starting from an 8 aligned boundary.
>
> without that <<3 on start_cr i had no way to know that you meant CR[6*8].
>
> until you provided this clear example i previously thought you meant
> start from CR[6+i]
>
>>>
>>> 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.
>>>
>>
>> CR[i] is the notation used by the OpenPower spec to refer to CR field #i,
>> so FP instructions with Rc=1 write to CR[1] aka SVCR1_000.
>
> ok so again, perfect example that clearly shows the relationship.
>
>>>
>>>
>>> > 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.
>>>
>>
>> I think it's a good idea to allow mixing them,
>
> let me think it through at the hardware level.  it also means finding
> one spare bit (see discussion format) which there *might* be in the
> reg vector specifier portion.  maybe.
>

there isn't..    not without reducing the scalar/vec augmenter from 3
bits down to only 2.

which would compromise twin predication in a different way.

arse.

always no good choices.

mfcr and mtcr in particular the thought there was to use one of the 3
bits to get better control over which parts of the 64 CRs are referred
to.

ah! something just occurred to me! the crweird ops might be
implementable entirely using data-dependent fffirst and predication.
i will find the relevant bugreport.



> that's LD ST mv extsw fcvt rsqrt fclass fsgn VSPLAT VEXTRACT VREDUCE
> VINSERT and a ton more, all of which involve moving and processing of
> data.

and i just realised, the immediate-based shift/mask operations, these
are 1 reg in 1 reg out, too.

   rlwimi RA,RS,SH,MB,ME (Rc=0)
   rlwimi. RA,RS,SH,MB,ME (Rc=1)

these are twin predicate candidates.

that makes them possible to include in the Monsta Shift Regista :)

l.