| ghostmansd | I've submitted the minor correction to OPF | 07:50 |
|---|---|---|
| ghostmansd | Thanks for the URL! | 07:51 |
| lkcl | ghostmansd, very cool | 08:00 |
| ghostmansd | I'm more and more confident that adding the validation is essential. | 08:00 |
| lkcl | a bit of investigation overnight - deep breath - it looks like we actually altered the pseudocode about 18 months ago | 08:00 |
| lkcl | 369 n <- sh # changed ~18 months ago | 08:01 |
| lkcl | where 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 |
| ghostmansd | Hm | 08:01 |
| ghostmansd | Yeah I seem there's a discrepancy | 08:02 |
| lkcl | i'm going back to sleep for a bit but wanted to do a heads-up | 08:02 |
| ghostmansd | It's not caused by XLEN migration, though... | 08:02 |
| ghostmansd | Present in the "add markdown" | 08:02 |
| ghostmansd | commit | 08:02 |
| lkcl | basically unless you do that the definition of sh in section 1.6.2 is useless. | 08:02 |
| lkcl | no, correct, because it's an immediate | 08:02 |
| lkcl | i.e. whoever wrote the spec got that ordering of the bits wrong. | 08:03 |
| lkcl | (in the pseudocode) | 08:05 |
| ghostmansd | Yet another corrigenda? | 08:06 |
| ghostmansd | Wait... But isn't sh[5] || sh[0:4] is the same as sh? | 08:07 |
| lkcl | urrr... i have a sneaky suspicion you might be right :) | 08:10 |
| lkcl | can 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 |
| lkcl | extswsli ... sh=1 | 08:12 |
| lkcl | extswsli ... sh=2 | 08:12 |
| lkcl | extswsli ... sh=4 | 08:12 |
| lkcl | extswsli ... sh=8 | 08:12 |
| lkcl | extswsli ... sh=16 | 08:12 |
| lkcl | extswsli ... sh=32 | 08:12 |
| lkcl | so we can see where the bits actually land in the 32-bit binary, in both binutils and pysvp64dis? | 08:13 |
| lkcl | ghostmansd, damnit, no sh[5] || sh[0:4] *isn't* the same because MSB0 order, remember? | 08:16 |
| lkcl | SH[5] is the *LSB* which is shifted to the *top* bit position numbered 0 in MSB0 order... urrr.... | 08:16 |
| * lkcl brainmelt | 08:17 | |
| programmerjake | lkcl, the fptrans opcodes overlap, can I reallocate them? or should I let you? | 08:20 |
| *** jn_ is now known as jn | 08:20 | |
| programmerjake | in 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 processor | 08:22 |
| programmerjake | for 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#c5 | 08:23 |
| programmerjake | none of the 1-in instructions will have EO added | 08:24 |
| ghostmansd[m] | lkcl, sure | 09:07 |
| ghostmansd | Let me tune the code appropriately so I'll dump all fields, too | 09:08 |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC | 09:13 | |
| ghostmansd | binutils: 0: f4 3e 23 7c extswsli r3,r1,7 | 09:13 |
| ghostmansd | pysvp64dis: f4 3e 23 7c extswsli r3,r1,7 | 09:14 |
| ghostmansd | fields={'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 |
| ghostmansd | operands=[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-soc | 09:15 | |
| ghostmansd | sh = insn[record.fields["sh"]] | 09:19 |
| ghostmansd | print(_selectconcat(sh[5], sh[0:4])) | 09:19 |
| ghostmansd | print(_selectconcat(sh)) | 09:19 |
| ghostmansd | SelectableInt(value=0x11, bits=5) | 09:19 |
| ghostmansd | SelectableInt(value=0x7, bits=6) | 09:19 |
| ghostmansd | Hm, I'm confused | 09:20 |
| ghostmansd | Ah wait, the order must have been reversed... | 09:22 |
| programmerjake | extswsli: https://gcc.godbolt.org/z/95P4c94dn | 09:24 |
| ghostmansd | print(_selectconcat(sh[0:5], sh[5])) | 09:25 |
| ghostmansd | Only this combination gives the same as accessing sh | 09:26 |
| ghostmansd | Also, 7 is a bad choice... | 09:27 |
| ghostmansd | but anyway | 09:28 |
| ghostmansd | these three are equal | 09:29 |
| ghostmansd | _selectconcat(sh[0:6]) | 09:29 |
| ghostmansd | _selectconcat(sh[0:5], sh[5]) | 09:29 |
| ghostmansd | _selectconcat(sh) | 09:29 |
| programmerjake | https://gcc.godbolt.org/z/drYh5Padc | 09:38 |
| programmerjake | template<unsigned v> | 09:39 |
| programmerjake | static 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 |
| programmerjake | matches exactly | 09:40 |
| ghostmansd | lkcl, ah, you also checked other XS-form users, nice | 09:45 |
| ghostmansd | so much cringe in ISA :-) | 09:46 |
| ghostmansd | lkcl, please keep commits title short | 09:56 |
| ghostmansd | c865b6c9 | 09:56 |
| ghostmansd | https://www.conventionalcommits.org/en/v1.0.0/ | 09:56 |
| programmerjake | off-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/11787 | 09:57 |
| ghostmansd | Folks, 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 |
| ghostmansd | There 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 |
| ghostmansd | Oh, and test_caller is also OK. | 10:01 |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC | 10:24 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC | 10:49 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.43.156> has joined #libre-soc | 10:50 | |
| *** octavius <octavius!~octavius@130.147.93.209.dyn.plus.net> has joined #libre-soc | 11:01 | |
| lkcl | ghostmansd[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 |
| lkcl | yes | 11:58 |
| ghostmansd[m] | OK then :-) | 11:58 |
| lkcl | whewww | 11:58 |
| ghostmansd[m] | I have not yet updated RC.RCOE, though | 11:58 |
| ghostmansd[m] | Will do soon | 11:59 |
| ghostmansd[m] | I rebased this code and forgot to tune it | 11:59 |
| lkcl | programmerjake, i went over the table a month ago, i made sure to miss any existing ops | 11:59 |
| lkcl | however | 11:59 |
| lkcl | there is no guarantee that i didn't get the top-5-bit and lower-5-bit the wrong way round | 11:59 |
| lkcl | (a common mistake i tend to make) | 11:59 |
| programmerjake | so do you mind if i redo it? i'm probably much less prone to that particular mistake | 12:01 |
| lkcl | can you see the pattern that i made? | 12:01 |
| programmerjake | i didn't look for patterns at the time, but i can look when it's not 4am | 12:02 |
| lkcl | :) | 12:02 |
| programmerjake | i saw the notes about f*s going in 1 major op and f* in the other | 12:02 |
| ghostmansd[m] | Nah, 4 am is the best time to check patterns | 12:02 |
| lkcl | 0b00 exp{something}-minus-one | 12:02 |
| lkcl | 0b01 log{something}-plus-one | 12:03 |
| lkcl | 0b10 exp{something} | 12:03 |
| ghostmansd[m] | I'm one of freaks who tend to study these things at 4am :-) | 12:03 |
| lkcl | 0b11 log{something} | 12:03 |
| lkcl | ghostmansd[m], been there... | 12:03 |
| lkcl | and a similar thing for sin cos and tan | 12:04 |
| programmerjake | i'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 sleep | 12:04 |
| lkcl | it was a lot of work. | 12:04 |
| lkcl | niiice | 12:04 |
| programmerjake | imho grouping by the algorithm needed to implement it might be a better approach | 12:05 |
| lkcl | you have to be *really* careful with the fact that they've dropped a bunch of other operations in places | 12:05 |
| lkcl | get some sleep, i'll take a quick look and see if it's dead-easy-to-fix | 12:06 |
| programmerjake | yeah, i'll look at the appendix listing unused XO values | 12:06 |
| programmerjake | i 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 instructions | 12:07 |
| programmerjake | https://lists.libre-soc.org/pipermail/libre-soc-dev/2022-September/005253.html | 12:08 |
| programmerjake | and the following email | 12:08 |
| lkcl | frick, i know what it is. i was looking at v3.0B and they've now taken up some of that space with v3.1. frick | 12:11 |
| lkcl | that completely fucks up everything i did. | 12:11 |
| programmerjake | it's mostly fptrans conflicting with fptrans, i didn't check for conflicts with v3.1B yet | 12:13 |
| programmerjake | lemme fit it tomorrow | 12:14 |
| programmerjake | if that's ok with you | 12:14 |
| programmerjake | fix not fit | 12:14 |
| lkcl | ok. sure. i can get on with other things. | 12:15 |
| lkcl | ghostmansd[m], test_caller*.py all good in master | 13:03 |
| programmerjake | oh, btw lkcl: i renamed the decoder formal proofs to test_*.py so pytest runs them in ci, they both fail and need updating | 13:10 |
| programmerjake | https://git.libre-soc.org/?p=openpower-isa.git;a=commitdiff;h=a205a63b53e3db7b217bc11263f29f5fb09421f3 | 13:11 |
| programmerjake | I updated RC -> RCOE but test_decoder2.py needs the other new values added | 13:13 |
| lkcl | not happening. they are better off being deleted. | 13:14 |
| lkcl | ah actually they're not so bad | 13:15 |
| programmerjake | a 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 it | 13:23 |
| lkcl | there are multiple Records that can be dropped into pdecode2.e | 13:24 |
| lkcl | you have to make sure that the Record used actually has that attribute | 13:25 |
| lkcl | ghostmansd[m], soc/simpletest/test_issuer.py nosvp64 all good | 13:27 |
| ghostmansd[m] | Cool | 13:28 |
| ghostmansd[m] | Seems like we're all set for SVP64 disassembly? | 13:28 |
| * lkcl scared | 13:28 | |
| lkcl | yes? | 13:28 |
| lkcl | seriously, yes - go for it. | 13:30 |
| lkcl | i can try svshape2, now | 13:30 |
| programmerjake | lkcl, 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 |
| lkcl | oh duh | 14:01 |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.43.156> has quit IRC | 14:01 | |
| lkcl | pffh :) | 14:01 |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc | 14:02 | |
| ghostmansd[m] | Even if you're scared, imagine how I am! :-D | 14:04 |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc | 14:47 | |
| *** lx0 <lx0!~lxo@gateway/tor-sasl/lxo> has quit IRC | 15:26 | |
| *** lx0 <lx0!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc | 15:27 | |
| ghostmansd | I 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 |
| ghostmansd | First, I'd really like to update these on the flight in fields, instead of remembering it and setting later. | 15:29 |
| ghostmansd | Second, setting fields instead of having separate enum-like stuff is much cleaner. | 15:30 |
| ghostmansd | Third... I really want to re-use this code in both binutils and disasm, and have no patience to write it that differently. | 15:31 |
| ghostmansd | I 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 |
| ghostmansd | And then get/set fields via these getters/setters. | 15:32 |
| ghostmansd | Calculating these via shifts and bit masks is a madness, it's way too verbose. | 15:33 |
| lkcl | yes - bear in mind the long-term plan is to have SVP64MODE.REDUCE etc. read out of an svp64-fields.txt file | 15:33 |
| lkcl | and 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 |
| lkcl | haha :) | 15:34 |
| ghostmansd | Then it's even more valid to start migration sooner. | 15:34 |
| lkcl | yes, otherwise you get mistakes | 15:34 |
| ghostmansd | Or well, I meant pysvp64dis | 15:34 |
| ghostmansd | Sorry :-) | 15:34 |
| * lkcl doing an svshape2 stub | 15:35 | |
| lkcl | kinda concentrating ^ | 15:35 |
| ghostmansd | Anyway, I knew you'd share this idea | 15:35 |
| lkcl | or trying to. 4 phone calls | 15:35 |
| ghostmansd | OK, good luck :-) | 15:35 |
| lkcl | yes indeed | 15:35 |
| lkcl | appreciated :) | 15:35 |
| lkcl | svshape2 added to master (stub) | 15:57 |
| lkcl | ghostmansd, SVrm values used by svshape disallowed... | 16:17 |
| lkcl | https://git.libre-soc.org/?p=openpower-isa.git;a=commitdiff;h=52029d836a0ee8c5c701cb2f056b1cb56bd9a211 | 16:17 |
| lkcl | now to add svshape2 | 16:17 |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC | 16:25 | |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC | 16:25 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.54.125> has joined #libre-soc | 16:26 | |
| lkcl | ghostmansd[m], ping - rrright. target_addr *is* correct. | 17:12 |
| lkcl | (and does have to be done as a custom field) | 17:12 |
| lkcl | it's like the "SVd-1" thing | 17:12 |
| lkcl | it is *not* LI (or BI). | 17:12 |
| lkcl | why? | 17:12 |
| lkcl | because if you have a target_addr of say 0b000001 | 17:12 |
| lkcl | that is *not expressable* with (LI || 0b00) | 17:13 |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.54.125> has quit IRC | 17:13 | |
| lkcl | the first two bits (0b01) try to match up with (0b00) and of course fail | 17:13 |
| lkcl | and the *other* bits 0b0000 match up with LI | 17:13 |
| lkcl | this is what the spec authors were trying to say with target_addr but didn't really make it clear | 17:14 |
| lkcl | so yes, the things you were doing with target_addr custom field were actually the right direction | 17:14 |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc | 17:14 | |
| lkcl | wark-wark | 17:14 |
| lkcl | "commit 05cfb8ad4" was correct but also needed a corresponding *assemble* thing | 17:16 |
| lkcl | which | 17:16 |
| lkcl | * checks that the first two bits of target_addr are zero | 17:16 |
| lkcl | * chops them off | 17:16 |
| lkcl | * drops the remainder into the "LI" field | 17:16 |
| lkcl | * continues from there | 17:16 |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc | 17:47 | |
| ghostmansd | srcwid = (bc_vsb << 1) | bc_lru | 17:59 |
| ghostmansd | destwid = (bc_lru << 1) | bc_all | 17:59 |
| ghostmansd | Is it correct that bc_lru used both for srcwid and dstwid, and appears in different place? | 18:00 |
| lkcl | ghostmansd, i haven't been able to get to svp64 branches. too overloaded. | 18:00 |
| lkcl | i need to spend about 5-7 days implementing a massive stack of unit tests | 18:01 |
| lkcl | at which point i can answer questions confidently | 18:01 |
| ghostmansd | sigh, accidentally these were the first I looked at, since the whole code starts with "if we're in branch function..." | 18:02 |
| lkcl | ooops :) | 18:03 |
| lkcl | give me a moment to try to answer then | 18:03 |
| lkcl | https://libre-soc.org/openpower/sv/branches/ | 18:04 |
| lkcl | vs the Common RM Fields | 18:05 |
| lkcl | https://libre-soc.org/openpower/sv/svp64/ | 18:05 |
| lkcl | ELWIDTH 4:5 Element Width | 18:05 |
| lkcl | ELWIDTH_SRC 6:7 Element Width for Source | 18:05 |
| lkcl | therefore destwidth = (ALL, SNZ) | 18:07 |
| lkcl | and srcwidth = (VSb, CTi) | 18:07 |
| lkcl | can 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 there | 18:09 |
| ghostmansd[m] | These 4..23... What do they stand for? | 18:10 |
| lkcl | i altered it *after* i did the first implementation of svp64.py | 18:10 |
| lkcl | SVP64.RM[4..23] | 18:10 |
| ghostmansd[m] | These are bit positions, but relative to what? | 18:10 |
| ghostmansd[m] | Ah, OK | 18:10 |
| lkcl | the 24-bit RM | 18:10 |
| ghostmansd[m] | Ok, what'd be the better place to start with? | 18:10 |
| lkcl | normal mode and ld/st mode | 18:11 |
| ghostmansd[m] | Ok, 4..23. and where are the rest? | 18:11 |
| ghostmansd[m] | 0..3 inclusively? | 18:11 |
| lkcl | https://libre-soc.org/openpower/sv/svp64/ | 18:11 |
| lkcl | Common RM fields | 18:11 |
| lkcl | MASKMODE 0 Execution (predication) Mask Kind | 18:11 |
| lkcl | MASK 1:3 Execution Mask | 18:11 |
| ghostmansd[m] | OK | 18:12 |
| ghostmansd[m] | ...I'll start with LDST then | 18:12 |
| lkcl | good idea :) | 18:12 |
| ghostmansd[m] | https://libre-soc.org/openpower/sv/ldst/ | 18:13 |
| ghostmansd[m] | This, right? | 18:14 |
| lkcl | yyyep | 18:14 |
| lkcl | i still have to add parallel-prefix specifier btw to sv/trans/svp64.py | 18:14 |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC | 18: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 |
| lkcl | i hit it all at once, blasted through it | 18:24 |
| lkcl | gooood | 18: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 fields | 18: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 |
| lkcl | no in that case they refer to SVP64.RM.MODE | 18:29 |
| lkcl | which is from | 18:29 |
| lkcl | https://libre-soc.org/openpower/sv/svp64/ | 18:29 |
| lkcl | Common RM fields | 18:30 |
| lkcl | MODE 19:23 changes Vector behaviour | 18:30 |
| * lkcl just editing to make that clear | 18:30 | |
| ghostmansd[m] | Can the tables be formatted properly? After you mentioned, I found it. | 18:30 |
| ghostmansd[m] | Yeah thank you! | 18:31 |
| lkcl | done | 18:31 |
| ghostmansd[m] | I was rather expecting something like RM.MODE[0:1] in the table header :-) | 18:34 |
| ghostmansd[m] | But OK | 18:34 |
| lkcl | nggghh... ok 1 sec | 18:34 |
| lkcl | that has to be done in the (normal) table as well | 18:35 |
| lkcl | i know why i didn't do it: it expands the table hugely | 18: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 |
| lkcl | hmmm hmmm, kinda defeats the object of having RM.MODE | 18:38 |
| ghostmansd[m] | Fair enough | 18:41 |
| ghostmansd[m] | What is RA.isvec? | 18:42 |
| lkcl | that's from EXTRA2/3 encoding | 18:42 |
| ghostmansd[m] | RA is vector? Decoded from prefix? | 18:42 |
| lkcl | yes. | 18:42 |
| lkcl | it's a way to say "read EXTRA2/3 and find out if it's set to a vector" | 18:43 |
| lkcl | in semi-pseudo-code-like-language | 18:43 |
| ghostmansd[m] | Sigh | 18:44 |
| ghostmansd[m] | Why it should be this way? | 18:44 |
| lkcl | you'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 = indexed | 18:45 |
| ghostmansd[m] | This is the code I'm looking at | 18:45 |
| lkcl | ok 1 sec... | 18:45 |
| ghostmansd[m] | I mean, the reader must know the entire spec to get even the slightest idea | 18:46 |
| ghostmansd[m] | Why not say "refer to these bits in RM"? | 18:46 |
| lkcl | because the number of people who have actually read it and bothered to ask questions is f*****g negligeable | 18:46 |
| lkcl | and i can't do everything | 18:47 |
| ghostmansd[m] | :-) | 18:47 |
| ghostmansd[m] | Fair answer | 18:47 |
| * lkcl thinking | 18: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 yet | 18:48 |
| ghostmansd[m] | You, as the one who wrote it, know it, so for you some moments are obvious | 18:48 |
| ghostmansd[m] | Not the same for a stranger like me | 18:49 |
| lkcl | but it has to be submitted upstream | 18:49 |
| lkcl | so has to be right | 18:49 |
| lkcl | which is good | 18:49 |
| lkcl | as you help highlight things i missed | 18:49 |
| lkcl | btw that RC.isvec (etc) section is *not* changing the encode/decode | 18:51 |
| lkcl | meaning, you can concentrate on just the table(s) | 18:52 |
| lkcl | but | 18:52 |
| lkcl | at some point | 18:52 |
| lkcl | some sanity-assertions should be added | 18:53 |
| ghostmansd[m] | I agree | 18:56 |
| ghostmansd[m] | Sorry for distracting you, I know you have a lot to do | 18:56 |
| ghostmansd[m] | But this is crucial | 18:56 |
| ghostmansd[m] | For word instructions, things were simple (mostly) | 18:56 |
| programmerjake | though 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 questions | 18:58 |
| ghostmansd[m] | Nobody is to be blamed :-) | 18:59 |
| ghostmansd[m] | I just need your guidance, folks, that's it | 18:59 |
| lkcl | no 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-soc | 19:40 | |
| sadoon[m] | Hi guys | 20: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 :P | 20:39 |
| programmerjake | iirc 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 script | 20:53 |
| sadoon[m] | I'll fix it and push a commit | 20:54 |
| sadoon[m] | *pull request | 20: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 |
| lkcl | sadoon[m], yes, at least one person has, tplaten | 21:11 |
| lkcl | yep you need to specifically follow the scripts precisely and exactly | 21:12 |
| sadoon[m] | Just finished creating accounts on opencollective, the mailing list, and the site | 21: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 list | 21:26 |
| sadoon[m] | Where should I add myself? | 21:26 |
| lkcl | sadoon[m], lol | 21:29 |
| lkcl | https://libre-soc.org/about_us | 21:29 |
| lkcl | i think | 21:29 |
| lkcl | gimme a sec | 21:29 |
| sadoon[m] | Yes that's where I did it | 21:29 |
| sadoon[m] | But there's a list there "object automation" | 21:29 |
| lkcl | yes, i'll move them further down | 21:30 |
| sadoon[m] | Awesome thanks | 21:30 |
| lkcl | you're happy with the Charter, btw/ | 21:31 |
| lkcl | https://libre-soc.org/charter/discussion/ | 21:31 |
| lkcl | do let me know | 21:31 |
| lkcl | took me a while to find the right dilbert cartoons | 21:32 |
| sadoon[m] | I did read it before but that was a long time ago, I'll give it another read | 21:32 |
| sadoon[m] | I remember it being amusing | 21:32 |
| lkcl | oh good :) | 21:33 |
| ghostmansd | Does the following look right? https://pastebin.com/5q3Utj6y | 21:33 |
| ghostmansd | SVP64 instruction layout (obviously RM is remapped) | 21:34 |
| ghostmansd | (so is everything nested to it) | 21:34 |
| lkcl | eek! :) | 21:35 |
| ghostmansd | Names are idiotic. | 21:35 |
| ghostmansd | If you could give a sweet name to each mode, that'd be great. | 21:35 |
| lkcl | no like'em they're short | 21:35 |
| ghostmansd | They're short, but probably not quite self-documented. | 21:35 |
| ghostmansd | Nobody would guess what prrc1 means. | 21:36 |
| lkcl | pffh | 21:36 |
| lkcl | urrr, can you do the numbering relative to RM? | 21:36 |
| ghostmansd | pred-result with Rc=1 | 21:36 |
| lkcl | yaaay | 21:36 |
| ghostmansd | This is relative to RM... | 21:36 |
| ghostmansd | ...only to remapped one | 21:36 |
| ghostmansd | But I can, 1 sec | 21:36 |
| lkcl | i can't think in terms of "right down to the 32-bit int", but i can (just) think in terms of 24-bit RM | 21:37 |
| ghostmansd | https://pastebin.com/eEMDvMNw | 21:38 |
| ghostmansd | this is if RM is not remapped | 21:38 |
| lkcl | hooray. | 21:38 |
| lkcl | i can cope with that. gimme10. | 21:38 |
| sadoon[m] | <lkcl> "took me a while to find the..." <- They're perfect xD | 21:38 |
| sadoon[m] | Very happy with the charter, extremely welcoming and unlike another big project that starts with a G | 21:39 |
| lkcl | sadoon[m], awesome. | 21:39 |
| lkcl | ghostmansd, these are unnecessary | 21:39 |
| lkcl | prefix.rm.mode.ldst.imm.normal.dz (22,) | 21:39 |
| lkcl | prefix.rm.mode.ldst.imm.normal.sz (22,) | 21:39 |
| ghostmansd | Yeah I know | 21:40 |
| ghostmansd | Automatically added these | 21:40 |
| lkcl | and thse | 21:40 |
| ghostmansd | Since the spec mentioned that zz == both sz and dz | 21:40 |
| lkcl | prefix.rm.mode.ldst.imm.spu.dz (22,) | 21:40 |
| lkcl | prefix.rm.mode.ldst.imm.spu.sz (22,) | 21:40 |
| ghostmansd | but yeah I'll drop these | 21:40 |
| lkcl | but... ahhh yes | 21: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 |
| lkcl | ok i see what you did | 21:40 |
| lkcl | sadoon[m], night :) | 21:40 |
| ghostmansd | sadoon[m], gn! | 21:40 |
| programmerjake | gn | 21:41 |
| lkcl | they map to bit 22. ok that's smart | 21:41 |
| ghostmansd | yeah kinda alias | 21:41 |
| lkcl | are you going to add a mode to cover bits 19-20? | 21:42 |
| ghostmansd | I'm not sure how to handle it better TBH | 21:42 |
| ghostmansd | because these modes I posted... | 21:42 |
| ghostmansd | the actual choose... | 21:42 |
| ghostmansd | it depends on bits 19..20 | 21:42 |
| lkcl | which can be compared against 0b00 for normal... hang on... 19-23==0b000 | 21:42 |
| ghostmansd | I'm not sure how to describe it better | 21:42 |
| ghostmansd | I mean, Python-wise | 21:43 |
| ghostmansd | how do they call it in parseltongue? | 21:43 |
| ghostmansd | let me push the branch | 21:43 |
| ghostmansd | so that you could see how ugly it's in Python | 21:43 |
| ghostmansd | and how it begs to kill ^W generate it | 21:43 |
| lkcl | ok yep gone over them all, happy with them all | 21:43 |
| lkcl | really: we *really* should have done this as svp64fields.txt | 21:44 |
| lkcl | sigh | 21:44 |
| lkcl | hindsight's a bitch | 21:44 |
| ghostmansd | OK pushed | 21:46 |
| ghostmansd | beware | 21:46 |
| ghostmansd | can provoke eyes to bleed | 21:46 |
| lkcl | :) | 21:47 |
| ghostmansd | but yes, if these are _generated_, it won't be that bad | 21:47 |
| ghostmansd | only look listening to this song: https://www.youtube.com/watch?v=-tebshO9wZo | 21:47 |
| ghostmansd | (it's sufficient to listen to refrain only) | 21:48 |
| ghostmansd | Also, this Rc=1... where is it? | 21:49 |
| ghostmansd | Or Rc=0 | 21:49 |
| lkcl | "." | 21:49 |
| lkcl | sv.add. | 21:49 |
| ghostmansd | Ah | 21:49 |
| ghostmansd | so we check the suffix, too? | 21:49 |
| lkcl | yes | 21:49 |
| lkcl | fun, eh? | 21:49 |
| ghostmansd | You know, this is a cheat! | 21:49 |
| lkcl | uh-huhn :) | 21:49 |
| ghostmansd | Nobody likes cheaters :-) | 21:49 |
| lkcl | saves a bit in the (extremely precious) prefix | 21:49 |
| ghostmansd | > <lkcl> are you going to add a mode to cover bits 19-20? | 21:50 |
| lkcl | if it's not an Rc-style op, you assume the RC1 column | 21:50 |
| ghostmansd | > <ghostmansd> I'm not sure how to handle it better TBH | 21:50 |
| lkcl | this is a really werid song | 21:50 |
| ghostmansd | as everything by Pixies | 21:50 |
| ghostmansd | I haven't promised it'd sound like Morrisey | 21:50 |
| ghostmansd | :-) | 21:51 |
| ghostmansd | or well at least Robert Smith | 21:51 |
| ghostmansd | anyway | 21:51 |
| ghostmansd | returning to these bits | 21:51 |
| lkcl | https://www.youtube.com/watch?v=7ILNpR9DfYE | 21:51 |
| ghostmansd | I'd really like to somehow choosing the mode automatic... | 21:51 |
| ghostmansd | depending on RM.mode[(0, 1)] | 21:52 |
| ghostmansd | and other stuff like Rc | 21:52 |
| ghostmansd | But I have no idea how to code it | 21:52 |
| ghostmansd | I mean, how'd it look code-wise | 21:52 |
| lkcl | well, funnily enough, power_decoder.py CSV files covers exactly that | 21:52 |
| ghostmansd | I can do bunch of ifs/elses | 21:52 |
| lkcl | drunk on the laaawn in a nuclear daaawn, my seeenses fiiinally blurrred | 21:53 |
| lkcl | works for me. | 21:56 |
| ghostmansd | IDK why but it again reminds the song about old Mc'Donald and his cow | 21:57 |
| ghostmansd | but nice | 21:57 |
| ghostmansd | > works for me | 21:57 |
| ghostmansd | No, I mean, I know it'd work | 21:57 |
| ghostmansd | This is just not something I'd like to eventually see | 21:57 |
| ghostmansd | Ideally I'd like this to be generated... | 21:57 |
| ghostmansd | But no idea how to generate it from the tables | 21:58 |
| ghostmansd | Anyway, I'm postponing it for now | 21:58 |
| lkcl | yes. it'd be something close to power_decoder.py or ah yes, at least the CSV reader | 21:58 |
| lkcl | where "XO" is the "mode". | 21:58 |
| lkcl | XO would be "001" for normal | 21:59 |
| ghostmansd | yeah likely something like this | 21:59 |
| lkcl | "001" for PU | 21:59 |
| lkcl | "01-" for ffirst... you get the idea | 21:59 |
| lkcl | and there'd be a column "SVMode" as well | 22:00 |
| ghostmansd | you noticed how I eventually came up with kinda language in a language? | 22:00 |
| lkcl | scary :) | 22:00 |
| ghostmansd | that is, we kinda "describe" the fields | 22:00 |
| ghostmansd | I'm scared | 22:00 |
| lkcl | yehyeh | 22:00 |
| lkcl | y'know there's almost certainly reverse-engineering tools that do this stuff | 22:01 |
| lkcl | i used to do it all the time with samba / NT-domains (MSRPC aka DCE/RPC) | 22:01 |
| lkcl | and network-packet-analysis tools all have to do the same thing | 22:01 |
| lkcl | gem5 ended up doing something similar | 22:02 |
| lkcl | but hollyeeeee cowww is the auto-generated code BIG | 22:02 |
| lkcl | multi-depth switch statements | 22:02 |
| lkcl | and yes that's *actually* a mini-programming-language they ended up with | 22:02 |
| ghostmansd | well we kinda too | 22:03 |
| ghostmansd | for us this is simpler, though: the overall combinations are not that huge | 22:03 |
| ghostmansd | also, I noticed (even before, when I checked pysvp64asm, but now even clearer) | 22:03 |
| ghostmansd | some fields are present in both normal and LDST modes | 22:04 |
| lkcl | yes. | 22:04 |
| ghostmansd | So I'll likely decouple them eventually | 22:04 |
| lkcl | they are | 22:04 |
| lkcl | i tried keeping them roughly in the same place | 22:04 |
| ghostmansd | 10 N dz sz sat mode: N=0/1 u/s, SUBVL=1 | 22:04 |
| ghostmansd | this, for example, can be shared | 22:04 |
| lkcl | hmm... | 22:05 |
| ghostmansd | where do we have this? https://libre-soc.org/openpower/sv/normal/ | 22:05 |
| lkcl | power_enums.py - SVMode needs a LDST_IMM and a separate LDST_IDX | 22:06 |
| ghostmansd | I'd like to have the actual version in text, w/o switches to browser | 22:06 |
| lkcl | there's a pdf version | 22:06 |
| lkcl | and it's in the git repor | 22:06 |
| lkcl | 1sec | 22:06 |
| ghostmansd | no I mean kinda submode | 22:06 |
| lkcl | https://git.libre-soc.org/?p=libreriscv.git;a=blob;f=openpower/sv/normal.mdwn;hb=HEAD | 22:06 |
| lkcl | huhn? | 22:07 |
| ghostmansd | e.g. normal submode for normal has the same sat sub-submode as immediate submode for LDST mode | 22:07 |
| ghostmansd | https://libre-soc.org/openpower/sv/normal/ | 22:07 |
| ghostmansd | https://libre-soc.org/openpower/sv/ldst/ | 22:07 |
| ghostmansd | cf. `10 N dz sz sat mode: N=0/1 u/s, SUBVL=1` | 22:08 |
| ghostmansd | that line can be moved to some shared class | 22:08 |
| lkcl | too tired to think about it | 22:09 |
| ghostmansd | https://pastebin.com/6H3Mnnti | 22:09 |
| ghostmansd | this can be decoupled and re-used | 22:09 |
| ghostmansd | the layout is the same | 22:09 |
| ghostmansd | but OK, I won't bother :-) | 22:09 |
| lkcl | :) | 22:09 |
| lkcl | need to go read a book | 22:10 |
| ghostmansd | Holy shit! | 22:24 |
| ghostmansd | static inline uint64_t | 22:24 |
| ghostmansd | svp64_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 |
| ghostmansd | 22: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 |
| ghostmansd | The binutils even automatically granted such complex getters/setters | 22:24 |
| ghostmansd | *gained | 22:24 |
| ghostmansd | https://pastebin.com/V2B6Eicm | 22:25 |
| ghostmansd | kinda "feel the power of the automatic generation" | 22:26 |
| ghostmansd | A side note: could we call "normal" at https://libre-soc.org/openpower/sv/normal/ something else? | 22:48 |
| ghostmansd | or, at least, in the mode table there, call the first entry by a different name (and therefore do the same for LDST) | 22:49 |
| ghostmansd | perhaps we could call it "usual" or "regular" or "simple" | 22:49 |
| ghostmansd | having Normal.normal looks pretty strange, and also forces to explicitly mention which "normal" I mean in discussions | 22:50 |
| ghostmansd | OK I've added these modes: LD/ST immediate, LD/ST indexed, normal | 23:07 |
| ghostmansd | I assume branches and CR are not ready yet | 23:07 |
| ghostmansd | You 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 |
| ghostmansd | By the way, I introduced mode selector, already. And all mode-inherited classes also get this field. | 23:12 |
| ghostmansd | OK, enough for today, check dis branch (the usual eyes-bleeding disclaimer) | 23:13 |
| ghostmansd | oh, just one last note: https://pastebin.com/e5zjRvyc | 23:15 |
| ghostmansd | ^ collection of all fields we now have in RM | 23:15 |
| *** octavius <octavius!~octavius@130.147.93.209.dyn.plus.net> has quit IRC | 23:34 | |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!