| *** lxo <lxo!~lxo@linux-libre.fsfla.org> has quit IRC | 08:23 | |
| *** josuah <josuah!~irc@46.23.94.12> has quit IRC | 08:31 | |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc | 09:18 | |
| ghostmansd[m] | I added support for ew for normal, ld/st imm and ld/st idx modes | 09:21 |
|---|---|---|
| ghostmansd[m] | dis test is fine now | 09:21 |
| lkcl | briiliant | 09:22 |
| lkcl | echo -n -e '\xe0\x34\x44\x05\x15\x12\x01\x7c' | pysvp64dis -v | 09:24 |
| lkcl | e0 34 44 05 sv.add./ew=32 *r2,*r4,*r11 | 09:24 |
| lkcl | 15 12 01 7c | 09:24 |
| *** josuah <josuah!~irc@46.23.94.12> has joined #libre-soc | 09:34 | |
| ghostmansd[m] | Added sw | 09:34 |
| ghostmansd[m] | Plus test, merged to master | 09:34 |
| lkcl | there's supposed to be one which is a short-cut for both ew= and sw= if they are the same | 09:36 |
| lkcl | but it looks like i didn't add it to sv/trans/svp64.py | 09:37 |
| lkcl | like m= | 09:37 |
| lkcl | but w= | 09:37 |
| lkcl | oh well | 09:37 |
| lkcl | test pass confirmed | 09:38 |
| lkcl | doing test_caller_* to make sure | 09:38 |
| ghostmansd[m] | We only have sw and ew | 09:38 |
| ghostmansd[m] | Not dw | 09:38 |
| lkcl | yeah i know | 09:39 |
| lkcl | that's a minor omission | 09:39 |
| ghostmansd[m] | And ew sets destwid | 09:39 |
| ghostmansd[m] | I do what I see :-) | 09:39 |
| ghostmansd[m] | If there are errors in asm or docs, these must be fixed first | 09:40 |
| lkcl | yep. like sm= and dm= has m= to set both, the names should be consistent here | 09:40 |
| lkcl | yyep... | 09:40 |
| lkcl | when i'm more awake :) | 09:40 |
| ghostmansd[m] | I suggest having sw, dw and w | 09:40 |
| ghostmansd[m] | Like we have sm, dm and m | 09:40 |
| ghostmansd[m] | e in ew would be redundant then | 09:41 |
| lkcl | yep agreed | 09:45 |
| lkcl | now's the time to do it, before going much further | 09:45 |
| * lkcl sorting that in sv/trans/svp64.py | 09:49 | |
| lkcl | https://git.libre-soc.org/?p=openpower-isa.git;a=commitdiff;h=9f7e84ccc9aad7bd9073edab6ac6f052a3b49695 | 09:50 |
| ghostmansd[m] | Cool, will adjust dis, 1 sec | 09: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 dis | 10:04 |
| ghostmansd | lkcl, could you, please, share an example of instruction which supports /svm? | 10:42 |
| ghostmansd | Currently I come up with "sv.add./vec4/mrr/svm *3,*7,*11" | 10:42 |
| ghostmansd | Or vec2/vec3 | 10:44 |
| ghostmansd | Hm, it seems the RM for these cannot be deduced | 10:45 |
| programmerjake | lkcl: apparently if you build the latest git version of highlight it will make gitweb highlight python f-strings correctly: https://gitlab.com/saalen/highlight/-/issues/212#note_1104301686 | 11:05 |
| programmerjake | or, if not correctly, at least better | 11:05 |
| ghostmansd | lkcl, did you change https://libre-soc.org/openpower/sv/normal/? | 11:20 |
| ghostmansd | Because I see that it seriously contradicts the code we have now, so I was either _really_ confused, or the docs were updated. | 11:21 |
| ghostmansd | Aha! 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 |
| ghostmansd | Updated the disassembly. | 11:34 |
| ghostmansd | I also suggest we have a separate column corresponding to field names. | 11:35 |
| lkcl | ghostmansd, yes, if both equal then output m=. | 11:39 |
| ghostmansd | done already :-) | 11:39 |
| lkcl | i haven't added anything with svm (subvector mode) | 11:39 |
| ghostmansd | well still I must check whether it works | 11:40 |
| ghostmansd | because we have it both in docs and asm | 11:40 |
| lkcl | i do keep cut/pasting the markdown tables from the spec into the source code | 11:40 |
| ghostmansd | I don't understand why you do it, though | 11:41 |
| lkcl | but there are about 3 copies so it is hard to get them all | 11:41 |
| lkcl | because i have memory problems | 11:41 |
| ghostmansd | but you could put a link | 11:41 |
| ghostmansd | these rot pertty fast | 11:41 |
| lkcl | it doesn't help | 11:41 |
| ghostmansd | OK up to you | 11:41 |
| ghostmansd | I look at the docs on the site, though | 11:41 |
| lkcl | i 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 ago | 11:41 |
| lkcl | this is not a joke | 11:42 |
| lkcl | it is something i have observed as a slightly scary problem for over 10 years | 11:42 |
| lkcl | flicking back and forth five to six times between two pages is not enough to get the information into short-term recall | 11:43 |
| ghostmansd | OK, please do it as you find convenient and helpful | 11:43 |
| ghostmansd | no objections then | 11:43 |
| ghostmansd | I mostly look at the docs though | 11:43 |
| ghostmansd | and only check asm when in doubts | 11:43 |
| lkcl | only 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 |
| lkcl | yes it's a pain | 11:44 |
| lkcl | the fuckups are down to trying to implement things that were only found to be unworkable *by* actually implementing them | 11:44 |
| lkcl | pack/unpack has been particularly... obstreperous | 11:45 |
| lkcl | parallel-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 |
| lkcl | i don't anticipate any other idiocies being detected, although cannot say for sure :) | 11:46 |
| ghostmansd | no I'm OK with this :-) | 11:48 |
| ghostmansd | it's just slightly inconvenient that this happens in the middle :-) | 11:49 |
| ghostmansd | but, on the other hand, it _is_ convenient, because this stuff is easily spotted | 11:49 |
| ghostmansd | I have no idea how the mr/mrr/svm correspond to mapreduce_*** and https://libre-soc.org/openpower/sv/normal/ | 11:54 |
| ghostmansd | it's all way too hairy | 11:54 |
| ghostmansd | I found that "sv.add./mrr/vec2 *r3,*r7,*r11" is diagnosed as "scalar reduce mode", and this is what I expected | 11:55 |
| ghostmansd | To 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 work | 11:57 |
| ghostmansd | However, 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 |
| ghostmansd | Bingo, this worked, the mode is diagnosed "normal: subvector reduce mode, SUBVL>1", exactly like I expected. | 11:58 |
| ghostmansd | But 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!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has left #libre-soc | 11:59 | |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc | 11:59 | |
| ghostmansd | So 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 |
| ghostmansd | lkcl ^ this is important | 12:01 |
| ghostmansd | FWIW, I pushed the dis branch, so you can experiment | 12:01 |
| ghostmansd | These mapreduce modes also introduce an unused variable (cf. opmodes section) and, like the modes in is_bc section, seem pretty half-baked. | 12:03 |
| ghostmansd | I'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 |
| ghostmansd | lkcl, how about changing SVmask_src to a simple boolean? | 12:47 |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC | 12:51 | |
| lkcl | subvector mode is on vec2/3/4 | 13:55 |
| lkcl | i.e. when the 2 bits are non-zero | 13:56 |
| lkcl | vec2/svm MUST work | 13:56 |
| lkcl | vec3/svm MUST work | 13:56 |
| lkcl | vec4/svm MUST work | 13:56 |
| lkcl | anything else is a bug | 13:56 |
| lkcl | SVmask_src - boolean - no problem at all | 13:56 |
| lkcl | subvl on RG... argh of course | 13:57 |
| lkcl | and that's also why Pack/Unpack had to be removed | 13:58 |
| lkcl | siggh ok | 13:58 |
| lkcl | svm has to be removed. | 13:58 |
| lkcl | frick | 13:58 |
| ghostmansd[m] | lol | 14:01 |
| ghostmansd[m] | Ok I had a feeling there's something wrong | 14:02 |
| ghostmansd[m] | > vec2/svm MUST work | 14:02 |
| ghostmansd[m] | > svm has to be removed | 14:03 |
| ghostmansd[m] | Sorry, I could not resist and literally laughed :-D | 14:03 |
| lkcl | sigh.. | 14:13 |
| lkcl | such irony... | 14:14 |
| lkcl | ghostmansd[m], looking at https://libre-soc.org/openpower/sv/cr_ops/ actually it could be made more like the other modes, now | 14:24 |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc | 14:27 | |
| lkcl | ghostmansd[m], https://git.libre-soc.org/?p=openpower-isa.git;a=commitdiff;h=14e8214ccf3e4443b4b813b607ffbc173f123477 | 14:35 |
| lkcl | svm removed from sv/trans/svp64.py, removed /svm and /mrr/svm | 14:35 |
| lkcl | but added a (missing) /mr mode test | 14:35 |
| ghostmansd[m] | ...which we don't have yet :-) | 14:35 |
| ghostmansd[m] | But OK | 14:35 |
| lkcl | yes it's there | 14:35 |
| ghostmansd[m] | I'm checking predicates | 14:36 |
| lkcl | ah ok | 14:36 |
| ghostmansd[m] | I mean disassembly | 14:36 |
| ghostmansd[m] | I saw it in pysvp64asm | 14:36 |
| ghostmansd[m] | Just no dis support yet | 14:36 |
| ghostmansd[m] | I'll do it after predicates | 14:36 |
| lkcl | can i safely get rid of svmr without git-diff-conflict? | 14:36 |
| lkcl | should be ok, just checking | 14:37 |
| ghostmansd[m] | I think I can drop commits about it | 14:37 |
| lkcl | bye bye class NormalSubvectorReduceRM? | 14:37 |
| lkcl | ok | 14:38 |
| lkcl | on it | 14:38 |
| ghostmansd[m] | Ah you mean that | 14:38 |
| ghostmansd[m] | Not smr mode | 14:38 |
| lkcl | svmr: NormalSubvectorReduceRM gone | 14:38 |
| ghostmansd[m] | OK but keep in mind that we need to tune the select function, too | 14:38 |
| lkcl | svmr: CROpSubvectorReduceRM gone | 14:38 |
| lkcl | ack | 14:38 |
| lkcl | i'm just going to carefully excise them | 14:38 |
| ghostmansd[m] | Kill it with fire! 🔥 | 14:39 |
| lkcl | muahhahaah | 14:40 |
| ghostmansd | for predicates... am I right that we simply check mmode (0/1) and then check smask/mask? | 14:41 |
| lkcl | yes. | 14:41 |
| lkcl | there is only one mmode. | 14:41 |
| ghostmansd | Yep, 0/1 are values | 14:41 |
| ghostmansd | OK, and the logic is like with sw/dw/w? | 14:41 |
| lkcl | you need to check the CSV "2P" to find out if mask is active | 14:41 |
| ghostmansd | if ptype == '2P': | 14:41 |
| lkcl | like that new SVmask_src thing. | 14:41 |
| ghostmansd | # source pred: bits 16-18 | 14:41 |
| ghostmansd | svp64_rm.smask = smask | 14:41 |
| ghostmansd | this? | 14:42 |
| lkcl | hang on... | 14:42 |
| lkcl | no it's SM | 14:42 |
| lkcl | check the (new) SM field | 14:42 |
| ghostmansd | Nope I mean 2P check | 14:42 |
| lkcl | irony is, having added that SM field, i bet you it's synonymous with 2P | 14:42 |
| lkcl | sigh | 14:42 |
| lkcl | sometimes i am an idiot. | 14:42 |
| lkcl | yes of course it's 2P. | 14:42 |
| ghostmansd | that's OK :-) | 14:42 |
| lkcl | why did i frickin well add SM?? | 14:42 |
| * lkcl whyyy god whyyyyy | 14:43 | |
| * ghostmansd literally crying to the sky together | 14:43 | |
| lkcl | haha | 14:43 |
| ghostmansd | OK so I'm checking ptype | 14:43 |
| ghostmansd | we have it in record | 14:43 |
| lkcl | yes. | 14:43 |
| ghostmansd | if ptype is not 2P, what're our actions? | 14:44 |
| ghostmansd | Assume we have only dmask? | 14:44 |
| lkcl | "m=" | 14:44 |
| ghostmansd | 1 sec | 14:45 |
| lkcl | no, it applies as both source and dest mask | 14:45 |
| lkcl | therefore best to call it "m=" | 14:45 |
| ghostmansd | so, if P2, then we have both smask and dmask, and output either sm+dm or m (if these are equal) | 14:45 |
| ghostmansd | otherwise we only have m? | 14:45 |
| lkcl | yes | 14:45 |
| ghostmansd | OK, got it! | 14:45 |
| lkcl | exactly like with elwidths | 14:45 |
| ghostmansd | thanks for the explanation | 14:45 |
| lkcl | git pull btw | 14:45 |
| ghostmansd | wow, even no conflicts | 14:46 |
| * lkcl snorts | 14:46 | |
| lkcl | btw if it's ok with you i'm going to do a code-morph on RM.select | 14:46 |
| lkcl | to a single-level hierarchy | 14:46 |
| ghostmansd | sure | 14:47 |
| ghostmansd | perfectly fine with me | 14:47 |
| ghostmansd | because this code is a real piece of crap | 14:47 |
| lkcl | :) | 14:47 |
| ghostmansd | and I'm tired of adopting it to docs lol | 14:47 |
| ghostmansd | fuck now I realized specifiers are property | 14:47 |
| ghostmansd | and don't have record here... | 14:47 |
| ghostmansd | sigh | 14:47 |
| ghostmansd | OK | 14:47 |
| ghostmansd | lkcl, one more question | 15:00 |
| lkcl | yaa | 15:00 |
| ghostmansd | if mmode == 0 (non-CR-predicate) | 15:00 |
| ghostmansd | and mask or smask is 0... | 15:00 |
| ghostmansd | what would it be? | 15:00 |
| lkcl | nothing. | 15:01 |
| ghostmansd | aha ok | 15:01 |
| lkcl | that's "no predicate at all" | 15:01 |
| ghostmansd | exactly as I thought | 15:01 |
| lkcl | but you *have* to have both mask *and* smask zero for that (in 2P) | 15:01 |
| lkcl | but just mask and mmode zero (in 1P) | 15:01 |
| ghostmansd | any Twin-predicate op? | 15:04 |
| lkcl | que? | 15:04 |
| ghostmansd | AssertionError: source-mask can only be specified on Twin-predicate ops | 15:05 |
| ghostmansd | yet another battle to assembler lost | 15:05 |
| ghostmansd | tried the whole set of whistles and bells: sv.add./vec2/mrr/sm=r3/dm=r10 *3,*7,*11 | 15:06 |
| lkcl | oooOoo :) | 15:06 |
| lkcl | give me 1 sec | 15:06 |
| lkcl | that looks fuuun | 15:06 |
| ghostmansd | m= works | 15:06 |
| lkcl | sv.add should... hang on.. | 15:06 |
| lkcl | openpower/isatables/RM-1P-2S1D.csv:add,NORMAL,,1P,EXTRA3,NO,d:RT;d:CR0,s:RA,s:RB,0,RA,RB,0,RT,0,CR0,0 | 15:06 |
| lkcl | ha, yes, it's 1P | 15:07 |
| lkcl | that's correct! | 15:07 |
| lkcl | w00t | 15:07 |
| ghostmansd | lol we managed to disassemble this! `sv.add./mrr/m=r3/vec2 *r3,*r7,*r11` | 15:08 |
| lkcl | ok table-of-mask-values | 15:08 |
| lkcl | frickin ellfire! | 15:08 |
| lkcl | git pull | 15:08 |
| ghostmansd | 1 sec | 15:08 |
| ghostmansd | this has to be pushed first | 15:08 |
| ghostmansd | :-D | 15:08 |
| lkcl | ack | 15:08 |
| ghostmansd | Does NormalSaturationExtRM no longer exist? | 15:09 |
| ghostmansd | got a conflict | 15:09 |
| lkcl | correct it doesn't. | 15:09 |
| ghostmansd | but why? it's not svm-enabled | 15:10 |
| ghostmansd | and we discussed those | 15:10 |
| lkcl | it was subvl>1 | 15:10 |
| lkcl | bye bye... | 15:10 |
| lkcl | stomped on with attitude | 15:10 |
| ghostmansd | aaaah right | 15:10 |
| ghostmansd | OK I pushed | 15:11 |
| ghostmansd | I wanted to add some tests, but, after some thoughts, I decided I'd like to sort specifiers first | 15:11 |
| ghostmansd | this will likely need the tests to be fixed | 15:12 |
| ghostmansd | by the way I haven't checked the tests yet | 15:12 |
| lkcl | 1 sec | 15:12 |
| ghostmansd | hm, broken | 15:13 |
| ghostmansd | some mumbling about /mr | 15:13 |
| ghostmansd | aaah this one is not there yet | 15:14 |
| ghostmansd | OK | 15:14 |
| lkcl | yyep. | 15:14 |
| lkcl | braaaain | 15:14 |
| ghostmansd | OK need to take a rest for a while | 15:14 |
| lkcl | yep time to run tests anyway | 15:14 |
| ghostmansd | Cool! Cool cool cool. | 15:16 |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC | 15:21 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC | 15:32 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.160.217> has joined #libre-soc | 15:35 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.160.217> has quit IRC | 15:47 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc | 15:48 | |
| *** octavius <octavius!~octavius@158.147.93.209.dyn.plus.net> has joined #libre-soc | 15:48 | |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc | 16:00 | |
| ghostmansd | lkcl, new tables look real cool | 16:08 |
| lkcl | yeah | 16:08 |
| ghostmansd | I formatted the code a bit | 16:08 |
| lkcl | working towards svrm_fields.txt basically | 16:08 |
| lkcl | ahhh errr | 16:08 |
| ghostmansd | indents and whitespaces | 16:09 |
| lkcl | ok then i need to do merge/pull | 16:09 |
| lkcl | urk 1 sec doing branch | 16:09 |
| ghostmansd | yeah these are just whitespaces and indents | 16:09 |
| ghostmansd | nothing serious | 16:09 |
| ghostmansd | just so that code looks like everything around | 16:09 |
| lkcl | also means you went over it | 16:09 |
| lkcl | line-by-line | 16:09 |
| lkcl | i do that :) | 16:10 |
| ghostmansd | I'm moving at ffirst/predresult | 16:10 |
| ghostmansd | by the way | 16:10 |
| ghostmansd | elif encmode == 'zz': # TODO, a lot more checking on legality | 16:10 |
| ghostmansd | dst_zero = 1 # NOT on cr_ops, that's RM[6] | 16:10 |
| ghostmansd | elif encmode == 'sz': | 16:10 |
| ghostmansd | Shouldn't zz also set src_zero? | 16:11 |
| lkcl | yyyees it should | 16:11 |
| ghostmansd | OK, I'll push it | 16:11 |
| lkcl | ack. | 16:11 |
| lkcl | back to branch-table | 16:11 |
| lkcl | so like, *literally* those tables could be blatted into a csv file, now. | 16:17 |
| lkcl | branch done | 16:18 |
| lkcl | frick | 16:18 |
| lkcl | conflict sorted | 16:22 |
| lkcl | anyway the idea behind doing as tables is, quite obviously, that they then become part of the actual spec | 16:22 |
| ghostmansd | yeah that'd be the best options | 16:23 |
| ghostmansd | *option | 16:23 |
| ghostmansd | we don't have VLi support it in assembly it seems | 16:25 |
| ghostmansd | I'm ignoring this for now | 16:25 |
| lkcl | no, correct. nor ctr mode. | 16:25 |
| lkcl | yep | 16:25 |
| lkcl | good | 16:25 |
| lkcl | i need time to do the full modes in the Simulator for sv.branch | 16:26 |
| lkcl | holy cow that's going to be one hell of a lot. | 16:26 |
| lkcl | it's *512* separate and distinct options | 16:26 |
| lkcl | i lied - 2^11 | 16:27 |
| lkcl | holy shit 2048 unit test | 16:27 |
| lkcl | per instruction, sv.bc sv.bcl, sv.bclr, sv.bcctr... | 16:28 |
| lkcl | howwwwzaaah | 16:28 |
| ghostmansd | hell | 16:29 |
| ghostmansd | quite a load of work | 16:29 |
| lkcl | it makes auto-generation of test suites - for running on actual hardware - REALLY important | 16:29 |
| ghostmansd | we don't have ff= in idx, right? | 16:30 |
| lkcl | which is what that "ExpectedResults" - in the test api - is all about | 16:30 |
| ghostmansd | ld/st idx | 16:30 |
| lkcl | 1 sec | 16:30 |
| lkcl | failfirst mode... | 16:30 |
| lkcl | no, because it's a security risk | 16:30 |
| lkcl | fail-first is speculative execution | 16:30 |
| ghostmansd | fail-first (where Vector Indexed is banned) | 16:30 |
| ghostmansd | yeah found it | 16:30 |
| lkcl | an attacker could use it to perform multiple speculative page-probes | 16:31 |
| lkcl | at least with ldst-immediate the offsets are relatively small, you're likely to stay within the same VM page | 16:31 |
| ghostmansd | hm something's wrong with the tables | 16:44 |
| ghostmansd | here's the search I get with "sv.add/ff=RC1 *3,*7,*11": 0b010011 | 16:45 |
| ghostmansd | This corresponds to: normal: Rc=1: ffirst CR sel | 16:45 |
| ghostmansd | Meanwhile Rc=0 (bit 63) | 16:46 |
| *** littlebobeep <littlebobeep!~alMalsamo@gateway/tor-sasl/almalsamo> has joined #libre-soc | 16:48 | |
| ghostmansd | 1 sec, perhaps Rc which comes as argument is wrong | 16:49 |
| ghostmansd | Yeah this is the case | 16:49 |
| ghostmansd | Yeah :-D | 16:49 |
| ghostmansd | Hm, on the other hand... let me check more... | 16:50 |
| *** littlebobeep <littlebobeep!~alMalsamo@gateway/tor-sasl/almalsamo> has quit IRC | 16:55 | |
| ghostmansd | WAT | 16:56 |
| ghostmansd | self.suffix[record.fields["Rc"]] != self[63] | 16:57 |
| ghostmansd | WTF | 16:57 |
| ghostmansd | aaaah wait I think I know | 16:59 |
| ghostmansd | after these are merged, prefix and suffix... the numeration is different | 16:59 |
| ghostmansd | we read each of these separately | 17:02 |
| ghostmansd | these are suffix and svp64 combined | 17:02 |
| ghostmansd | [32]0x7c011214 | 17:02 |
| ghostmansd | [64]0x5403fe97c011214 | 17:02 |
| ghostmansd | We 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 |
| ghostmansd | on the other hand, why do we bother with STATIC operand at all? | 17:03 |
| lkcl | que? not sure what you mean, "static operand" | 17:04 |
| ghostmansd | Rc=0, Rc=1, Oe=0, Oe=1 | 17:06 |
| ghostmansd | Perhaps others | 17:06 |
| lkcl | yes, LK=1 for branch (and AA) | 17:06 |
| ghostmansd | Anything that's part of the instruction encoding statically, not provided dynamically by user | 17:06 |
| ghostmansd | Done | 17:06 |
| ghostmansd | pushed RC1/~RC1 support for ff/pr and test | 17:07 |
| lkcl | ack, checking | 17:07 |
| lkcl | hmmm i think i may have missed a mode. | 17:07 |
| lkcl | 01invCR-bitRc=1: ffirst CR sel | 17:08 |
| lkcl | it's possible to do just | 17:08 |
| lkcl | sv.add./ff | 17:08 |
| lkcl | not | 17:08 |
| lkcl | sv.add./ff=RC1 | 17:08 |
| lkcl | not | 17:08 |
| lkcl | sv.add./ff=~RC1 | 17:08 |
| lkcl | just | 17:08 |
| lkcl | sv.add./ff | 17:08 |
| lkcl | which indirectly answers the question you asked | 17:09 |
| lkcl | on any operation which has Rc=1 | 17:09 |
| ghostmansd[m] | Yep, asm checks these with equal sign | 17:09 |
| lkcl | you can enable fail-first | 17:09 |
| lkcl | ahhh 1 sec.. decode_bo | 17:10 |
| lkcl | yes. | 17:10 |
| lkcl | the CR-bit | 17:10 |
| lkcl | i am dumb | 17:10 |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC | 17:11 | |
| lkcl | rebased, | 17:11 |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.160.220> has joined #libre-soc | 17:12 | |
| lkcl | ha! cool! looks like ff=eq pr=ns works too! | 17:13 |
| * lkcl just adding tests... | 17:13 | |
| lkcl | odne | 17:14 |
| lkcl | that's cool. | 17:14 |
| lkcl | now. | 17:14 |
| lkcl | is anything missing? | 17:14 |
| lkcl | urrr i accidentally removed the call to the test | 17:17 |
| lkcl | ok compiling this | 17:17 |
| lkcl | sv.add./pr=eq *3,*7,*11 | 17:17 |
| ghostmansd | eq are not here yet | 17:18 |
| ghostmansd | RC1 for now only | 17:18 |
| ghostmansd | aaah | 17:18 |
| ghostmansd | missed information above | 17:18 |
| lkcl | 0: fc 3f 40 05 .long 0x5403ffc | 17:19 |
| lkcl | 4: 15 12 01 7c add. r0,r1,r2 | 17:19 |
| lkcl | echo -n -e '\xfc\x3f\x40\x05\x15\x12\x01\x7c' | pysvp64dis -v | 17:20 |
| lkcl | normal: Rc=1: pred-result CR sel | 17:20 |
| lkcl | RM | 17:20 |
| lkcl | RM.mode | 17:20 |
| lkcl | 11100 | 17:21 |
| lkcl | 27, 28, 29, 30, 31 | 17:21 |
| lkcl | is that correct... | 17:21 |
| lkcl | 0-123 4description | 17:21 |
| lkcl | 11invCR-bitRc=1: pred-result CR sel | 17:21 |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.160.220> has quit IRC | 17:21 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc | 17:22 | |
| lkcl | 11 yes 1 NO 00 yes | 17:22 |
| lkcl | inv is wrong | 17:22 |
| lkcl | (from sv/trans/svp64.py) | 17:22 |
| lkcl | urrr the f****g decode_bo bits are MSB0/LSB0-inverted | 17:23 |
| lkcl | frickin frick | 17:23 |
| lkcl | fer f***s sake | 17:23 |
| ghostmansd | fun | 17:23 |
| ghostmansd | joy never ends | 17:23 |
| lkcl | it means decode_bo needs reversing... i think that's all | 17:25 |
| ghostmansd | lkcl, am I right that you do ff=eq et al.? | 17:25 |
| lkcl | yes | 17:25 |
| ghostmansd | https://www.youtube.com/watch?v=8IIrf_JSuQk | 17:25 |
| lkcl | but this is only allowed on instructions that have an Rc=1 option ("add." etc.) | 17:25 |
| lkcl | :) | 17:26 |
| lkcl | RM.mode | 17:31 |
| lkcl | 11001 | 17:31 |
| lkcl | 27, 28, 29, 30, 31 | 17:31 |
| lkcl | betterrrrr | 17:31 |
| lkcl | echo -n -e '\xf9\x3f\x40\x05\x15\x12\x01\x7c' | pysvp64dis -v | 17:31 |
| ghostmansd | dis branch or master? | 17:38 |
| ghostmansd | f9 3f 40 05 sv.add. *r3,*r7,*r11 | 17:38 |
| ghostmansd | 15 12 01 7c | 17:38 |
| lkcl | master | 17:41 |
| lkcl | commit 361df8c7c74f3e58ef71 | 17:42 |
| lkcl | echo 'sv.add./pr=eq *3,*7,*11' | pysvp64asm > sv.add.preq.tst.s | 17:42 |
| lkcl | (strip out the crap) | 17:43 |
| lkcl | powerpc64le-linux-gnu-as sv.add.preq.tst.s | 17:43 |
| lkcl | powerpc64le-linux-gnu-objdump -D ./a.out | 17:43 |
| ghostmansd[m] | Ah OK, got it | 18:13 |
| ghostmansd[m] | You meant pysvp64asm changes | 18:14 |
| ghostmansd[m] | OK I'll support these in dis | 18:14 |
| ghostmansd | lkcl, one question | 18:18 |
| lkcl | ya | 18:18 |
| ghostmansd | we want to support ff=eq et al., right? | 18:18 |
| lkcl | ya | 18:18 |
| ghostmansd | but I see from the predicates table these should be 3-bit value | 18:19 |
| ghostmansd | and we have only 2 bits in CR field | 18:19 |
| lkcl | 3. | 18:19 |
| lkcl | inv | 18:19 |
| lkcl | invCR-bit | 18:19 |
| ghostmansd | Why do we call it inv, then? | 18:19 |
| lkcl | ~eq | 18:20 |
| lkcl | because it inverts the CR-bit | 18:20 |
| lkcl | it comes from branch. | 18:20 |
| lkcl | branch BO[0:2] is exactly the same format | 18:20 |
| ghostmansd | ~eq == ne, that's what you mean? | 18:20 |
| ghostmansd | (1, 0b000): "lt", | 18:21 |
| ghostmansd | that's how it's in table | 18:21 |
| lkcl | yes. | 18:21 |
| lkcl | yes. | 18:21 |
| ghostmansd | aha, OK | 18:21 |
| lkcl | hence the mistake just corrected where inv was ending up in bit... | 18:21 |
| lkcl | 4 | 18:21 |
| lkcl | not bit 2 | 18:21 |
| lkcl | https://libre-soc.org/openpower/isa/branch/ | 18:21 |
| ghostmansd | ahha, OK | 18:23 |
| ghostmansd | lkcl, please ping me when you update any of the tables in the docs | 19:27 |
| ghostmansd | explicitly, not like "oh there are some changes" | 19:27 |
| ghostmansd | but "check this, this and that tables" | 19:28 |
| ghostmansd | because I found that CR ops are obsolete, again | 19:28 |
| ghostmansd | even simple mode | 19:28 |
| ghostmansd | it's our luck that I'm refactoring this code, otherwise this would have gone unnoticed | 19:29 |
| ghostmansd | on bonus side, this became more elegant, I have to admit | 19:29 |
| ghostmansd | CR ops used to be kinda bastards of SVP64 | 19:30 |
| ghostmansd | (they still are, but at least appear to be normal if you observe them from a sufficiently long distance) | 19:30 |
| ghostmansd | Don'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 |
| ghostmansd | Fuck branches too | 19:34 |
| ghostmansd | Ah no, these appear to be the same | 19:35 |
| ghostmansd | +30 insertions -80 deletions with the latest patch, I like the new way | 19:36 |
| ghostmansd | OK I see it now, you also did it | 19:40 |
| ghostmansd | lol | 19:40 |
| ghostmansd | The rebase is completely fucked | 19:40 |
| ghostmansd | + if specifiers: # if any add one extra to get the extra "/" | 19:41 |
| ghostmansd | + specifiers = ['']+specifiers | 19:41 |
| ghostmansd | + if operands: # if any separate with a space | 19:41 |
| ghostmansd | + operands = " " + operands | 19:41 |
| ghostmansd | Please keep spaces | 19:41 |
| ghostmansd | Please stick to the same conventions everywhere | 19:41 |
| ghostmansd | And please avoid wording like "simpler to read", because it's not. | 19:42 |
| ghostmansd | To me these are the same TBH | 19:42 |
| ghostmansd | Anyway the former applies ^ | 19:42 |
| ghostmansd | Do not rebase it yet, the order of operands might have been changed. | 19:47 |
| ghostmansd | It 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 |
| ghostmansd | OK it seems that only /mr, /ff=COCO and /pr=JUMBO don't work, so I'm rebasing this | 19:50 |
| ghostmansd | pushed | 19:50 |
| ghostmansd | Now with the new hierarchy it'll be simpler to implement this stuff | 19:51 |
| ghostmansd | : instruction does not match 'sv.add./ff=gt *3,*7,*11' expected 'sv.add./ff=eq *3,*7,*11' | 20:02 |
| ghostmansd | que? | 20:02 |
| ghostmansd | MSB0 I'm looking at you! | 20:03 |
| ghostmansd | # barse-ackwards MSB0/LSB0. sigh | 20:04 |
| ghostmansd | lol | 20:04 |
| ghostmansd | bin(mapped)[:1:-1] | 20:04 |
| ghostmansd | This looks wrong | 20:10 |
| ghostmansd | I have these bits for eq: | 20:10 |
| ghostmansd | inv = SelectableInt(value=0x0, bits=1) | 20:10 |
| ghostmansd | CR = SelectableInt(value=0x1, bits=1) | 20:10 |
| ghostmansd | And these totally cannot be composed into 0b100 to make eq. | 20:11 |
| ghostmansd | Ah wait, I think I know | 20:15 |
| ghostmansd | first CR must be 2-bit | 20:16 |
| lkcl | ghostmansd, i did - you may have missed it, sorry | 20:16 |
| lkcl | > bin(mapped)[:1:-1] | 20:17 |
| lkcl | it looks wrong but is bizarrely correct. i say correct, i just realised it needs zero-extending | 20:17 |
| lkcl | 010 will be truncated to 10 which will be turned round to 01 | 20:18 |
| ghostmansd | no actually it works if it's kept as is | 20:18 |
| ghostmansd | as it was, to be correct | 20:18 |
| lkcl | durrr.... burble | 20:18 |
| ghostmansd | because then I can just do `mask = int(_selectconcat(inv, CR))` | 20:18 |
| ghostmansd | test is in progress | 20:19 |
| lkcl | v tired. do best you can. | 20:19 |
| ghostmansd | you already shift these by LSB_BO | 20:19 |
| ghostmansd | OK it works! Only /mr is left | 20:19 |
| ghostmansd | pushed the stuff | 20:20 |
| lkcl | ack | 20:20 |
| ghostmansd | cf. fe4eeff50d4c7a4b50854893c144edb034736ee7 to get an overall idea of how new hierarchy cuts the code | 20:20 |
| ghostmansd | rebased over master | 20:20 |
| ghostmansd | (there are more classes like this above, for sz, dz, zz, etc.) | 20:21 |
| ghostmansd | lkcl, amirite mrr is the same as mr, it's just RG=1? | 20:29 |
| ghostmansd | and all we need to do is... | 20:29 |
| ghostmansd | if self.RG: | 20:29 |
| ghostmansd | yield "mrr" | 20:29 |
| ghostmansd | add else branch here | 20:30 |
| ghostmansd | nah that's not correct... | 20:32 |
| ghostmansd | or, 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 |
| ghostmansd | I pushed this change anyway, because it leaves only two tests broken | 20:34 |
| *** octavius <octavius!~octavius@158.147.93.209.dyn.plus.net> has quit IRC | 20:37 | |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC | 21:01 | |
| lkcl | ghostmansd[m], yes basically | 21:13 |
| lkcl | echo 'sv.crand 12,2,33' | pysvp64asm > sv.crand.tst.s | 21:20 |
| lkcl | 0: 20 00 40 05 .long 0x5400020 | 21:21 |
| lkcl | 4: 02 0a 82 4d crand 4*cr3+lt,eq,gt | 21:21 |
| lkcl | echo -n -e '\x20\x00\x40\x05\x02\x0a\x82\x4d' | pysvp64dis -v | 21:22 |
| lkcl | cr_op: simple mode | 21:22 |
| lkcl | RM | 21:22 |
| lkcl | 000000000000000000100000 | 21:22 |
| lkcl | RM.mode | 21:22 |
| lkcl | 00000 | 21:22 |
| lkcl | 27, 28, 29, 30, 31 | 21:22 |
| lkcl | ghostmansd[m], sorted, bit of a hack-job. | 21:32 |
| lkcl | no i have a better way | 21:34 |
| lkcl | sorted | 21:34 |
| lkcl | predication sorted | 22:00 |
| *** lxo <lxo!~lxo@linux-libre.fsfla.org> has joined #libre-soc | 22:14 | |
| ghostmansd[m] | Check a bit | 22:30 |
| ghostmansd[m] | Again, please finally start using spaces when needed | 22:30 |
| lkcl | i have no idea what you're referring to | 22:31 |
| ghostmansd[m] | No "sw="+sws is not more readable than f"sw={sw}" | 22:31 |
| ghostmansd[m] | Not at all | 22:31 |
| lkcl | yep it should be "sm=" + sw | 22:31 |
| ghostmansd[m] | If you do some operation, please put spaces there | 22:31 |
| lkcl | pep8 will complain about it | 22:31 |
| lkcl | am rushing. it's late. meeting early tomorrow. sorry | 22:32 |
| ghostmansd[m] | Ok | 22:32 |
| ghostmansd[m] | That's just the third or forth time I'm asking about it | 22:32 |
| lkcl | missed it, sorry | 22:32 |
| ghostmansd[m] | If you're that stubborn with f strings, at least please make it clean | 22:33 |
| ghostmansd[m] | Ok, this is all bollocks, to the point | 22:33 |
| lkcl | tired, and i'm rushing. sorry. | 22:34 |
| ghostmansd[m] | I don't quite get the sense of change with CROpSimpleRM | 22:34 |
| lkcl | trying 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 possible | 22:35 |
| ghostmansd[m] | Why that RG is different? | 22:35 |
| lkcl | because it was deriving from.... something-else, forgotten | 22:35 |
| lkcl | RG was supposed to be only on mapreduce | 22:35 |
| lkcl | but there's space to do a reverse-gear in CRops | 22:35 |
| lkcl | *nothing to do with mapreduce* | 22:35 |
| ghostmansd[m] | But we don't even have 'rg' in asm | 22:35 |
| lkcl | therefore you cannot report... yes i know. | 22:36 |
| lkcl | i haven't done crops at all, remember? | 22:36 |
| lkcl | i'm amazed it works at all | 22:36 |
| ghostmansd[m] | So this is RG field which is not about reverse gear? | 22:36 |
| lkcl | yes it is reverse-gear | 22:36 |
| lkcl | but not mapreduce-reversegear | 22:36 |
| ghostmansd[m] | Ah, just not mapreduce | 22:36 |
| ghostmansd[m] | Sigh | 22:36 |
| lkcl | therefore you cannot report "mr" or "mrr" | 22:36 |
| ghostmansd[m] | It's fricking confusing :-) | 22:37 |
| lkcl | i _would_ have a reversegear in the other modes | 22:37 |
| lkcl | if there were enough bits | 22:37 |
| lkcl | which there aren't | 22:37 |
| ghostmansd[m] | Ok, that I couldn't imagine | 22:37 |
| ghostmansd[m] | OK, it became clearer | 22:37 |
| lkcl | it's olny CRops which has the extra spare bits (from using elwidths) | 22:37 |
| ghostmansd[m] | Thank you! | 22:37 |
| lkcl | but it turns out... | 22:37 |
| lkcl | mapreduce is a lie :) | 22:37 |
| lkcl | so you *can* actually enable /mrr and use the reverse-gear of mapreduce to do non-mapreduce reverse-gear | 22:38 |
| ghostmansd[m] | Just like PU and parallel? :-P | 22:38 |
| lkcl | arrrrrrrgh | 22:38 |
| lkcl | no god no | 22:38 |
| lkcl | those were just fucked :) | 22:38 |
| ghostmansd[m] | lol | 22:38 |
| lkcl | will explain tomorrow | 22:39 |
| lkcl | late. | 22:39 |
| ghostmansd[m] | Ok, I will clean this up tomorrow, too tired today | 22:39 |
| ghostmansd[m] | Same, yeah | 22:39 |
| * lkcl salutes | 22:39 | |
| ghostmansd[m] | I guess we almost completed asm, though | 22:39 |
| ghostmansd[m] | *dis | 22:39 |
| lkcl | pretty much | 22:39 |
| ghostmansd[m] | So when this is ready I'll begin binutils migration | 22: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!~lxo@linux-libre.fsfla.org> has quit IRC | 23:38 | |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!