Sunday, 2022-09-18

*** lxo <lxo!> has quit IRC08:23
*** josuah <josuah!~irc@> has quit IRC08:31
*** ghostmansd <ghostmansd!> has joined #libre-soc09:18
ghostmansd[m]I added support for ew for normal, ld/st imm and ld/st idx modes09:21
ghostmansd[m]dis test is fine now09:21
lkclecho -n -e '\xe0\x34\x44\x05\x15\x12\x01\x7c' | pysvp64dis -v09:24
lkcle0 34 44 05    sv.add./ew=32 *r2,*r4,*r1109:24
lkcl15 12 01 7c09:24
*** josuah <josuah!~irc@> has joined #libre-soc09:34
ghostmansd[m]Added sw09:34
ghostmansd[m]Plus test, merged to master09:34
lkclthere's supposed to be one which is a short-cut for both ew= and sw= if they are the same09:36
lkclbut it looks like i didn't add it to sv/trans/svp64.py09:37
lkcllike m=09:37
lkclbut w=09:37
lkcloh well09:37
lkcltest pass confirmed09:38
lkcldoing test_caller_* to make sure09:38
ghostmansd[m]We only have sw and ew09:38
ghostmansd[m]Not dw09:38
lkclyeah i know09:39
lkclthat's a minor omission09:39
ghostmansd[m]And ew sets destwid09:39
ghostmansd[m]I do what I see :-)09:39
ghostmansd[m]If there are errors in asm or docs, these must be fixed first09:40
lkclyep. like sm= and dm= has m= to set both, the names should be consistent here09:40
lkclwhen i'm more awake :)09:40
ghostmansd[m]I suggest having sw, dw and w09:40
ghostmansd[m]Like we have sm, dm and m09:40
ghostmansd[m]e in ew would be redundant then09:41
lkclyep agreed09:45
lkclnow's the time to do it, before going much further09:45
* lkcl sorting that in sv/trans/svp64.py09:49
ghostmansd[m]Cool, will adjust dis, 1 sec09:54
ghostmansd[m]Oh, by the way. We should output w= if sw==ew, and both are non-zero, right?09:55
ghostmansd[m]Note by the way that our instructions can have several equivalent representations (not only order of specifiers is irrelevant, but also /w=32 is the same as /sw=32/dw=32).09:56
ghostmansd[m]I'm not saying it's incorrect, just explicitly stating the obvious.10:00
ghostmansd[m]Rebased master with w/sw/dw support in dis10:04
ghostmansdlkcl, could you, please, share an example of instruction which supports /svm?10:42
ghostmansdCurrently I come up with "sv.add./vec4/mrr/svm *3,*7,*11"10:42
ghostmansdOr vec2/vec310:44
ghostmansdHm, it seems the RM for these cannot be deduced10:45
programmerjakelkcl: apparently if you build the latest git version of highlight it will make gitweb highlight python f-strings correctly:
programmerjakeor, if not correctly, at least better11:05
ghostmansdlkcl, did you change
ghostmansdBecause I see that it seriously contradicts the code we have now, so I was either _really_ confused, or the docs were updated.11:21
ghostmansdAha! There's no longer parallel reduce mode.11:21
ghostmansd[m]Sigh. Totally revamped.11:32
ghostmansd[m]Is it at least actual and stable enough?11:32
ghostmansdUpdated the disassembly.11:34
ghostmansdI also suggest we have a separate column corresponding to field names.11:35
lkclghostmansd, yes, if both equal then output m=.11:39
ghostmansddone already :-)11:39
lkcli haven't added anything with svm (subvector mode)11:39
ghostmansdwell still I must check whether it works11:40
ghostmansdbecause we have it both in docs and asm11:40
lkcli do keep cut/pasting the markdown tables from the spec into the source code11:40
ghostmansdI don't understand why you do it, though11:41
lkclbut there are about 3 copies so it is hard to get them all11:41
lkclbecause i have memory problems11:41
ghostmansdbut you could put a link11:41
ghostmansdthese rot pertty fast11:41
lkclit doesn't help11:41
ghostmansdOK up to you11:41
ghostmansdI look at the docs on the site, though11:41
lkcli am literally unable to view one page then go to another and recall what it was that was on the page that i saw 5 seconds ago11:41
lkclthis is not a joke11:42
lkclit is something i have observed as a slightly scary problem for over 10 years11:42
lkclflicking back and forth five to six times between two pages is not enough to get the information into short-term recall11:43
ghostmansdOK, please do it as you find convenient and helpful11:43
ghostmansdno objections then11:43
ghostmansdI mostly look at the docs though11:43
ghostmansdand only check asm when in doubts11:43
lkclonly when they are literally right there in front of me can i recall it.11:43
lkcl(hence why keeping code to a single page, and to under 80 chars, is critical for me)11:43
lkclyes it's a pain11:44
lkclthe fuckups are down to trying to implement things that were only found to be unworkable *by* actually implementing them11:44
lkclpack/unpack has been particularly... obstreperous11:45
lkclparallel-reduction was put in *over two years ago* and has only just been noticed (last week?) as being impossible to implement except as a REMAP!11:45
lkcli don't anticipate any other idiocies being detected, although cannot say for sure :)11:46
ghostmansdno I'm OK with this :-)11:48
ghostmansdit's just slightly inconvenient that this happens in the middle :-)11:49
ghostmansdbut, on the other hand, it _is_ convenient, because this stuff is easily spotted11:49
ghostmansdI have no idea how the mr/mrr/svm correspond to mapreduce_*** and
ghostmansdit's all way too hairy11:54
ghostmansdI found that "sv.add./mrr/vec2 *r3,*r7,*r11" is diagnosed as "scalar reduce mode", and this is what I expected11:55
ghostmansdTo set /svm, I must choose subvl 2/3 (not 1 and not 0), this is fine, and I'd have expected "sv.add./vec4/svm *3,*7,*11" to work11:57
ghostmansdHowever, it doesn't: `AssertionError: sub-vector mode in mapreduce only`11:57
ghostmansd"OK", I thought, and then added /mrr to that assembly: "sv.add./vec4/mrr/svm *3,*7,*11"11:58
ghostmansdBingo, this worked, the mode is diagnosed "normal: subvector reduce mode, SUBVL>1", exactly like I expected.11:58
ghostmansdBut guess what? I cannot output "/mrr" back to disassembly, because there's no such thing as RG in "normal: subvector reduce mode, SUBVL>1"11:59
*** ghostmansd <ghostmansd!> has left #libre-soc11:59
*** ghostmansd <ghostmansd!> has joined #libre-soc11:59
ghostmansdSo yeah, this is a problem, and I don't understand how it's supposed to work. Either I totally miss something obvious, or opmodes need an update, or pysvp64asm code which checks the condition must be updated, or the docs contradict to the implementation.12:01
ghostmansdlkcl ^ this is important12:01
ghostmansdFWIW, I pushed the dis branch, so you can experiment12:01
ghostmansdThese mapreduce modes also introduce an unused variable (cf. opmodes section) and, like the modes in is_bc section, seem pretty half-baked.12:03
ghostmansdI'm judging from the fact that many variables are not used at all, very little code uses these, and in overall they seem less organized than other stuff.12:06
ghostmansdlkcl, how about changing SVmask_src to a simple boolean?12:47
*** ghostmansd <ghostmansd!> has quit IRC12:51
lkclsubvector mode is on vec2/3/413:55
lkcli.e. when the 2 bits are non-zero13:56
lkclvec2/svm MUST work13:56
lkclvec3/svm MUST work13:56
lkclvec4/svm MUST work13:56
lkclanything else is a bug13:56
lkclSVmask_src - boolean - no problem at all13:56
lkclsubvl on RG... argh of course13:57
lkcland that's also why Pack/Unpack had to be removed13:58
lkclsiggh ok13:58
lkclsvm has to be removed.13:58
ghostmansd[m]Ok I had a feeling there's something wrong14:02
ghostmansd[m]> vec2/svm MUST work14:02
ghostmansd[m]> svm has to be removed14:03
ghostmansd[m]Sorry, I could not resist and literally laughed :-D14:03
lkclsuch irony...14:14
lkclghostmansd[m], looking at actually it could be made more like the other modes, now14:24
*** ghostmansd <ghostmansd!> has joined #libre-soc14:27
lkclsvm removed from sv/trans/, removed /svm and /mrr/svm14:35
lkclbut added a (missing) /mr mode test14:35
ghostmansd[m]...which we don't have yet :-)14:35
ghostmansd[m]But OK14:35
lkclyes it's there14:35
ghostmansd[m]I'm checking predicates14:36
lkclah ok14:36
ghostmansd[m]I mean disassembly14:36
ghostmansd[m]I saw it in pysvp64asm14:36
ghostmansd[m]Just no dis support yet14:36
ghostmansd[m]I'll do it after predicates14:36
lkclcan i safely get rid of svmr without git-diff-conflict?14:36
lkclshould be ok, just checking14:37
ghostmansd[m]I think I can drop commits about it14:37
lkclbye bye class NormalSubvectorReduceRM?14:37
lkclon it14:38
ghostmansd[m]Ah you mean that14:38
ghostmansd[m]Not smr mode14:38
lkcl    svmr: NormalSubvectorReduceRM gone14:38
ghostmansd[m]OK but keep in mind that we need to tune the select function, too14:38
lkcl    svmr: CROpSubvectorReduceRM gone14:38
lkcli'm just going to carefully excise them14:38
ghostmansd[m]Kill it with fire! 🔥14:39
ghostmansdfor predicates... am I right that we simply check mmode (0/1) and then check smask/mask?14:41
lkclthere is only one mmode.14:41
ghostmansdYep, 0/1 are values14:41
ghostmansdOK, and the logic is like with sw/dw/w?14:41
lkclyou need to check the CSV "2P" to find out if mask is active14:41
ghostmansdif ptype == '2P':14:41
lkcllike that new SVmask_src thing.14:41
ghostmansd            # source pred: bits 16-1814:41
ghostmansd            svp64_rm.smask = smask14:41
lkclhang on...14:42
lkclno it's SM14:42
lkclcheck the (new) SM field14:42
ghostmansdNope I mean 2P check14:42
lkclirony is, having added that SM field, i bet you it's synonymous with 2P14:42
lkclsometimes i am an idiot.14:42
lkclyes of course it's 2P.14:42
ghostmansdthat's OK :-)14:42
lkclwhy did i frickin well add SM??14:42
* lkcl whyyy god whyyyyy14:43
* ghostmansd literally crying to the sky together14:43
ghostmansdOK so I'm checking ptype14:43
ghostmansdwe have it in record14:43
ghostmansdif ptype is not 2P, what're our actions?14:44
ghostmansdAssume we have only dmask?14:44
ghostmansd1 sec14:45
lkclno, it applies as both source and dest mask14:45
lkcltherefore best to call it "m="14:45
ghostmansdso, if P2, then we have both smask and dmask, and output either sm+dm or m (if these are equal)14:45
ghostmansdotherwise we only have m?14:45
ghostmansdOK, got it!14:45
lkclexactly like with elwidths14:45
ghostmansdthanks for the explanation14:45
lkclgit pull btw14:45
ghostmansdwow, even no conflicts14:46
* lkcl snorts14:46
lkclbtw if it's ok with you i'm going to do a code-morph on RM.select14:46
lkclto a single-level hierarchy14:46
ghostmansdperfectly fine with me14:47
ghostmansdbecause this code is a real piece of crap14:47
ghostmansdand I'm tired of adopting it to docs lol14:47
ghostmansdfuck now I realized specifiers are property14:47
ghostmansdand don't have record here...14:47
ghostmansdlkcl, one more question15:00
ghostmansdif mmode == 0 (non-CR-predicate)15:00
ghostmansdand mask or smask is 0...15:00
ghostmansdwhat would it be?15:00
ghostmansdaha ok15:01
lkclthat's "no predicate at all"15:01
ghostmansdexactly as I thought15:01
lkclbut you *have* to have both mask *and* smask zero for that (in 2P)15:01
lkclbut just mask and mmode zero (in 1P)15:01
ghostmansdany Twin-predicate op?15:04
ghostmansdAssertionError: source-mask can only be specified on Twin-predicate ops15:05
ghostmansdyet another battle to assembler lost15:05
ghostmansdtried the whole set of whistles and bells: sv.add./vec2/mrr/sm=r3/dm=r10 *3,*7,*1115:06
lkcloooOoo :)15:06
lkclgive me 1 sec15:06
lkclthat looks fuuun15:06
ghostmansdm= works15:06
lkclsv.add should... hang on..15:06
lkclha, yes, it's 1P15:07
lkclthat's correct!15:07
ghostmansdlol we managed to disassemble this! `sv.add./mrr/m=r3/vec2 *r3,*r7,*r11`15:08
lkclok table-of-mask-values15:08
lkclfrickin ellfire!15:08
lkclgit pull15:08
ghostmansd1 sec15:08
ghostmansdthis has to be pushed first15:08
ghostmansdDoes NormalSaturationExtRM no longer exist?15:09
ghostmansdgot a conflict15:09
lkclcorrect it doesn't.15:09
ghostmansdbut why? it's not svm-enabled15:10
ghostmansdand we discussed those15:10
lkclit was subvl>115:10
lkclbye bye...15:10
lkclstomped on with attitude15:10
ghostmansdaaaah right15:10
ghostmansdOK I pushed15:11
ghostmansdI wanted to add some tests, but, after some thoughts, I decided I'd like to sort specifiers first15:11
ghostmansdthis will likely need the tests to be fixed15:12
ghostmansdby the way I haven't checked the tests yet15:12
lkcl1 sec15:12
ghostmansdhm, broken15:13
ghostmansdsome mumbling about /mr15:13
ghostmansdaaah this one is not there yet15:14
ghostmansdOK need to take a rest for a while15:14
lkclyep time to run tests anyway15:14
ghostmansdCool! Cool cool cool.15:16
*** ghostmansd <ghostmansd!> has quit IRC15:21
*** ghostmansd[m] <ghostmansd[m]!> has quit IRC15:32
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has joined #libre-soc15:35
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has quit IRC15:47
*** ghostmansd[m] <ghostmansd[m]!> has joined #libre-soc15:48
*** octavius <octavius!> has joined #libre-soc15:48
*** ghostmansd <ghostmansd!> has joined #libre-soc16:00
ghostmansdlkcl, new tables look real cool16:08
ghostmansdI formatted the code a bit16:08
lkclworking towards svrm_fields.txt basically16:08
lkclahhh errr16:08
ghostmansdindents and whitespaces16:09
lkclok then i need to do merge/pull16:09
lkclurk 1 sec doing branch16:09
ghostmansdyeah these are just whitespaces and indents16:09
ghostmansdnothing serious16:09
ghostmansdjust so that code looks like everything around16:09
lkclalso means you went over it16:09
lkcli do that :)16:10
ghostmansdI'm moving at ffirst/predresult16:10
ghostmansdby the way16:10
ghostmansdelif encmode == 'zz': # TODO, a lot more checking on legality16:10
ghostmansd    dst_zero = 1      # NOT on cr_ops, that's RM[6]16:10
ghostmansdelif encmode == 'sz':16:10
ghostmansdShouldn't zz also set src_zero?16:11
lkclyyyees it should16:11
ghostmansdOK, I'll push it16:11
lkclback to branch-table16:11
lkclso like, *literally* those tables could be blatted into a csv file, now.16:17
lkclbranch done16:18
lkclconflict sorted16:22
lkclanyway the idea behind doing as tables is, quite obviously, that they then become part of the actual spec16:22
ghostmansdyeah that'd be the best options16:23
ghostmansdwe don't have VLi support it in assembly it seems16:25
ghostmansdI'm ignoring this for now16:25
lkclno, correct. nor ctr mode.16:25
lkcli need time to do the full modes in the Simulator for sv.branch16:26
lkclholy cow that's going to be one hell of a lot.16:26
lkclit's *512* separate and distinct options16:26
lkcli lied - 2^1116:27
lkclholy shit 2048 unit test16:27
lkclper instruction, sv.bc sv.bcl, sv.bclr, sv.bcctr...16:28
ghostmansdquite a load of work16:29
lkclit makes auto-generation of test suites - for running on actual hardware - REALLY important16:29
ghostmansdwe don't have ff= in idx, right?16:30
lkclwhich is what that "ExpectedResults" - in the test api - is all about16:30
ghostmansdld/st idx16:30
lkcl1 sec16:30
lkclfailfirst mode...16:30
lkclno, because it's a security risk16:30
lkclfail-first is speculative execution16:30
ghostmansdfail-first (where Vector Indexed is banned)16:30
ghostmansdyeah found it16:30
lkclan attacker could use it to perform multiple speculative page-probes16:31
lkclat least with ldst-immediate the offsets are relatively small, you're likely to stay within the same VM page16:31
ghostmansdhm something's wrong with the tables16:44
ghostmansdhere's the search I get with "sv.add/ff=RC1 *3,*7,*11": 0b01001116:45
ghostmansdThis corresponds to: normal: Rc=1: ffirst CR sel16:45
ghostmansdMeanwhile Rc=0 (bit 63)16:46
*** littlebobeep <littlebobeep!~alMalsamo@gateway/tor-sasl/almalsamo> has joined #libre-soc16:48
ghostmansd1 sec, perhaps Rc which comes as argument is wrong16:49
ghostmansdYeah this is the case16:49
ghostmansdYeah :-D16:49
ghostmansdHm, on the other hand... let me check more...16:50
*** littlebobeep <littlebobeep!~alMalsamo@gateway/tor-sasl/almalsamo> has quit IRC16:55
ghostmansdself.suffix[record.fields["Rc"]] != self[63]16:57
ghostmansdaaaah wait I think I know16:59
ghostmansdafter these are merged, prefix and suffix... the numeration is different16:59
ghostmansdwe read each of these separately17:02
ghostmansdthese are suffix and svp64 combined17:02
ghostmansdWe must read not from suffix but consider the shift, like we do it in operands: span = tuple(map(lambda bit: (bit + 32), span))17:03
ghostmansdon the other hand, why do we bother with STATIC operand at all?17:03
lkclque? not sure what you mean, "static operand"17:04
ghostmansdRc=0, Rc=1, Oe=0, Oe=117:06
ghostmansdPerhaps others17:06
lkclyes, LK=1 for branch (and AA)17:06
ghostmansdAnything that's part of the instruction encoding statically, not provided dynamically by user17:06
ghostmansdpushed RC1/~RC1 support for ff/pr and test17:07
lkclack, checking17:07
lkclhmmm i think i may have missed a mode.17:07
lkcl01invCR-bitRc=1: ffirst CR sel17:08
lkclit's possible to do just17:08
lkclwhich indirectly answers the question you asked17:09
lkclon any operation which has Rc=117:09
ghostmansd[m]Yep, asm checks these with equal sign17:09
lkclyou can enable fail-first17:09
lkclahhh 1 sec.. decode_bo17:10
lkclthe CR-bit17:10
lkcli am dumb17:10
*** ghostmansd[m] <ghostmansd[m]!> has quit IRC17:11
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has joined #libre-soc17:12
lkclha! cool! looks like ff=eq pr=ns works too!17:13
* lkcl just adding tests...17:13
lkclthat's cool.17:14
lkclis anything missing?17:14
lkclurrr i accidentally removed the call to the test17:17
lkclok compiling this17:17
lkclsv.add./pr=eq *3,*7,*1117:17
ghostmansdeq are not here yet17:18
ghostmansdRC1 for now only17:18
ghostmansdmissed information above17:18
lkcl   0:   fc 3f 40 05     .long 0x5403ffc17:19
lkcl   4:   15 12 01 7c     add.    r0,r1,r217:19
lkclecho -n -e '\xfc\x3f\x40\x05\x15\x12\x01\x7c' | pysvp64dis -v17:20
lkcl        normal: Rc=1: pred-result CR sel17:20
lkcl        RM17:20
lkcl        RM.mode17:20
lkcl            1110017:21
lkcl            27, 28, 29, 30, 3117:21
lkclis that correct...17:21
lkcl0-123 4description17:21
lkcl11invCR-bitRc=1: pred-result CR sel17:21
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has quit IRC17:21
*** ghostmansd[m] <ghostmansd[m]!> has joined #libre-soc17:22
lkcl11 yes 1 NO 00 yes17:22
lkclinv is wrong17:22
lkcl(from sv/trans/
lkclurrr the f****g decode_bo bits are MSB0/LSB0-inverted17:23
lkclfrickin frick17:23
lkclfer f***s sake17:23
ghostmansdjoy never ends17:23
lkclit means decode_bo needs reversing... i think that's all17:25
ghostmansdlkcl, am I right that you do ff=eq et al.?17:25
lkclbut this is only allowed on instructions that have an Rc=1 option ("add." etc.)17:25
lkcl        RM.mode17:31
lkcl            1100117:31
lkcl            27, 28, 29, 30, 3117:31
lkclecho -n -e '\xf9\x3f\x40\x05\x15\x12\x01\x7c' | pysvp64dis -v17:31
ghostmansddis branch or master?17:38
ghostmansdf9 3f 40 05    sv.add. *r3,*r7,*r1117:38
ghostmansd15 12 01 7c17:38
lkclcommit 361df8c7c74f3e58ef7117:42
lkclecho 'sv.add./pr=eq *3,*7,*11' | pysvp64asm > sv.add.preq.tst.s17:42
lkcl(strip out the crap)17:43
lkclpowerpc64le-linux-gnu-as sv.add.preq.tst.s17:43
lkclpowerpc64le-linux-gnu-objdump -D ./a.out17:43
ghostmansd[m]Ah OK, got it18:13
ghostmansd[m]You meant pysvp64asm changes18:14
ghostmansd[m]OK I'll support these in dis18:14
ghostmansdlkcl, one question18:18
ghostmansdwe want to support ff=eq et al., right?18:18
ghostmansdbut I see from the predicates table these should be 3-bit value18:19
ghostmansdand we have only 2 bits in CR field18:19
ghostmansdWhy do we call it inv, then?18:19
lkclbecause it inverts the CR-bit18:20
lkclit comes from branch.18:20
lkclbranch BO[0:2] is exactly the same format18:20
ghostmansd~eq == ne, that's what you mean?18:20
ghostmansd(1, 0b000): "lt",18:21
ghostmansdthat's how it's in table18:21
ghostmansdaha, OK18:21
lkclhence the mistake just corrected where inv was ending up in bit...18:21
lkclnot bit 218:21
ghostmansdahha, OK18:23
ghostmansdlkcl, please ping me when you update any of the tables in the docs19:27
ghostmansdexplicitly, not like "oh there are some changes"19:27
ghostmansdbut "check this, this and that tables"19:28
ghostmansdbecause I found that CR ops are obsolete, again19:28
ghostmansdeven simple mode19:28
ghostmansdit's our luck that I'm refactoring this code, otherwise this would have gone unnoticed19:29
ghostmansdon bonus side, this became more elegant, I have to admit19:29
ghostmansdCR ops used to be kinda bastards of SVP6419:30
ghostmansd(they still are, but at least appear to be normal if you observe them from a sufficiently long distance)19:30
ghostmansdDon't update these, I'm refactoring the classes hierarchy, I'm tired with copy&paste and came up with alternative approach, but it will be a pain in the ass to rebase it.19:32
ghostmansdFuck branches too19:34
ghostmansdAh no, these appear to be the same19:35
ghostmansd+30 insertions -80 deletions with the latest patch, I like the new way19:36
ghostmansdOK I see it now, you also did it19:40
ghostmansdThe rebase is completely fucked19:40
ghostmansd+        if specifiers: # if any add one extra to get the extra "/"19:41
ghostmansd+            specifiers = ['']+specifiers19:41
ghostmansd+        if operands: # if any separate with a space19:41
ghostmansd+            operands = " " + operands19:41
ghostmansdPlease keep spaces19:41
ghostmansdPlease stick to the same conventions everywhere19:41
ghostmansdAnd please avoid wording like "simpler to read", because it's not.19:42
ghostmansdTo me these are the same TBH19:42
ghostmansdAnyway the former applies ^19:42
ghostmansdDo not rebase it yet, the order of operands might have been changed.19:47
ghostmansdIt all started when I began adding these CR-related stuff. I realized that I'm really pissed with the amount of copy & paste, so the hierarchy is changed again.19:48
ghostmansdOK it seems that only /mr, /ff=COCO and /pr=JUMBO don't work, so I'm rebasing this19:50
ghostmansdNow with the new hierarchy it'll be simpler to implement this stuff19:51
ghostmansd : instruction does not match 'sv.add./ff=gt *3,*7,*11' expected 'sv.add./ff=eq *3,*7,*11'20:02
ghostmansdMSB0 I'm looking at you!20:03
ghostmansd# barse-ackwards MSB0/LSB0. sigh20:04
ghostmansdThis looks wrong20:10
ghostmansdI have these bits for eq:20:10
ghostmansdinv = SelectableInt(value=0x0, bits=1)20:10
ghostmansdCR = SelectableInt(value=0x1, bits=1)20:10
ghostmansdAnd these totally cannot be composed into 0b100 to make eq.20:11
ghostmansdAh wait, I think I know20:15
ghostmansdfirst CR must be 2-bit20:16
lkclghostmansd, i did - you may have missed it, sorry20:16
lkcl> bin(mapped)[:1:-1]20:17
lkclit looks wrong but is bizarrely correct.  i say correct, i just realised it needs zero-extending20:17
lkcl010 will be truncated to 10 which will be turned round to 0120:18
ghostmansdno actually it works if it's kept as is20:18
ghostmansdas it was, to be correct20:18
lkcldurrr.... burble20:18
ghostmansdbecause then I can just do `mask = int(_selectconcat(inv, CR))`20:18
ghostmansdtest is in progress20:19
lkclv tired. do best you can.20:19
ghostmansdyou already shift these by LSB_BO20:19
ghostmansdOK it works! Only /mr is left20:19
ghostmansdpushed the stuff20:20
ghostmansdcf. fe4eeff50d4c7a4b50854893c144edb034736ee7 to get an overall idea of how new hierarchy cuts the code20:20
ghostmansdrebased over master20:20
ghostmansd(there are more classes like this above, for sz, dz, zz, etc.)20:21
ghostmansdlkcl, amirite mrr is the same as mr, it's just RG=1?20:29
ghostmansdand all we need to do is...20:29
ghostmansd        if self.RG:20:29
ghostmansd            yield "mrr"20:29
ghostmansdadd else branch here20:30
ghostmansdnah that's not correct...20:32
ghostmansdor, well, not entirely, because this change breaks another test: ` : instruction does not match 'sv.crand/mr 12,2,33' expected 'sv.crand 12,2,33'`20:33
ghostmansdI pushed this change anyway, because it leaves only two tests broken20:34
*** octavius <octavius!> has quit IRC20:37
*** ghostmansd <ghostmansd!> has quit IRC21:01
lkclghostmansd[m], yes basically21:13
lkclecho 'sv.crand 12,2,33' | pysvp64asm > sv.crand.tst.s21:20
lkcl   0:   20 00 40 05     .long 0x540002021:21
lkcl   4:   02 0a 82 4d     crand   4*cr3+lt,eq,gt21:21
lkclecho -n -e '\x20\x00\x40\x05\x02\x0a\x82\x4d' | pysvp64dis -v21:22
lkcl        cr_op: simple mode21:22
lkcl        RM21:22
lkcl            00000000000000000010000021:22
lkcl        RM.mode21:22
lkcl            0000021:22
lkcl            27, 28, 29, 30, 3121:22
lkclghostmansd[m], sorted, bit of a hack-job.21:32
lkclno i have a better way21:34
lkclpredication sorted22:00
*** lxo <lxo!> has joined #libre-soc22:14
ghostmansd[m]Check a bit22:30
ghostmansd[m]Again, please finally start using spaces when needed22:30
lkcli have no idea what you're referring to22:31
ghostmansd[m]No "sw="+sws is not more readable than f"sw={sw}"22:31
ghostmansd[m]Not at all22:31
lkclyep it should be "sm=" + sw22:31
ghostmansd[m]If you do some operation, please put spaces there22:31
lkclpep8 will complain about it22:31
lkclam rushing. it's late. meeting early tomorrow.  sorry22:32
ghostmansd[m]That's just the third or forth time I'm asking about it22:32
lkclmissed it, sorry22:32
ghostmansd[m]If you're that stubborn with f strings, at least please make it clean22:33
ghostmansd[m]Ok, this is all bollocks, to the point22:33
lkcltired, and i'm rushing. sorry.22:34
ghostmansd[m]I don't quite get the sense of change with CROpSimpleRM22:34
lkcltrying to do the RFC at the same time.22:34
ghostmansd[m]I thought that the whole idea of this unification was to have the same specifiers and binary layout whenever possible22:35
ghostmansd[m]Why that RG is different?22:35
lkclbecause it was deriving from.... something-else, forgotten22:35
lkclRG was supposed to be only on mapreduce22:35
lkclbut there's space to do a reverse-gear in CRops22:35
lkcl*nothing to do with mapreduce*22:35
ghostmansd[m]But we don't even have 'rg' in asm22:35
lkcltherefore you cannot report... yes i know.22:36
lkcli haven't done crops at all, remember?22:36
lkcli'm amazed it works at all22:36
ghostmansd[m]So this is RG field which is not about reverse gear?22:36
lkclyes it is reverse-gear22:36
lkclbut not mapreduce-reversegear22:36
ghostmansd[m]Ah, just not mapreduce22:36
lkcltherefore you cannot report "mr" or "mrr"22:36
ghostmansd[m]It's fricking confusing :-)22:37
lkcli _would_ have a reversegear in the other modes22:37
lkclif there were enough bits22:37
lkclwhich there aren't22:37
ghostmansd[m]Ok, that I couldn't imagine22:37
ghostmansd[m]OK, it became clearer22:37
lkclit's olny CRops which has the extra spare bits (from using elwidths)22:37
ghostmansd[m]Thank you!22:37
lkclbut it turns out...22:37
lkclmapreduce is a lie :)22:37
lkclso you *can* actually enable /mrr and use the reverse-gear of mapreduce to do non-mapreduce reverse-gear22:38
ghostmansd[m]Just like PU and parallel? :-P22:38
lkclno god no22:38
lkclthose were just fucked :)22:38
lkclwill explain tomorrow22:39
ghostmansd[m]Ok, I will clean this up tomorrow, too tired today22:39
ghostmansd[m]Same, yeah22:39
* lkcl salutes22:39
ghostmansd[m]I guess we almost completed asm, though22:39
lkclpretty much22:39
ghostmansd[m]So when this is ready I'll begin binutils migration22:39
ghostmansd[m]I hope that will be mostly mechanical work, but not really sure.22:40
ghostmansd[m]Stuff changed a lot, to the best, but still it's really different in many points.22:41
*** lxo <lxo!> has quit IRC23:38

Generated by 2.17.1 by Marius Gedminas - find it at!