(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