Tuesday, 2022-09-06

*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC00:49
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc00:50
lkclsadoon[m] (for when you're awake) - one possibility is that the "dependency install" scripts built-in to cvc5 are not "reproducible"01:34
programmerjakei just checked a bunch of the auto download scripts, all the scripts i checked should be reproducable -- they either fetch a particular git commit or a particular released version with a hardcoded checksum01:54
programmerjakesadoon: when you have a chance, can you post the build error cvc5 gives? maybe via a link to some kind of pastebin service if it's more than a few lines02:01
sadoon[m]lkcl: programmerjake: it built fine on x86 btw06:03
sadoon[m]I'll check once I am back home, I would be able to check now but my "ssh -R" setup is giving me a "connection refused"06:03
programmerjakek, thx06:05
*** markos <markos!~Konstanti@> has quit IRC06:27
*** markos <markos!~Konstanti@> has joined #libre-soc06:40
sadoon[m]so I had the chance to go back home and set up ssh to keep-alive since my work is close to home and I have a "field engineer" type of thing today08:09
sadoon[m]let me see what the error was08:09
sadoon[m]On a side note it's deeply ironic that https://github.com/Nheko-Reborn/nheko works perfectly on ppc64le and is crashing on x86_6408:09
ghostmansd> <lkcl> ghostmansd, is this correct? (git diff follows)08:14
ghostmansdTotally not, should be the other way round.08:14
ghostmansd[m]Hm. On my dis branch, things are fine.08:15
ghostmansd[m]On master it's correct too.08:15
ghostmansd[m]This "name" property represents the actual name of the operand we're dealing with.08:16
ghostmansd[m]The rest of the information is supplied in the disassembly.08:16
ghostmansd[m]Or well, not name of the operand, but, rather, a real field benind it.08:17
sadoon[m]Good news, cvc5 built just fine after I deleted the "src" directory, strange08:36
*** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC08:37
programmerjakewell, at least it's fixed :)08:37
programmerjakemaybe you tried it before I fixed it on ppc64le (>1mo ago iirc) and that left some broken files lying around...08:38
sadoon[m]nah it's a new git clone, it probably failed somewhere and then failed again because the directories are already there08:42
sadoon[m]that's the error I got before deleting it just now08:42
*** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc08:50
ghostmansdFuuuuuck. I think I found what went wrong with lwarx.09:04
ghostmansdWe don't have an entry for this in markdown. No, really, at all.09:05
ghostmansdAlso, it looks like binutils extra2 remap is broken. Decoding, however, works (but that one doesn't really goes into analyzing the remapped parts yet).09:12
ghostmansdpysvp64dis can already correctly guess extra2 though (example for lwzu):09:13
ghostmansd    RT09:13
ghostmansd        0101009:13
ghostmansd        [6, 7, 8, 9, 10]09:13
ghostmansd        extra2[0]09:13
ghostmansd    D09:13
ghostmansd        000000000000000009:13
ghostmansd        [16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31]09:13
ghostmansd    RA09:13
ghostmansd        0000009:13
ghostmansd        [11, 12, 13, 14, 15]09:13
ghostmansd        extra2[2]09:13
ghostmansdSo, I guess, this will be fixed in binutils when we migrate to new fields, since remap will deal with svp64_insn directly.09:17
*** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC09:21
*** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc09:33
sadoon[m]I assume ppc64-gdb-gcc should not work and is not needed on ppc64le right?09:37
ghostmansdWe deal with LE only for now.09:54
programmerjakelkcl: i got fed up with pandoc and line breaks in table cells, so I just added code to pandoc_img.py to convert <br> to latex \\10:19
programmerjake(sorry matrix users, it was `<br>` to `\\`, matrix decided to interpret that)10:21
*** octavius <octavius!~octavius@> has joined #libre-soc11:36
lkclghostmansd, lwarx - ah, yes, no you're right.11:42
lkcland there's a reason for that: if you look at the pseudocode it has concepts that aren't in ISACaller11:42
lkclso yes, please just leave it for now11:42
lkclprogrammerjake, good enough. there's quite a lot of hacks like that11:43
lkclghostmansd, dis branch produces:11:45
lkcl    spec11:45
lkcl        bcl BO,BI,BD (AA=0 LK=1)11:45
lkclwhich is wrong11:45
lkclmaster branch produces:11:45
ghostmansd[m]Ah you mean the argument name in spec11:45
lkcl09 08 00 40    bcl 0,0,0x80811:45
lkcl    spec11:45
lkcl        bcl BO,BI,BD (AA=0 LK=1)11:45
lkclwhich is wrong11:45
ghostmansd[m]Ok gotcha11:45
lkcltarget_addr branch produces11:45
ghostmansd[m]Yeah I think I know how to refactor this11:45
lkcllkcl@fizzy:~/src/libresoc/openpower-isa/src/openpower$ echo -n -e '\x09\x08\x00\x40' | pysvp64dis -v11:45
lkcl09 08 00 40    bcl 0,0,0x80811:45
lkcl    spec11:45
lkcl        bcl BO,BI,target_addr (AA=0 LK=1)11:45
ghostmansd[m]Yeah yeah11:46
lkclbut.. ahhh yes11:46
ghostmansd[m]That's due to custom name property11:46
lkclit also does11:46
lkcl    target_addr11:46
lkcl        0000100000001011:46
lkcl        [16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29]11:46
lkcl        target_addr = EXTS(BD || 0b00))11:46
lkcl   BD11:46
lkcl      0001000....11:46
lkclghostmansd[m], i'll add some dummy pseudocode for lwarx/lbarx/lharx11:48
programmerjakelkcl: i added support for <sup>/<sub>/<small> so the new math stuff looks much better in the pdf11:50
lkclprogrammerjake, ahh goood11:53
lkclyeah those look a hell of a lot better11:54
lkclghostmansd[m], done.  called fixedsync.mdwn12:01
lkclyou'll need to re-run pywriter12:01
ghostmansdlkcl, thank you!12:07
ghostmansdnah, actually I won't :-)12:08
ghostmansdI'm dealing with vanilla mdwn via pagereader12:08
ghostmansdfor disassembly there's no need, only for simulation12:08
lkclyou still need the actual definition (XXXX-Form, register declarations)12:09
lkclthat's why i added it12:09
lkclotherwise sv/trans/svp64.py - when it's made automated - can't know the Form or the regs either12:09
lkclhmm hmm irony: for assembly you need *another* expression involving target_addr12:11
lkclBD = target_addr>>212:11
ghostmansdYes :-)12:11
ghostmansdI've been thinking of adding assembly method to operands12:11
ghostmansdFuck that's what I've been talking about12:12
ghostmansdWhy in order to run pywriter do I need nmigen?12:12
ghostmansdAt one point or another, we'll have to think about splitting the components and putting components into reservation12:12
ghostmansdFor now I'll do it on talos, but frankly running pysvp64dis on my laptop is much more convenient12:13
*** octavius <octavius!~octavius@> has quit IRC12:13
lkclbecause a function called create_args() is hack-pulled in from ISACaller12:14
lkclyou shouldn't be attempting to do anything in openpower-isa without having nmigen installed, anyway.12:15
lkclwithout it you can't run any unit tests at all12:15
lkclthe decoupling at this point is a major rewrite of the entirety of ISACaller12:16
ghostmansdActually I could have used it without nmigen, because neither markdown nor csv nor anything in insndb needs nmigen at all.12:16
ghostmansdBut right now I can't.12:16
ghostmansdAnyway, this is a random rant, you can ignore it.12:16
ghostmansdI seemply dislike dependencies where none are needed.12:17
ghostmansdFuck you see the rage, I cannot even write w/o grammer errars :-)12:17
ghostmansdOK rant ended, running pywriter on talos12:18
lkclif you move create_args() to somewhere else it *may* work12:18
lkcluh-huhn, i totally get that one.12:18
ghostmansdNah, fuck it, I don't have time for that12:18
lkclack. i may try it some time12:19
ghostmansdOK none surprises, lwrax didn't magically started working yet, checking what's wrong12:19
lkclit's lwarx12:19
ghostmansdyeah sorry, typo12:19
lkclhmmm there may not exist a correct fields.txt entry12:19
lkcl1 sex12:19
lkcl1 sec12:19
lkclnow you got _me_ mistyping!12:19
ghostmansdno it's opcodes12:20
ghostmansdthe error's here12:20
ghostmansddigging where "here" exactly12:20
ghostmansdOK lwarx is in database12:21
lkclEH in fields.txt is correct12:21
lkclbtw you saw the "echo -e -n '\xNN' | pysvp64dis -v" example i gave?12:22
ghostmansdlwarx FieldsOpcode(value=0x7c000028, mask=0xfc0007fe) 0x7d4b602812:22
ghostmansdnope, missed it12:22
lkclcan you give... ahhh i should be able to create one...12:22
lkclwhen you do status reports can you put the repro command into the bugtracker comment, in that form?12:23
ghostmansdAh OK12:23
lkclecho -n -e '\x28\x60\x4b\x7d' | pysvp64dis -v12:23
ghostmansdI doing it the other way, building some crap with binutils, then objcopy, then scp it to talos where I run pysvp64dis12:23
ghostmansdBut your way is better as repro12:23
lkcl echo -n -e '\x7d\x4b\x60\x28' | pysvp64dis -v12:24
lkcl7d 4b 60 28    cmpli 0,1,r0,1932512:24
lkclwhoops :)12:24
lkclsuccessfully decompiled, too!12:24
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC12:25
ghostmansdyou know what?12:25
lkclbinutils/objcopy would work too, as long as there's a repro12:26
ghostmansdwe even managed to recognize the opcode12:26
ghostmansdso it's somewhere on the later stage!12:26
ghostmansdOK this makes the stuff simpler12:26
ghostmansdEH field12:27
ghostmansdSomething's wrong with that12:27
lkclEH Field is in X-Form (fields.txt)12:27
lkcl# 1.6.7 X-FORM12:28
lkcl    |0     |6 |7|8|9  |10  |11|12|13  |15|16|17     |20|21    |31  |12:28
lkcl    | PO   |       RT      |    RA       |    RB       |   XO |EH  |12:28
lkcl    EH (31)12:28
ghostmansd1 sec12:28
lkcl        Formats: X12:28
ghostmansdhere are the fields I see for lwarx12:29
ghostmansdfields={'A': [6], 'BF': [6, 7, 8], 'BFA': [11, 12, 13], 'BO': [6, 7, 8, 9, 10], 'CT': [7, 8, 9, 10], 'DCMX': [9, 10, 11, 12, 13, 14, 15], 'DRM': [18, 19, 20], 'E': [16], 'E_1': [12, 13, 14, 15], 'EO': [11, 12], 'EO_1': [11, 12, 13, 14, 15], 'EX': [31], 'FC': [16, 17, 18, 19, 20], 'FRA': [11, 12, 13, 14, 15], 'FRAp': [11, 12, 13, 14, 15], 'FRB': [16, 17, 18, 19, 20], 'FRBp': [16, 17, 18, 19, 20], '12:29
lkclok... ehn?? moo?12:29
ghostmansdAh well these are all fields for form12:30
ghostmansdBut still, there's no EH12:30
ghostmansdAnd still EH is exactly the operand mentioned12:30
ghostmansdRecord(name='lwarx', section=Section(path=PosixPath('minor_31.csv'), opcode=Opcode(value=0x0000001f, mask=0x0000001f), bitsel=[21:30], suffix=0b101, mode=<Mode.INTEGER: 1>), ppc=PPCMultiRecord({PPCRecord(opcode=IntegerOpcode(value=0x00000014, mask=0x00000014), comment='lwarx', flags=Flags({'cry out', '32b', 'rsrv', 'sgl pipe', 'sgn', 'inv A', 'BR', 'sgn ext', 'lk', 'inv out'}), comment2='', functi12:31
ghostmansdfucking fucking IRC12:31
lkcltry not to flood libera :)12:32
ghostmansdhere's the whole record for lwarx12:32
ghostmansdit's X form12:32
lkclthat would have resulted in a flood notification if it had gotten through12:32
ghostmansdoperands are: RT, RB, RA, EH12:32
lkclmmmm ok can you do a push to dis branch?12:32
programmerjakelookie at all the pretty XO values, all nicely allocated :) https://libre-soc.org/openpower/power_trans_ops/12:33
ghostmansdlkcl, cf dis branch12:33
ghostmansdI pushed a commit which prints12:33
lkclok got it12:34
programmerjakeI did notice that fpown and frootn should have been defined to take RB rather than FRB, because they are between a float and int, so I changed the text to fix that...12:34
lkclecho -n -e '\x28\x60\x4b\x7d' | pysvp64dis -v -l12:34
lkclprogrammerjake, ah well spotted12:35
ghostmansdecho -n -e '\x28\x60\x4b\x7d' | python3 src/openpower/sv/trans/pysvp64dis.py /tmp/bin.o -v12:35
programmerjakenow, to clean up all the no-longer accurate comments in the mdwn...12:35
lkclwhadderfrick why is EH missing?12:35
lkclghostmansd, is Rc in the list? it is...12:36
lkcl 'Rc': [31],12:36
ghostmansdOccupies the same bit, eh?12:36
lkclthat's not a problem12:36
lkclok let's just run power_fields.py12:37
ghostmansdcf. class FieldsDatabase:12:37
ghostmansdIt uses openpower.decoder.power_fields.DecodeFields12:37
ghostmansdalmost 1:112:37
lkcl    field EO BitRange([(0, 11), (1, 12)])12:37
lkclbut no EH??12:37
ghostmansdno EH12:38
ghostmansdyeah you also found12:38
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc12:38
lkclahhh frick, you know what?12:38
lkcllook at E, just above12:38
ghostmansdI ran power_fields.py12:38
lkcl    E (12:15)12:38
lkcl        Field used to specify the access types ordered by12:38
lkcl        an Elemental Memory Barrier type of sync instruc-12:38
lkcl        tion.12:38
ghostmansdthey don't overlap12:39
ghostmansdEH is bit 3212:39
lkclwhere's the words "Format: XXXXX"?12:39
ghostmansdYeah this is the reason12:39
ghostmansdI guess it considers everything a description for E field12:40
ghostmansdholy fuck :-D12:40
lkclin fact, there isn't even a field E in v3.0B or v3.112:40
lkclhow the hell did they get there? must be an early pre-release version of the PDF12:40
ghostmansdremoving it fixes12:41
lkcllet me commit it12:41
ghostmansdsure, go ahead12:42
ghostmansdOK at least generally disasm is correct :-)12:42
ghostmansdthis is a good sign12:42
ghostmansdthat said, I again come to conclusion we should really check stuff in fields.text better12:42
ghostmansdlike everywhere else12:43
lkcl28 60 4b 7d    lwarx r10,r11,r12,012:43
lkcl    spec12:43
lkcl        lwarx RT,RA,RB,EH12:43
lkclwell, ya know, it did the job.12:43
ghostmansdI know, time constraints, let's plan it12:43
ghostmansdyeah that's what I said above :-)12:43
ghostmansdcool. cool cool cool.12:43
lkclunit test running and rebase time?12:44
ghostmansdlet me drop some hacks12:44
ghostmansd1 sec12:44
lkclhow the hell did he manage to get that in 1 second?? :)12:44
ghostmansdok rebased master12:45
ghostmansdI dropped this print for lwarx and hack with sys.path I used for a while :-)12:45
lkclok underway. going to get some lunch. machine unresponsive for 20 mins so might as well12:46
ghostmansdOK now I have something with EXTRA212:46
lkclgo ahead12:46
ghostmansdlet's proceed with whole EXTRA2 vs EXTRA3 operand value getters12:47
lkclhonestly that pseudocode you posted yesterday(?) really is all that's needed12:47
ghostmansdJust have to check what the fuck SPEC is12:47
ghostmansdalso I haven't introduced DynamicOperandCR yet12:48
lkclthe bits from the EXTRA2/3 you looked up12:48
ghostmansdthese will be tricky12:48
ghostmansd(we should also print these better, but that's yet another story)12:48
lkclso if you have identified that RM.EXTRA - which is 9 bits - is subdivided into 4 EXTRA2s12:48
ghostmansdahem... 8 bits?12:49
lkcland identified that RT is EXTRA2[0]12:49
lkclno, 9 :)12:49
lkclthen spec for RT = RM.EXTRA[0..1]12:49
ghostmansdah yes12:49
lkcldropping the MSB to zero12:49
lkclso you can see12:50
lkcl        self.extra   = Signal(9, reset_less=True)12:50
lkclone *each* of these SVP64ExtraSpecs is allocate for *every* operand12:50
lkclone for RA, one for RB, one for RC, one for RT, one for RS.... one for BA, one for BB, ....12:51
lkclit's really not that hard12:52
ghostmansdI'll think about how to organize it12:52
ghostmansdFrankly, for binutils I really want something reusable12:55
ghostmansdAnd I'd really love if we have something like what we have with Mode classes12:55
ghostmansd(you recall these LDSTIdxMode, LDSTImmMode, NormalMode and similar)12:55
ghostmansdSo, if we can express operands in terms of spans rather than operations...12:55
ghostmansd...that'd totally do the binutils.12:56
ghostmansdThat's, we can check EType and select the getter/setter appropriately12:56
ghostmansdAnd that one will simply access some bits in svp64_insn12:56
ghostmansdBecause basically it's like "we have 5 bits for RA reserved in suffix, but hey bro, we also take 2 bits from some EXTRA"13:03
ghostmansddo we have some kind of this table?13:04
lkclyes - the scalar/vector bit of spec.  bit zero13:05
ghostmansdI mean, the same we have in pseudocode, but in terms of spans13:05
lkcleverything's there.13:05
lkcl        with m.If(self.isvec):13:06
lkcl            # Vector: shifted up, extra in LSBs (RA << 2) | spec[1:2]13:06
lkcl        with m.Else():13:06
lkcl            # Scalar: not shifted up, extra in MSBs RA | (spec[1:2] << 5)13:06
lkclis that what you mean?13:06
ghostmansdyes this is it13:06
lkclCRs are slightly different13:06
ghostmansdexcept for isvec part...13:06
ghostmansdlet me trace where these come from13:07
lkcl        # simple: isvec is top bit of spec13:07
lkcl        comb += self.isvec.eq(spec[SPEC.VEC])13:07
lkclok so top bit (MSB) not lowest bit13:07
lkclspec comes from having decoded with SVP64ExtraSpec13:07
ghostmansdbut you get what I mean, right?13:07
lkclclass SVP64RegExtra(SVP64ExtraSpec):13:07
ghostmansdwith spans and similar crap13:07
lkclnot entirely.13:08
ghostmansdcf. Mode and its descendants13:08
lkclfood on cooker13:08
ghostmansdlet me open git13:08
ghostmansdI'll post some links with comments13:08
lkclok not burning any more13:08
lkcloh. yes. Modes. yes. sorry, different context13:09
ghostmansdWe have a Mode class13:09
ghostmansdBelow there are some of its descendants, which specify the actual Modes13:09
ghostmansdand their layout13:10
lkclremember, sel there needs to be the entire 5 bits - we established that a couple days ago.13:10
lkcland 5-bit mask-patterning "00---" etc. needed13:10
ghostmansdthis sel bit doesn't do what you think it does13:10
lkcl"000--" for simple mode13:10
ghostmansdif you want, I can drop it entirely and simply refer to mode[0] and mode[1]13:11
lkcl"0010-" for...13:11
ghostmansdbut let's concentrate on the other stuff now13:11
lkclno that's what i'm saying, you *shouldn't* just refer to mode[0] and mode[1]13:11
lkclit really should be13:11
lkcl"0010-" for scalar reduce mode13:11
ghostmansdWe don't have way to do it now13:11
ghostmansdWe don't have some CSV with patterns13:11
lkcl"10--1" for pack/unpack sat mode13:12
ghostmansdIf I had some pattern-like stuff to refer to, I'd have done it13:12
ghostmansdfor now, I deal with it with bunch of if/else13:12
lkclhonestly i think you'll find that if you use patterns like that it'll be a flat hierarchy not a nested if/else hierarchy13:12
lkclto the point where it could be reduced to a simple array... just *as if* XO had come out of a CSV file13:13
programmerjakelkcl, reading all the nice comments you added to minor_59.csv while dealing with rebasing...ffadds is 2-in 2-out, not 3-in 2-out13:13
lkcl(is what i'm advocating.  it makes it easier to drop in CSV files later)13:13
lkclprogrammerjake, doh13:13
ghostmansd[m]Yes, I'like a flat hierarchy.13:14
ghostmansd[m]But I don't have time to implement it now.13:14
lkclack :)13:14
ghostmansd[m]So I do it the way it's done in this Signal-using code.13:14
ghostmansd[m]Yes this is one of things to plan.13:14
lkclsigh yes.13:14
lkclok. so. sorry for the distractio13:14
ghostmansd[m]But I get the idea and share it.13:14
lkclwhat were you saying13:14
ghostmansd[m]Ok, so, regardless of the structure..m13:15
ghostmansd[m]We end up with the exact class13:15
ghostmansd[m]Which specifies the exact fields13:15
ghostmansdthis is normal.ffrc013:15
ghostmansdand, from that, we can already say what RC1 is...13:16
ghostmansdor what sz/dz are (if we take some other mode)13:16
ghostmansdThese modes are just convenient way to show spans13:16
ghostmansdAnd, since they're remapped too, as the whole RM...13:16
lkclspans... i think i get that word13:17
lkclMode inherits from Mapping, which is the meta-bollox thing13:18
ghostmansdwe have getters like this: svp64_insn_get_prefix_rm_mode_normal_simple_sz13:18
ghostmansdthis is a static inline uint64_t13:18
ghostmansdsvp64_insn_get_prefix_rm_mode_normal_simple_sz(const struct svp64_insn *insn)13:18
ghostmansd  uint64_t value = insn->value;13:18
ghostmansd  return (13:18
ghostmansd    (((value >> UINT64_C(32)) & UINT64_C(1)) << UINT64_C(0))13:18
ghostmansd  );13:18
lkclall autogenerated13:18
ghostmansdMy point is, I'd like to express operands in the same way13:18
lkclerm...ermermerm... operands you mean EXTRA2/3 operands?13:19
ghostmansdand have some getter like svp64_insn_get_in013:19
ghostmansdActually I'd like to have the whole operand combined13:19
lkclfrickin-ellfire :)13:19
ghostmansdThat is, 5 bits from suffix AND 2 bits from EXTRA13:19
ghostmansdin one getter/setter pair13:19
lkclcompiler technology, deep joy.13:20
ghostmansdThat's, I'd like to generate getter which already does that crap internally.13:20
lkclcan i recommend first writing it out manually, so that you know clearly which bits go where?13:20
ghostmansdYes, I think I'll start with this13:20
ghostmansdBut I have to dive into SPEC deeper13:20
ghostmansdand stuff around, too13:20
ghostmansdOnce I realize all possible combinations...13:21
lkclbtw, you know what the next stage is, here, don't you.  a *nmigen* auto-generator, joining the binutils one.13:21
lkclwhich actually really should not be that hard to do.13:21
ghostmansd...I guess expressing these in a structures similar to Mode classes is really simple.13:21
ghostmansdWith Modes, it was simpler: we had tables, not pseudocode.13:21
ghostmansdThat is, all these shiny stuff like "OK, bit 2 are X, bit 3 is Y, then mode is Z"13:22
ghostmansdand then I created class Z13:22
lkclgive it a shot, you'll kick yourself as to how simple it really is.13:22
ghostmansdOK will try to come up with some table13:24
ghostmansdI guess mutable parts are13:25
ghostmansdtype: GP/FP vs CR13:25
ghostmansdvector: yes or no13:25
ghostmansdetype: EXTRA2/EXTRA3/NONE13:25
programmerjakewell, ghostmansd, I think I unblocked you on #899 since I allocated all instructions and added them to the CSV files.13:34
programmerjakeI stayed up too late, gn13:35
sadoon[m]I'm starting the buildd stuff now13:36
ghostmansdand thanks for unblocking 899!13:45
ghostmansdlkcl, OK, so we simply build 3 bits, eh?13:49
lkclyyep.  for spec, yes.13:50
ghostmansd"spec" is just a collection of three bits: 0 is vector, 1 and 2 are "extensions" for registers13:50
lkclSVP64ExtraSpec makes a consistent 3-bit spec13:50
lkclin MSB0-numbering yes.13:50
lkcli think.13:50
ghostmansdThe nmigen notation is fucking idiotic, with these "comb += cocojumbo.eq"13:51
ghostmansdIt's not obvious cocojumbo is kinda "updated"13:51
lkclit's because python hasn't got an override for assignment13:51
lkclx = 513:51
ghostmansdWell it has for attributes13:51
lkclwould assign x *equal* to the number 513:51
ghostmansdbut a.x can (and sometimes must) be overloaded13:51
ghostmansdThis is how say properties work13:52
lkclone of the other python-based RTLs did something incredibly stupid - they overloaded the "<=" operator to be assignment13:52
ghostmansd[m]Fucking morons13:52
lkclhey, idiotic or not it made things "readable"13:53
lkclbut changing the meaning of a python operator... yeah.13:53
ghostmansdYes, this is something that hurts readability even more.13:53
ghostmansdWith eq, it's at least feels kinda "do an operation and return reference"13:54
ghostmansdAnd with <= it feels like "we're morons, don't ever consider this particular piece of code"13:54
ghostmansdSorry, I know, this is strongly opinionated...13:55
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC13:55
lkclyou have to bear in mind that nmigen is a compiler for an Abstract Syntax Tree13:56
lkclthat is attempting to keep to a reasonably-human-readable syntax for hardware13:56
lkcleven with gate-level design it took me 6 *months* to get used to nmigen, and verilog and VHDL were about as long as well13:57
lkclit's a totally different mindset, don't beat yourself up about it13:57
* lkcl starting on preduce unit test13:57
ghostmansdSo, if we have etype == EXTRA2 AND found that operands goes to extra2[0]... this leads to spec[0] = extra2[0][0] and spec[1][1] = extra2[0][1]13:58
* lkcl checking...13:58
ghostmansdI have to hunt for LSB yet, but, other than that, it becomes clearer13:59
lkclextra2--> split == RM.EXTRA[0:1], RM.EXTRA[2:3], RM.EXTRA[4:5], RM.EXTRA[6:7]13:59
ghostmansdby EXTRA, you mean all bits of extra present in both EXTRA2 and EXTRA3, right?14:00
lkclthen the spec associated with *extra2[0]* goes into...14:00
lkclRM.EXTRA is 9-bit14:00
lkclclass SVP64ExtraSpec14:00
lkcl        self.extra   = Signal(9, reset_less=True)14:00
ghostmansdextra: _Field = range(10, 19)14:00
ghostmansdextra2: _Array[4] = (14:00
ghostmansd        range(10, 12),14:00
ghostmansd        range(12, 14),14:00
ghostmansd        range(14, 16),14:00
ghostmansd        range(16, 18),14:00
ghostmansd    )14:00
ghostmansdextra3: _Array[3] = (14:00
lkclCommon RM fields14:00
ghostmansd        range(10, 13),14:00
ghostmansd        range(13, 16),14:00
ghostmansd        range(16, 19),14:00
ghostmansd    )14:00
lkclEXTRA10:18Register Extra encoding14:00
lkclconfirmed.... ha, python range is of course 1 more so yes, confirmed extra: correct14:01
lkclextra2.... 10-12 12-14 14-16 16-18 correct14:01
lkclextra3... 10-13 13-16 16-19 correct14:02
lkclall good14:02
ghostmansdOK, but still, extra[2] has only VEC and MSB...14:02
ghostmansdextra2 has only VEC and MSB14:02
ghostmansdsince it's only two-bit14:02
ghostmansdand LSB... where is it?14:02
lkclhell i don't know :)14:03
ghostmansdcomb += spec_aug.eq(field(spec, SPECb.MSB, SPECb.LSB, SPEC_SIZE))14:03
lkcli would have to look at the definition of SPEC and SVEXTRA.IDX :)14:03
ghostmansdThat's what I found14:03
lkclMSB0-LSB0 ordering does my head in :)14:03
ghostmansdwith m.If(self.isvec):14:04
ghostmansd            # Vector: shifted up, extra in LSBs (RA << 2) | spec[1:2]14:04
ghostmansd            comb += self.reg_out.eq(Cat(spec_aug, self.reg_in))14:04
ghostmansd        with m.Else():14:04
ghostmansd            # Scalar: not shifted up, extra in MSBs RA | (spec[1:2] << 5)14:04
ghostmansd            comb += self.reg_out.eq(Cat(self.reg_in, spec_aug))14:04
ghostmansdthis stuff even has cats!14:04
lkclCat is "concatenate all bits"14:04
ghostmansdkinda begin to appreciate it14:04
lkclstandard fare for VHDL14:04
ghostmansdwhat a please14:04
lkcl# EXTRA3 3-bit subfield (spec)14:04
lkclclass SPECb(_Const):14:04
lkcl    VEC = 0  # 1 for vector, 0 for scalar14:04
lkcl    MSB = 1  # augmented register number, MSB14:04
lkcl    LSB = 2  # augmented register number, LSB14:04
lkclok see consts.py14:05
ghostmansdyeah here14:05
lkclanything XXXXXb is MSB0 ordering14:05
ghostmansdWe're MSB0, don't think about it14:05
programmerjake<lkcl> "even with gate-level design it..." <- for verilog it took me 1-2 weeks, since I found a book on it and was bored at the time14:05
lkclcesar kindly wrote an auto-enum-generator which turns those round into LSB-ordering14:05
lkclthat's what ConstLE is about.14:06
ghostmansdall these fields are MSB0-enabled, all getters/setters convert the stuff on the fly14:06
lkcllet's take SPECb which is 3-bits14:06
lkclVEC = 014:06
lkclwhich is in MSB0-numbering14:06
lkclwhich if you are using SelectableInt is what you want14:06
ghostmansdI do :-)14:07
lkclthank god for that14:07
ghostmansdall C getters/setters do too14:07
ghostmansdand all these fields hide that too14:07
lkclclass EXTRA2b(_Const):14:07
lkcl    IDX0_VEC = 014:07
lkcl    IDX0_MSB = 114:07
lkclthis is slightly brain-dead, no subtlety, just enumerate all the bits14:08
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc14:08
ghostmansdeverything is clear except for LSB14:08
lkcl    IDX3_VEC = 614:08
lkcl    IDX3_MSB = 714:08
lkclclass SPECb(_Const):14:08
lkcl    VEC = 0  # 1 for vector, 0 for scalar14:08
lkcl    MSB = 1  # augmented register number, MSB14:08
lkcl    LSB = 2  # augmented register number, LSB14:08
lkclyou can turn an EXTRA2 into an EXTRA3 simply with "<<"14:09
ghostmansdspec[VEC] = IDX0_VEC14:09
ghostmansdspec[MSB] = IDX0_MSB14:09
lkclspec[LSB] = 014:09
ghostmansdAhem... so it's always 0?14:09
ghostmansdI don't get, how then we have 0..127?14:10
ghostmansdBecause we should've got 0..6314:10
lkclfor scalar, yes.14:10
lkclbut for vector you have 0 2 4 6 .... 12614:10
ghostmansdthis is still 64, just step is 214:11
ghostmansd> INT is extended from r0-31 to r0-12714:11
lkclwith EXTRA2 there is only one bit available for increasing the numbering, leaving... yes, only 6 bits14:11
lkclint it extended from r0-31 to r0-127 in increments of one with EXTRA314:12
lkclint it extended from r0-31 to r0-126 in increments of TWO with EXTRA214:12
lkclbut because the conversion from EXTRA2/3 to 3-bit spec has *already happened* by that point, you dont' know that14:12
lkclspec as generated from an EXTRA3 simply has the LSB zero.14:12
ghostmansdmmmm.... you mean EXTRA2?14:13
lkclyes whoops14:13
lkclhang on....14:13
ghostmansdWith EXTRA3, stuff is clear14:13
lkclso just convert to spec14:14
ghostmansdAh wait14:14
lkcland forget about EXTRA2/314:14
lkclthen the fact that one bit is zero because of EXTRA2 you just don't care, at all14:14
lkclNot Your Problem(tm)14:14
ghostmansdBut how comes? I have one bit which determines if thing is a vector, that's OK.14:15
lkclyou're very much overthinking this :)14:15
ghostmansdAnother one shows MSB, OK, so far so good.14:15
ghostmansdreturn (spec[1:2] << 5) | RA14:15
ghostmansdLet's forget about vectors, for a while14:16
lkclthat's for... scalar numbering.14:16
ghostmansdI don't understand, if spec[2] is always zero...14:16
ghostmansdhow do we enable range(0, 128)?14:16
lkcli have a sneaking suspicion that it should be inverted, there14:16
lkclwhich is probably the purpose of this line14:17
lkcl        comb += spec_aug.eq(field(spec, SPECb.MSB, SPECb.LSB, SPEC_SIZE))14:17
ghostmansdI don't know what this means14:17
lkclthat's equivalent job to FieldSelectableInt14:17
ghostmansdand, even if it's inverted, it's still the same range14:17
lkclfor a range14:17
ghostmansdeven if we always have 1 for spec[2], it doesn't help14:18
lkclyes but it means that ... hang on14:18
lkclit means that the pseudocode is wrong14:18
lkclspec_aug = spec[1]<<1 | spec[2]14:18
ghostmansdOK perhaps I must try encoding some values via pysvp64asm14:18
lkclreturn (spec_aug[0:1] << 5) | RA14:18
lkclphone call14:19
ghostmansdHm, perhaps way too verbose14:24
lkclooo joy :)14:24
lkclok sv.add 127,0,0 should work as this is EXTRA314:25
ghostmansdfunny, I also found an issue in pysvp64asm14:25
ghostmansdwe create database upon each instruction14:25
lkcladd is RM-2P-2S1D and as 3 operands i know that fits into 9-bit EXTRA14:25
ghostmansdwhich takes almost a second14:25
lkclso for 127,0,0 you get14:26
lkclextra3=[[0]=[3]0x3, [1]=[3]0x0, [2]=[3]0x0]14:26
lkclwhich looks correct.14:26
lkcllet's check the RM-2P2S1D.csv file14:26
lkclRM-1P-2S1D oh well14:27
lkclEXTRA3[0] = d:RT and CR014:28
lkclmeaning add RT,RA,RB matches RT with EXTRA3[0[14:28
lkclso that's working14:28
lkclthe others are zero because the operands RA and RB are zero14:28
ghostmansdOK let's try on something EXTRA214:28
ghostmansdBad choice with EXTRA314:28
ghostmansdsince the whole discussion was about extra2 :-)14:28
lkclisel is an RM-1P-3S1D14:29
lkclfour operands14:29
lkclor fmadds14:29
ghostmansdAssertionError: scalar GPR RT cannot fit into EXTRA2 (0, '127', 'RT', 'GPR', None)14:29
lkclthere you go14:30
ghostmansdThat's on sv.isel 127,0,0,014:30
lkclthat's correct.14:30
lkclthat's 100% correct14:30
ghostmansdSo they are not supported, at all?14:30
ghostmansdfor EXTRA214:30
lkclno of course. you can't express 7-bits of numbers in only 6 bits14:30
ghostmansdI mean, do we only support 0..63 for EXTRA2?14:30
lkcl(5 bits for RA/RB/RC)14:30
lkcl(only 1 bit in EXTRA2)14:30
ghostmansdOK it'd have been easier if you just told me that :-D14:31
lkcli did!14:31
lkclbut i suspect you had to see it for yourself14:31
ghostmansdyeah seems like that was the case14:31
lkcl> ghostmansd> Because we should've got 0..6314:31
ghostmansdhm... do we have it in spec explicitly?14:31
lkclyes because for EXTRA2, spec[LSB] is always zero14:32
ghostmansdin this explicit form: WE DON'T SUPPORT RANGE 0..127 EVERYWHERE, ONLY FOR EXTRA314:32
lkclbtw this is because RA is 5-bit14:33
lkclfor CRs which only have 3 bits the range is *even less*14:33
ghostmansdSo we have another operand at the cost of reducing operand width?14:33
ghostmansdIs it what this is about?14:33
lkclotherwise we need something mad like 72-bit or 96-bit instructions14:33
ghostmansdWe can support 4 operands, but with sacrificing the range.14:33
ghostmansdWhy have range 127, then?14:34
lkclbecause you have to make a decision in hardware about the number of registers14:34
ghostmansdI mean, why don't we simply assert we support 0..63 anywhere14:34
lkclwe decided 128 because this is intended for a 3D GPU / VPU14:34
lkcland if you have only say 64 registers, that's nowhere near enough14:34
lkclyou end up with [extremely costly] stack-spill14:34
ghostmansdStill I'd like to see this clearly in the docs.14:35
lkclNVIDIA and the latest AMDGPUs have i think *512* registers14:35
ghostmansdI mean, not in form one should guess and try14:35
ghostmansdBut clearly, EXTRA2 only supports ranges 0..6314:35
lkcli've repeated this so many times in so many places i'm actually fed up of adding more words14:35
lkclit is there.14:35
ghostmansdYou don't have to repeat it, just write it in words :-)14:36
lkcli really don't want to add more words repeating this.14:36
ghostmansdNot pseudocode14:36
lkclit's already there14:36
lkclburied in amongst 160+ pages, it's there14:36
ghostmansdhow does the end user knows what is EXTRA2 and EXTRA3?14:36
lkclwe encountered this phenomenon already with the [1,600] page Power ISA spec itself14:37
ghostmansdI mean, just looking at opcode name...14:37
lkcldeep breath: they need to look at the CSV files.14:37
lkclanother deep breath14:37
lkcli have converted to tables and included in the spec14:37
lkclhence why sv_analysis is so critically, critically important14:37
ghostmansdWe do have it as PDF, right?14:37
lkcland *also* included in the spec14:37
ghostmansdBecause I'm one of the weirdos who does it with CSV14:37
lkcli modifed sv_analysis.py to actually explicitly output .mdwn14:38
lkclwhere previously it was outputting csv files with [[!table file=some.csv]]14:38
lkclwhich pandoc didn't understand14:38
* lkcl typing too much14:39
ghostmansdOK let's say we have addis14:39
lkclneed to minimise typing.14:39
lkclcarry on14:39
ghostmansdWhere do I have in the spec a clear and explicit table which says "it's EXTRA3"?14:39
ghostmansdor well, isel is EXTRA2?14:39
ghostmansdyes, I'm looking at it14:40
lkclappendix F p21114:40
ghostmansdRM-1P-3S1D Single Predication dest/src1/2/3, applies to 4-operand instructions14:40
ghostmansd6.12.1 RM-1P-3S1D14:40
ghostmansdRdest_EXTRA2 10:11 extends Rdest (R*_EXTRA2 Encoding)14:40
ghostmansdRsrc1_EXTRA2 12:13 extends Rsrc1 (R*_EXTRA2 Encoding)14:40
ghostmansdRsrc2_EXTRA2 14:15 extends Rsrc2 (R*_EXTRA2 Encoding)14:40
ghostmansdOK I'm starting to understand14:41
lkclwhich is direct from mdwn14:41
lkclwhich is direct from sv_analysis14:41
ghostmansdit applies to the whole remap form14:41
ghostmansdwe document the remap forms, not particular instructions14:41
ghostmansdfor instruction, we print which remap form it has14:41
lkclreg-profiling sv_analysis14:41
ghostmansdand then the users simply check the remap form and see what the fuck EXTRA it supports14:42
lkclif they're insane, yes14:42
ghostmansdwhy call it insanity?14:42
lkclif they're sane they use the csv files (auto-generate)14:42
lkclmanual reading == mistakes14:42
ghostmansdmy first natural attempt was isel 12714:42
ghostmansdfrom the docs I saw this:14:42
ghostmansdINT is extended from r0-31 to r0-12714:42
ghostmansdso yeah, unsurprisingly I tried doing it14:43
ghostmansdand found I lost14:43
ghostmansdor, well, failed14:43
lkclah yep got it14:43
lkcllet me correct that14:43
lkclah that is register *quantities*14:43
ghostmansdwell you still see the reason for the confusion, right?14:44
ghostmansdso, OK, to summarize14:44
lkcl * CR Fields are extended from CR0-7 to CR0-12714:45
lkcl+However due to pressure in `RM.EXTRA` not all these registers14:45
lkcl+are accessible by all instructions, particularly those with14:45
lkcl+a large number of operands (`madd`, `isel`).14:45
ghostmansdfor EXTRA3, we take all 3 bits from the corresponding extra3, the first one designates whether the operand is vector14:45
ghostmansdfor EXTRA2, we take two bits, and the last one is always 014:45
ghostmansdwe than combine it with the value from the suffix14:46
lkclwhen converted to 3bit spec yes14:46
ghostmansdand -- voi-la! -- we have the value in SVP64 world14:46
ghostmansdThis is actually something expressible via layouts :-)14:46
ghostmansdOK, I'll think how to express it now14:46
ghostmansdmany thanks to you for your help and patience!14:47
ghostmansdI'd suggest explicitly writing "EXTRA2 form supports only these ranges: XXX"14:48
ghostmansdExplicit is better than implicit14:48
ghostmansdWe can end up with extra_idx == NONE for stuff like immediates, right?15:06
ghostmansdIf I'm not mistaken, these are output as is?15:06
lkclimmediates never change15:06
ghostmansd(thus the naming)15:06
ghostmansdSomething else than immediates>15:07
lkclimms not involved in EXTRA2/3 at all15:07
ghostmansdFor EXTRA2, do we end up with r0, r1, ... r63, or we end up with r0, r2, r4, ... r126?15:11
ghostmansdFrom LSB being set looks like the latter.15:11
lkclsee the bits about spec_aug... let me find irc ref....15:12
ghostmansdAh OK, the pseudocode must be updated15:14
lkclsupposed to be simple/readable15:14
ghostmansdwhen you have someone in IRC to explain all the gory details -- it is :-)15:15
lkclspec is wrong15:15
ghostmansdI know this is not the consolation you wanted, but hey, that's something15:15
ghostmansdAnother dumb and obvious question. We also can never end up with extra_idx == Idx3 for EXTRA2, right?15:17
lkclurrr... no15:17
ghostmansdAnd we'd better have an assertion to check what our code gave us.15:17
lkclnever extra_idx == idx3 for *EXTRA3*15:18
lkcl9 bit15:18
ghostmansdah yes15:18
ghostmansdmy fault15:19
*** hl <hl!~hl@user/hl> has quit IRC15:22
*** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC15:23
lkclpreduce 1st pseudocode in15:29
*** hl <hl!~hl@user/hl> has joined #libre-soc15:30
lkclfrickin ellfier15:36
lkclholy shit it worked15:42
*** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc15:47
ghostmansdCan Idx_1_2 scheme appear only for CRs?15:52
ghostmansdI'm asking since CRs will anyway end up in their own classes, and I can diagnose such situation for GPR/FPR as an error.15:53
ghostmansdAlso, another question. What does this magic with shifts if register is vector really mean?15:55
*** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC16:19
*** octavius <octavius!~octavius@> has joined #libre-soc16:23
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC16:23
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has joined #libre-soc16:24
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has quit IRC17:13
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc17:14
lkclok so it is really for EXTRA2 (and for CRs)17:23
lkclthere are limited bits (e.g. in CRs) - only 3-bits in BFA17:24
lkclbut they need to be expanded to range 0..12717:24
*** octavius <octavius!~octavius@> has quit IRC17:25
lkclEXTRA2 only provides 1 more17:25
lkclEXTRA3 provides 2 more bits17:25
lkclfor CR Field numbers that's 3+(1-or-2) which is obviously not 717:25
lkcltherefore, logically, you have to shift up17:26
lkclthink about it: it's no bloody good having 128 registers if you can't bloody well access them!!17:26
lkclbecause the numbering only goes up to say 15 or 31!17:26
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC17:34
*** octavius <octavius!~octavius@> has joined #libre-soc17:35
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has joined #libre-soc17:38
lkcltoshywoshy, ping, openpowerbot's gone walkies :)17:47
lkclnow, as for scalar: if you perform the same "shift" on *scalar* regs17:50
lkclr0 r2 r4 r6 ... r12617:50
lkclhow the hell do you access r1?17:50
lkclyou can't.17:50
lkclso the sacrifice was made to access the scalar regs in sequence (which *includes v3.0B registers in full* - that's really important)17:51
lkclbut to sacrifice the LSBs on vector access because you'll likely do VL=4 and above anyway17:51
*** openpowerbot <openpowerbot!~openpower@94-226-188-34.access.telenet.be> has joined #libre-soc17:52
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has quit IRC17:55
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc17:55
ghostmansd[m]How would we call part of reg which is hold in the spec?17:58
ghostmansd[m]Suffix part I called "base"17:58
ghostmansd[m](suffix part is what pseudocode calls RA)17:59
ghostmansd[m]spec[0] I called vector...17:59
ghostmansd[m]And spec[1..2] or spec[1] (depending on the extra), how would we call it?17:59
ghostmansd[m]Seriously I'm that tired I gonna call it "rest"18:00
ghostmansd[m]Hm. IIRC in pysvp64asm it's called sv_extra.18:02
ghostmansd[m]Let me call it extra.18:02
lkclbtw reminder of the idea that occurred to me a few days ago: a secondary auto-generator creating nmigen data-struct and Records19:06
lkcltherefore if you could stick reasonably closely to the existing variable/class-names where it makes sense to do so, it makes for less work in ripping out all of the hand-written code19:07
ghostmansd[m]I'm trying to, but sometimes it's really difficult19:52
ghostmansd[m]For example, I already have to move from nested arrays in Extra2/Extra319:53
ghostmansd[m]And replace these with Idx0..Idx319:53
lkclactually things like that don't matter so much20:13
*** octavius <octavius!~octavius@> has quit IRC20:13
lkclreason being that it's the inputs and the outputs that ultimately matter20:13
lkclintermediary data structures, no so much20:14
lkcltests re-run and rebased dis btw20:14
lkclcommit 20575120e20:14
lkcl    pysvp64asm: create database once20:14
ghostmansd[m]Ah OK this one should be OK20:17
ghostmansd[m]Don't pick anything I might push soon, it might hurt :-)20:18
ghostmansd[m]Thanks for rebase20:18
ghostmansd[m]lkcl, could we perhaps go through say sv.add first operand?20:18
ghostmansd[m]And tell which bits exactly it uses for new value20:19
ghostmansd[m]The particular bits span used to produce new value20:19
*** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc20:20
ghostmansdFor now I have this span for RT: (6, 7, 8, 9, 10, 18, 19, 20)20:20
ghostmansdin this particular order20:20
ghostmansdAh wait I see...20:21
ghostmansdI should've got first 5 bits in the order they appeared in suffix20:21
sadoon[m]I have found the perfect solution for building full debian from source https://pbuilder-team.pages.debian.net/pbuilder20:43
sadoon[m]I have it setup about 40% of the way, and it provides useful automation20:43
sadoon[m]and with that, good night everyone :)20:43
ghostmansdsadoon[m], gn!20:47
ghostmansdlkcl: https://bugs.libre-soc.org/show_bug.cgi?id=917#c520:56
ghostmansdnote that this is hacky, and you have 0 guarantees upon rebasing this: I really had to touch EXTRAs (had to switch from Array class to Mapping).20:57
ghostmansdThat said, Array were a giant hack anyway. I've already been thinking about how to drop these.20:57
ghostmansdPlease check the examples I posted, there might (and for sure will) be errors.20:58
ghostmansdThat said, this is at least something for starters.20:58
ghostmansdTomorrow I'm going to claim RFP for word instructions, I need at least some RFP already for all this torment... :-D Is it OK? I consider this complete except for special CR handling (but these can be printed as plain numbers anyway IIRC).21:00
ghostmansdAlso, 838. Do we have anything left there, apart from DecodeFields quirk we found today? I'd grab this too.21:01
ghostmansdI'm considering these tasks:21:03
ghostmansdhttps://bugs.libre-soc.org/show_bug.cgi?id=838 no idea what's left here besides done; we kept the form, but went into great efforts to cross-check (and even managed to find some issues)21:04
ghostmansdhttps://bugs.libre-soc.org/show_bug.cgi?id=918 I'd consider taking 1/3 of #917 for insndb21:05
ghostmansdhttps://bugs.libre-soc.org/show_bug.cgi?id=919 1/3 of #917 for word instructions21:05
ghostmansd[m]Tomorrow I'm going to continue on extras (I think they're still pretty hacky). The next target is CRs.21:09
ghostmansd[m]I'm unsure what's next besides capturing "specifiers" and printing these (dz, sz, etc., anything we had separated by / in assembly). I'd be great if we have an exhaustive list of those by hand. I'm not sure what we should print.21:12
ghostmansd[m]Also, by this point I'm confident that the whole svp64asm can be written as a mapping of specifier:callback_to_routine_which_sets_some_fields_in_SVP64Instruction_instance21:13
ghostmansd[m]But that's yet another story.21:13
ghostmansd[m]Too tired today to think straight, but wanted to express this thought until I forget it; see you tomorrow.21:14
*** octavius <octavius!~octavius@> has joined #libre-soc21:36
programmerjakemeeting in 7min everyone21:54
programmerjake6min now21:54
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC21:57
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc21:58
ghostmansd[m]Ah we have a meeting today22:01
ghostmansd[m]Ok I'll join too22:02
*** markos <markos!~Konstanti@> has quit IRC23:17
*** markos <markos!~Konstanti@> has joined #libre-soc23:30
*** octavius_ <octavius_!~octavius@> has joined #libre-soc23:31
*** octavius <octavius!~octavius@> has quit IRC23:36
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC23:37
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc23:39
ghostmansd[m]Cool sync today23:53
ghostmansd[m]Almost 2 AM here :-)23:53
ghostmansd[m]Thanks for talk, and good night!23:53

Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!