Friday, 2022-09-09

*** ghostmansd <ghostmansd!> has quit IRC00:21
lkclyyeah it's one of the ones that will fit the multi-pattern thing00:27
lkclthere's a full 32 entries in the CSV file00:27
lkclotherwise we have to convert the entirety of minor_31.csv XO to "bitpattern"00:27
ghostmansd[m]The issue is with mask.00:38
ghostmansd[m]binutils have the same opcode value.00:38
ghostmansd[m]Anyway, tomorrow.00:38
ghostmansd[m]I suspect it's related to cr_reg and cr_bit, but need to check more.00:38
*** octavius <octavius!> has quit IRC01:49
*** sadoon[m] <sadoon[m]!~sadoonunr@2001:470:69fc:105::1:f0fa> has quit IRC02:30
*** jevinskie[m] <jevinskie[m]!~jevinskie@2001:470:69fc:105::bb3> has quit IRC02:35
*** tinybronca[m] <tinybronca[m]!~tinybronc@2001:470:69fc:105::2:1af6> has quit IRC02:39
*** lx0 <lx0!~lxo@gateway/tor-sasl/lxo> has quit IRC03:06
*** lx0 <lx0!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc03:07
*** sadoon[m] <sadoon[m]!~sadoonunr@2001:470:69fc:105::1:f0fa> has joined #libre-soc03:19
*** tplaten <tplaten!> has quit IRC03:34
*** tplaten <tplaten!> has joined #libre-soc03:49
*** lx0 <lx0!~lxo@gateway/tor-sasl/lxo> has quit IRC04:01
*** lx0 <lx0!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc04:02
*** tplaten <tplaten!> has quit IRC05:18
*** lx0 <lx0!~lxo@gateway/tor-sasl/lxo> has quit IRC05:51
*** lx0 <lx0!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc05:52
*** lx0 <lx0!~lxo@gateway/tor-sasl/lxo> has quit IRC05:56
*** lx0 <lx0!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc05:57
programmerjakelkcl: reading through transcendentals.mdwn again, I noticed it specifically lists "With thanks to:" and lists everyone but you, implying you wrote the whole thing, which isn't really true. imho it would be better to add you to the list and change the list's title to "Authors/Contributors" or similar, since that doesn't imply only one author. What do you think?06:44
lkclyep go for it06:48
lkclgood call06:48
lkclactually it was me who was collating all input, did all the tables, initially.06:49
programmerjakehmm, iirc I did that for the risc-v version06:50
lkclhonestly can't remember. 3+ years ago now (!)06:50
programmerjakeI'll change that phrase in the other places it occurs since they probably have the exact same issue06:51
lkcli remember spending a long time formatting the table with khronos/opencl, and doing the risc-v opcode table06:51
lkclgiven you're now working on it i'm happy with "authors"06:52
programmerjakewell, not everyone listed actually wrote any of the text, therefore I think contributors is necessary06:53
programmerjakee.g. Andrew Waterman is listed06:53
programmerjakeiirc he just supplied some suggestions to the original risc-v one06:54
lkclyes. as did most people there.06:54
lkcli collated responses from mailing lists and email.06:54
lkclthey didn't actually do one single edit06:55
lkclthe only people actually authors is you and me.06:55
programmerjakek, I replaced "with thanks to" in openpower/transcendentals.mdwn simple_v_extension/specification.mdwn and ztrans_proposal.mdwn, does that sound good?07:10
*** lx0 <lx0!~lxo@gateway/tor-sasl/lxo> has quit IRC07:45
*** lx0 <lx0!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc07:46
*** lx0 <lx0!~lxo@gateway/tor-sasl/lxo> has quit IRC07:48
*** lx0 <lx0!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc07:48
*** lx0 <lx0!~lxo@gateway/tor-sasl/lxo> has quit IRC07:53
*** lx0 <lx0!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc07:55
*** lx0 <lx0!~lxo@gateway/tor-sasl/lxo> has quit IRC08:12
*** lx0 <lx0!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc08:13
*** lx0 <lx0!~lxo@gateway/tor-sasl/lxo> has quit IRC08:53
*** lx0 <lx0!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc08:54
*** lx0 <lx0!~lxo@gateway/tor-sasl/lxo> has quit IRC09:14
*** lx0 <lx0!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc09:15
programmerjakeghostmansd: sorry -- more fptrans ops, we forgot to add them to fptrans, so I just now added them to fptrans, they still need to be allocated XO values and added to the CSVs, see and
*** jevinskie[m] <jevinskie[m]!~jevinskie@2001:470:69fc:105::bb3> has joined #libre-soc10:03
*** ghostmansd <ghostmansd!> has joined #libre-soc10:24
ghostmansdlkcl, what the merged value and mask you'd expect here?
ghostmansdThis is what we get now: FieldsOpcode(value=0x7c00001e, mask=0xfc0007fe)11:03
ghostmansdThe fields we look at are: [(0x0000001f, [0:5]), (0x0000000f, [21:30])]11:04
ghostmansdI found that we don't use suffix field from insndb. What'd be the right way to use it?11:06
ghostmansd[m]minor_31 table is the only one which uses suffix. lkcl, it'd be great if you could explain what suffix is and how to adopt it to "opcode" function and FieldsOpcodeClass.11:32
sadoon[m]My debian repo mirror seems incomplete but just adding it locally has sped up builds while I work on completing the mirror12:02
sadoon[m]It's now churning12:02
sadoon[m]Do we have gcc that builds for ppc64le without any vector extensions by any chance?12:02
sadoon[m]I also forgot to add ccache but that can be done later12:03
sadoon[m]lkcl: forgot to tag you re: gcc without vectors12:03
lkclsadoon[m], gis a min to answer ghostmansd12:41
lkclghostmansd, ok isel p89 section 3.3.1212:41
lkcl   15  /12:41
lkcl26    3112:41
lkclso bits 26:30 = 1512:42
lkclthere are 32 entries with bits 21:25 cycling *right* the way through 00000 to 1111112:42
lkclso we can deduce that the idea there is, "ignore the BC field bits 21:26"12:43
lkcl   BC12:43
lkcl21    2612:43
lkclmask = 26:30 == 0b11111112:43
lkclval  = 26:30 == 0b01111112:43
lkclsadoon[m], you just specify -mnoaltivec -mnovsx12:44
sadoon[m]Unfortunately as you know, with debian that is almost impossible to guarantee to work12:44
lkclno we don't have a pre-compiled gcc which has those as defaults12:44
sadoon[m]Certain packages will not abide12:44
sadoon[m]But that can be done I assume right?12:45
lkclbuild a version of gcc that has those as defaults? i don't see why not12:45
lkclit has to be done at some point12:45
lkclits prefix should be12:45
sadoon[m]I'll handle it when building specifically for libre-soc12:46
lkclSFFS is the name of the Compliance Level12:46
lkclScalar Fixed Floatingpoint Subset12:46
lkclthere's also SFS which is without FP but we're not going that far :)12:46
lkclwatch out for Quad-Floating-Point which has to be dropped as well12:47
lkclthat's the triplet12:47
lkcl  -mfloat128                  Enable IEEE 128-bit floating point via the12:48
lkcl                              __float128 keyword.12:48
lkcl  -mfloat128-hardware         Enable using IEEE 128-bit floating point12:48
lkclso probably12:49
lkcl-mno-float128-hardware at the very least12:49
lkcltoshywoshy, how did you deal/cope with this? :)12:49
sadoon[m]so -mnoaltivec -mnosvx -mno-float128-hardware12:49
lkclyes almost definitely except -mnovsx not nosvx :)12:50
sadoon[m]right :P12:50
lkclif you drop __float128 keyword that might cause problems12:50
lkclbut see how it goes12:50
sadoon[m]probably the software that will heavily depend on that stuff is things like ffmpeg and co.12:51
toshywoshyso I have been working on pcc64lesffs12:51
sadoon[m]I don't think it'll be a problem to start, considering the goal is a usable linux system at first12:51
toshywoshyit will be a miniroot, at least that is what I am calling it for now12:52
*** ghostmansd[m] <ghostmansd[m]!> has quit IRC12:55
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has joined #libre-soc12:55
toshywoshyI build with "-mnoaltivec -mnovsx -mnodirect-move -mnocrypto -mnoquad-memory -mnoquad-memory-atomic -mnopower8-fusion -mnovrsave -mnofloat128 -mnofloat128-hardware -mnoisel -mnohtm"12:56
ghostmansd[m]lkcl, what'd be the right way to fix it in generic way with FieldsOpcode and `def opcode`?12:57
toshywoshythat is what I found in gcc documentation and as it is building on a stripped down qemu, I want to be specific for now12:57
ghostmansd[m]I thought about adopting the mask, so that all its fields where dynamic operands are, become zeroes12:58
ghostmansd[m]But this is sort of hack12:58
ghostmansd[m]Also, it's strange that we have opcode range 21:30, but some fields are occupied by operands12:59
lkclthink again in terms of switch/case statements12:59
lkclif *all* 32 permutations cover BC then it is *as if* there was only the one12:59
lkclit's not a hack13:00
lkclit's a special-case that really does need to be detected13:00
lkcl.... yes.13:00
lkclit can be done with sets13:00
ghostmansd[m]So you think that, when we construct opcode from fields, we need the way to tell "but hey, for this particular instruction, exclude this and that range from mask and opcode, operands are here"13:01
ghostmansd[m]Is it right?13:01
lkcli think it can be algorithmically detected to reduce the mask13:02
lkclit shouldn't have to be hard-coded/special-cased13:02
lkclit *should* be possible to do 1 bit at a time, repeated recursively13:03
lkclgroup by things-that-match-zero and things-that-match-one13:03
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has quit IRC13:04
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has joined #libre-soc13:04
lkcli know there's an algorithm somewhere in there :)13:04
ghostmansdlkcl, I didn't mean some special case for isel. I mean that we'd do this for any instruction.13:07
ghostmansdThere are no groups or recursion needed, though, and doesn't seem like any required.13:08
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has quit IRC13:08
lkclyes agreed: for any instruction.13:09
lkclthe "gotcha" you have to watch out for: svshape would *not* be reduced-mask13:09
lkclthat's the kicker, it's the one to watch out for13:09
*** ghostmansd[m] <ghostmansd[m]!> has joined #libre-soc13:09
lkclbecause the two combinations in the middle, 0b1000 and ob100113:10
lkcltoshywoshy, are you able to help / participate in a non-confidential opcode with general topics "how to reduce opcode pressure" discussion before tuesday 13th?13:12
ghostmansd> because the two combinations in the middle, 0b1000 and ob100113:12
lkcli know it's short notice13:13
lkclghostmansd, those two are allocated to svshape2.13:13
ghostmansdI'll check these specifically13:13
ghostmansdbut these should be fine, since, again, this is on a per-insn basis13:13
ghostmansdthe names are different and we have multirecord for both svshape and svshape213:13
ghostmansdthese don't overlap in insndb13:14
lkcli *know* there's an algorithm that can spot redundant mask-bits. it shouldn't be necessary to hack it special-case13:14
ghostmansdor, well, shouldn't13:14
ghostmansdOK let me play around this code13:14
lkcli know.13:14
lkclok so you have the single-value, right?13:15
lkclyou've found all the "common" bits.13:15
lkclthe common bits between these13:15
lkclso it's dead simple:13:15
lkclmask that out (in a temporary)13:16
lkcland you are left with analysing13:16
lkclwhat you *then* do is also very simple13:16
*** ghostmansd[m] <ghostmansd[m]!> has quit IRC13:16
lkclfirst you count the number of bits (4) in this case13:17
lkclso you know to expect 16 permutations.13:17
lkclyou also know therefore that there will be 8 with zero and 8 with 113:17
lkclyou can take the 1st bit, and break down into 2 lists13:18
lkclone where bit 0 is 013:18
lkclone where bit 0 is 113:18
lkclif they are *EXACTLY* 8 in each list:13:18
lkclta-daaaaa you can ELIMINATE that mask-bit13:18
lkclnow you are at13:18
toshywoshylkcl: yes I think so, I am in the middle of some other work, but in about 2 hours that should be done13:18
lkcltoshywoshy, an initial call with you would be good then we need to arrange a team time.  can you send calendar/zoom/jitsi/whatever invite to me and david?13:19
lkcl(when you're ready)13:19
lkclghostmansd, then you can move to the next bit13:19
lkclfor isel i expect that algorithm to *succeed* and wipe out all 32 entries13:20
lkclfor svshape/svshape2 it should *fail* because svshape2.13:20
lkclthe number of entries will be *7* when they should be *8*13:20
lkclta-daaa :)13:20
ghostmansdFrankly cutting out dynamic operands looks by order of magnitude simpler13:21
lkclawww i really liked that algorithm13:23
lkclit's almost certainly a recipe somewhere online13:23
ghostmansdisel (6, 7, 8, 9, 10)13:29
ghostmansdisel (11, 12, 13, 14, 15)13:29
ghostmansdisel (16, 17, 18, 19, 20)13:29
ghostmansdisel (21, 22, 23, 24, 25)13:29
ghostmansdthat's dynamic operand ranges for isel13:29
ghostmansdI guess if we cut out these bits from the result mask then we're done13:30
lkclno, it's only (21, 22, 23, 24, 25).  the field named "BC"13:30
ghostmansdthis is generic, we can get operands for any instruction13:30
lkclthe others are ignored13:31
ghostmansdI speak about ignored13:31
lkclah yes :)13:31
lkclah... no13:31
lkcl(21, 22, 23, 24, 25) *isn't* ignored... but should be13:31
ghostmansdall should be ignored13:32
lkclthe algorithm above will auto-identify them13:32
lkclyyes true13:32
lkcli mean13:32
ghostmansdbut current code assumes that BC is part of opcode13:32
lkclinsn_db.csv minor_31 entry *already* ignores 6..2013:32
ghostmansdexactly because it doesn't give a shit about dynamic operands13:32
ghostmansdWell in this sense yes13:32
ghostmansdbut it doesn't ignores first bits here ^13:32
lkclwhich from insndb.csv is bits 21-3013:33
ghostmansdit thinks, "oh my, you shown these as opcode!"13:33
ghostmansdand puts these as an established value/mask for opcode13:33
ghostmansdnever giving a single fuck about the fact these are operands13:33
ghostmansdbecause, well, all entries in minor_31.csv have 9 bits13:34
ghostmansdthey don't have a way to tell the code "hey, you know what, isel has some of these shiny 21:30 bits reserved for operands"13:34
lkcl10 :)13:34
ghostmansdcan you follow me13:34
lkcl21-30 inclusive :)13:34
ghostmansdno matter13:34
ghostmansdI don't even think about count13:34
lkclthere are only two types of problems in computing13:35
ghostmansdbut still, do you get what I mean?13:35
lkcland off-by-one errors13:35
ghostmansdMSB0: things done simple13:35
ghostmansd(except for the fact they're not)13:35
* lkcl MSB0 headbanging13:35
lkclok so what's the quick-hack?13:36
ghostmansdI think checking which bits are for dynamic operands is the best shot13:36
lkclahh right13:36
ghostmansdwe already consider static operands to explicitly toggle some bits to be parts of opcode13:36
lkclso you use the fact that it's 32 entries fitting the full 5 bits of BC?13:36
ghostmansdI don't understand the question13:37
ghostmansdanyway, as I mentioned13:37
lkclBC is bits 21:2513:37
lkclisel      RT,RA,RB,BC13:37
lkcl     31   RT     RA     RB    BC    15  /13:37
lkcl0       6     11     16    21    26    3113:37
ghostmansdcurrent code just blindly takes the whole opcode it got from csv13:37
ghostmansdand doesn't bother to check whether it should use all bits there13:38
ghostmansdthe whole CSV structure implies it should13:38
ghostmansdbut in fact for isel (maybe others too) some of these fields are _not_ opcode13:38
ghostmansdor, well, some of these _bits_ correspond to _operands_13:38
ghostmansdso this is the reason why the algorithm as it stands is incorrect13:39
ghostmansdand leads to wrong results13:39
lkclyes.  and you have to have *exactly* 2^{length-of-operand} entries in the switch/case to say so13:39
lkclit is *guaranteed* that to get that field to be ignored you *absolutely must* have 2^{length-of-operand} entries in the database13:39
lkclBC is 5 bits13:39
lkcltherefore there are 2^5=32 entries13:40
lkclsvshape is 4 bits13:40
lkcltherefore there should be 2^4=16 entries but there are *NOT* 16 entries there are only 14.13:40
ghostmansdagain: it has nothing to do with BC or isel or svshape; this is a general fault.13:40
ghostmansdThe code _must_ consider which operands are present in mask (static, those which are _part_ of the opcode)13:41
ghostmansd...and which are absent (dynamic)13:41
lkclindeed. so that was why i suggested the algorithm for auto-detecting the dynamic parts13:41
ghostmansdThis is not obvious.13:41
lkclthe current scheme has already detected the static part13:41
lkcli know :)  i'm thinking it through, sitting here with a monster headache, sigh13:42
ghostmansdHowever, when you see below "if bit is in static_operand: mask[bit] = 1"13:42
lkcl(not a metaphor)13:42
ghostmansdthen if you see "if bit in dynamic_operand: mask[bit] = 0"13:42
ghostmansdit is crystal clear what happens13:42
lkcli think we are likely talking about exactly the same thing13:42
ghostmansdespecially if you recall you're in the code which constructs the opcode and its mask13:43
ghostmansdyeah likely13:43
ghostmansdbut in different terms13:43
lkcltell you what, go for it.13:43
* lkcl have to get on, lots to do13:43
ghostmansdgive yourself a rest13:43
ghostmansdthere's no point working if you're exhausted13:44
ghostmansdI'll think how to make this code good. We have even more reasons to do it.13:49
ghostmansdYou probably recall pysvp64asm custom instructions?13:49
ghostmansdThere's no point at all in them at this stage. And, cough, even in outputting "vanilla" instructions.13:50
ghostmansdWe have _that_ much information that we can build a real assembler.13:50
ghostmansdOr well, in our case, rather, translator.13:50
ghostmansdThis needs at least assemble() method for each operand type, but, other than that, it's almost near.13:51
*** octavius <octavius!> has joined #libre-soc13:52
ghostmansdThat said, I won't do it in this scope, this still a damn big task and I cannot be distracted at this point.14:00
*** ghostmansd[m] <ghostmansd[m]!> has joined #libre-soc14:07
ghostmansdLuke you don't really have to do this whitespace cleanup this way14:40
ghostmansdI do it the way I did for a reason14:40
ghostmansdin no way this is a cleanup, it actually hurts14:40
ghostmansd-                sv_extra, field = crf_extra(etype,14:41
ghostmansd-                    rname, extra_idx, regmode, field, extras)14:41
ghostmansd+                sv_extra, field = crf_extra(etype, rname, extra_idx,14:41
ghostmansd+                                            regmode, field, extras)14:41
ghostmansdNow assume the name of the function changes14:41
ghostmansdOr the return value changes14:41
ghostmansdWhat next? Yet another cleanup?14:41
ghostmansdPlease stop doing this, it _hurts_ the maintainability.14:41
ghostmansdYou literally force to do work twice.14:42
ghostmansdSimply indent one level, that's simple and sweet. In some cases -- two (e.g. split if statement).14:42
ghostmansdIf the editor does it for you, please, replace this option with something sane.14:47
ghostmansdFound more issues in our CSVs with insndb: rldcl/rldcr should have MDS form. Pushed to master.15:00
lkclghostmansd, it's actually an alignment with autopep8 - the bracket is the marker - and after 20 years i've gotten used to it15:00
lkcli've always been confused by non-vertical-whitespace-layout (over 25 years)15:01
ghostmansdNot anything written in pep8 should be considered as ultimate guide.15:01
lkclooo MD/MDS-Form mistake, ooo15:01
lkcllet me double-check that15:01
ghostmansdIt's MDS in spec.15:02
ghostmansdAnd MDS in mdwn.15:02
lkclahh okaay.15:02
ghostmansdWe should cross-check it, too.15:02
lkclyes i remember adding the Forms to CSV, by hand15:02
ghostmansdPerhaps one day I'll add some validation inside the record.15:02
lkclRotate Left Doubleword then Clear Left15:02
lkcl                              MDS-form15:02
lkclRotate Left Doubleword then Clear Right15:03
lkcl                              MDS-form15:03
lkclyep all good15:03
lkcllet me re-run unit tests to make absolutely sure15:03
ghostmansdI wouldn't have pushed any change in CSVs to master otherwise.15:03
ghostmansdThis bit is too critical to fuck up.15:03
lkclohh yes15:03
ghostmansdPerhaps there are more, I'm still checking. This is slow and annoying process.15:04
ghostmansdFound by an accident, now re-using the same happy accident over and over again.15:04
lkclnow imagine what it was like the first time15:04
lkclwhen there were like 25+ mistakes / missing-things in the v3.0B spec...15:04
lkclit's taken months - so don't make it a critical-path priority15:05
ghostmansdIt's currently a show stopper if there are some fields declared but not present.15:07
ghostmansdThis was exactly how I found it -- RB was reported in operands but was missing in fields.15:07
ghostmansdSo I checked the form, and -- boom! -- it was wrong.15:07
ghostmansdThis now has to be priority #1. No other option.15:07
lkclha, this is actually good15:09
lkcla suite of instructions is needed. unit-test style.  using openpower/simulator/'s Program() generate_instructions() function15:10
lkcland throwing them through pysvp64dis15:10
ghostmansdandi./andis. are wrong too15:11
ghostmansdthey should've been D form15:11
ghostmansdAND Immediate Shifted D-form15:11
ghostmansdAND Immediate D-form15:11
lkclwant me to do it?15:11
ghostmansdno that's fine15:11
ghostmansdit's actually good because it helps me somewhat to ensure all operands/fields are OK15:11
ghostmansdI'm basically running my code and whenever it fails look at the spec15:11
lkcly'know what? i'll write that mini-test-program15:12
ghostmansdwhich one?15:12
lkclit won't take 5 mins15:12
ghostmansdyou mean validation?15:12 using's Program()15:12
lkcland an SVP64Asm() instance15:12
ghostmansdthis one15:12
ghostmansdgood thing, appreciate that15:13
ghostmansdternlogi is fucked too15:13
ghostmansdI'm currently checking why15:14
ghostmansdeeeeeehm what the15:14
ghostmansdall of RT/RA/RB are empty15:14
lkcl1 sec15:15
ghostmansdno TLI form??15:15
ghostmansdah yeah here it is15:15
ghostmansdhm this one should be fine, what the hell15:16
ghostmansd    Form.TLI15:16
ghostmansd    DynamicOperandGPR(name='RT')15:16
ghostmansd    DynamicOperandGPR(name='RA')15:16
ghostmansd    DynamicOperandGPR(name='RB')15:16
ghostmansd    DynamicOperand(name='TLI')15:16
ghostmansd    [(True, 0x00000005, [0:5]), (True, 0x00000000, [21:31]), (False, 0, None), (False, 0, None), (False, 0, None), (False, 0, (21, 22, 23, 24, 25, 26, 27, 28))]15:16
ghostmansdNone stands for "hey I couldn't find the operand in fields.text"15:16
lkclgimme sec15:16
lkclyep i know why15:17
lkclnot added to fields.txt15:17
ghostmansdah, RT needs Formats: TLI15:17
lkclon it15:17
ghostmansdOK :-)15:18
ghostmansdI also understood already15:18
ghostmansdfeel free to push, ping me to rebase my branch15:18
ghostmansdall three, RT, RA, RB15:18
ghostmansdOK, more: rldicl, setb, svshape2, fishmv15:41
ghostmansdplease especially check fishmv changes: I had to introduce the field based on how I understood what it does15:42
lkclnope can't do that15:43
lkcl1 sec15:44
lkclok "D" is one of those exceptions, like target_addr and DCMX15:44
ghostmansdfp32[16:31] <- d0 || d1 || d215:45
ghostmansdHow comes?15:45
lkclyes.  so that's why d0 d1 d2 exist15:45
lkcllike target_addr15:45
ghostmansdbut this is the same15:45
ghostmansdas concatenating these15:45
lkclthe "D" is...15:45
lkclyes it is (that's deliberate)15:45
lkclbut D is in a totally different order15:46
ghostmansdwhat do you mean?15:46
lkcl    d0,d1,d2 (16:25,11:15,31)15:46
lkcl        Immediate fields that are concatenated to specify a15:46
lkcl        16-bit signed two's complement integer which is15:46
lkcl        sign-extended to 64 bits.15:46
lkcl        Formats: DX15:46
ghostmansddeclaring one huge D in order as d0,d1,d2 are followed looks the same15:47
lkclnote d0 d1 d215:47
lkclnote the bit-order15:47
ghostmansdAaah fuck15:47
lkcld0 = 16:2515:47
ghostmansdyeah now I see15:47
lkclhas to be a custom field, like target_addr15:47
ghostmansdWhy don't simply use D?15:47
lkclbecause that doesn't match with existing HDL15:47
lkclwhich would mean an addition of MUXes15:48
ghostmansdit has to do with some hardware limitations?15:48
lkclwhich is expensive in gates15:48
lkclusing the *existing* d0||d1||d215:48
lkclthat HDL path (existing gates) can be used15:48
ghostmansdOK gotcha15:48
lkclit's not like software15:48
ghostmansdOK then, please update it as you mentioned above15:48
lkcldone, i reverted the addition of D15:48
lkclit has to be done like target_addr.15:49
lkclthere will be... maybe 1-2 more like that15:49
ghostmansdplease keep the commit name!15:49
lkclwell spotted15:49
ghostmansdthis is totally essential15:49
ghostmansdotherwise won't work15:49
ghostmansdwon't move15:50
lkclhuhn? don't quite follow15:50
ghostmansdAuthor: Dmitry Selyutin <>15:50
ghostmansdDate:   Fri Sep 9 17:28:30 2022 +030015:50
ghostmansd    fields.text: this fish ain't moving15:50
lkcldo you mean "when running git revert xyz"?15:50
ghostmansdah OK it's kept15:50
ghostmansdjust wanted to keep it for lulz15:51
ghostmansdOK I think I went through all of them15:51
ghostmansdplease ping me when fish moves15:52
lkclit's done.15:52
lkclyou'll need to now add it as a custom field15:52
lkcllike target_addr15:52
ghostmansdAh OK15:53
lkclwhen any other d0||d1||d2 instruction comes along, the same custom-D-Field will be needed there, too15:53
lkcl    D <- d0||d1||d215:54
lkclthat's where i got the idea for d0/1/2 from15:54
lkclenumerating the list of instructions from load() actually manages to... ahh the file needs a seek back to zero15:56
lkcli need to add a "short" option to insn.disassemble()16:00
lkclto get only the operation, not the hex16:00
ghostmansdwhat do you mean by operation?16:01
ghostmansdah got it16:01
lkcl19 24 2f 5b    svshape2 12,1,15,4,0,016:01
lkcli need just16:01
lkclsvshape2 12,1,15,4,0,016:01
ghostmansdbetter add some method perhaps16:01
ghostmansdbu up to you16:01
lkclbtw there's an off-by-one on that 4 (should have been 5)16:02
lkclbut that's not surprising, it's one of those SVd thingies16:02
ghostmansdthere's already verbose argument16:02
lkcli need a "totally short" arg16:02
ghostmansdthis will need a separate operand16:02
lkclindeed. later16:02
*** ghostmansd[m] <ghostmansd[m]!> has quit IRC16:09
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has joined #libre-soc16:10
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has quit IRC16:18
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has joined #libre-soc16:18
ghostmansd[m]Perhaps we need level16:19
ghostmansd[m]Not short and verbose16:19
programmerjaketurns out SVP64-Single is in the wiki, gitweb grep is case sensitive (with no apparent option for case insensitive). it still has no explanation of what it actually does tho...16:19
ghostmansd[m]Please do it as enum16:19
lkclghostmansd[m], i'm in a rush, i'll get to it later if you suggest something better16:20
lkclprogrammerjake, yes correct.  it's to make it possible to reach all the regs16:21
lkcland is a *scalar*-only instruction (single, duh)16:21
lkclbut can still have predication (one bit)16:21
lkcland element-width overrides16:21
lkclonly single-predication not twin-predication16:22
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has quit IRC16:22
*** ghostmansd[m] <ghostmansd[m]!> has joined #libre-soc16:23
programmerjakehmm, ok...imho it wouldn't need a full 24-bit rm then, 20-ish bits should be completely sufficient, and save tons of encoding space16:23
lkclunfortunately 4-bits per reg are needed (CR fields)16:24
lkclso that's a minimum 4x3 = 12 bits16:24
programmerjakei was counting 12-bits of reg fields -- 3 each for 4 madd args16:25
ghostmansd    def disassemble(self, insn, record, field, verbose=False, indent="",16:25
ghostmansd                                               short=False):16:25
ghostmansdLuke will you PLEASE stop doing this??16:25
lkclghostmansd, i don't know what convention you need me to use16:25
lkcland i'm on the clock16:25
lkclso i must apologise, but please don't go nuts about it - please be patient and just set them to what you want/need16:26
ghostmansdexactly as I asked: simply indent 1 level, 2 if there's something indented below16:26
lkcli *have* to keep to under 80 chars16:26
ghostmansdYes but not the cost of turning it into a crap16:26
ghostmansdI'll fix it16:26
lkclbut this is a completely different convention from everything i've used for 20 years16:26
lkclgot meeting in 3mins hence why i'm rushing16:27
ghostmansdyou don't need short everywhere BTW :-)16:27
ghostmansdAaaah I see, you used it in operands too16:27
programmerjakeimho it's better to just use autopep8 and not argue with each other about it...even if it's not our favorite, it's mostly consistent and automated...16:28
programmerjakeand because it's the de-facto python style, most will have an easier time reading it16:30
ghostmansdit turns code into the shit with these idiotic spaces16:30
ghostmansdso no, it's not16:30
ghostmansdif there's an option to tune it -- I'm OK16:31
programmerjakelkcl: if your meeting's about opcode space, please look at
ghostmansdDon't even try to convince me this is readable16:33
ghostmansd    def disassemble(self, insn, record, verbose=False, prefix="", indent="",16:33
ghostmansd                                        short=False):16:33
programmerjakei actually think all the indentation is better because both it's visually lined up with other relevant parts, and it's automated so you don't have to manually line anything up16:33
ghostmansdit is NOT16:33
ghostmansdand it's not maintainable16:33
programmerjakewell, if i were reading this in a monospace font, it looks fine to me...16:34
ghostmansdagain: unless this is enforced by repository, I won't support it16:34
ghostmansdOK put it to monospace font16:34
ghostmansdwhat the fuck do you think I have in editor, Comic Sans?16:34
ghostmansdobviously it's monospace16:34
programmerjakeno, i meant in irc16:34
ghostmansdit looks awful anywhere16:35
ghostmansdagain: if you want me to follow this idiotic pattern, then enforce it16:35
ghostmansdotherwise I won't do something which makes code less readable in my opinion16:35
programmerjakeuuh, is that really what autopep8 put out? looks like it's missing some spaces on the first line you posted...16:37
programmerjakethe arguments on the 2nd line are supposed to be lined up with the lparen or the comma after self...16:37
ghostmansdperhaps that's not autopep816:38
ghostmansdanyway, if autopep8 aligns in a similar fashion, this is wrong16:38
ghostmansdbecause it is not maintainable16:38
ghostmansdagain: such idiotic indentation depends on function results, on naming, and other factors16:38
ghostmansdcompared to that, a fixed indentation has no such limits16:39
ghostmansdindent once unless there's an indentation below already; if there's, indent twice16:39
ghostmansdit's as simple as it gets16:39
programmerjakenever seen autopep8 put out that particular atrocity...16:40
ghostmansdno bullshit like "OK name's 5 characters so I'll put 5 + 1 spaces"16:40
ghostmansdit's not autopep8, this is a common sense16:40
programmerjakeit's usually pretty reasonable, tho it likes to line up with stuff (which you seem to dislike).16:41
ghostmansdif you use some tools for autoformatting -- please tune then appropriately to keep it readable AND maintainable16:41
ghostmansdit's like indenting names and types in structures16:41
ghostmansdor indenting by name and = sign16:41
programmerjakei use autoformatting tools, but i've tuned them to usually only format lines i'm modifying anyway...16:42
ghostmansdit's much more than some brain-dead autopep816:42
ghostmansdindentation must be systematic16:42
ghostmansdsure there might be some flexibility16:42
ghostmansdbut for sure it should not be fragile and dependent on factors like length of variable name or function arguments or other idiotic reasons16:43
ghostmansdOK rant's over16:43
programmerjakeautopep8 is particularly braindead for an autoformatter imho, it should be more like rustfmt where you can type any arbitrary junk whitespace wherever and it always outputs the same thing (or nearly always) -- kinda like canonicalizing it.16:44
programmerjakealso if autopep8 needs to split a line, it tends to pick terrible spots to split it16:47
ghostmansdI used gofmt16:47
ghostmansdI don't like go or its formatter16:47
ghostmansdbut it was enforced16:48
ghostmansdand there it made sense16:48
programmerjakegofmt is much more like rustfmt where basically everyone uses it, unlike c where it's like a rite of passage for beginning programmers to invent their own incompatible format16:49
ghostmansdwell for C it can also be enforced16:50
ghostmansdand in some project IS16:50
programmerjakeyeah, but in at least the textbook i read they basically said to invent your own style. imho that's terrible advice -- consistency is waay better and clang-format probably supports the consistent style so you don't have to take twice as long to get the spacing just right16:52
ghostmansdC is just somewhat more liberal I think16:54
ghostmansdbut at least even the code in book which suggests to invent your style is more readable than the spacing produced by pep816:55
programmerjakeimho it just makes it harder to read if every line of code has it's own unique style16:55
programmerjakeimho autopep8's output is pretty readable, as long as you manually break lines yourself where it messes up16:56
programmerjakeexample output:;a=blob;f=src/openpower/test/algorithms/;h=afcbde6809917ba138a15dad733ade4411b75a3e;hb=HEAD16:57
programmerjakeidk if anyone noticed...Global Foundaries released a 180nm open source PDK:
ghostmansdI don't say it's unreadable (or, well, perhaps it sometimes is, but that's not my point). I say it is not maintainable unless enforced.17:09
ghostmansd  57     AllActualErrors = (TooLong | TooShort | Overlong2 | Surrogate |17:09
ghostmansd  58                        Overlong3 | Overlong4OrTooLarge | TooLarge)17:09
ghostmansdIf one day length of any of these fields changes, you'll have to update two lines17:09
ghostmansdOr even the whole thing will be fucked by autoformatter, depending on moon phase.17:09
ghostmansdAllActualErrors = (TooLong | TooShort | Overlong2 | Surrogate |17:10
ghostmansd                   Overlong3 | Overlong4OrTooLarge | TooLarge)17:10
ghostmansdSomeActualErrors = (TooLong | TooShort | Overlong2 | Surrogate |17:10
ghostmansd                   Overlong3 | Overlong4OrTooLarge | TooLarge)17:10
ghostmansdDue to a single byte you already have to touch the line below.17:10
programmerjakewell, at least for me, it's enforced, because i have my editor set up to format on save17:14
programmerjakeimho lkcl needs format on save too...17:15
*** octavius <octavius!> has quit IRC17:23
ghostmansd> I say it is not maintainable unless enforced.17:27
ghostmansdI don't say suck spacing is sane even if enforced.17:27
ghostmansdlkcl, I switched the whole thing to verbosity levels17:28
ghostmansdPerhaps we'll have more information to pass there, or maybe even fiter stuff one day via some mask.17:28
ghostmansdBut it's still better to having two mutually exclusive options -- short and verbose -- as arguments in fuctions.17:29
ghostmansdlkcl, about the fishmv: perhaps you'd like to name argument differently, to avoid confusion? D naturally makes one think of, well, D. target_addr, on the other hand, had the advantage it was clearly unusual even by its name.17:51
*** markos <markos!> has quit IRC17:58
*** markos <markos!> has joined #libre-soc17:59
ghostmansdFor now I went with D; there also was fmvis.18:27
*** octavius <octavius!> has joined #libre-soc19:08
lkclit is completely ironic that autopep8, in this one area, is a total screw-up.19:21
lkclwhewwww one meeting over, then another one19:21
lkclthen a long message trying to...19:21
* lkcl head spinning19:21
lkclso now there's an actual unit test for addi and svshape2 as starting points19:24
ghostmansdaaaaaand actually this is the one I'm debugging now :-)19:24
ghostmansdit's not matched (perhaps matched in master, though; I didn't check it in master)19:25
lkclcorrect, it doesn't match19:27
lkclthat's SVd being reported off-by-one19:27
ghostmansdnot only this I think19:29
ghostmansdthe entire opcode looks doomed too19:29
ghostmansddamn, I finally gave up and printed some tables to calculate bits19:30
ghostmansdwas too lazy to draw them by hand19:30
lkcldoomed, dooomed i say19:51
lkclghostmansd, unfortunately, D is already in use by addpcis20:07
lkcland that's part of the spec20:07
ghostmansdSorry, I'm out of context. What do you mean? I haven't touched the reverted commit.20:07
ghostmansdInstead I just did this:20:08
lkclfishmv RT,D20:08
ghostmansd"fishmv": {"D": DynamicOperandDDX},20:08
lkcladdpcis RT,D20:08
ghostmansd"fmvis": {"D": DynamicOperandDDX},20:08
lkclp66 v3.0C "Add PC Immediate Shifted"20:08
lkclsection 3.3.920:08
lkclso that'll also need20:10
lkcl"addpcis": {"D": DynamicOperandDDX},20:11
ghostmansdAh OK20:19
*** ghostmansd <ghostmansd!> has quit IRC23:50

Generated by 2.17.1 by Marius Gedminas - find it at!