(please do cc me to preserve thread, i am subscribed digest, thank you)

https://bugs.libre-soc.org/show_bug.cgi?id=615

summary: Libre-SOC needs an assembly syntax for SVP64 which is acceptable
for all parties, gcc and binutils primarily.

background: the Libre-SOC team, funded by NLnet, is adding Cray-style
Vectorisation (SVP64) to the OpenPOWER ISA under the guidance of the
OpenPOWER Foundation.  the work is to be submitted to the OPF ISA WG and
last week the first successful instructions were executed under both the
hardware and simulator.

we are therefore working on gcc and binutils and need guidance on what
assembly syntax is acceptable for SVP64.

extreme brief conceptual summary of SVP64: a Sub-Program-Counter which
walks sequentially through the regfile executing a *SCALAR* instruction
multiple times (0 to VectLen-1) before moving to the next instruction (PC+8)

this is done by prefixing *SCALAR* OpenPOWER v3.0B instructions
*UNMODIFIED* with 24 bits of additional Vectorisation Context, embedded
into a 32 bit (OpenPOWER v3.1) format.

we have a program already written which understands a draft SVP64 assembly
syntax, and we need help in evaluating it to find a form that is acceptable
to all (link at the bugreport at top of post).  examples:

sv.isel 64.v, 3, 2, 65.v

this embeds the ppc64 scalar v3.0B "isel" instruction (isel RT,RA,RB,BC) into
a Vectorisation Contexts that extends:

* BC as a Vector of Condition Register fields
* leaves RB and RA as scalar
* RT as a Vector INTs (GPR)

    sv.add. 5.v, 2.v, 1.

this one embeds "add Rc=1" into a Vectorisation Context that extends CR0,
RA and RT as Vector whilst leaving RB as Scalar

sv.extsw./pr=eq 5.v, 31

this one embeds "extsw" whilst making CR0 and RT Vectorised and RA scalar
but *also applies Condition Register Predication* to all Vectorised extsw
operations, using the CR field "eq" bit

Segher kindly already informed me a couple hours ago for example that using
"." in register names has to go.

the bottom line here is that we will soon be submitting upstream patches
and would like to engage in dialog with the right people to ensure that
what is submitted is understood, reviewed and acceptable to all.

thus we need guidance on what format of syntax will be acceptable, that
also correctly and successfully represents the SVP64 concept in a way that
makes sense.

i do appreciate that this will take time: SVP64 is conceptually
unprecedented in the history of computing.  the closest conceptual
equivalents are a hybrid of:

* Cray-style Vectors (without any actual Vector opcodes)
* Zero Overhead Loops from TI DSPs
* Intel MMX and OpenPOWER VSX reuse of the FP regfile to overlay registers
of completely different type and size.

whilst those are similar they are also completely wrong :)

any questions please do not hesitate to ask.

l.


-- 
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68

Reply via email to