Friday, 2022-09-02

ghostmansdI've submitted the minor correction to OPF07:50
ghostmansdThanks for the URL!07:51
lkclghostmansd, very cool08:00
ghostmansdI'm more and more confident that adding the validation is essential.08:00
lkcla bit of investigation overnight - deep breath - it looks like we actually altered the pseudocode about 18 months ago08:00
lkcl 369     n  <- sh                 # changed ~18 months ago08:01
lkclwhere the original (v3.0B and v3.0C and v3.1 and v3.1C)08:01
lkcl 369     n <- sh[5] || sh[0:4]08:01
ghostmansdHm08:01
ghostmansdYeah I seem there's a discrepancy08:02
lkcli'm going back to sleep for a bit but wanted to do a heads-up08:02
ghostmansdIt's not caused by XLEN migration, though...08:02
ghostmansdPresent in the "add markdown"08:02
ghostmansdcommit08:02
lkclbasically unless you do that the definition of sh in section 1.6.2 is useless.08:02
lkclno, correct, because it's an immediate08:02
lkcli.e. whoever wrote the spec got that ordering of the bits wrong.08:03
lkcl(in the pseudocode)08:05
ghostmansdYet another corrigenda?08:06
ghostmansdWait... But isn't sh[5] || sh[0:4] is the same as sh?08:07
lkclurrr... i have a sneaky suspicion you might be right :)08:10
lkclcan i ask you a favour, could you do a proper unit test showing binutils vs pysvp64dis?08:11
lkcl(but also printing out to stdout)08:12
lkclextswsli  ... sh=108:12
lkclextswsli  ... sh=208:12
lkclextswsli  ... sh=408:12
lkclextswsli  ... sh=808:12
lkclextswsli  ... sh=1608:12
lkclextswsli  ... sh=3208:12
lkclso we can see where the bits actually land in the 32-bit binary, in both binutils and pysvp64dis?08:13
lkclghostmansd, damnit, no sh[5] || sh[0:4] *isn't* the same because MSB0 order, remember?08:16
lkclSH[5] is the *LSB* which is shifted to the *top* bit position numbered 0 in MSB0 order... urrr....08:16
* lkcl brainmelt08:17
programmerjakelkcl, the fptrans opcodes overlap, can I reallocate them? or should I let you?08:20
*** jn_ is now known as jn08:20
programmerjakein the process, I'd like to convert the A-FORM instructions to X-FORM, in order to match XO allocation style for every single instruction added since the original PPC processor08:22
programmerjakefor details, see https://lists.libre-soc.org/pipermail/libre-soc-dev/2022-September/005253.html  and https://bugs.libre-soc.org/show_bug.cgi?id=899#c508:23
programmerjakenone of the 1-in instructions will have EO added08:24
ghostmansd[m]lkcl, sure09:07
ghostmansdLet me tune the code appropriately so I'll dump all fields, too09:08
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC09:13
ghostmansdbinutils:   0:   f4 3e 23 7c     extswsli r3,r1,709:13
ghostmansdpysvp64dis: f4 3e 23 7c    extswsli r3,r1,709:14
ghostmansdfields={'RA': (11, 12, 13, 14, 15), 'Rc': (31,), 'RS': (6, 7, 8, 9, 10), 'sh': (30, 16, 17, 18, 19, 20), 'XO': (21, 22, 23, 24, 25, 26, 27, 28, 29)}09:14
ghostmansdoperands=[Operands.DynamicOperandGPR(name='RA'), Operands.DynamicOperandGPR(name='RS'), Operands.DynamicOperand(name='sh'), Operands.StaticOperand(name='Rc', value=0)]09:14
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc09:15
ghostmansdsh = insn[record.fields["sh"]]09:19
ghostmansdprint(_selectconcat(sh[5], sh[0:4]))09:19
ghostmansdprint(_selectconcat(sh))09:19
ghostmansdSelectableInt(value=0x11, bits=5)09:19
ghostmansdSelectableInt(value=0x7, bits=6)09:19
ghostmansdHm, I'm confused09:20
ghostmansdAh wait, the order must have been reversed...09:22
programmerjakeextswsli: https://gcc.godbolt.org/z/95P4c94dn09:24
ghostmansdprint(_selectconcat(sh[0:5], sh[5]))09:25
ghostmansdOnly this combination gives the same as accessing sh09:26
ghostmansdAlso, 7 is a bad choice...09:27
ghostmansdbut anyway09:28
ghostmansdthese three are equal09:29
ghostmansd_selectconcat(sh[0:6])09:29
ghostmansd_selectconcat(sh[0:5], sh[5])09:29
ghostmansd_selectconcat(sh)09:29
programmerjakehttps://gcc.godbolt.org/z/drYh5Padc09:38
programmerjaketemplate<unsigned v>09:39
programmerjakestatic void extswsli_3_3_v() {09:39
programmerjake    const unsigned opcode = ((v & 0x20) >> 4) + ((v & 0x1F) << 11) + 0x7C6306F4U;09:39
programmerjake    asm volatile(09:39
programmerjake        "nop\t\n"09:39
programmerjake        ".long %0\t\n"09:39
programmerjake        "extswsli 3, 3, %1"09:39
programmerjake        :: "i"(opcode), "i"(v)09:39
programmerjake        : "r3");09:40
programmerjake}09:40
programmerjakematches exactly09:40
ghostmansdlkcl, ah, you also checked other XS-form users, nice09:45
ghostmansdso much cringe in ISA :-)09:46
ghostmansdlkcl, please keep commits title short09:56
ghostmansdc865b6c909:56
ghostmansdhttps://www.conventionalcommits.org/en/v1.0.0/09:56
programmerjakeoff-topic, if anyone is using mosh in termux, don't apt upgrade till after they fix this bug: https://github.com/termux/termux-packages/issues/1178709:57
ghostmansdFolks, I've rebased master over dis branch; please let me know if any issues appear, feel free to rollback. I checked test_caller_svp64, works fine.09:59
ghostmansdThere are simply too many changes to keep them aside. That said, all changes reside in power_insn, power_fields and pysvp64dis, so they should be plus-minus safe.10:01
ghostmansdOh, and test_caller is also OK.10:01
*** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC10:24
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC10:49
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.43.156> has joined #libre-soc10:50
*** octavius <octavius!~octavius@130.147.93.209.dyn.plus.net> has joined #libre-soc11:01
lkclghostmansd[m], were you able to keep the rc_only branch work from yesterday?11:57
ghostmansd[m]I rebased atop of the recent master; since I had to rename enum from RC to RCOE, I suppose you already merged it to master, didn't you?11:58
lkclyes11:58
ghostmansd[m]OK then :-)11:58
lkclwhewww11:58
ghostmansd[m]I have not yet updated RC.RCOE, though11:58
ghostmansd[m]Will do soon11:59
ghostmansd[m]I rebased this code and forgot to tune it11:59
lkclprogrammerjake, i went over the table a month ago, i made sure to miss any existing ops11:59
lkclhowever11:59
lkclthere is no guarantee that i didn't get the top-5-bit and lower-5-bit the wrong way round11:59
lkcl(a common mistake i tend to make)11:59
programmerjakeso do you mind if i redo it? i'm probably much less prone to that particular mistake12:01
lkclcan you see the pattern that i made?12:01
programmerjakei didn't look for patterns at the time, but i can look when it's not 4am12:02
lkcl:)12:02
programmerjakei saw the notes about f*s going in 1 major op and f* in the other12:02
ghostmansd[m]Nah, 4 am is the best time to check patterns12:02
lkcl0b00 exp{something}-minus-one12:02
lkcl0b01 log{something}-plus-one12:03
lkcl0b10 exp{something}12:03
ghostmansd[m]I'm one of freaks who tend to study these things at 4am :-)12:03
lkcl0b11 log{something}12:03
lkclghostmansd[m], been there...12:03
lkcland a similar thing for sin cos and tan12:04
programmerjakei'm watching videos until sunrise, when i'll spray some wasp nests that decided my car was a nice place to live...then i'll get some sleep12:04
lkclit was a lot of work.12:04
lkclniiice12:04
programmerjakeimho grouping by the algorithm needed to implement it might be a better approach12:05
lkclyou have to be *really* careful with the fact that they've dropped a bunch of other operations in places12:05
lkclget some sleep, i'll take a quick look and see if it's dead-easy-to-fix12:06
programmerjakeyeah, i'll look at the appendix listing unused XO values12:06
programmerjakei want to also convert all A-form to X-form in the process, see my emails about that...matches existing practice from last 17yr of new instructions12:07
programmerjakehttps://lists.libre-soc.org/pipermail/libre-soc-dev/2022-September/005253.html12:08
programmerjakeand the following email12:08
lkclfrick, i know what it is. i was looking at v3.0B and they've now taken up some of that space with v3.1.  frick12:11
lkclthat completely fucks up everything i did.12:11
programmerjakeit's mostly fptrans conflicting with fptrans, i didn't check for conflicts with v3.1B yet12:13
programmerjakelemme fit it tomorrow12:14
programmerjakeif that's ok with you12:14
programmerjakefix not fit12:14
lkclok. sure. i can get on with other things.12:15
lkclghostmansd[m], test_caller*.py all good in master13:03
programmerjakeoh, btw lkcl: i renamed the decoder formal proofs to test_*.py so pytest runs them in ci, they both fail and need updating13:10
programmerjakehttps://git.libre-soc.org/?p=openpower-isa.git;a=commitdiff;h=a205a63b53e3db7b217bc11263f29f5fb09421f313:11
programmerjakeI updated RC -> RCOE but test_decoder2.py needs the other new values added13:13
lkclnot happening. they are better off being deleted.13:14
lkclah actually they're not so bad13:15
programmerjakea recurring issue imho is AttributeError: pdecode2.e.imm_data ... i've seen that several places, i'm guessing you made that optional and not enabled by default but missed changing all uses of it13:23
lkclthere are multiple Records that can be dropped into pdecode2.e13:24
lkclyou have to make sure that the Record used actually has that attribute13:25
lkclghostmansd[m], soc/simpletest/test_issuer.py nosvp64 all good13:27
ghostmansd[m]Cool13:28
ghostmansd[m]Seems like we're all set for SVP64 disassembly?13:28
* lkcl scared13:28
lkclyes?13:28
lkclseriously, yes - go for it.13:30
lkcli can try svshape2, now13:30
programmerjakelkcl, if you have a signal that you want to match against all enum values in an enum, you can use sig.matches(*MyEnum)14:01
lkcloh duh14:01
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.43.156> has quit IRC14:01
lkclpffh :)14:01
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc14:02
ghostmansd[m]Even if you're scared, imagine how I am! :-D14:04
*** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc14:47
*** lx0 <lx0!~lxo@gateway/tor-sasl/lxo> has quit IRC15:26
*** lx0 <lx0!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc15:27
ghostmansdI thought about it, and came to conclusion that we should express stuff like SVP64MODE.REDUCE, SVP64MODE.SZ, SVP64MODE.MOD2_MSB via fields, too.15:29
ghostmansdFirst, I'd really like to update these on the flight in fields, instead of remembering it and setting later.15:29
ghostmansdSecond, setting fields instead of having separate enum-like stuff is much cleaner.15:30
ghostmansdThird... I really want to re-use this code in both binutils and disasm, and have no patience to write it that differently.15:31
ghostmansdI think that the fields I introduce even allow multiple inheritance. I think that I'll introduce some classes like SVP64Prefix.Branch, SVP64Prefix.MapReduce, etc.15:32
ghostmansdAnd then get/set fields via these getters/setters.15:32
ghostmansdCalculating these via shifts and bit masks is a madness, it's way too verbose.15:33
lkclyes - bear in mind the long-term plan is to have SVP64MODE.REDUCE etc. read out of an svp64-fields.txt file15:33
lkcland for arithmetic/branch/ldst/cr_ops, to be "Forms"15:34
lkcl>  I really want to re-use this code in both binutils and disasm,15:34
lkclhaha :)15:34
ghostmansdThen it's even more valid to start migration sooner.15:34
lkclyes, otherwise you get mistakes15:34
ghostmansdOr well, I meant pysvp64dis15:34
ghostmansdSorry :-)15:34
* lkcl doing an svshape2 stub15:35
lkclkinda concentrating ^15:35
ghostmansdAnyway, I knew you'd share this idea15:35
lkclor trying to.  4 phone calls15:35
ghostmansdOK, good luck :-)15:35
lkclyes indeed15:35
lkclappreciated :)15:35
lkclsvshape2 added to master (stub)15:57
lkclghostmansd, SVrm values used by svshape disallowed...16:17
lkclhttps://git.libre-soc.org/?p=openpower-isa.git;a=commitdiff;h=52029d836a0ee8c5c701cb2f056b1cb56bd9a21116:17
lkclnow to add svshape216:17
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC16:25
*** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC16:25
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.54.125> has joined #libre-soc16:26
lkclghostmansd[m], ping - rrright.  target_addr *is* correct.17:12
lkcl(and does have to be done as a custom field)17:12
lkclit's like the "SVd-1" thing17:12
lkclit is *not* LI (or BI).17:12
lkclwhy?17:12
lkclbecause if you have a target_addr of say 0b00000117:12
lkclthat is *not expressable* with (LI || 0b00)17:13
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.54.125> has quit IRC17:13
lkclthe first two bits (0b01) try to match up with (0b00) and of course fail17:13
lkcland the *other* bits 0b0000 match up with LI17:13
lkclthis is what the spec authors were trying to say with target_addr but didn't really make it clear17:14
lkclso yes, the things you were doing with target_addr custom field were actually the right direction17:14
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc17:14
lkclwark-wark17:14
lkcl"commit 05cfb8ad4" was correct but also needed a corresponding *assemble* thing17:16
lkclwhich17:16
lkcl* checks that the first two bits of target_addr are zero17:16
lkcl* chops them off17:16
lkcl* drops the remainder into the "LI" field17:16
lkcl* continues from there17:16
*** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc17:47
ghostmansdsrcwid = (bc_vsb << 1) | bc_lru17:59
ghostmansddestwid = (bc_lru << 1) | bc_all17:59
ghostmansdIs it correct that bc_lru used both for srcwid and dstwid, and appears in different place?18:00
lkclghostmansd, i haven't been able to get to svp64 branches. too overloaded.18:00
lkcli need to spend about 5-7 days implementing a massive stack of unit tests18:01
lkclat which point i can answer questions confidently18:01
ghostmansdsigh, accidentally these were the first I looked at, since the whole code starts with "if we're in branch function..."18:02
lkclooops :)18:03
lkclgive me a moment to try to answer then18:03
lkclhttps://libre-soc.org/openpower/sv/branches/18:04
lkclvs the Common RM Fields18:05
lkclhttps://libre-soc.org/openpower/sv/svp64/18:05
lkclELWIDTH 4:5 Element Width18:05
lkclELWIDTH_SRC 6:7 Element Width for Source18:05
lkcltherefore destwidth = (ALL, SNZ)18:07
lkcland srcwidth = (VSb, CTi)18:07
lkclcan i suggest skipping branch entirely for now due to the spec rewrite that occurred appx... 5 months ago?18:08
ghostmansd[m]lkcl, I cannot even understand how to read the table there18:09
ghostmansd[m]These 4..23... What do they stand for?18:10
lkcli altered it *after* i did the first implementation of svp64.py18:10
lkclSVP64.RM[4..23]18:10
ghostmansd[m]These are bit positions, but relative to what?18:10
ghostmansd[m]Ah, OK18:10
lkclthe 24-bit RM18:10
ghostmansd[m]Ok, what'd be the better place to start with?18:10
lkclnormal mode and ld/st mode18:11
ghostmansd[m]Ok, 4..23. and where are the rest?18:11
ghostmansd[m]0..3 inclusively?18:11
lkclhttps://libre-soc.org/openpower/sv/svp64/18:11
lkclCommon RM fields18:11
lkclMASKMODE 0 Execution (predication) Mask Kind18:11
lkclMASK 1:3 Execution Mask18:11
ghostmansd[m]OK18:12
ghostmansd[m]...I'll start with LDST then18:12
lkclgood idea :)18:12
ghostmansd[m]https://libre-soc.org/openpower/sv/ldst/18:13
ghostmansd[m]This, right?18:14
lkclyyyep18:14
lkcli still have to add parallel-prefix specifier btw to sv/trans/svp64.py18:14
*** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC18:19
ghostmansd[m]It's SOOO complicated in pysvp64asm. The link talks about bits, but we operate on these bits only with respect to fields.18:23
ghostmansd[m]But OK, with new fields it'll be a mirror of spec.18:24
lkcli hit it all at once, blasted through it18:24
lkclgooood18:24
ghostmansd[m]https://libre-soc.org/openpower/sv/ldst/18:27
ghostmansd[m]Again, in these tables...18:27
ghostmansd[m]Say in section 4 Format and fields18:27
ghostmansd[m]0-1 2 3 4 refer to bits inside RM?18:28
ghostmansd[m]That is, like RM[0,1], RM[2], and so on?18:28
lkclno in that case they refer to SVP64.RM.MODE18:29
lkclwhich is from18:29
lkclhttps://libre-soc.org/openpower/sv/svp64/18:29
lkclCommon RM fields18:30
lkclMODE 19:23 changes Vector behaviour18:30
* lkcl just editing to make that clear18:30
ghostmansd[m]Can the tables be formatted properly? After you mentioned, I found it.18:30
ghostmansd[m]Yeah thank you!18:31
lkcldone18:31
ghostmansd[m]I was rather expecting something like RM.MODE[0:1] in the table header :-)18:34
ghostmansd[m]But OK18:34
lkclnggghh... ok 1 sec18:34
lkclthat has to be done in the (normal) table as well18:35
lkcli know why i didn't do it: it expands the table hugely18:35
lkcl(and i edit regularly on a smartphone. usually at 3-4am...)18:36
ghostmansd[m]Hm... Perhaps we might use indices relative to RM always, then?18:37
lkclhmmm hmmm, kinda defeats the object of having RM.MODE18:38
ghostmansd[m]Fair enough18:41
ghostmansd[m]What is RA.isvec?18:42
lkclthat's from EXTRA2/3 encoding18:42
ghostmansd[m]RA is vector? Decoded from prefix?18:42
lkclyes.18:42
lkclit's a way to say "read EXTRA2/3 and find out if it's set to a vector"18:43
lkclin semi-pseudo-code-like-language18:43
ghostmansd[m]Sigh18:44
ghostmansd[m]Why it should be this way?18:44
lkclyou're looking at the LD/ST pseudocode?18:44
ghostmansd[m]Why not say extra2[IDX][BIT]?18:44
ghostmansd[m]if RA.isvec:18:45
ghostmansd[m]    svctx.ldstmode = indexed18:45
ghostmansd[m]This is the code I'm looking at18:45
lkclok 1 sec...18:45
ghostmansd[m]I mean, the reader must know the entire spec to get even the slightest idea18:46
ghostmansd[m]Why not say "refer to these bits in RM"?18:46
lkclbecause the number of people who have actually read it and bothered to ask questions is f*****g negligeable18:46
lkcland i can't do everything18:47
ghostmansd[m]:-)18:47
ghostmansd[m]Fair answer18:47
* lkcl thinking18:48
ghostmansd[m]Anyway, this was rather "how about...",  not really "why the fuck" :-)18:48
ghostmansd[m]No pun intended, I'm just not that good in spec yet18:48
ghostmansd[m]You, as the one who wrote it, know it, so for you some moments are obvious18:48
ghostmansd[m]Not the same for a stranger like me18:49
lkclbut it has to be submitted upstream18:49
lkclso has to be right18:49
lkclwhich is good18:49
lkclas you help highlight things i missed18:49
lkclbtw that RC.isvec (etc) section is *not* changing the encode/decode18:51
lkclmeaning, you can concentrate on just the table(s)18:52
lkclbut18:52
lkclat some point18:52
lkclsome sanity-assertions should be added18:53
ghostmansd[m]I agree18:56
ghostmansd[m]Sorry for distracting you, I know you have a lot to do18:56
ghostmansd[m]But this is crucial18:56
ghostmansd[m]For word instructions, things were simple (mostly)18:56
programmerjakethough iirc i'm actually the one who came up with extra2/3 -- so blame me?18:58
ghostmansd[m]And here many things have to be done manually, and, since I've just started diving into that, I have a lot of stupid questions18:58
ghostmansd[m]Nobody is to be blamed :-)18:59
ghostmansd[m]I just need your guidance, folks, that's it18:59
lkclno problem. for now focus on the table(s)19:01
*** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc19:40
sadoon[m]Hi guys20:35
sadoon[m]Has anyone tried to set up the dev environment on ppc64le yet?20:35
sadoon[m]Or in better phrasing, do the scripts from https://libre-soc.org/HDL_workflow/devscripts/ work with ppc64le?20:38
sadoon[m]I started the process but I just want to make sure I'm not wasting time reinventing the wheel :P20:39
programmerjakeiirc someone tried before, it was mostly successful.20:52
sadoon[m]Hmm sounds good to me, but I already ran into an issue with user creation at the end of the script20:53
sadoon[m]I'll fix it and push a commit20:54
sadoon[m]*pull request20:54
sadoon[m]Ah I see, the problem is the script assumes there's a "$SUDO_USER" variable but I use doas on my system.20:59
lkclsadoon[m], yes, at least one person has, tplaten21:11
lkclyep you need to specifically follow the scripts precisely and exactly21:12
sadoon[m]Just finished creating accounts on opencollective, the mailing list, and the site21:13
sadoon[m]Now working on adding my name to the current members and then I'd like to add an if statement to the script to check for $SUDO_USER :)21:14
sadoon[m]Well I already screwed up, added myself to the object automation list21:26
sadoon[m]Where should I add myself?21:26
lkclsadoon[m], lol21:29
lkclhttps://libre-soc.org/about_us21:29
lkcli think21:29
lkclgimme a sec21:29
sadoon[m]Yes that's where I did it21:29
sadoon[m]But there's a list there "object automation"21:29
lkclyes, i'll move them further down21:30
sadoon[m]Awesome thanks21:30
lkclyou're happy with the Charter, btw/21:31
lkclhttps://libre-soc.org/charter/discussion/21:31
lkcldo let me know21:31
lkcltook me a while to find the right dilbert cartoons21:32
sadoon[m]I did read it before but that was a long time ago, I'll give it another read21:32
sadoon[m]I remember it being amusing21:32
lkcloh good :)21:33
ghostmansdDoes the following look right? https://pastebin.com/5q3Utj6y21:33
ghostmansdSVP64 instruction layout (obviously RM is remapped)21:34
ghostmansd(so is everything nested to it)21:34
lkcleek! :)21:35
ghostmansdNames are idiotic.21:35
ghostmansdIf you could give a sweet name to each mode, that'd be great.21:35
lkclno like'em they're short21:35
ghostmansdThey're short, but probably not quite self-documented.21:35
ghostmansdNobody would guess what prrc1 means.21:36
lkclpffh21:36
lkclurrr, can you do the numbering relative to RM?21:36
ghostmansdpred-result with Rc=121:36
lkclyaaay21:36
ghostmansdThis is relative to RM...21:36
ghostmansd...only to remapped one21:36
ghostmansdBut I can, 1 sec21:36
lkcli can't think in terms of "right down to the 32-bit int", but i can (just) think in terms of 24-bit RM21:37
ghostmansdhttps://pastebin.com/eEMDvMNw21:38
ghostmansdthis is if RM is not remapped21:38
lkclhooray.21:38
lkcli can cope with that. gimme10.21:38
sadoon[m]<lkcl> "took me a while to find the..." <- They're perfect xD21:38
sadoon[m]Very happy with the charter, extremely welcoming and unlike another big project that starts with a G21:39
lkclsadoon[m], awesome.21:39
lkclghostmansd, these are unnecessary21:39
lkclprefix.rm.mode.ldst.imm.normal.dz (22,)21:39
lkclprefix.rm.mode.ldst.imm.normal.sz (22,)21:39
ghostmansdYeah I know21:40
ghostmansdAutomatically added these21:40
lkcland thse21:40
ghostmansdSince the spec mentioned that zz == both sz and dz21:40
lkclprefix.rm.mode.ldst.imm.spu.dz (22,)21:40
lkclprefix.rm.mode.ldst.imm.spu.sz (22,)21:40
ghostmansdbut yeah I'll drop these21:40
lkclbut... ahhh yes21:40
sadoon[m]Time to hit the sack here, I'll leave the script running and see how it does in the morning. Night everyone!21:40
lkclok i see what you did21:40
lkclsadoon[m], night :)21:40
ghostmansdsadoon[m], gn!21:40
programmerjakegn21:41
lkclthey map to bit 22.  ok that's smart21:41
ghostmansdyeah kinda alias21:41
lkclare you going to add a mode to cover bits 19-20?21:42
ghostmansdI'm not sure how to handle it better TBH21:42
ghostmansdbecause these modes I posted...21:42
ghostmansdthe actual choose...21:42
ghostmansdit depends on bits 19..2021:42
lkclwhich can be compared against 0b00 for normal... hang on... 19-23==0b00021:42
ghostmansdI'm not sure how to describe it better21:42
ghostmansdI mean, Python-wise21:43
ghostmansdhow do they call it in parseltongue?21:43
ghostmansdlet me push the branch21:43
ghostmansdso that you could see how ugly it's in Python21:43
ghostmansdand how it begs to kill ^W generate it21:43
lkclok yep gone over them all, happy with them all21:43
lkclreally: we *really* should have done this as svp64fields.txt21:44
lkclsigh21:44
lkclhindsight's a bitch21:44
ghostmansdOK pushed21:46
ghostmansdbeware21:46
ghostmansdcan provoke eyes to bleed21:46
lkcl:)21:47
ghostmansdbut yes, if these are _generated_, it won't be that bad21:47
ghostmansdonly look listening to this song: https://www.youtube.com/watch?v=-tebshO9wZo21:47
ghostmansd(it's sufficient to listen to refrain only)21:48
ghostmansdAlso, this Rc=1... where is it?21:49
ghostmansdOr Rc=021:49
lkcl"."21:49
lkclsv.add.21:49
ghostmansdAh21:49
ghostmansdso we check the suffix, too?21:49
lkclyes21:49
lkclfun, eh?21:49
ghostmansdYou know, this is a cheat!21:49
lkcluh-huhn :)21:49
ghostmansdNobody likes cheaters :-)21:49
lkclsaves a bit in the (extremely precious) prefix21:49
ghostmansd> <lkcl> are you going to add a mode to cover bits 19-20?21:50
lkclif it's not an Rc-style op, you assume the RC1 column21:50
ghostmansd> <ghostmansd> I'm not sure how to handle it better TBH21:50
lkclthis is a really werid song21:50
ghostmansdas everything by Pixies21:50
ghostmansdI haven't promised it'd sound like Morrisey21:50
ghostmansd:-)21:51
ghostmansdor well at least Robert Smith21:51
ghostmansdanyway21:51
ghostmansdreturning to these bits21:51
lkclhttps://www.youtube.com/watch?v=7ILNpR9DfYE21:51
ghostmansdI'd really like to somehow choosing the mode automatic...21:51
ghostmansddepending on RM.mode[(0, 1)]21:52
ghostmansdand other stuff like Rc21:52
ghostmansdBut I have no idea how to code it21:52
ghostmansdI mean, how'd it look code-wise21:52
lkclwell, funnily enough, power_decoder.py CSV files covers exactly that21:52
ghostmansdI can do bunch of ifs/elses21:52
lkcldrunk on the laaawn in a nuclear daaawn, my seeenses fiiinally blurrred21:53
lkclworks for me.21:56
ghostmansdIDK why but it again reminds the song about old Mc'Donald and his cow21:57
ghostmansdbut nice21:57
ghostmansd> works for me21:57
ghostmansdNo, I mean, I know it'd work21:57
ghostmansdThis is just not something I'd like to eventually see21:57
ghostmansdIdeally I'd like this to be generated...21:57
ghostmansdBut no idea how to generate it from the tables21:58
ghostmansdAnyway, I'm postponing it for now21:58
lkclyes. it'd be something close to power_decoder.py or ah yes, at least the CSV reader21:58
lkclwhere "XO" is the "mode".21:58
lkclXO would be "001" for normal21:59
ghostmansdyeah likely something like this21:59
lkcl"001" for PU21:59
lkcl"01-" for ffirst... you get the idea21:59
lkcland there'd be a column "SVMode" as well22:00
ghostmansdyou noticed how I eventually came up with kinda language in a language?22:00
lkclscary :)22:00
ghostmansdthat is, we kinda "describe" the fields22:00
ghostmansdI'm scared22:00
lkclyehyeh22:00
lkcly'know there's almost certainly reverse-engineering tools that do this stuff22:01
lkcli used to do it all the time with samba / NT-domains (MSRPC aka DCE/RPC)22:01
lkcland network-packet-analysis tools all have to do the same thing22:01
lkclgem5 ended up doing something similar22:02
lkclbut hollyeeeee cowww is the auto-generated code BIG22:02
lkclmulti-depth switch statements22:02
lkcland yes that's *actually* a mini-programming-language they ended up with22:02
ghostmansdwell we kinda too22:03
ghostmansdfor us this is simpler, though: the overall combinations are not that huge22:03
ghostmansdalso, I noticed (even before, when I checked pysvp64asm, but now even clearer)22:03
ghostmansdsome fields are present in both normal and LDST modes22:04
lkclyes.22:04
ghostmansdSo I'll likely decouple them eventually22:04
lkclthey are22:04
lkcli tried keeping them roughly in the same place22:04
ghostmansd10     N     dz sz     sat mode: N=0/1 u/s, SUBVL=122:04
ghostmansdthis, for example, can be shared22:04
lkclhmm...22:05
ghostmansdwhere do we have this? https://libre-soc.org/openpower/sv/normal/22:05
lkclpower_enums.py - SVMode needs a LDST_IMM and a separate LDST_IDX22:06
ghostmansdI'd like to have the actual version in text, w/o switches to browser22:06
lkclthere's a pdf version22:06
lkcland it's in the git repor22:06
lkcl1sec22:06
ghostmansdno I mean kinda submode22:06
lkclhttps://git.libre-soc.org/?p=libreriscv.git;a=blob;f=openpower/sv/normal.mdwn;hb=HEAD22:06
lkclhuhn?22:07
ghostmansde.g. normal submode for normal has the same sat sub-submode as immediate submode for LDST mode22:07
ghostmansdhttps://libre-soc.org/openpower/sv/normal/22:07
ghostmansdhttps://libre-soc.org/openpower/sv/ldst/22:07
ghostmansdcf. `10     N     dz sz     sat mode: N=0/1 u/s, SUBVL=1`22:08
ghostmansdthat line can be moved to some shared class22:08
lkcltoo tired to think about it22:09
ghostmansdhttps://pastebin.com/6H3Mnnti22:09
ghostmansdthis can be decoupled and re-used22:09
ghostmansdthe layout is the same22:09
ghostmansdbut OK, I won't bother :-)22:09
lkcl:)22:09
lkclneed to go read a book22:10
ghostmansdHoly shit!22:24
ghostmansdstatic inline uint64_t22:24
ghostmansdsvp64_insn_get_prefix_rm_mode_ldst_imm_sat_zz(const struct svp64_insn *insn)22:24
ghostmansd{22:24
ghostmansd  uint64_t value = insn->value;22:24
ghostmansd22:24
ghostmansd  return (22:24
ghostmansd    (((value >> UINT64_C(33)) & UINT64_C(1)) << UINT64_C(0)) |22:24
ghostmansd    UINT64_C(0)22:24
ghostmansd  );22:24
ghostmansd}22:24
ghostmansdThe binutils even automatically granted such complex getters/setters22:24
ghostmansd*gained22:24
ghostmansdhttps://pastebin.com/V2B6Eicm22:25
ghostmansdkinda "feel the power of the automatic generation"22:26
ghostmansdA side note: could we call "normal" at https://libre-soc.org/openpower/sv/normal/ something else?22:48
ghostmansdor, at least, in the mode table there, call the first entry by a different name (and therefore do the same for LDST)22:49
ghostmansdperhaps we could call it "usual" or "regular" or "simple"22:49
ghostmansdhaving Normal.normal looks pretty strange, and also forces to explicitly mention which "normal" I mean in discussions22:50
ghostmansdOK I've added these modes: LD/ST immediate, LD/ST indexed, normal23:07
ghostmansdI assume branches and CR are not ready yet23:07
ghostmansdYou know what I thought? Eventually it'd be great to rewrite the pysvp64asm so that, for example, when it sees, say, "/sz", it would simply update the instruction in-flight, that is, based on its type, select the right field.23:08
ghostmansdBy the way, I introduced mode selector, already. And all mode-inherited classes also get this field.23:12
ghostmansdOK, enough for today, check dis branch (the usual eyes-bleeding disclaimer)23:13
ghostmansdoh, just one last note: https://pastebin.com/e5zjRvyc23:15
ghostmansd^ collection of all fields we now have in RM23:15
*** octavius <octavius!~octavius@130.147.93.209.dyn.plus.net> has quit IRC23:34

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