removed duplicate from last week
[libreriscv.git] / meetings / sync_up / sync_up_2024-01-16.mdwn
index c5c9d346993bed18036de5959911f5f82253f831..e46cdc7713a8e8e6ab4b7c1dc37431113dc517a2 100644 (file)
@@ -64,24 +64,39 @@ Meeting notes:
 Jacob provided great help:
 
 ```
-maddedu would be useful if you have a packed 130 bit number in words where the non-msb words have 64-bits per word, the code you had last i checked instead has 44-bits per register used 
-this is the pattern used by the x + y remap mode...which isn't working yet, so svindex is suitable for now 
+maddedu would be useful if you have a packed 130 bit number
+in words where the non-msb words have 64-bits per word, the
+code you had last i checked instead has 44-bits per register used
+
+this is the pattern used by the x + y remap mode...which
+isn't working yet, so svindex is suitable for now
+
 maddedu also has carry-out, which you don't have here 
 so maddld is sufficient 
 yes 
 or the x + y remap once that's implemented 
 setup shapes with svindex insn 
-no, those are offset by the register specified in the sv. insn that remap is applied to 
+no, those are offset by the register specified in the sv. insn
+that remap is applied to
+
 svindex has element numbers, not x,y,z 
 x,y,z are used for other remap modes 
 yes, use the svindex insn 
 you specify the vector to load element numbers from in the svindex insn
-but they're accessed with element-sized chunks with element size determined by svindex 
+but they're accessed with element-sized chunks with element size
+determined by svindex
+
 svindex is if you want only one sv.maddld insn that loops 9 times 
 lemme move to my desktop so i can type easier... 
-ok, so you'll want a mod-3 matrix remap in one SVSHAPE register, and svindex remap in another SVSHAPE register 
-so run svshape to set the matrix remap, then run svindex to overwrite one remap... 
-svshape writes all 4 SVSHAPE registers, svindex can set the SVSHAPE register you specify 
+ok, so you'll want a mod-3 matrix remap in one SVSHAPE register,
+and svindex remap in another SVSHAPE register
+
+so run svshape to set the matrix remap, then run svindex
+to overwrite one remap...
+
+svshape writes all 4 SVSHAPE registers, svindex can set the SVSHAPE
+register you specify
+
 (or all 4, but you don't want that mode) 
 so test_1_sv_index is an example of what you want... 
 it sets SVSHAPE2 
@@ -91,13 +106,21 @@ see comments immediately above
 see line 396 of simplev.mdwn for how rmm is used 
 in openpower-isa.git 
 * **SVG** - GPR SVG<<2 to be used for Indexing 
-so if you want the indexes to be in r4,r5,r6... set SVG to 1 which comes out to r4 (1 << 2) 
+so if you want the indexes to be in r4,r5,r6... set SVG to 1 which
+comes out to r4 (1 << 2)
+
 yes, a value of zero means use element 0 
-so, if you want remap to use elements 1,2,3,4,5,6,7,8 set the first register to 0x0807060504030201 and use byte elwid 
+so, if you want remap to use elements 1,2,3,4,5,6,7,8 set the first
+register to 0x0807060504030201 and use byte elwid 
 the svindex elwid, not the sv.insn elwid, they're independent 
-svremap tells the following sv.insn which SVSHAPE[0-3] register to use for each operand 
-you don't want to set the SVSHAPE register directly, instead put the indexes in GPRs and svindex insn sets SVSHAPE to point to those GPRs 
-ok, so if your indexes are in r4,r5 with byte elements, afaict you want svindex 1, 1, 9, 3, 0, 1, 0 which sets byte mode, sets SVSHAPE1 
+svremap tells the following sv.insn which SVSHAPE[0-3]
+register to use for each operand
+
+you don't want to set the SVSHAPE register directly, instead put the
+indexes in GPRs and svindex insn sets SVSHAPE to point to those GPRs
+
+ok, so if your indexes are in r4,r5 with byte elements, afaict you
+want svindex 1, 1, 9, 3, 0, 1, 0 which sets byte mode, sets SVSHAPE1 
 ```
 
 
@@ -123,34 +146,8 @@ Announcement on
 
 # Jacob
 
-- so, not a whole lot of news from me, i fixed a
-extra-parenthesis-in-a-wrong-spot bug for dmitry and fixed a bug
-luke left, but didn't actually make any coding progress beyond
-that.
-
-During call, walked with Sadoon through assembler:
-
-```
-summary: discussing how to best split into sub-word chunks
-for poly1305
-> tbh dsrd isn't better than other shifts here
-It did help with taking the shift remainders and stitching them together which shortened the code quite a bit
-Also considering doing sv.dsrd instead of two dsrd's since we already use setvl=2 here
-> sv.dsrd is 8 bytes, just like 2x dsrd 
-But it's a good demo of setvl anyways
-> yeah, being a good demo doesn't mean there isn't a better demo 
-The better demo is the mul/adds ðŸ˜ƒ
-> try using a different register than r0, the simulator may be treating that like (RA|0) and just using r0 in both iterations... 
-```
-
-# Sadoon
-
-* Working through Poly1305 assembler.
-* Poly1305, [bug #1157](https://bugs.libre-soc.org/show_bug.cgi?id=1157)
-* Learned to use `dsrd`, done in first half of poly1305_blocks. Had issues with using `sv.dsrd` but it's kind of working now, will use it.
-* TODO: Make comments on bug #1157.
-
-* After that, work with the team on presentations as well as my own
+- suggested that presentations should be submitted much closer to fosdem (few days), since 2 weeks is too early. I will not be ready by 2 weeks before.
+- (didn't actually get around to during meeting:) not a whole lot, will start working on presentation, helped resolve issue with luke & dmitry, fixed some bugs for dmitry.
 
 [[!tag meeting2024]]
 [[!tag meeting_sync_up]]