(no commit message)
[libreriscv.git] / simple_v_extension / vector_ops.mdwn
index aa4b3f0018b5e4ab9da892ab3213f0f9b62463d2..394e5b24d3f477e86bd165615335afe1a9881c2d 100644 (file)
@@ -8,10 +8,25 @@ Normally in SV all operations are scalar and independent, and the operations on
 
 In this extension, the subvector itself is typically the unit, although some operations will work on scalars or standard vectors as well, or the result is a scalar that is dependent on all elements within the vector arguments.
 
+However given that some of the parameters are vectors (with and without SUBVL set), and some are scalars (where SUBVL will not apply), some clear rules need to be defined as to how the operations work.
+
 Examples which can require SUBVL include cross product and may in future involve complex numbers.
 
 ## CORDIC
 
+* SUBVL=2, vd, vs; SUBVL ignored on beta.
+* VL nonzero ok.  beta as scalar ok (applies across all vectors)
+* non vector args vd, vs, or SUBVL!=2 reserved.
+
+6 opcode options (fmt3):
+
+* CORDIC.lin.rot vd, vs, beta
+* CORDIC.cir.rot vd, vs, beta
+* CORDIC.hyp.rot vd, vs, beta
+* CORDIC.lin.vec vd, vs, beta
+* CORDIC.cir.vec vd, vs, beta
+* CORDIC.hyp.vec vd, vs, beta
+
 CORDIC is an extremely general-purpose algorithm useful for a huge number
 of diverse purposes.  In its full form it does however require quite a
 few parameters, one of which is a vector, making it awkward to include in
@@ -22,43 +37,21 @@ may also be run in either "vector" mode or "rotation" mode.  See [[discussion]]
 CORDIC can also be used for performing DCT.  See
 <https://arxiv.org/abs/1606.02424>
 
-vx, vy = CORDIC(vx, vy, coordinate\_mode, beta)
-
-     int i = 0;
-     int iterations = 0; // Number of times to run the algorithm
-     float arctanTable[iterations]; // in Radians
-     float K = 0.6073; // K
-     float v_x,v_y; // Vector v; x and y components
-
-     for(i=0; i < iterations; i++) {
-        arctanTable[i] = atan(pow(2,-i));
-     }
-
-     float vnew_x;   // To store the new value of x;
-     for(i = 0; i < iterations; i++) {
-         // If beta is negative, we need to do a counter-clockwise rotation:
-         if( beta < 0) {
-            vnew_x = v_x + (v_y*pow(2,-i)); 
-            v_y -= (v_x*pow(2,-i));  
-            beta += arctanTable[i]; 
-         }
-         // If beta is positive, we need to do a clockwise rotation:
-         else {
-            vnew_x = v_x - (v_y*pow(2,-i));
-            v_y += (v_x*pow(2,-i));
-            beta -= arctanTable[i];
-         }
-         v_x = vnew_x;
-     }
-     v_x *= K;
-     v_y *= K;
+CORDIC has several RADIX-4 papers for efficient pipelining.  Each stage requires its own ROM tables which can get costly.  Two combinatorial blocks may be chained together to double the RADIX and halve the pipeline depth, at the cost of doubling the latency.
+
+Also, to get good accuracy, particularly at the limits of CORDIC input range, requires double the bitwidth of the output in internal computations. This similar to how MUL requires double the bitwidth to compute.
 
 Links:
 
 * <http://www.myhdl.org/docs/examples/sinecomp/>
+* <https://www.atlantis-press.com/proceedings/jcis2006/232>
 
 ## Vector cross product
 
+SUBVL=3, all regs. VL nonzero produces multiple vd results.
+
+* VCROSS vd, vs1, vs1
+
 Result is the cross product of x and y, i.e., the resulting components are, in order:
 
     x[1] * y[2] - y[1] * x[2]
@@ -78,8 +71,22 @@ Pseudocode:
     vec3 p = t3 * t4;
     vec3 cross = t1 * t2 - p;
 
+Assembler:
+
+    fpermute,2130 F4, F1
+    fpermute,1320 F5, F1
+    fpermute,2130 F6, F2
+    fpermute,1320 F7, F2
+    fmul F8, F5, F6
+    fmulsub F3, F4, F7, F8
+
 ## Vector dot product
 
+* SUBVL ignored on rd.  SUBVL=2,3,4 vs1,vs2, if all vectors, multiple results generated. If rd scalar, only first (unpredicated) SUBVector is used.
+* rd=scalar, SUBVL=1 and vs1, vs2=vec will produce one scalar result. Predication allowed on src vectors.
+
+* VDOT rd, vs1, vs2
+
 Computes the dot product of two vectors. Internal accuracy must be
 greater than the input vectors and the result.
 
@@ -98,14 +105,35 @@ Pseudocode in c:
         return result;
     }
 
+## Vector Normalisation (not included)
+
+Vector normalisation may be performed through dot product, recip square root and multiplication:
+
+    fdot F3, F1, F1 # vector dot with self
+    rcpsqrta F3, F3
+    fscale,0 F2, F3, F1
+
+Or it may be performed through VLEN (Vector length) and division.
+
 ## Vector length
 
+* rd=scalar, vs1=vec (SUBVL=1)
+* rd=scalar, vs1=vec (SUBVL=2,3,4) only 1 (predication rules apply)
+* rd=vec, SUBVL ignored; vs1=vec, SUBVL=2,3,4
+* rd=vec, SUBVL ignored; vs1=vec, SUBVL=1: reserved encoding.
+
+* VLEN rd, vs1
+
 The scalar length of a vector:
 
     sqrt(x[0]^2 + x[1]^2 + ...).
 
+One option is for this to be a macro op fusion sequence, with inverse-sqrt also being a second macro op sequence suitable for normalisation.
+
 ## Vector distance
 
+* VDIST rd, vs1, vs2
+
 The scalar distance between two vectors. Subtracts one vector from the
 other and returns length:
 
@@ -113,6 +141,8 @@ other and returns length:
 
 ## Vector LERP
 
+* VLERP rd, vs1, rs2 # SUBVL=2: vs1.v0 vs1.v1
+
 Known as **fmix** in GLSL.
 
 <https://en.m.wikipedia.org/wiki/Linear_interpolation>
@@ -134,8 +164,10 @@ Pseudocode:
 
 ## Vector SLERP
 
+* VSLERP vd, vs1, vs2, rs3
+
 Not recommended as it is not commonly used and has several trigonometric
-functions.
+functions, although CORDIC in vector rotate circular mode is designed for this purpose. Also a costly 4 arg operation.
 
 <https://en.m.wikipedia.org/wiki/Slerp>
 
@@ -278,3 +310,19 @@ The technique is outlined in a paper as being applicable to 3D:
 # Expensive 3-operand OP32 operations
 
 3-operand operations are extremely expensive in terms of OP32 encoding space.  A potential idea is to embed 3 RVC register formats across two out of three 5-bit fields rs1/rs2/rd
+
+Another is to overwrite one of the src registers.
+
+# Opcode Table
+
+TODO
+
+# Links
+
+* <http://lists.libre-riscv.org/pipermail/libre-riscv-dev/2019-September/002736.html>
+* <http://lists.libre-riscv.org/pipermail/libre-riscv-dev/2019-September/002733.html>
+* <http://bugs.libre-riscv.org/show_bug.cgi?id=142>
+
+Research Papers
+
+* <https://www.researchgate.net/publication/2938554_PLX_FP_An_Efficient_Floating-Point_Instruction_Set_for_3D_Graphics>