[Libre-soc-dev] SVP64 bclrl

lkcl luke.leighton at gmail.com
Thu Apr 7 00:39:45 BST 2022

Paul, hi,

notes added on pseudocode for SVP64 sv.bclrl to the end of this page.

the basic fundamental principle of SVP64 is: you *do not* add Vector instructions, you wrap *scalar* instructions in a generic abstraction of a hardware for-loop, and keep interaction between the two to the absolute bare minimum (i.e. nil / nada / zip in 99.8% of cases).  in that way it becomes possible to do multi-issue, pipelining etc etc very cleanly, to a pre-existing scalar design.


basically if not adapted, then on the first time round the 0..VL-1 loop, the possibility for branching to LR exists (cond_ok=true) but let us say that for element 0 CR Field test the branch is not taken (cond_ok=false)

the next action according to the pseudocode: LK=1 so LR is *overwritten*

next time round the loop, ARRRGH: LR has just been destroyed, element 1 has cond_ok=true but branches not to the expected value of LR but instead to (CIA+4).

clearly that would be Bad, consequently a flag is needed which *only* sets LR if the branch actually takes place.

it goes without saying that a side-effect of the branch taking place would be that the SVP64 looping is terminated (early-exit)

regarding validation, we kinda learned a lot from writing unit tests in python, and can probably do something terrible like 9 nested for-loops in a single unit test.  dynamic generation of instructions and parameters is something we do all the time.

the insane way to do it would be to write out thousands of unit tests, hand-written assembler.

but... SVP64 Branches are... yeah.  a proper review on this is going to be essential.


More information about the Libre-soc-dev mailing list