[Libre-soc-dev] svp64

[Luke Kenneth Casson Leighton]

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.


> however supporting a reduced
> set of predicates to save instruction encoding bits is a valid reason to
> define a smaller predicate field just for twin predication.

no, definitely not.  penalising twin predication "punishes" too large
a swathe of the SV ISA.

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.

it's critically important to view twin predication as a fundamental
part of the ISA.  otherwise it is necessary to take up yet more time
completely designing replacements for V* operations.

>>
>> 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.
>>
>
> The explicit formula is bit concatenation -- N is the most significant
> bits, M is the least significant bits, with the intention that future
> regfile expansions will tack more bits on the LSB end of M, hence why the
> mnemonics use binary instead of decimal for M.

excellent. that makes sense. can you put a note to that effect? keep
it short though, ultimately we want... how can i put it... "alert,
concise phrases".

Alain will be the one deciding the actual words to go into the spec.
he needs to have this completely clear before that can happen.

l.