[Libre-soc-dev] [RFC] SVP64 on branch instructions

[lkcl]

On August 3, 2021 6:21:33 PM UTC, Jacob Lifshay <programmerjake at gmail.com> wrote:
>On Tue, Aug 3, 2021, 07:52 Luke Kenneth Casson Leighton <lkcl at lkcl.net>
>wrote:
>
>> drat. fricking gmail HTML Basic mode is barely useable. hit send
>> instead of save. grrr.
>>
>> ok.
>>
>> https://libre-soc.org/openpower/sv/branches/?updated
>>
>> i've added the example and created SVP64 hypothetical assembler.
>
>
>ok, 3 issues:
>1. CR fields set before a call and used after a call will not work, 

ah, i just noticed: you may have missed the significance of this:

   sv.crand CR80.v.SO, CR60.v.GT, CR80.v.LT # if = loop & pred_b
   f(CR80.v.SO)


that's taking the *LT* field from the CRv for b, and ANDing it with the *GT* field for a, and storing it in *a completely separate* CR field (SO).

thus whatever f() does there will be no impact.

technically, EABI definitions are out of scope at the moment, i would like to get the ISA design right and focus on that, first.

Vectors of CRs is not a concept that exists in EABI v2.0 so there is no existing EABI.  at some point we have to define one... i would prefer that not to be right now (it is a massive task of its own)



regarding overwrite and use of AA for alternative purposes, i realised after some thought that actually, combining the predicate mask with the Vector-Branch-CR test is not appropriate to do inside Branch itself.

the example above illustrates why: CR80.v.SO has bits *cleared* where the predicate mask is cleared, and the behaviour of predicate masks in operations is to act on elements where the bits are *set*.

altering Branch to cope with these inverted semantics, given its early-out capability, is completely inappropriate.

l.