| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC | 00:49 | |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc | 00:50 | |
| lkcl | sadoon[m] (for when you're awake) - one possibility is that the "dependency install" scripts built-in to cvc5 are not "reproducible" | 01:34 |
|---|---|---|
| programmerjake | i just checked a bunch of the auto download scripts, all the scripts i checked should be reproducable -- they either fetch a particular git commit or a particular released version with a hardcoded checksum | 01:54 |
| programmerjake | sadoon: when you have a chance, can you post the build error cvc5 gives? maybe via a link to some kind of pastebin service if it's more than a few lines | 02:01 |
| sadoon[m] | lkcl: programmerjake: it built fine on x86 btw | 06:03 |
| sadoon[m] | I'll check once I am back home, I would be able to check now but my "ssh -R" setup is giving me a "connection refused" | 06:03 |
| programmerjake | k, thx | 06:05 |
| *** markos <markos!~Konstanti@178.59.250.4> has quit IRC | 06:27 | |
| *** markos <markos!~Konstanti@178.59.251.230> has joined #libre-soc | 06:40 | |
| sadoon[m] | so I had the chance to go back home and set up ssh to keep-alive since my work is close to home and I have a "field engineer" type of thing today | 08:09 |
| sadoon[m] | let me see what the error was | 08:09 |
| sadoon[m] | On a side note it's deeply ironic that https://github.com/Nheko-Reborn/nheko works perfectly on ppc64le and is crashing on x86_64 | 08:09 |
| ghostmansd | > <lkcl> ghostmansd, is this correct? (git diff follows) | 08:14 |
| ghostmansd | Totally not, should be the other way round. | 08:14 |
| ghostmansd[m] | Hm. On my dis branch, things are fine. | 08:15 |
| ghostmansd[m] | On master it's correct too. | 08:15 |
| ghostmansd[m] | This "name" property represents the actual name of the operand we're dealing with. | 08:16 |
| ghostmansd[m] | The rest of the information is supplied in the disassembly. | 08:16 |
| ghostmansd[m] | Or well, not name of the operand, but, rather, a real field benind it. | 08:17 |
| sadoon[m] | Good news, cvc5 built just fine after I deleted the "src" directory, strange | 08:36 |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC | 08:37 | |
| programmerjake | well, at least it's fixed :) | 08:37 |
| programmerjake | maybe you tried it before I fixed it on ppc64le (>1mo ago iirc) and that left some broken files lying around... | 08:38 |
| sadoon[m] | nah it's a new git clone, it probably failed somewhere and then failed again because the directories are already there | 08:42 |
| sadoon[m] | that's the error I got before deleting it just now | 08:42 |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc | 08:50 | |
| ghostmansd | Fuuuuuck. I think I found what went wrong with lwarx. | 09:04 |
| ghostmansd | We don't have an entry for this in markdown. No, really, at all. | 09:05 |
| ghostmansd | Also, it looks like binutils extra2 remap is broken. Decoding, however, works (but that one doesn't really goes into analyzing the remapped parts yet). | 09:12 |
| ghostmansd | pysvp64dis can already correctly guess extra2 though (example for lwzu): | 09:13 |
| ghostmansd | RT | 09:13 |
| ghostmansd | 01010 | 09:13 |
| ghostmansd | [6, 7, 8, 9, 10] | 09:13 |
| ghostmansd | extra2[0] | 09:13 |
| ghostmansd | D | 09:13 |
| ghostmansd | 0000000000000000 | 09:13 |
| ghostmansd | [16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31] | 09:13 |
| ghostmansd | RA | 09:13 |
| ghostmansd | 00000 | 09:13 |
| ghostmansd | [11, 12, 13, 14, 15] | 09:13 |
| ghostmansd | extra2[2] | 09:13 |
| ghostmansd | So, I guess, this will be fixed in binutils when we migrate to new fields, since remap will deal with svp64_insn directly. | 09:17 |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC | 09:21 | |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc | 09:33 | |
| sadoon[m] | I assume ppc64-gdb-gcc should not work and is not needed on ppc64le right? | 09:37 |
| ghostmansd | We deal with LE only for now. | 09:54 |
| programmerjake | lkcl: i got fed up with pandoc and line breaks in table cells, so I just added code to pandoc_img.py to convert <br> to latex \\ | 10:19 |
| programmerjake | (sorry matrix users, it was `<br>` to `\\`, matrix decided to interpret that) | 10:21 |
| *** octavius <octavius!~octavius@238.147.93.209.dyn.plus.net> has joined #libre-soc | 11:36 | |
| lkcl | ghostmansd, lwarx - ah, yes, no you're right. | 11:42 |
| lkcl | and there's a reason for that: if you look at the pseudocode it has concepts that aren't in ISACaller | 11:42 |
| lkcl | so yes, please just leave it for now | 11:42 |
| lkcl | programmerjake, good enough. there's quite a lot of hacks like that | 11:43 |
| lkcl | ghostmansd, dis branch produces: | 11:45 |
| lkcl | spec | 11:45 |
| lkcl | bcl BO,BI,BD (AA=0 LK=1) | 11:45 |
| lkcl | which is wrong | 11:45 |
| lkcl | master branch produces: | 11:45 |
| ghostmansd[m] | Ah you mean the argument name in spec | 11:45 |
| lkcl | 09 08 00 40 bcl 0,0,0x808 | 11:45 |
| lkcl | spec | 11:45 |
| lkcl | bcl BO,BI,BD (AA=0 LK=1) | 11:45 |
| lkcl | which is wrong | 11:45 |
| lkcl | (yes) | 11:45 |
| ghostmansd[m] | Ok gotcha | 11:45 |
| lkcl | target_addr branch produces | 11:45 |
| ghostmansd[m] | Yeah I think I know how to refactor this | 11:45 |
| lkcl | lkcl@fizzy:~/src/libresoc/openpower-isa/src/openpower$ echo -n -e '\x09\x08\x00\x40' | pysvp64dis -v | 11:45 |
| lkcl | 09 08 00 40 bcl 0,0,0x808 | 11:45 |
| lkcl | spec | 11:45 |
| lkcl | bcl BO,BI,target_addr (AA=0 LK=1) | 11:45 |
| ghostmansd[m] | Yeah yeah | 11:46 |
| lkcl | but.. ahhh yes | 11:46 |
| ghostmansd[m] | That's due to custom name property | 11:46 |
| lkcl | it also does | 11:46 |
| lkcl | target_addr | 11:46 |
| lkcl | 00001000000010 | 11:46 |
| lkcl | [16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29] | 11:46 |
| lkcl | target_addr = EXTS(BD || 0b00)) | 11:46 |
| lkcl | not | 11:46 |
| lkcl | BD | 11:46 |
| lkcl | 0001000.... | 11:46 |
| lkcl | ok | 11:46 |
| lkcl | ghostmansd[m], i'll add some dummy pseudocode for lwarx/lbarx/lharx | 11:48 |
| programmerjake | lkcl: i added support for <sup>/<sub>/<small> so the new math stuff looks much better in the pdf | 11:50 |
| lkcl | programmerjake, ahh goood | 11:53 |
| lkcl | yeah those look a hell of a lot better | 11:54 |
| lkcl | ghostmansd[m], done. called fixedsync.mdwn | 12:01 |
| lkcl | you'll need to re-run pywriter | 12:01 |
| ghostmansd | lkcl, thank you! | 12:07 |
| ghostmansd | nah, actually I won't :-) | 12:08 |
| ghostmansd | I'm dealing with vanilla mdwn via pagereader | 12:08 |
| ghostmansd | for disassembly there's no need, only for simulation | 12:08 |
| lkcl | you still need the actual definition (XXXX-Form, register declarations) | 12:09 |
| lkcl | that's why i added it | 12:09 |
| lkcl | otherwise sv/trans/svp64.py - when it's made automated - can't know the Form or the regs either | 12:09 |
| lkcl | hmm hmm irony: for assembly you need *another* expression involving target_addr | 12:11 |
| lkcl | BD = target_addr>>2 | 12:11 |
| ghostmansd | Yes :-) | 12:11 |
| lkcl | sigh | 12:11 |
| ghostmansd | I've been thinking of adding assembly method to operands | 12:11 |
| ghostmansd | Fuck that's what I've been talking about | 12:12 |
| ghostmansd | Why in order to run pywriter do I need nmigen? | 12:12 |
| ghostmansd | At one point or another, we'll have to think about splitting the components and putting components into reservation | 12:12 |
| ghostmansd | For now I'll do it on talos, but frankly running pysvp64dis on my laptop is much more convenient | 12:13 |
| *** octavius <octavius!~octavius@238.147.93.209.dyn.plus.net> has quit IRC | 12:13 | |
| lkcl | because a function called create_args() is hack-pulled in from ISACaller | 12:14 |
| lkcl | you shouldn't be attempting to do anything in openpower-isa without having nmigen installed, anyway. | 12:15 |
| lkcl | without it you can't run any unit tests at all | 12:15 |
| lkcl | the decoupling at this point is a major rewrite of the entirety of ISACaller | 12:16 |
| ghostmansd | Actually I could have used it without nmigen, because neither markdown nor csv nor anything in insndb needs nmigen at all. | 12:16 |
| ghostmansd | But right now I can't. | 12:16 |
| ghostmansd | Anyway, this is a random rant, you can ignore it. | 12:16 |
| lkcl | :) | 12:17 |
| ghostmansd | I seemply dislike dependencies where none are needed. | 12:17 |
| ghostmansd | *simply | 12:17 |
| ghostmansd | Fuck you see the rage, I cannot even write w/o grammer errars :-) | 12:17 |
| ghostmansd | OK rant ended, running pywriter on talos | 12:18 |
| lkcl | if you move create_args() to somewhere else it *may* work | 12:18 |
| lkcl | uh-huhn, i totally get that one. | 12:18 |
| ghostmansd | Nah, fuck it, I don't have time for that | 12:18 |
| lkcl | ack. i may try it some time | 12:19 |
| ghostmansd | OK none surprises, lwrax didn't magically started working yet, checking what's wrong | 12:19 |
| lkcl | it's lwarx | 12:19 |
| ghostmansd | yeah sorry, typo | 12:19 |
| lkcl | hmmm there may not exist a correct fields.txt entry | 12:19 |
| lkcl | 1 sex | 12:19 |
| lkcl | 1 sec | 12:19 |
| ghostmansd | lol | 12:19 |
| lkcl | now you got _me_ mistyping! | 12:19 |
| ghostmansd | no it's opcodes | 12:20 |
| ghostmansd | the error's here | 12:20 |
| ghostmansd | digging where "here" exactly | 12:20 |
| ghostmansd | OK lwarx is in database | 12:21 |
| lkcl | EH in fields.txt is correct | 12:21 |
| lkcl | btw you saw the "echo -e -n '\xNN' | pysvp64dis -v" example i gave? | 12:22 |
| ghostmansd | lwarx FieldsOpcode(value=0x7c000028, mask=0xfc0007fe) 0x7d4b6028 | 12:22 |
| ghostmansd | nope, missed it | 12:22 |
| lkcl | can you give... ahhh i should be able to create one... | 12:22 |
| lkcl | when you do status reports can you put the repro command into the bugtracker comment, in that form? | 12:23 |
| ghostmansd | Ah OK | 12:23 |
| lkcl | echo -n -e '\x28\x60\x4b\x7d' | pysvp64dis -v | 12:23 |
| lkcl | blech | 12:23 |
| ghostmansd | I doing it the other way, building some crap with binutils, then objcopy, then scp it to talos where I run pysvp64dis | 12:23 |
| ghostmansd | But your way is better as repro | 12:23 |
| lkcl | echo -n -e '\x7d\x4b\x60\x28' | pysvp64dis -v | 12:24 |
| lkcl | 7d 4b 60 28 cmpli 0,1,r0,19325 | 12:24 |
| lkcl | whoops :) | 12:24 |
| lkcl | successfully decompiled, too! | 12:24 |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC | 12:25 | |
| ghostmansd | ahem | 12:25 |
| ghostmansd | you know what? | 12:25 |
| lkcl | binutils/objcopy would work too, as long as there's a repro | 12:26 |
| lkcl | yaaa? | 12:26 |
| ghostmansd | we even managed to recognize the opcode | 12:26 |
| ghostmansd | so it's somewhere on the later stage! | 12:26 |
| ghostmansd | OK this makes the stuff simpler | 12:26 |
| ghostmansd | EH field | 12:27 |
| ghostmansd | Something's wrong with that | 12:27 |
| lkcl | EH Field is in X-Form (fields.txt) | 12:27 |
| lkcl | # 1.6.7 X-FORM | 12:28 |
| lkcl | |0 |6 |7|8|9 |10 |11|12|13 |15|16|17 |20|21 |31 | | 12:28 |
| lkcl | | PO | RT | RA | RB | XO |EH | | 12:28 |
| lkcl | EH (31) | 12:28 |
| ghostmansd | 1 sec | 12:28 |
| lkcl | Formats: X | 12:28 |
| ghostmansd | here are the fields I see for lwarx | 12:29 |
| ghostmansd | fields={'A': [6], 'BF': [6, 7, 8], 'BFA': [11, 12, 13], 'BO': [6, 7, 8, 9, 10], 'CT': [7, 8, 9, 10], 'DCMX': [9, 10, 11, 12, 13, 14, 15], 'DRM': [18, 19, 20], 'E': [16], 'E_1': [12, 13, 14, 15], 'EO': [11, 12], 'EO_1': [11, 12, 13, 14, 15], 'EX': [31], 'FC': [16, 17, 18, 19, 20], 'FRA': [11, 12, 13, 14, 15], 'FRAp': [11, 12, 13, 14, 15], 'FRB': [16, 17, 18, 19, 20], 'FRBp': [16, 17, 18, 19, 20], ' | 12:29 |
| lkcl | ok... ehn?? moo? | 12:29 |
| ghostmansd | Ah well these are all fields for form | 12:30 |
| ghostmansd | But still, there's no EH | 12:30 |
| ghostmansd | And still EH is exactly the operand mentioned | 12:30 |
| ghostmansd | *needed | 12:30 |
| lkcl | huhn? | 12:30 |
| ghostmansd | Record(name='lwarx', section=Section(path=PosixPath('minor_31.csv'), opcode=Opcode(value=0x0000001f, mask=0x0000001f), bitsel=[21:30], suffix=0b101, mode=<Mode.INTEGER: 1>), ppc=PPCMultiRecord({PPCRecord(opcode=IntegerOpcode(value=0x00000014, mask=0x00000014), comment='lwarx', flags=Flags({'cry out', '32b', 'rsrv', 'sgl pipe', 'sgn', 'inv A', 'BR', 'sgn ext', 'lk', 'inv out'}), comment2='', functi | 12:31 |
| ghostmansd | sigh | 12:31 |
| ghostmansd | fucking fucking IRC | 12:31 |
| ghostmansd | https://pastebin.com/fGLuNgeu | 12:31 |
| lkcl | try not to flood libera :) | 12:32 |
| ghostmansd | here's the whole record for lwarx | 12:32 |
| ghostmansd | it's X form | 12:32 |
| lkcl | that would have resulted in a flood notification if it had gotten through | 12:32 |
| lkcl | ack | 12:32 |
| ghostmansd | operands are: RT, RB, RA, EH | 12:32 |
| lkcl | mmmm ok can you do a push to dis branch? | 12:32 |
| programmerjake | lookie at all the pretty XO values, all nicely allocated :) https://libre-soc.org/openpower/power_trans_ops/ | 12:33 |
| ghostmansd | lkcl, cf dis branch | 12:33 |
| ghostmansd | I pushed a commit which prints | 12:33 |
| lkcl | ok got it | 12:34 |
| programmerjake | I did notice that fpown and frootn should have been defined to take RB rather than FRB, because they are between a float and int, so I changed the text to fix that... | 12:34 |
| lkcl | echo -n -e '\x28\x60\x4b\x7d' | pysvp64dis -v -l | 12:34 |
| lkcl | programmerjake, ah well spotted | 12:35 |
| ghostmansd | echo -n -e '\x28\x60\x4b\x7d' | python3 src/openpower/sv/trans/pysvp64dis.py /tmp/bin.o -v | 12:35 |
| ghostmansd | yeah | 12:35 |
| programmerjake | now, to clean up all the no-longer accurate comments in the mdwn... | 12:35 |
| lkcl | whadderfrick why is EH missing? | 12:35 |
| lkcl | ghostmansd, is Rc in the list? it is... | 12:36 |
| lkcl | 'Rc': [31], | 12:36 |
| ghostmansd | Occupies the same bit, eh? | 12:36 |
| lkcl | that's not a problem | 12:36 |
| lkcl | ok let's just run power_fields.py | 12:37 |
| ghostmansd | cf. class FieldsDatabase: | 12:37 |
| ghostmansd | It uses openpower.decoder.power_fields.DecodeFields | 12:37 |
| ghostmansd | almost 1:1 | 12:37 |
| lkcl | field EO BitRange([(0, 11), (1, 12)]) | 12:37 |
| lkcl | but no EH?? | 12:37 |
| lkcl | mooo??? | 12:38 |
| ghostmansd | no EH | 12:38 |
| ghostmansd | yeah you also found | 12:38 |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc | 12:38 | |
| lkcl | ahhh frick, you know what? | 12:38 |
| lkcl | look at E, just above | 12:38 |
| ghostmansd | I ran power_fields.py | 12:38 |
| lkcl | E (12:15) | 12:38 |
| lkcl | Field used to specify the access types ordered by | 12:38 |
| lkcl | an Elemental Memory Barrier type of sync instruc- | 12:38 |
| lkcl | tion. | 12:38 |
| ghostmansd | Aaaaaand? | 12:39 |
| ghostmansd | they don't overlap | 12:39 |
| ghostmansd | EH is bit 32 | 12:39 |
| ghostmansd | *31 | 12:39 |
| lkcl | where's the words "Format: XXXXX"? | 12:39 |
| ghostmansd | Dammit | 12:39 |
| ghostmansd | :-D | 12:39 |
| ghostmansd | Yeah this is the reason | 12:39 |
| ghostmansd | I guess it considers everything a description for E field | 12:40 |
| ghostmansd | holy fuck :-D | 12:40 |
| lkcl | in fact, there isn't even a field E in v3.0B or v3.1 | 12:40 |
| lkcl | how the hell did they get there? must be an early pre-release version of the PDF | 12:40 |
| ghostmansd | removing it fixes | 12:41 |
| lkcl | let me commit it | 12:41 |
| ghostmansd | sure, go ahead | 12:42 |
| ghostmansd | OK at least generally disasm is correct :-) | 12:42 |
| ghostmansd | this is a good sign | 12:42 |
| ghostmansd | that said, I again come to conclusion we should really check stuff in fields.text better | 12:42 |
| ghostmansd | like everywhere else | 12:43 |
| lkcl | 28 60 4b 7d lwarx r10,r11,r12,0 | 12:43 |
| lkcl | spec | 12:43 |
| lkcl | lwarx RT,RA,RB,EH | 12:43 |
| lkcl | well, ya know, it did the job. | 12:43 |
| ghostmansd | I know, time constraints, let's plan it | 12:43 |
| ghostmansd | yeah that's what I said above :-) | 12:43 |
| ghostmansd | cool. cool cool cool. | 12:43 |
| lkcl | unit test running and rebase time? | 12:44 |
| ghostmansd | https://www.youtube.com/watch?v=8IIrf_JSuQk | 12:44 |
| ghostmansd | let me drop some hacks | 12:44 |
| ghostmansd | 1 sec | 12:44 |
| lkcl | how the hell did he manage to get that in 1 second?? :) | 12:44 |
| lkcl | ack | 12:44 |
| ghostmansd | ok rebased master | 12:45 |
| lkcl | ack | 12:45 |
| ghostmansd | I dropped this print for lwarx and hack with sys.path I used for a while :-) | 12:45 |
| lkcl | ok underway. going to get some lunch. machine unresponsive for 20 mins so might as well | 12:46 |
| ghostmansd | OK now I have something with EXTRA2 | 12:46 |
| lkcl | ya | 12:46 |
| lkcl | go ahead | 12:46 |
| ghostmansd | let's proceed with whole EXTRA2 vs EXTRA3 operand value getters | 12:47 |
| lkcl | honestly that pseudocode you posted yesterday(?) really is all that's needed | 12:47 |
| ghostmansd | Yeah | 12:47 |
| ghostmansd | Just have to check what the fuck SPEC is | 12:47 |
| ghostmansd | src/openpower/decoder/power_svp64_extra.py | 12:47 |
| ghostmansd | also I haven't introduced DynamicOperandCR yet | 12:48 |
| lkcl | the bits from the EXTRA2/3 you looked up | 12:48 |
| ghostmansd | these will be tricky | 12:48 |
| ghostmansd | (we should also print these better, but that's yet another story) | 12:48 |
| lkcl | so if you have identified that RM.EXTRA - which is 9 bits - is subdivided into 4 EXTRA2s | 12:48 |
| ghostmansd | ahem... 8 bits? | 12:49 |
| lkcl | and identified that RT is EXTRA2[0] | 12:49 |
| lkcl | no, 9 :) | 12:49 |
| lkcl | then spec for RT = RM.EXTRA[0..1] | 12:49 |
| ghostmansd | ah yes | 12:49 |
| lkcl | dropping the MSB to zero | 12:49 |
| lkcl | so you can see | 12:50 |
| lkcl | self.extra = Signal(9, reset_less=True) | 12:50 |
| lkcl | one *each* of these SVP64ExtraSpecs is allocate for *every* operand | 12:50 |
| lkcl | one for RA, one for RB, one for RC, one for RT, one for RS.... one for BA, one for BB, .... | 12:51 |
| lkcl | it's really not that hard | 12:52 |
| ghostmansd | I'll think about how to organize it | 12:52 |
| ghostmansd | Frankly, for binutils I really want something reusable | 12:55 |
| ghostmansd | And I'd really love if we have something like what we have with Mode classes | 12:55 |
| ghostmansd | (you recall these LDSTIdxMode, LDSTImmMode, NormalMode and similar) | 12:55 |
| ghostmansd | So, if we can express operands in terms of spans rather than operations... | 12:55 |
| ghostmansd | ...that'd totally do the binutils. | 12:56 |
| ghostmansd | That's, we can check EType and select the getter/setter appropriately | 12:56 |
| ghostmansd | And that one will simply access some bits in svp64_insn | 12:56 |
| ghostmansd | Because basically it's like "we have 5 bits for RA reserved in suffix, but hey bro, we also take 2 bits from some EXTRA" | 13:03 |
| ghostmansd | do we have some kind of this table? | 13:04 |
| lkcl | yes - the scalar/vector bit of spec. bit zero | 13:05 |
| ghostmansd | I mean, the same we have in pseudocode, but in terms of spans | 13:05 |
| lkcl | everything's there. | 13:05 |
| lkcl | SVP64RegExtra? | 13:05 |
| lkcl | with m.If(self.isvec): | 13:06 |
| lkcl | # Vector: shifted up, extra in LSBs (RA << 2) | spec[1:2] | 13:06 |
| lkcl | with m.Else(): | 13:06 |
| lkcl | # Scalar: not shifted up, extra in MSBs RA | (spec[1:2] << 5) | 13:06 |
| lkcl | is that what you mean? | 13:06 |
| ghostmansd | hm.... | 13:06 |
| ghostmansd | yes this is it | 13:06 |
| lkcl | CRs are slightly different | 13:06 |
| ghostmansd | except for isvec part... | 13:06 |
| ghostmansd | let me trace where these come from | 13:07 |
| lkcl | # simple: isvec is top bit of spec | 13:07 |
| lkcl | comb += self.isvec.eq(spec[SPEC.VEC]) | 13:07 |
| ghostmansd | spec | 13:07 |
| lkcl | ok so top bit (MSB) not lowest bit | 13:07 |
| lkcl | spec comes from having decoded with SVP64ExtraSpec | 13:07 |
| ghostmansd | but you get what I mean, right? | 13:07 |
| lkcl | class SVP64RegExtra(SVP64ExtraSpec): | 13:07 |
| ghostmansd | with spans and similar crap | 13:07 |
| lkcl | not entirely. | 13:08 |
| ghostmansd | cf. Mode and its descendants | 13:08 |
| lkcl | food on cooker | 13:08 |
| ghostmansd | let me open git | 13:08 |
| ghostmansd | I'll post some links with comments | 13:08 |
| lkcl | ok not burning any more | 13:08 |
| lkcl | oh. yes. Modes. yes. sorry, different context | 13:09 |
| ghostmansd | We have a Mode class | 13:09 |
| ghostmansd | https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/decoder/power_insn.py;h=4e05468188a4d162751467fa8d3ab0a43081a0da;hb=34043f1140c226d937c6db5bf4cfafe8ba5e8936#l957 | 13:09 |
| ghostmansd | Below there are some of its descendants, which specify the actual Modes | 13:09 |
| ghostmansd | and their layout | 13:10 |
| lkcl | remember, sel there needs to be the entire 5 bits - we established that a couple days ago. | 13:10 |
| lkcl | and 5-bit mask-patterning "00---" etc. needed | 13:10 |
| ghostmansd | this sel bit doesn't do what you think it does | 13:10 |
| lkcl | "000--" for simple mode | 13:10 |
| ghostmansd | if you want, I can drop it entirely and simply refer to mode[0] and mode[1] | 13:11 |
| lkcl | "0010-" for... | 13:11 |
| ghostmansd | but let's concentrate on the other stuff now | 13:11 |
| lkcl | no that's what i'm saying, you *shouldn't* just refer to mode[0] and mode[1] | 13:11 |
| lkcl | it really should be | 13:11 |
| lkcl | "0010-" for scalar reduce mode | 13:11 |
| ghostmansd | We don't have way to do it now | 13:11 |
| ghostmansd | We don't have some CSV with patterns | 13:11 |
| lkcl | "10--1" for pack/unpack sat mode | 13:12 |
| ghostmansd | If I had some pattern-like stuff to refer to, I'd have done it | 13:12 |
| ghostmansd | for now, I deal with it with bunch of if/else | 13:12 |
| lkcl | honestly i think you'll find that if you use patterns like that it'll be a flat hierarchy not a nested if/else hierarchy | 13:12 |
| lkcl | to the point where it could be reduced to a simple array... just *as if* XO had come out of a CSV file | 13:13 |
| programmerjake | lkcl, reading all the nice comments you added to minor_59.csv while dealing with rebasing...ffadds is 2-in 2-out, not 3-in 2-out | 13:13 |
| lkcl | (is what i'm advocating. it makes it easier to drop in CSV files later) | 13:13 |
| lkcl | programmerjake, doh | 13:13 |
| ghostmansd[m] | Yes, I'like a flat hierarchy. | 13:14 |
| ghostmansd[m] | But I don't have time to implement it now. | 13:14 |
| lkcl | ack :) | 13:14 |
| ghostmansd[m] | So I do it the way it's done in this Signal-using code. | 13:14 |
| ghostmansd[m] | Yes this is one of things to plan. | 13:14 |
| lkcl | sigh yes. | 13:14 |
| lkcl | ok. so. sorry for the distractio | 13:14 |
| ghostmansd[m] | But I get the idea and share it. | 13:14 |
| lkcl | what were you saying | 13:14 |
| ghostmansd[m] | Ok, so, regardless of the structure..m | 13:15 |
| ghostmansd[m] | We end up with the exact class | 13:15 |
| ghostmansd[m] | Which specifies the exact fields | 13:15 |
| ghostmansd | https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/decoder/power_insn.py;h=4e05468188a4d162751467fa8d3ab0a43081a0da;hb=34043f1140c226d937c6db5bf4cfafe8ba5e8936#l989 | 13:15 |
| ghostmansd | this is normal.ffrc0 | 13:15 |
| lkcl | yep | 13:16 |
| ghostmansd | and, from that, we can already say what RC1 is... | 13:16 |
| ghostmansd | or what sz/dz are (if we take some other mode) | 13:16 |
| lkcl | yep... | 13:16 |
| ghostmansd | These modes are just convenient way to show spans | 13:16 |
| ghostmansd | And, since they're remapped too, as the whole RM... | 13:16 |
| lkcl | spans... i think i get that word | 13:17 |
| lkcl | Mode inherits from Mapping, which is the meta-bollox thing | 13:18 |
| ghostmansd | we have getters like this: svp64_insn_get_prefix_rm_mode_normal_simple_sz | 13:18 |
| lkcl | awesome | 13:18 |
| ghostmansd | this is a static inline uint64_t | 13:18 |
| ghostmansd | svp64_insn_get_prefix_rm_mode_normal_simple_sz(const struct svp64_insn *insn) | 13:18 |
| ghostmansd | { | 13:18 |
| ghostmansd | uint64_t value = insn->value; | 13:18 |
| ghostmansd | return ( | 13:18 |
| ghostmansd | (((value >> UINT64_C(32)) & UINT64_C(1)) << UINT64_C(0)) | 13:18 |
| ghostmansd | ); | 13:18 |
| ghostmansd | } | 13:18 |
| lkcl | all autogenerated | 13:18 |
| ghostmansd | My point is, I'd like to express operands in the same way | 13:18 |
| lkcl | erm...ermermerm... operands you mean EXTRA2/3 operands? | 13:19 |
| ghostmansd | and have some getter like svp64_insn_get_in0 | 13:19 |
| ghostmansd | Actually I'd like to have the whole operand combined | 13:19 |
| lkcl | frickin-ellfire :) | 13:19 |
| ghostmansd | That is, 5 bits from suffix AND 2 bits from EXTRA | 13:19 |
| ghostmansd | in one getter/setter pair | 13:19 |
| lkcl | compiler technology, deep joy. | 13:20 |
| lkcl | ok. | 13:20 |
| ghostmansd | That's, I'd like to generate getter which already does that crap internally. | 13:20 |
| lkcl | can i recommend first writing it out manually, so that you know clearly which bits go where? | 13:20 |
| ghostmansd | Yes, I think I'll start with this | 13:20 |
| ghostmansd | But I have to dive into SPEC deeper | 13:20 |
| ghostmansd | and stuff around, too | 13:20 |
| ghostmansd | Once I realize all possible combinations... | 13:21 |
| lkcl | btw, you know what the next stage is, here, don't you. a *nmigen* auto-generator, joining the binutils one. | 13:21 |
| lkcl | which actually really should not be that hard to do. | 13:21 |
| ghostmansd | ...I guess expressing these in a structures similar to Mode classes is really simple. | 13:21 |
| ghostmansd | With Modes, it was simpler: we had tables, not pseudocode. | 13:21 |
| ghostmansd | That is, all these shiny stuff like "OK, bit 2 are X, bit 3 is Y, then mode is Z" | 13:22 |
| lkcl | yehyeh | 13:22 |
| ghostmansd | and then I created class Z | 13:22 |
| lkcl | give it a shot, you'll kick yourself as to how simple it really is. | 13:22 |
| ghostmansd | OK will try to come up with some table | 13:24 |
| ghostmansd | I guess mutable parts are | 13:25 |
| ghostmansd | type: GP/FP vs CR | 13:25 |
| ghostmansd | vector: yes or no | 13:25 |
| ghostmansd | etype: EXTRA2/EXTRA3/NONE | 13:25 |
| programmerjake | well, ghostmansd, I think I unblocked you on #899 since I allocated all instructions and added them to the CSV files. | 13:34 |
| programmerjake | I stayed up too late, gn | 13:35 |
| sadoon[m] | night | 13:36 |
| sadoon[m] | I'm starting the buildd stuff now | 13:36 |
| ghostmansd[m] | gn | 13:43 |
| ghostmansd | and thanks for unblocking 899! | 13:45 |
| programmerjake | yw | 13:45 |
| ghostmansd | lkcl, OK, so we simply build 3 bits, eh? | 13:49 |
| lkcl | yyep. for spec, yes. | 13:50 |
| ghostmansd | "spec" is just a collection of three bits: 0 is vector, 1 and 2 are "extensions" for registers | 13:50 |
| lkcl | SVP64ExtraSpec makes a consistent 3-bit spec | 13:50 |
| lkcl | in MSB0-numbering yes. | 13:50 |
| lkcl | i think. | 13:50 |
| ghostmansd | The nmigen notation is fucking idiotic, with these "comb += cocojumbo.eq" | 13:51 |
| ghostmansd | It's not obvious cocojumbo is kinda "updated" | 13:51 |
| lkcl | it's because python hasn't got an override for assignment | 13:51 |
| lkcl | x = 5 | 13:51 |
| ghostmansd | Well it has for attributes | 13:51 |
| lkcl | would assign x *equal* to the number 5 | 13:51 |
| ghostmansd | but a.x can (and sometimes must) be overloaded | 13:51 |
| ghostmansd | This is how say properties work | 13:52 |
| lkcl | one of the other python-based RTLs did something incredibly stupid - they overloaded the "<=" operator to be assignment | 13:52 |
| ghostmansd[m] | Fucking morons | 13:52 |
| lkcl | hey, idiotic or not it made things "readable" | 13:53 |
| lkcl | but changing the meaning of a python operator... yeah. | 13:53 |
| ghostmansd | Yes, this is something that hurts readability even more. | 13:53 |
| ghostmansd | With eq, it's at least feels kinda "do an operation and return reference" | 13:54 |
| ghostmansd | And with <= it feels like "we're morons, don't ever consider this particular piece of code" | 13:54 |
| ghostmansd | Sorry, I know, this is strongly opinionated... | 13:55 |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC | 13:55 | |
| lkcl | you have to bear in mind that nmigen is a compiler for an Abstract Syntax Tree | 13:56 |
| lkcl | that is attempting to keep to a reasonably-human-readable syntax for hardware | 13:56 |
| lkcl | even with gate-level design it took me 6 *months* to get used to nmigen, and verilog and VHDL were about as long as well | 13:57 |
| lkcl | it's a totally different mindset, don't beat yourself up about it | 13:57 |
| * lkcl starting on preduce unit test | 13:57 | |
| ghostmansd | So, if we have etype == EXTRA2 AND found that operands goes to extra2[0]... this leads to spec[0] = extra2[0][0] and spec[1][1] = extra2[0][1] | 13:58 |
| * lkcl checking... | 13:58 | |
| ghostmansd | I have to hunt for LSB yet, but, other than that, it becomes clearer | 13:59 |
| lkcl | extra2--> split == RM.EXTRA[0:1], RM.EXTRA[2:3], RM.EXTRA[4:5], RM.EXTRA[6:7] | 13:59 |
| ghostmansd | by EXTRA, you mean all bits of extra present in both EXTRA2 and EXTRA3, right? | 14:00 |
| lkcl | then the spec associated with *extra2[0]* goes into... | 14:00 |
| lkcl | yes | 14:00 |
| lkcl | RM.EXTRA is 9-bit | 14:00 |
| lkcl | class SVP64ExtraSpec | 14:00 |
| lkcl | self.extra = Signal(9, reset_less=True) | 14:00 |
| ghostmansd | extra: _Field = range(10, 19) | 14:00 |
| lkcl | https://libre-soc.org/openpower/sv/svp64/ | 14:00 |
| ghostmansd | extra2: _Array[4] = ( | 14:00 |
| ghostmansd | range(10, 12), | 14:00 |
| ghostmansd | range(12, 14), | 14:00 |
| ghostmansd | range(14, 16), | 14:00 |
| ghostmansd | range(16, 18), | 14:00 |
| ghostmansd | ) | 14:00 |
| ghostmansd | extra3: _Array[3] = ( | 14:00 |
| lkcl | Common RM fields | 14:00 |
| ghostmansd | range(10, 13), | 14:00 |
| ghostmansd | range(13, 16), | 14:00 |
| ghostmansd | range(16, 19), | 14:00 |
| ghostmansd | ) | 14:00 |
| lkcl | EXTRA10:18Register Extra encoding | 14:00 |
| lkcl | confirmed.... ha, python range is of course 1 more so yes, confirmed extra: correct | 14:01 |
| lkcl | extra2.... 10-12 12-14 14-16 16-18 correct | 14:01 |
| lkcl | extra3... 10-13 13-16 16-19 correct | 14:02 |
| lkcl | yes. | 14:02 |
| lkcl | all good | 14:02 |
| ghostmansd | OK, but still, extra[2] has only VEC and MSB... | 14:02 |
| ghostmansd | heck | 14:02 |
| ghostmansd | extra2 has only VEC and MSB | 14:02 |
| lkcl | yes. | 14:02 |
| ghostmansd | since it's only two-bit | 14:02 |
| ghostmansd | and LSB... where is it? | 14:02 |
| lkcl | hell i don't know :) | 14:03 |
| ghostmansd | comb += spec_aug.eq(field(spec, SPECb.MSB, SPECb.LSB, SPEC_SIZE)) | 14:03 |
| lkcl | i would have to look at the definition of SPEC and SVEXTRA.IDX :) | 14:03 |
| ghostmansd | That's what I found | 14:03 |
| lkcl | MSB0-LSB0 ordering does my head in :) | 14:03 |
| ghostmansd | with m.If(self.isvec): | 14:04 |
| ghostmansd | # Vector: shifted up, extra in LSBs (RA << 2) | spec[1:2] | 14:04 |
| ghostmansd | comb += self.reg_out.eq(Cat(spec_aug, self.reg_in)) | 14:04 |
| ghostmansd | with m.Else(): | 14:04 |
| ghostmansd | # Scalar: not shifted up, extra in MSBs RA | (spec[1:2] << 5) | 14:04 |
| ghostmansd | comb += self.reg_out.eq(Cat(self.reg_in, spec_aug)) | 14:04 |
| ghostmansd | this stuff even has cats! | 14:04 |
| ghostmansd | meow | 14:04 |
| lkcl | Cat is "concatenate all bits" | 14:04 |
| ghostmansd | kinda begin to appreciate it | 14:04 |
| lkcl | standard fare for VHDL | 14:04 |
| ghostmansd | what a please | 14:04 |
| lkcl | # EXTRA3 3-bit subfield (spec) | 14:04 |
| lkcl | class SPECb(_Const): | 14:04 |
| lkcl | VEC = 0 # 1 for vector, 0 for scalar | 14:04 |
| lkcl | MSB = 1 # augmented register number, MSB | 14:04 |
| lkcl | LSB = 2 # augmented register number, LSB | 14:04 |
| lkcl | ok see consts.py | 14:05 |
| ghostmansd | yeah here | 14:05 |
| lkcl | anything XXXXXb is MSB0 ordering | 14:05 |
| ghostmansd | We're MSB0, don't think about it | 14:05 |
| programmerjake | <lkcl> "even with gate-level design it..." <- for verilog it took me 1-2 weeks, since I found a book on it and was bored at the time | 14:05 |
| lkcl | cesar kindly wrote an auto-enum-generator which turns those round into LSB-ordering | 14:05 |
| lkcl | that's what ConstLE is about. | 14:06 |
| lkcl | so | 14:06 |
| ghostmansd | all these fields are MSB0-enabled, all getters/setters convert the stuff on the fly | 14:06 |
| lkcl | let's take SPECb which is 3-bits | 14:06 |
| ghostmansd | aha | 14:06 |
| lkcl | VEC = 0 | 14:06 |
| lkcl | which is in MSB0-numbering | 14:06 |
| ghostmansd | yehyeh | 14:06 |
| lkcl | which if you are using SelectableInt is what you want | 14:06 |
| ghostmansd | yes | 14:07 |
| ghostmansd | I do :-) | 14:07 |
| lkcl | thank god for that | 14:07 |
| ghostmansd | all C getters/setters do too | 14:07 |
| ghostmansd | and all these fields hide that too | 14:07 |
| lkcl | class EXTRA2b(_Const): | 14:07 |
| lkcl | IDX0_VEC = 0 | 14:07 |
| lkcl | IDX0_MSB = 1 | 14:07 |
| ghostmansd | Yeah | 14:07 |
| lkcl | this is slightly brain-dead, no subtlety, just enumerate all the bits | 14:08 |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc | 14:08 | |
| ghostmansd | everything is clear except for LSB | 14:08 |
| lkcl | ... | 14:08 |
| lkcl | IDX3_VEC = 6 | 14:08 |
| lkcl | IDX3_MSB = 7 | 14:08 |
| lkcl | class SPECb(_Const): | 14:08 |
| lkcl | VEC = 0 # 1 for vector, 0 for scalar | 14:08 |
| lkcl | MSB = 1 # augmented register number, MSB | 14:08 |
| lkcl | LSB = 2 # augmented register number, LSB | 14:08 |
| lkcl | you can turn an EXTRA2 into an EXTRA3 simply with "<<" | 14:09 |
| ghostmansd | spec[VEC] = IDX0_VEC | 14:09 |
| ghostmansd | spec[MSB] = IDX0_MSB | 14:09 |
| lkcl | spec[LSB] = 0 | 14:09 |
| ghostmansd | Ahem... so it's always 0? | 14:09 |
| lkcl | yes | 14:10 |
| ghostmansd | I don't get, how then we have 0..127? | 14:10 |
| ghostmansd | Because we should've got 0..63 | 14:10 |
| lkcl | for scalar, yes. | 14:10 |
| lkcl | but for vector you have 0 2 4 6 .... 126 | 14:10 |
| ghostmansd | this is still 64, just step is 2 | 14:11 |
| ghostmansd | > INT is extended from r0-31 to r0-127 | 14:11 |
| lkcl | with EXTRA2 there is only one bit available for increasing the numbering, leaving... yes, only 6 bits | 14:11 |
| lkcl | no | 14:11 |
| lkcl | int it extended from r0-31 to r0-127 in increments of one with EXTRA3 | 14:12 |
| lkcl | int it extended from r0-31 to r0-126 in increments of TWO with EXTRA2 | 14:12 |
| ghostmansd | ... | 14:12 |
| lkcl | but because the conversion from EXTRA2/3 to 3-bit spec has *already happened* by that point, you dont' know that | 14:12 |
| lkcl | spec as generated from an EXTRA3 simply has the LSB zero. | 14:12 |
| ghostmansd | mmmm.... you mean EXTRA2? | 14:13 |
| lkcl | yes whoops | 14:13 |
| lkcl | hang on.... | 14:13 |
| lkcl | ha. | 14:13 |
| ghostmansd | With EXTRA3, stuff is clear | 14:13 |
| lkcl | yep. | 14:14 |
| lkcl | so just convert to spec | 14:14 |
| ghostmansd | Ah wait | 14:14 |
| lkcl | and forget about EXTRA2/3 | 14:14 |
| lkcl | then the fact that one bit is zero because of EXTRA2 you just don't care, at all | 14:14 |
| lkcl | Not Your Problem(tm) | 14:14 |
| ghostmansd | But how comes? I have one bit which determines if thing is a vector, that's OK. | 14:15 |
| lkcl | you're very much overthinking this :) | 14:15 |
| ghostmansd | Another one shows MSB, OK, so far so good. | 14:15 |
| ghostmansd | return (spec[1:2] << 5) | RA | 14:15 |
| ghostmansd | Let's forget about vectors, for a while | 14:16 |
| lkcl | that's for... scalar numbering. | 14:16 |
| ghostmansd | I don't understand, if spec[2] is always zero... | 14:16 |
| ghostmansd | how do we enable range(0, 128)? | 14:16 |
| lkcl | i have a sneaking suspicion that it should be inverted, there | 14:16 |
| lkcl | sigh | 14:16 |
| lkcl | which is probably the purpose of this line | 14:17 |
| lkcl | comb += spec_aug.eq(field(spec, SPECb.MSB, SPECb.LSB, SPEC_SIZE)) | 14:17 |
| ghostmansd | I don't know what this means | 14:17 |
| lkcl | that's equivalent job to FieldSelectableInt | 14:17 |
| ghostmansd | and, even if it's inverted, it's still the same range | 14:17 |
| lkcl | for a range | 14:17 |
| ghostmansd | even if we always have 1 for spec[2], it doesn't help | 14:18 |
| lkcl | yes but it means that ... hang on | 14:18 |
| lkcl | it means that the pseudocode is wrong | 14:18 |
| lkcl | spec_aug = spec[1]<<1 | spec[2] | 14:18 |
| ghostmansd | OK perhaps I must try encoding some values via pysvp64asm | 14:18 |
| lkcl | then | 14:18 |
| lkcl | return (spec_aug[0:1] << 5) | RA | 14:18 |
| lkcl | phone call | 14:19 |
| ghostmansd | OK | 14:19 |
| ghostmansd | https://pastebin.com/CccqwRNL | 14:24 |
| ghostmansd | Hm, perhaps way too verbose | 14:24 |
| lkcl | ooo joy :) | 14:24 |
| lkcl | ok sv.add 127,0,0 should work as this is EXTRA3 | 14:25 |
| ghostmansd | funny, I also found an issue in pysvp64asm | 14:25 |
| ghostmansd | we create database upon each instruction | 14:25 |
| lkcl | add is RM-2P-2S1D and as 3 operands i know that fits into 9-bit EXTRA | 14:25 |
| ghostmansd | which takes almost a second | 14:25 |
| lkcl | so for 127,0,0 you get | 14:26 |
| lkcl | extra3=[[0]=[3]0x3, [1]=[3]0x0, [2]=[3]0x0] | 14:26 |
| lkcl | which looks correct. | 14:26 |
| lkcl | let's check the RM-2P2S1D.csv file | 14:26 |
| lkcl | whoops | 14:27 |
| lkcl | RM-1P-2S1D oh well | 14:27 |
| lkcl | add,NORMAL,,1P,EXTRA3,d:RT;d:CR0,s:RA,s:RB,0,RA,RB,0,RT,0,CR0,0 | 14:27 |
| lkcl | EXTRA3[0] = d:RT and CR0 | 14:28 |
| lkcl | meaning add RT,RA,RB matches RT with EXTRA3[0[ | 14:28 |
| lkcl | so that's working | 14:28 |
| lkcl | the others are zero because the operands RA and RB are zero | 14:28 |
| ghostmansd | OK let's try on something EXTRA2 | 14:28 |
| ghostmansd | Bad choice with EXTRA3 | 14:28 |
| lkcl | isel | 14:28 |
| ghostmansd | since the whole discussion was about extra2 :-) | 14:28 |
| lkcl | isel is an RM-1P-3S1D | 14:29 |
| lkcl | four operands | 14:29 |
| lkcl | or fmadds | 14:29 |
| lkcl | sv.fmadds | 14:29 |
| ghostmansd | AssertionError: scalar GPR RT cannot fit into EXTRA2 (0, '127', 'RT', 'GPR', None) | 14:29 |
| lkcl | ta-daaaa | 14:30 |
| lkcl | there you go | 14:30 |
| ghostmansd | That's on sv.isel 127,0,0,0 | 14:30 |
| lkcl | that's correct. | 14:30 |
| lkcl | that's 100% correct | 14:30 |
| ghostmansd | So they are not supported, at all? | 14:30 |
| ghostmansd | for EXTRA2 | 14:30 |
| lkcl | no of course. you can't express 7-bits of numbers in only 6 bits | 14:30 |
| ghostmansd | I mean, do we only support 0..63 for EXTRA2? | 14:30 |
| lkcl | (5 bits for RA/RB/RC) | 14:30 |
| lkcl | (only 1 bit in EXTRA2) | 14:30 |
| ghostmansd | OK it'd have been easier if you just told me that :-D | 14:31 |
| lkcl | yes. | 14:31 |
| lkcl | i did! | 14:31 |
| lkcl | but i suspect you had to see it for yourself | 14:31 |
| ghostmansd | yeah seems like that was the case | 14:31 |
| lkcl | > ghostmansd> Because we should've got 0..63 | 14:31 |
| lkcl | :) | 14:31 |
| ghostmansd | hm... do we have it in spec explicitly? | 14:31 |
| lkcl | yes because for EXTRA2, spec[LSB] is always zero | 14:32 |
| ghostmansd | in this explicit form: WE DON'T SUPPORT RANGE 0..127 EVERYWHERE, ONLY FOR EXTRA3 | 14:32 |
| lkcl | correct. | 14:32 |
| lkcl | btw this is because RA is 5-bit | 14:33 |
| lkcl | for CRs which only have 3 bits the range is *even less* | 14:33 |
| ghostmansd | So we have another operand at the cost of reducing operand width? | 14:33 |
| ghostmansd | Is it what this is about? | 14:33 |
| lkcl | correct. | 14:33 |
| lkcl | otherwise we need something mad like 72-bit or 96-bit instructions | 14:33 |
| ghostmansd | We can support 4 operands, but with sacrificing the range. | 14:33 |
| lkcl | correct | 14:33 |
| ghostmansd | Why have range 127, then? | 14:34 |
| ghostmansd | range(128) | 14:34 |
| lkcl | because you have to make a decision in hardware about the number of registers | 14:34 |
| ghostmansd | I mean, why don't we simply assert we support 0..63 anywhere | 14:34 |
| lkcl | we decided 128 because this is intended for a 3D GPU / VPU | 14:34 |
| lkcl | and if you have only say 64 registers, that's nowhere near enough | 14:34 |
| ghostmansd | Hm... | 14:34 |
| lkcl | you end up with [extremely costly] stack-spill | 14:34 |
| ghostmansd | Still I'd like to see this clearly in the docs. | 14:35 |
| lkcl | NVIDIA and the latest AMDGPUs have i think *512* registers | 14:35 |
| lkcl | honestly? | 14:35 |
| ghostmansd | I mean, not in form one should guess and try | 14:35 |
| ghostmansd | But clearly, EXTRA2 only supports ranges 0..63 | 14:35 |
| lkcl | i've repeated this so many times in so many places i'm actually fed up of adding more words | 14:35 |
| lkcl | it is there. | 14:35 |
| ghostmansd | You don't have to repeat it, just write it in words :-) | 14:36 |
| lkcl | i really don't want to add more words repeating this. | 14:36 |
| ghostmansd | Not pseudocode | 14:36 |
| lkcl | it's already there | 14:36 |
| lkcl | buried in amongst 160+ pages, it's there | 14:36 |
| ghostmansd | lol | 14:36 |
| ghostmansd | ... | 14:36 |
| ghostmansd | how does the end user knows what is EXTRA2 and EXTRA3? | 14:36 |
| lkcl | we encountered this phenomenon already with the [1,600] page Power ISA spec itself | 14:37 |
| ghostmansd | I mean, just looking at opcode name... | 14:37 |
| lkcl | deep breath: they need to look at the CSV files. | 14:37 |
| lkcl | which | 14:37 |
| ghostmansd | fuck | 14:37 |
| lkcl | another deep breath | 14:37 |
| lkcl | i have converted to tables and included in the spec | 14:37 |
| ghostmansd | A-ha | 14:37 |
| lkcl | hence why sv_analysis is so critically, critically important | 14:37 |
| ghostmansd | We do have it as PDF, right? | 14:37 |
| lkcl | and *also* included in the spec | 14:37 |
| lkcl | yes | 14:37 |
| ghostmansd | Because I'm one of the weirdos who does it with CSV | 14:37 |
| lkcl | https://ftp.libre-soc.org/simple_v_spec.pdf | 14:38 |
| lkcl | i modifed sv_analysis.py to actually explicitly output .mdwn | 14:38 |
| lkcl | where previously it was outputting csv files with [[!table file=some.csv]] | 14:38 |
| lkcl | which pandoc didn't understand | 14:38 |
| * lkcl typing too much | 14:39 | |
| ghostmansd | OK let's say we have addis | 14:39 |
| lkcl | need to minimise typing. | 14:39 |
| lkcl | carry on | 14:39 |
| ghostmansd | Where do I have in the spec a clear and explicit table which says "it's EXTRA3"? | 14:39 |
| lkcl | https://ftp.libre-soc.org/simple_v_spec.pdf | 14:39 |
| ghostmansd | or well, isel is EXTRA2? | 14:39 |
| ghostmansd | yes, I'm looking at it | 14:40 |
| ghostmansd | Ah | 14:40 |
| lkcl | appendix F p211 | 14:40 |
| ghostmansd | RM-1P-3S1D Single Predication dest/src1/2/3, applies to 4-operand instructions | 14:40 |
| ghostmansd | 6.12.1 RM-1P-3S1D | 14:40 |
| ghostmansd | Rdest_EXTRA2 10:11 extends Rdest (R*_EXTRA2 Encoding) | 14:40 |
| ghostmansd | Rsrc1_EXTRA2 12:13 extends Rsrc1 (R*_EXTRA2 Encoding) | 14:40 |
| ghostmansd | Rsrc2_EXTRA2 14:15 extends Rsrc2 (R*_EXTRA2 Encoding) | 14:40 |
| ghostmansd | OK I'm starting to understand | 14:41 |
| lkcl | which is direct from mdwn | 14:41 |
| lkcl | which is direct from sv_analysis | 14:41 |
| ghostmansd | it applies to the whole remap form | 14:41 |
| ghostmansd | we document the remap forms, not particular instructions | 14:41 |
| ghostmansd | for instruction, we print which remap form it has | 14:41 |
| lkcl | reg-profiling sv_analysis | 14:41 |
| lkcl | yes. | 14:41 |
| ghostmansd | and then the users simply check the remap form and see what the fuck EXTRA it supports | 14:42 |
| lkcl | if they're insane, yes | 14:42 |
| ghostmansd | why call it insanity? | 14:42 |
| lkcl | if they're sane they use the csv files (auto-generate) | 14:42 |
| lkcl | manual reading == mistakes | 14:42 |
| ghostmansd | my first natural attempt was isel 127 | 14:42 |
| ghostmansd | from the docs I saw this: | 14:42 |
| ghostmansd | INT is extended from r0-31 to r0-127 | 14:42 |
| ghostmansd | so yeah, unsurprisingly I tried doing it | 14:43 |
| ghostmansd | and found I lost | 14:43 |
| ghostmansd | or, well, failed | 14:43 |
| lkcl | ah yep got it | 14:43 |
| lkcl | let me correct that | 14:43 |
| lkcl | ah that is register *quantities* | 14:43 |
| ghostmansd | well you still see the reason for the confusion, right? | 14:44 |
| ghostmansd | so, OK, to summarize | 14:44 |
| lkcl | * CR Fields are extended from CR0-7 to CR0-127 | 14:45 |
| lkcl | 14:45 | |
| lkcl | +However due to pressure in `RM.EXTRA` not all these registers | 14:45 |
| lkcl | +are accessible by all instructions, particularly those with | 14:45 |
| lkcl | +a large number of operands (`madd`, `isel`). | 14:45 |
| ghostmansd | for EXTRA3, we take all 3 bits from the corresponding extra3, the first one designates whether the operand is vector | 14:45 |
| ghostmansd | for EXTRA2, we take two bits, and the last one is always 0 | 14:45 |
| lkcl | yes | 14:45 |
| ghostmansd | we than combine it with the value from the suffix | 14:46 |
| lkcl | when converted to 3bit spec yes | 14:46 |
| ghostmansd | and -- voi-la! -- we have the value in SVP64 world | 14:46 |
| lkcl | yes | 14:46 |
| ghostmansd | OK | 14:46 |
| lkcl | ta-daa | 14:46 |
| ghostmansd | This is actually something expressible via layouts :-) | 14:46 |
| ghostmansd | OK, I'll think how to express it now | 14:46 |
| ghostmansd | many thanks to you for your help and patience! | 14:47 |
| lkcl | dang | 14:47 |
| ghostmansd | I'd suggest explicitly writing "EXTRA2 form supports only these ranges: XXX" | 14:48 |
| ghostmansd | Explicit is better than implicit | 14:48 |
| ghostmansd | We can end up with extra_idx == NONE for stuff like immediates, right? | 15:06 |
| lkcl | yes | 15:06 |
| ghostmansd | If I'm not mistaken, these are output as is? | 15:06 |
| lkcl | immediates never change | 15:06 |
| ghostmansd | (thus the naming) | 15:06 |
| ghostmansd | Something else than immediates> | 15:07 |
| ghostmansd | ? | 15:07 |
| lkcl | imms not involved in EXTRA2/3 at all | 15:07 |
| lkcl | ignore | 15:07 |
| ghostmansd | ack | 15:07 |
| ghostmansd | For EXTRA2, do we end up with r0, r1, ... r63, or we end up with r0, r2, r4, ... r126? | 15:11 |
| ghostmansd | From LSB being set looks like the latter. | 15:11 |
| lkcl | r0..r63 | 15:11 |
| lkcl | see the bits about spec_aug... let me find irc ref.... | 15:12 |
| lkcl | https://libre-soc.org/irclog/%23libre-soc.2022-09-06.log.html#t2022-09-06T14:18:24 | 15:12 |
| ghostmansd | Ah OK, the pseudocode must be updated | 15:14 |
| ghostmansd | https://libre-soc.org/openpower/sv/svp64/#index13h1 | 15:14 |
| lkcl | yes | 15:14 |
| lkcl | sigh | 15:14 |
| lkcl | annoying. | 15:14 |
| lkcl | supposed to be simple/readable | 15:14 |
| ghostmansd | when you have someone in IRC to explain all the gory details -- it is :-) | 15:15 |
| lkcl | spec is wrong | 15:15 |
| ghostmansd | I know this is not the consolation you wanted, but hey, that's something | 15:15 |
| lkcl | :) | 15:15 |
| ghostmansd | Another dumb and obvious question. We also can never end up with extra_idx == Idx3 for EXTRA2, right? | 15:17 |
| lkcl | urrr... no | 15:17 |
| ghostmansd | And we'd better have an assertion to check what our code gave us. | 15:17 |
| lkcl | never | 15:17 |
| lkcl | wait... | 15:17 |
| lkcl | incorrect | 15:17 |
| lkcl | never extra_idx == idx3 for *EXTRA3* | 15:18 |
| lkcl | 9 bit | 15:18 |
| lkcl | div3 | 15:18 |
| lkcl | Idx0 | 15:18 |
| lkcl | Idx1 | 15:18 |
| lkcl | Idx2 | 15:18 |
| ghostmansd | ah yes | 15:18 |
| ghostmansd | sorry | 15:19 |
| ghostmansd | my fault | 15:19 |
| *** hl <hl!~hl@user/hl> has quit IRC | 15:22 | |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC | 15:23 | |
| lkcl | preduce 1st pseudocode in | 15:29 |
| *** hl <hl!~hl@user/hl> has joined #libre-soc | 15:30 | |
| lkcl | frickin ellfier | 15:36 |
| lkcl | holy shit it worked | 15:42 |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc | 15:47 | |
| ghostmansd | Can Idx_1_2 scheme appear only for CRs? | 15:52 |
| ghostmansd | I'm asking since CRs will anyway end up in their own classes, and I can diagnose such situation for GPR/FPR as an error. | 15:53 |
| ghostmansd | Also, another question. What does this magic with shifts if register is vector really mean? | 15:55 |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC | 16:19 | |
| *** octavius <octavius!~octavius@238.147.93.209.dyn.plus.net> has joined #libre-soc | 16:23 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC | 16:23 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.55.206> has joined #libre-soc | 16:24 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.55.206> has quit IRC | 17:13 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc | 17:14 | |
| lkcl | ok so it is really for EXTRA2 (and for CRs) | 17:23 |
| lkcl | there are limited bits (e.g. in CRs) - only 3-bits in BFA | 17:24 |
| lkcl | but they need to be expanded to range 0..127 | 17:24 |
| lkcl | 7-bits | 17:24 |
| *** octavius <octavius!~octavius@238.147.93.209.dyn.plus.net> has quit IRC | 17:25 | |
| lkcl | EXTRA2 only provides 1 more | 17:25 |
| lkcl | EXTRA3 provides 2 more bits | 17:25 |
| lkcl | for CR Field numbers that's 3+(1-or-2) which is obviously not 7 | 17:25 |
| lkcl | therefore, logically, you have to shift up | 17:26 |
| lkcl | think about it: it's no bloody good having 128 registers if you can't bloody well access them!! | 17:26 |
| lkcl | because the numbering only goes up to say 15 or 31! | 17:26 |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC | 17:34 | |
| *** octavius <octavius!~octavius@238.147.93.209.dyn.plus.net> has joined #libre-soc | 17:35 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.55.254> has joined #libre-soc | 17:38 | |
| lkcl | toshywoshy, ping, openpowerbot's gone walkies :) | 17:47 |
| lkcl | now, as for scalar: if you perform the same "shift" on *scalar* regs | 17:50 |
| lkcl | r0 r2 r4 r6 ... r126 | 17:50 |
| lkcl | how the hell do you access r1? | 17:50 |
| lkcl | you can't. | 17:50 |
| lkcl | so the sacrifice was made to access the scalar regs in sequence (which *includes v3.0B registers in full* - that's really important) | 17:51 |
| lkcl | but to sacrifice the LSBs on vector access because you'll likely do VL=4 and above anyway | 17:51 |
| *** openpowerbot <openpowerbot!~openpower@94-226-188-34.access.telenet.be> has joined #libre-soc | 17:52 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.55.254> has quit IRC | 17:55 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc | 17:55 | |
| ghostmansd[m] | How would we call part of reg which is hold in the spec? | 17:58 |
| ghostmansd[m] | Suffix part I called "base" | 17:58 |
| ghostmansd[m] | (suffix part is what pseudocode calls RA) | 17:59 |
| ghostmansd[m] | spec[0] I called vector... | 17:59 |
| ghostmansd[m] | And spec[1..2] or spec[1] (depending on the extra), how would we call it? | 17:59 |
| ghostmansd[m] | Seriously I'm that tired I gonna call it "rest" | 18:00 |
| ghostmansd[m] | Hm. IIRC in pysvp64asm it's called sv_extra. | 18:02 |
| ghostmansd[m] | Let me call it extra. | 18:02 |
| lkcl | btw reminder of the idea that occurred to me a few days ago: a secondary auto-generator creating nmigen data-struct and Records | 19:06 |
| lkcl | therefore if you could stick reasonably closely to the existing variable/class-names where it makes sense to do so, it makes for less work in ripping out all of the hand-written code | 19:07 |
| ghostmansd[m] | I'm trying to, but sometimes it's really difficult | 19:52 |
| ghostmansd[m] | For example, I already have to move from nested arrays in Extra2/Extra3 | 19:53 |
| ghostmansd[m] | And replace these with Idx0..Idx3 | 19:53 |
| lkcl | actually things like that don't matter so much | 20:13 |
| *** octavius <octavius!~octavius@238.147.93.209.dyn.plus.net> has quit IRC | 20:13 | |
| lkcl | reason being that it's the inputs and the outputs that ultimately matter | 20:13 |
| lkcl | intermediary data structures, no so much | 20:14 |
| lkcl | tests re-run and rebased dis btw | 20:14 |
| lkcl | commit 20575120e | 20:14 |
| lkcl | pysvp64asm: create database once | 20:14 |
| ghostmansd[m] | Ah OK this one should be OK | 20:17 |
| ghostmansd[m] | Don't pick anything I might push soon, it might hurt :-) | 20:18 |
| ghostmansd[m] | Thanks for rebase | 20:18 |
| ghostmansd[m] | lkcl, could we perhaps go through say sv.add first operand? | 20:18 |
| ghostmansd[m] | And tell which bits exactly it uses for new value | 20:19 |
| ghostmansd[m] | The particular bits span used to produce new value | 20:19 |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc | 20:20 | |
| ghostmansd | For now I have this span for RT: (6, 7, 8, 9, 10, 18, 19, 20) | 20:20 |
| ghostmansd | in this particular order | 20:20 |
| ghostmansd | Ah wait I see... | 20:21 |
| ghostmansd | I should've got first 5 bits in the order they appeared in suffix | 20:21 |
| sadoon[m] | I have found the perfect solution for building full debian from source https://pbuilder-team.pages.debian.net/pbuilder | 20:43 |
| sadoon[m] | I have it setup about 40% of the way, and it provides useful automation | 20:43 |
| sadoon[m] | and with that, good night everyone :) | 20:43 |
| ghostmansd | sadoon[m], gn! | 20:47 |
| ghostmansd | lkcl: https://bugs.libre-soc.org/show_bug.cgi?id=917#c5 | 20:56 |
| ghostmansd | note that this is hacky, and you have 0 guarantees upon rebasing this: I really had to touch EXTRAs (had to switch from Array class to Mapping). | 20:57 |
| ghostmansd | That said, Array were a giant hack anyway. I've already been thinking about how to drop these. | 20:57 |
| ghostmansd | Please check the examples I posted, there might (and for sure will) be errors. | 20:58 |
| ghostmansd | That said, this is at least something for starters. | 20:58 |
| ghostmansd | Tomorrow I'm going to claim RFP for word instructions, I need at least some RFP already for all this torment... :-D Is it OK? I consider this complete except for special CR handling (but these can be printed as plain numbers anyway IIRC). | 21:00 |
| ghostmansd | Also, 838. Do we have anything left there, apart from DecodeFields quirk we found today? I'd grab this too. | 21:01 |
| ghostmansd | I'm considering these tasks: | 21:03 |
| ghostmansd | https://bugs.libre-soc.org/show_bug.cgi?id=838 no idea what's left here besides done; we kept the form, but went into great efforts to cross-check (and even managed to find some issues) | 21:04 |
| ghostmansd | https://bugs.libre-soc.org/show_bug.cgi?id=918 I'd consider taking 1/3 of #917 for insndb | 21:05 |
| ghostmansd | https://bugs.libre-soc.org/show_bug.cgi?id=919 1/3 of #917 for word instructions | 21:05 |
| ghostmansd[m] | Tomorrow I'm going to continue on extras (I think they're still pretty hacky). The next target is CRs. | 21:09 |
| ghostmansd[m] | I'm unsure what's next besides capturing "specifiers" and printing these (dz, sz, etc., anything we had separated by / in assembly). I'd be great if we have an exhaustive list of those by hand. I'm not sure what we should print. | 21:12 |
| ghostmansd[m] | Also, by this point I'm confident that the whole svp64asm can be written as a mapping of specifier:callback_to_routine_which_sets_some_fields_in_SVP64Instruction_instance | 21:13 |
| ghostmansd[m] | But that's yet another story. | 21:13 |
| ghostmansd[m] | Too tired today to think straight, but wanted to express this thought until I forget it; see you tomorrow. | 21:14 |
| *** octavius <octavius!~octavius@238.147.93.209.dyn.plus.net> has joined #libre-soc | 21:36 | |
| lkcl | appreciated. | 21:46 |
| programmerjake | meeting in 7min everyone | 21:54 |
| programmerjake | 6min now | 21:54 |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC | 21:57 | |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc | 21:58 | |
| ghostmansd[m] | Ah we have a meeting today | 22:01 |
| ghostmansd[m] | Ok I'll join too | 22:02 |
| *** markos <markos!~Konstanti@178.59.251.230> has quit IRC | 23:17 | |
| *** markos <markos!~Konstanti@178.59.251.230> has joined #libre-soc | 23:30 | |
| *** octavius_ <octavius_!~octavius@238.147.93.209.dyn.plus.net> has joined #libre-soc | 23:31 | |
| *** octavius <octavius!~octavius@238.147.93.209.dyn.plus.net> has quit IRC | 23:36 | |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC | 23:37 | |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc | 23:39 | |
| ghostmansd[m] | Cool sync today | 23:53 |
| ghostmansd[m] | Almost 2 AM here :-) | 23:53 |
| ghostmansd[m] | Thanks for talk, and good night! | 23:53 |
| programmerjake | gn | 23:54 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!