[this](https://lists.libre-soc.org/pipermail/libre-soc-dev/2024-January/005912.html)
email thread. Points to be discussed:
-* TODO: Will be filled in the next few days
-* ...
+* Due to length, moved to separate discussion page:
+[[discussion/sync_up_2024-01-16_discussion]]
After meeting discussion, points agreed upon will be documented
in the wiki.
[bug #1166](https://bugs.libre-soc.org/show_bug.cgi?id=1166),
[bug #1167](https://bugs.libre-soc.org/show_bug.cgi?id=1167)
-# Andrey
+# Dmitry
-- Came back from holiday yesterday.
-- [Bug #1048](https://bugs.libre-soc.org/show_bug.cgi?id=1048),
- Cleaning up ls011 by using inline ld/st imports.
+- [bug #980](https://bugs.libre-soc.org/show_bug.cgi?id=980)
+ - Still some work required. A few days until
+ - Two types of pseudocode: instructions, python functions
+ - For now provides prototypes for many features
-# Jacob
+# Sadoon
-- 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.
+- [bug #1157](https://bugs.libre-soc.org/show_bug.cgi?id=1157)
+ - walkthrough code during meeting.
-During call, walked with Sadoon through assembler:
+Jacob provided great help:
```
-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...
+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
+
+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
+
+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
+
+(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
+encoded in the LSB 2 bits of the operand that's 14
+the rmm operand
+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)
+
+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
+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
```
-# 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.
+# Andrey
+
+- Recovering from a cold (worst of it already happened on the weekend,
+now mostly blocked nose).
+- [Bug #1048](https://bugs.libre-soc.org/show_bug.cgi?id=1048),
+ Luke and Jacob made comments regarding the summary, I'll work on it
+ when available.
+- Checked that RfP for Red was paid, so added extra commentary on IRC
+(continued from walkthrough Luke and I did last month).
+ - [[HDL_workflow/rfp_submission_guide]]
+ - Additional
+[IRC messages](https://libre-soc.org/irclog/latest.log.html#t2024-01-15T17:58:17)
+- Created a discussion page for the "git commit frequency" topic that
+came up last week: [[discussion/sync_up_2024-01-16_discussion]].
+Announcement on
+[IRC](https://libre-soc.org/irclog/latest.log.html#t2024-01-15T19:05:24)
+- TODO:
+ - Change my main email from technepisteme.xyz to the gmail one.
+ - Redo the calendar invites for the sync-up meetings.
+
+# Jacob
-* 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]]