From: Luke Kenneth Casson Leighton Date: Sun, 15 Oct 2023 17:42:49 +0000 (+0000) Subject: move daxpy to cookbook X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=64cd52761706500685f3cb51f35a3383c723a94f;p=libreriscv.git move daxpy to cookbook --- diff --git a/openpower/sv/cookbook/daxpy_example.mdwn b/openpower/sv/cookbook/daxpy_example.mdwn new file mode 100644 index 000000000..6316ca2ab --- /dev/null +++ b/openpower/sv/cookbook/daxpy_example.mdwn @@ -0,0 +1,138 @@ +# daxpy + +This is a standard textbook algorithm demonstration for Vector and SIMD ISAs. + +* + +Summary + +| ISA | total | loop | words | notes | +|-----|-------|------|-------|-------| +| SVP64 | 8 | 6 | 13 | 5 64-bit, 4 32-bit | +| RVV | 13 | 11 | 9.5 | 7 32-bit, 5 16-bit | +| SVE | 12 | 7 | 12 | all 32-bit | + +# c code + +``` + void daxpy(size_t n, double a, const double x[], double y[]) { + for (size_t i = 0; i < n; i++) + y[i] = a*x[i] + y[i]; + } +``` + +# SVP64 Power ISA version + +The first instruction is simple: the plan is to use CTR for looping. +Therefore, copy n (r5) into CTR. Next however, at the start of +the loop (L2) is not so obvious: MAXVL is being set to 32 +elements, but at the same time VL is being set to MIN(MAXVL,CTR). + +This algorithm +relies on post-increment, relies on no overlap between x and y +in memory, and critically relies on y overwrite. x is post-incremented +when read, but y is post-incremented on write. Load/Store Post-Increment +is a new Draft set of instructions for the Scalar Subsets, which save +having to pre-subtract an offset before running the loop. + +For `sv.lfdup`, RA is Scalar so continuously accumulates +additions of the immediate (8) but only *after* RA has been used +as the Effective Address. +The last write to RA is the address for +the next block (the next time round the CTR loop). +To understand this it is necessary to appreciate that +SVP64 is as if a sequence of loop-unrolled scalar instructions were +issued. With that sequence all writing the new version of RA +before the next element-instruction, the end result is identical +in effect to Element-Strided, except that RA points to the start +of the next batch. + +Use of Element-Strided on `sv.lfd/els` +ensures the Immediate (8) results in a contiguous LD +*without* modifying RA. +The first element is loaded from RA, the second from RA+8, the third +from RA+16 and so on. However unlike the `sv.lfdup`, RA remains +pointing at the current block being processed of the y array. + +With both a part of x and y loaded into a batch of GPR +registers starting at 32 and 64 respectively, a multiply-and-accumulate +can be carried out. The scalar constant `a` is in fp1. + +Where the curret pointer to y had not been updated by the `sv.lfd/els` +instruction, this means that y (r7) is already pointing to the +right place to store the results. However given that we want r7 +to point to the start of the next batch, *now* we can use +`sv.stfdup` which will post-increment RA repeatedly by 8 + +Now that the batch of length `VL` has been done, the next step +is to decrement CTR by VL, which we know due to the setvl instruction +that VL and CTR will be equal or that if CTR is greater than MAXVL, +that VL will be *equal* to MAXVL. Therefore, when `sv bc/ctr` +performs a decrement of CTR by VL, we an be confident that CTR +will only reach zero if there is no more of the array to process. + +Thus in an elegant way each RISC instruction is actually quite sophisticated, +but not a huge CISC-like difference from the original Power ISA. +Scalar Power ISA already has LD/ST-Update (pre-increment on RA): +we propose adding Post-Increment (Motorola 68000 and 8086 have had +both for decades). Power ISA branch-conditional has had Decrement-CTR +since its inception: we propose in SVP64 to add "Decrement CTR by VL". +The end result is an exceptionally compact daxpy that is easy to read +and understand. + +``` + # r5: n count; r6: x ptr; r7: y ptr; fp1: a + 1 mtctr 5 # move n to CTR + 2 .L2 + 3 setvl MAXVL=32,VL=CTR # actually VL=MIN(MAXVL,CTR) + 4 sv.lfdup *32,8(6) # load x into fp32-63, incr x + 5 sv.lfd/els *64,8(7) # load y into fp64-95, NO INC + 6 sv.fmadd *64,*64,1,*32 # (*y) = (*y) * (*x) + a + 7 sv.stfdup *64,8(7) # store at y, post-incr y + 8 sv.bc/ctr .L2 # decr CTR by VL, jump !zero + 9 blr # return +``` + +# RVV version + + +``` + # a0 is n, a1 is pointer to x[0], a2 is pointer to y[0], fa0 is a + li t0, 2<<25 + vsetdcfg t0 # enable 2 64b Fl.Pt. registers + loop: + setvl t0, a0 # vl = t0 = min(mvl, n) + vld v0, a1 # load vector x + c.slli t1, t0, 3 # t1 = vl * 8 (in bytes) + vld v1, a2 # load vector y + c.add a1, a1, t1 # increment pointer to x by vl*8 + vfmadd v1, v0, fa0, v1 # v1 += v0 * fa0 (y = a * x + y) + c.sub a0, a0, t0 # n -= vl (t0) + vst v1, a2 # store Y + c.add a2, a2, t1 # increment pointer to y by vl*8 + c.bnez a0, loop # repeat if n != 0 + c.ret # return +``` + +# SVE Version + +``` + 1 // x0 = &x[0], x1 = &y[0], x2 = &a, x3 = &n + 2 daxpy_: + 3 ldrswx3, [x3] // x3=*n + 4 movx4, #0 // x4=i=0 + 5 whilelt p0.d, x4, x3 // p0=while(i++ - -Summary - -| ISA | total | loop | words | notes | -|-----|-------|------|-------|-------| -| SVP64 | 8 | 6 | 13 | 5 64-bit, 4 32-bit | -| RVV | 13 | 11 | 9.5 | 7 32-bit, 5 16-bit | -| SVE | 12 | 7 | 12 | all 32-bit | - -# c code - -``` - void daxpy(size_t n, double a, const double x[], double y[]) { - for (size_t i = 0; i < n; i++) - y[i] = a*x[i] + y[i]; - } -``` - -# SVP64 Power ISA version - -The first instruction is simple: the plan is to use CTR for looping. -Therefore, copy n (r5) into CTR. Next however, at the start of -the loop (L2) is not so obvious: MAXVL is being set to 32 -elements, but at the same time VL is being set to MIN(MAXVL,CTR). - -This algorithm -relies on post-increment, relies on no overlap between x and y -in memory, and critically relies on y overwrite. x is post-incremented -when read, but y is post-incremented on write. Load/Store Post-Increment -is a new Draft set of instructions for the Scalar Subsets, which save -having to pre-subtract an offset before running the loop. - -For `sv.lfdup`, RA is Scalar so continuously accumulates -additions of the immediate (8) but only *after* RA has been used -as the Effective Address. -The last write to RA is the address for -the next block (the next time round the CTR loop). -To understand this it is necessary to appreciate that -SVP64 is as if a sequence of loop-unrolled scalar instructions were -issued. With that sequence all writing the new version of RA -before the next element-instruction, the end result is identical -in effect to Element-Strided, except that RA points to the start -of the next batch. - -Use of Element-Strided on `sv.lfd/els` -ensures the Immediate (8) results in a contiguous LD -*without* modifying RA. -The first element is loaded from RA, the second from RA+8, the third -from RA+16 and so on. However unlike the `sv.lfdup`, RA remains -pointing at the current block being processed of the y array. - -With both a part of x and y loaded into a batch of GPR -registers starting at 32 and 64 respectively, a multiply-and-accumulate -can be carried out. The scalar constant `a` is in fp1. - -Where the curret pointer to y had not been updated by the `sv.lfd/els` -instruction, this means that y (r7) is already pointing to the -right place to store the results. However given that we want r7 -to point to the start of the next batch, *now* we can use -`sv.stfdup` which will post-increment RA repeatedly by 8 - -Now that the batch of length `VL` has been done, the next step -is to decrement CTR by VL, which we know due to the setvl instruction -that VL and CTR will be equal or that if CTR is greater than MAXVL, -that VL will be *equal* to MAXVL. Therefore, when `sv bc/ctr` -performs a decrement of CTR by VL, we an be confident that CTR -will only reach zero if there is no more of the array to process. - -Thus in an elegant way each RISC instruction is actually quite sophisticated, -but not a huge CISC-like difference from the original Power ISA. -Scalar Power ISA already has LD/ST-Update (pre-increment on RA): -we propose adding Post-Increment (Motorola 68000 and 8086 have had -both for decades). Power ISA branch-conditional has had Decrement-CTR -since its inception: we propose in SVP64 to add "Decrement CTR by VL". -The end result is an exceptionally compact daxpy that is easy to read -and understand. - -``` - # r5: n count; r6: x ptr; r7: y ptr; fp1: a - 1 mtctr 5 # move n to CTR - 2 .L2 - 3 setvl MAXVL=32,VL=CTR # actually VL=MIN(MAXVL,CTR) - 4 sv.lfdup *32,8(6) # load x into fp32-63, incr x - 5 sv.lfd/els *64,8(7) # load y into fp64-95, NO INC - 6 sv.fmadd *64,*64,1,*32 # (*y) = (*y) * (*x) + a - 7 sv.stfdup *64,8(7) # store at y, post-incr y - 8 sv.bc/ctr .L2 # decr CTR by VL, jump !zero - 9 blr # return -``` - -# RVV version - - -``` - # a0 is n, a1 is pointer to x[0], a2 is pointer to y[0], fa0 is a - li t0, 2<<25 - vsetdcfg t0 # enable 2 64b Fl.Pt. registers - loop: - setvl t0, a0 # vl = t0 = min(mvl, n) - vld v0, a1 # load vector x - c.slli t1, t0, 3 # t1 = vl * 8 (in bytes) - vld v1, a2 # load vector y - c.add a1, a1, t1 # increment pointer to x by vl*8 - vfmadd v1, v0, fa0, v1 # v1 += v0 * fa0 (y = a * x + y) - c.sub a0, a0, t0 # n -= vl (t0) - vst v1, a2 # store Y - c.add a2, a2, t1 # increment pointer to y by vl*8 - c.bnez a0, loop # repeat if n != 0 - c.ret # return -``` - -# SVE Version - -``` - 1 // x0 = &x[0], x1 = &y[0], x2 = &a, x3 = &n - 2 daxpy_: - 3 ldrswx3, [x3] // x3=*n - 4 movx4, #0 // x4=i=0 - 5 whilelt p0.d, x4, x3 // p0=while(i++