| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@91.205.170.135> has quit IRC | 00:02 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.172.86> has joined #libre-soc | 00:04 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.172.86> has quit IRC | 00:19 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@91.205.170.135> has joined #libre-soc | 00:22 | |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc | 00:22 | |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC | 00:51 | |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc | 00:52 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@91.205.170.135> has quit IRC | 04:47 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.42.207> has joined #libre-soc | 04:58 | |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC | 05:12 | |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc | 05:17 | |
| programmerjake | lkcl: afaict the comment here is no longer needed, it already works for doing load/store ops of smaller width: https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/decoder/isa/mem.py;h=c41e436e5e5133a6bebaf76b9df81d4d60baa51c;hb=HEAD#l82 | 08:12 |
|---|---|---|
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.42.207> has quit IRC | 08:27 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.42.207> has joined #libre-soc | 08:32 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.42.207> has quit IRC | 08:37 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc | 08:37 | |
| lkcl | probably :) | 10:14 |
| lkcl | programmerjake, i fixed "sv.addi." several days ago | 10:40 |
| lkcl | do be really careful with sv/trans/svp64.py - check that "sv.ffmadds." is still decoded | 10:40 |
| programmerjake | sv.addi. -- thx! sv.fmadds. -- replied via email | 10:42 |
| programmerjake | basically i'm fixing it tomorrow and will add tests (assuming i remember), so i didn't check if it's broken now. all existing tests passed on my pc | 10:43 |
| lkcl | yep, it's broken. " ffmadds. 1, 0, 1, 1 | 10:43 |
| lkcl | " is placed directly into the assembler | 10:43 |
| lkcl | which of course does not exist | 10:43 |
| lkcl | but ffmadds is correctly converted to a ".long" | 10:44 |
| programmerjake | oh, btw, you might want to watch the SLS rocket launch in 2-3hr | 10:46 |
| *** octavius <octavius!~octavius@146.90.27.39> has joined #libre-soc | 10:47 | |
| lkcl | programmerjake, btw (appreciate it's late) do you want to do [scalar] transcendentals, next? | 10:58 |
| lkcl | blast through them | 10:59 |
| lkcl | some EUR budget for ghostmansd[m] for adding to binutils | 10:59 |
| lkcl | it'll be things like atan / atan2 (sin/cos is already there), and log1p exp1m etc. | 11:00 |
| programmerjake | if we're doing them properly it will take quite a while...we'd need something like crlibm for python | 11:02 |
| programmerjake | and all the fp exception flags and rounding modes, etc. | 11:03 |
| lkcl | no, not doing them "properly". | 11:03 |
| lkcl | no exceptions no rounding modes | 11:03 |
| lkcl | and using python math | 11:03 |
| lkcl | time-budget absolute max of about... 8 days. so *real* fast - 3 to 4 opcodes a day, minimum. | 11:04 |
| programmerjake | k, yeah, i can work on that | 11:04 |
| lkcl | there's a follow-up EUR 100,000 NLnet grant with no time-pressure to do "cleanup" | 11:05 |
| programmerjake | cleanup in general or fp specifically? | 11:05 |
| lkcl | (and corresponding separate EUR 100k standards one because all of the FP-flags modes esp. what happens on sin(inf) etc. hasn't even been defined yet) | 11:06 |
| lkcl | both the standard proposal and then correspondingly the simulator (to make sure the standard's correctly adhered to) | 11:07 |
| programmerjake | iirc the ieee754 standard specifies fp exceptions for all those ops (and if not, we shouuld be able to easily extrapolate from other ops it does specify) | 11:07 |
| lkcl | i'm certain sin(inf) etc are all listed in the IEEE754.... yes. | 11:07 |
| lkcl | the simulator doesn't have FP modes at all at the moment, all the sin/cos (etc.) were added in a rush to get DCT/FFT and mp3 working in the bare minimum amount of time | 11:08 |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc | 11:26 | |
| ghostmansd[m] | Fuck. My laptop ran out of battery and I ended up with some broken objects in git. Now I have to resort to some combinations of git fsck and similar dark magic. | 11:27 |
| ghostmansd[m] | Hopefully nothing that unrepairable, but still pretty depressing. | 11:28 |
| programmerjake | what fun...at least it's not fat32... | 11:31 |
| programmerjake | that's how I lost the source for the quickbasic compiler i wrote | 11:32 |
| lkcl | ngggh | 11:57 |
| lkcl | there's... there's some options in fstab which help with that. | 11:58 |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC | 12:04 | |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc | 12:06 | |
| *** octavius <octavius!~octavius@146.90.27.39> has quit IRC | 12:57 | |
| lkcl | ghostmansd[m], i thought of a solution to the issue of overlapping patterns | 13:24 |
| lkcl | as to how to do disasm, that is | 13:24 |
| lkcl | or is it asm, i have difficulty working out which | 13:25 |
| lkcl | basically you collate a list | 13:25 |
| lkcl | then you go through the 1st bit of every element of that list, and if they're the same, you put that into bit 1 of the output | 13:26 |
| ghostmansd[m] | What's the issue with overlapping patterns? You mean instructions with the same name, right? | 13:26 |
| lkcl | if *any* of them are *not* the same you put a "-" into the bit 1 output | 13:26 |
| lkcl | yes. | 13:26 |
| lkcl | like the rldicr used to have, before they were replaced with a single pattern | 13:26 |
| lkcl | i _need_ to add 13 identical patterns with 4 bits almost the same | 13:27 |
| lkcl | 1 of those patterns is reserved | 13:27 |
| lkcl | and 2 more are a *different instruction* | 13:27 |
| lkcl | svshape2 | 13:27 |
| ghostmansd[m] | But how these end up having the same name? | 13:27 |
| lkcl | because they are the same | 13:27 |
| ghostmansd[m] | Is it like, different patterns are allowed for the same instruction? | 13:28 |
| lkcl | a *later* decode - on those 4 bits - will decide... | 13:28 |
| lkcl | there's a sub-field (SVRM) which as of right now is decoded within the instruction | 13:28 |
| lkcl | it is 4 bits long | 13:28 |
| ghostmansd[m] | Sorry, I'm lacking the context. Could we take some specific example from say some CSV? | 13:28 |
| lkcl | therefore there are 16 options | 13:28 |
| lkcl | https://libre-soc.org/openpower/sv/remap/#svshape | 13:29 |
| lkcl | 0.56.1011.1516..2021..252526..31name | 13:29 |
| lkcl | OPCDSVxdSVydSVzdSVRMvfXOsvshape | 13:29 |
| lkcl | bits 21-25 (SVRM) are at present decoded by the svshape instruction, entirely | 13:30 |
| lkcl | but | 13:30 |
| lkcl | see the two entries | 13:30 |
| lkcl | 0b1000reserved | 13:30 |
| lkcl | 0b1001reserved | 13:30 |
| lkcl | ? | 13:30 |
| lkcl | i want to use those for svshape2 *with an entirely different Form* | 13:30 |
| lkcl | so | 13:31 |
| lkcl | instead of | 13:31 |
| lkcl | -----011001,VL,OP_SVSHAPE,N | 13:31 |
| lkcl | which is what is there at present | 13:31 |
| lkcl | we must add | 13:31 |
| lkcl | 0000-011001,VL,OP_SVSHAPE, # 0b0000Matrix 1/2/3D | 13:32 |
| lkcl | 0001-011001,VL,OP_SVSHAPE, # 0b0001FFT Butterfly | 13:32 |
| lkcl | ... | 13:32 |
| lkcl | .... | 13:32 |
| lkcl | 1000-011001,VL,OP_SVSHAPE2, # 0b1000COMPLETELY DIFFERENT ENCODING FORM FOR SVSHAPE2 | 13:33 |
| lkcl | 1001-011001,VL,OP_SVSHAPE2, # 0b1001COMPLETELY DIFFERENT ENCODING FORM FOR SVSHAPE2 | 13:33 |
| lkcl | ... | 13:33 |
| lkcl | 1111-011001,VL,OP_SVSHAPE, # 0b1111FFT half-swap | 13:33 |
| lkcl | sorry | 13:35 |
| ghostmansd | I still don't get. These are different patterns. | 13:35 |
| lkcl | that svshape2 one can be | 13:35 |
| ghostmansd | How do different opcodes end up having the same mnemonic? | 13:35 |
| lkcl | 100--011001,VL,OP_SVSHAPE2, | 13:35 |
| lkcl | because they go through to a Decoder which reads the bits *again*, as one of the sub-fields | 13:36 |
| lkcl | switch(XO) | 13:36 |
| lkcl | case 0b10000: | 13:36 |
| ghostmansd | From what I see in binutils, they expect different mnemonics. | 13:36 |
| lkcl | case 0b10001: | 13:36 |
| lkcl | these could actually just be | 13:36 |
| lkcl | switch(XO) | 13:37 |
| ghostmansd | Or well... are there examples of such behavior in OpenPower ISA already? | 13:37 |
| lkcl | case 0b100- | 13:37 |
| lkcl | it's nothing to do with Power ISA | 13:37 |
| lkcl | it's to do with decoding | 13:37 |
| ghostmansd | It has to do with opcode decoding. | 13:37 |
| lkcl | yes. | 13:37 |
| lkcl | so it is a decision of the implementor, not an actual "hard actual requirement of the Power ISA specification" | 13:38 |
| ghostmansd | We're talking of minor_22, right? | 13:38 |
| ghostmansd | Do you have a WiP to share? | 13:38 |
| ghostmansd | So that I could take a look. | 13:38 |
| lkcl | yes | 13:38 |
| lkcl | no, because the moment i add those 13 patterns disasm will break | 13:39 |
| lkcl | and when sv/trans/svp64.py is adapted, that will break too | 13:39 |
| lkcl | so this is really important to add the list-handling | 13:40 |
| ghostmansd | opcode,unit,internal op,in1,in2,in3,out,CR in,CR out,inv A,inv out,cry in,cry out,ldst len,BR,sgn ext,upd,rsrv,32b,sgn,rc,lk,sgl pipe,comment,form,CONDITIONS,unofficial,comment2 | 13:40 |
| ghostmansd | -----011001,VL,OP_SVSHAPE,NONE,NONE,NONE,NONE,NONE,NONE,0,0,ZERO,0,NONE,0,0,0,0,0,0,NONE,0,0,svshape,SVM,,1,unofficial until submitted and approved/renumbered by the opf isa wg | 13:40 |
| lkcl | yes. | 13:40 |
| lkcl | that becomes | 13:40 |
| lkcl | 0000-011001,VL,OP_SVSHAPE, | 13:40 |
| lkcl | 0001-011001,VL,OP_SVSHAPE, | 13:40 |
| lkcl | ... | 13:40 |
| lkcl | .... | 13:40 |
| lkcl | 1111-011001,VL,OP_SVSHAPE, | 13:40 |
| lkcl | 13 entries. | 13:41 |
| lkcl | they *will* (have to be) identical | 13:41 |
| lkcl | and a rule set, "if the other fields do not match throw a runtime assertion" | 13:41 |
| ghostmansd | and all these share the same name/comment? | 13:45 |
| ghostmansd | and, well, instead of a single per-record opcode, we'd rather should have _list_ of opcodes? | 13:45 |
| lkcl | yes. all fields except for the pattern it is critical that they be the same | 13:46 |
| lkcl | urrr.... yyeees... except if you think that through visually it'll be awful | 13:46 |
| lkcl | i mean, yes, it's a solution. something like [NN NN NN] | 13:47 |
| lkcl | but here's the thing: the patterns must *ONLY* be added to cover one of the fields that is to be further decoded elsewhere/elsewhen | 13:48 |
| lkcl | you can NOT do this: | 13:48 |
| lkcl | 0000-011001 | 13:49 |
| lkcl | -000101101 | 13:49 |
| lkcl | sorry | 13:49 |
| lkcl | 0000-011001 | 13:49 |
| lkcl | -0001011001 | 13:49 |
| lkcl | or worse | 13:49 |
| lkcl | 0000-011001 | 13:49 |
| lkcl | 0010-011011 | 13:49 |
| lkcl | or bullshit like that | 13:49 |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC | 13:50 | |
| lkcl | what this scheme is declaring is: | 13:50 |
| lkcl | * i respect the XO of the instruction | 13:50 |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc | 13:50 | |
| lkcl | * i have a sub-field which i am in control of... mostly | 13:50 |
| lkcl | * i want *SOME* encodings of that sub-field to be handed over to a *different* instruction | 13:51 |
| lkcl | * therefore i am declaring what those sub-fields are, explicitly | 13:51 |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC | 13:52 | |
| ghostmansd[m] | Couldn't we hash not only name but both opcode and name? | 13:55 |
| ghostmansd[m] | Because currently the issue is caused by the fact that I hash by name. | 13:56 |
| lkcl | that's perfectly fine | 13:59 |
| lkcl | i worked out how to "get" the actual XO out of the thing | 13:59 |
| lkcl | oh | 13:59 |
| lkcl | i know | 13:59 |
| lkcl | a *sub-pattern* as a list (new field) | 14:00 |
| lkcl | keep the "-----011001,VL,OP_SVSHAPE,NO" | 14:00 |
| lkcl | .... | 14:00 |
| lkcl | but add an *EXTRA* pattern that must be laid on top | 14:00 |
| lkcl | [0000---------, | 14:00 |
| lkcl | 0001-------, | 14:00 |
| lkcl | 0010-------, | 14:01 |
| lkcl | .... | 14:01 |
| lkcl | ... | 14:01 |
| lkcl | 1111-------] | 14:01 |
| lkcl | eurgh that means altering PowerDecoder | 14:02 |
| lkcl | ah wait i know a way to do it | 14:02 |
| ghostmansd | I'll think about it | 14:02 |
| ghostmansd | I'm now dealing with switching binutils to new fields | 14:02 |
| lkcl | fun | 14:02 |
| ghostmansd | Including the disassembler bits | 14:02 |
| ghostmansd | Frankly it became a lot clearer | 14:02 |
| lkcl | great! | 14:03 |
| ghostmansd | There are no longer stuff like custom structures for each field which then have to be combined or decoupled here and there. | 14:03 |
| ghostmansd | Only one 64-bit integer, with many getters and setters. | 14:03 |
| lkcl | ahh way better | 14:04 |
| ghostmansd | https://pastebin.com/aubfJ6ZG | 14:04 |
| lkcl | that sounds like for cavatools it's going to be laughably easy | 14:04 |
| ghostmansd | Well the part I already done was remarkably hard... :-) | 14:05 |
| lkcl | :) | 14:05 |
| ghostmansd | Probably the hardest yet, TBH. | 14:05 |
| ghostmansd | Two weeks I spent completely buried in metaclasses crap. | 14:05 |
| ghostmansd | I think I knew more than I ever wanted to. | 14:05 |
| ghostmansd | But the outcome is nice, so hey, who cares. | 14:06 |
| lkcl | :) | 14:06 |
| lkcl | if i had time and great enthusiasm i'd ask, "oo yes, _please_ explain metaclasses to me, i really want to know everything about them" | 14:07 |
| ghostmansd | ...that'd take two weeks more. :-) | 14:08 |
| ghostmansd | This a really arcane magic. | 14:08 |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc | 14:08 | |
| ghostmansd | Not only metaclasses but also descriptors which I also had to use. | 14:08 |
| ghostmansd | No, just kidding. It can be done faster. | 14:08 |
| ghostmansd | But still as one who almost never used these I really had to investigate many concepts. | 14:09 |
| lkcl | honestly i am astounded, impressed, and slightly scared. | 14:10 |
| ghostmansd | I'm still scared. But I guess soon the fear will go away to be replaced with the Stokholm syndrome. | 14:15 |
| ghostmansd | lkcl, speaking of opcodes. Am I right that stuff like sradi., extswsli are also affected? | 14:42 |
| ghostmansd | Also mulhw and mulhd. | 14:43 |
| lkcl | if there are double-entries? yes. | 14:57 |
| lkcl | basically imagine that those CSV files *literally* generate case-statement entries in a giant switch | 14:58 |
| lkcl | if there are multiple entries you Just Don't Care (tm) because the multiple entries do PRECISELY and EXACTLY what is required: | 14:58 |
| lkcl | all go through to the EXACT same instruction | 14:58 |
| lkcl | where that goes to hell in a handbasket is the reverse-mapping | 14:59 |
| lkcl | and it comes down to the fact that the multiple-entries are in fact matching against **TWO** fields | 15:00 |
| lkcl | 1) the XO | 15:00 |
| lkcl | 2) some-other-field-somewhere-else-in-the-binary | 15:00 |
| lkcl | when reconstructing the assembly (disasm) you want the **XO** | 15:01 |
| lkcl | you do **NOT* want the some-other-fields-somewhere | 15:01 |
| lkcl | hence | 15:01 |
| lkcl | the idea of splitting out (2) into a new CSV column. | 15:01 |
| ghostmansd | yield ".long 0x%08x # %s" % (svp64_prefix.insn.value, insn) | 17:03 |
| ghostmansd | Guys you broke it :-) | 17:03 |
| ghostmansd | `sv.bc 2, 9, 8` | 17:04 |
| ghostmansd | ...will lead to disassembly `.long 0x05400000 # sv.bc 2, 9, 8; bc 2, 9, 8 # sv.bc 2, 9, 8` | 17:04 |
| ghostmansd | Ah well, rather this code | 17:07 |
| ghostmansd | lst = '; '.join(lst) | 17:07 |
| ghostmansd | outfile.write("%s%s # %s\n" % (ws, lst, op)) | 17:07 |
| ghostmansd | You now output a lonely long and a large comment | 17:07 |
| ghostmansd | submitted a fix | 17:14 |
| ghostmansd | https://git.libre-soc.org/?p=openpower-isa.git;a=commit;h=1be3f54265d04ded28343c16614bee9c797b44ca | 17:14 |
| ghostmansd | now the comment goes last: `.long 0x05400000; bc 2, 9, 8; # sv.bc 2, 9, 8 # sv.bc 2, 9, 8` | 17:15 |
| ghostmansd | Luke, out of curiosity, why did you dropped the way to start pysvp64asm from __main__? | 17:15 |
| ghostmansd | IMHO if we want to have a unit test covering it, this should go to a separate file. | 17:16 |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC | 17:20 | |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc | 17:41 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC | 18:06 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.41.172> has joined #libre-soc | 18:38 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.41.172> has quit IRC | 18:56 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc | 18:57 | |
| lkcl | ghostmansd, because if you want to run stdin/stdout or pass in options at the commandline that should be "pysvp64asm < filename" | 19:30 |
| lkcl | not | 19:30 |
| lkcl | "python3 sv/trans/svp64.py < filename" | 19:30 |
| lkcl | ghostmansd, the addition of the comment is programmerjake who has not used pysvp64asm before (or written any svp64 unit tests) | 19:31 |
| lkcl | ghostmansd, i feel it's definitely time to cut over the pysvp64dis branch | 19:36 |
| lkcl | extended periods of non-merging makes me very jumpy | 19:37 |
| * lkcl running tests now | 19:41 | |
| lkcl | test_caller_svp64_[predication/dct/fft/matrix/logical/mapreduce/fp/alu] all good so far | 19:43 |
| ghostmansd[m] | Yep, fine with me | 19:45 |
| lkcl | ghostmansd[m], excellent | 19:45 |
| lkcl | just running test_issuer.py as well | 19:45 |
| ghostmansd[m] | I'll rest for today, seems I caught a flu | 19:45 |
| lkcl | ah joy | 19:45 |
| lkcl | i'll do the merge | 19:45 |
| ghostmansd[m] | Thanks! | 19:46 |
| ghostmansd[m] | I recently rebased it IIRC | 19:46 |
| lkcl | yes i saw | 19:46 |
| ghostmansd[m] | So a simple git rebase pysvp64dis should do the trick | 19:46 |
| ghostmansd[m] | In master | 19:46 |
| lkcl | commit b8539167b55f815e7 | 19:46 |
| lkcl | ok whew | 19:46 |
| lkcl | i like easy | 19:46 |
| ghostmansd[m] | Perhaps, I'm AFK, so can neither confirm nor deny it :-) | 19:46 |
| lkcl | : | 19:46 |
| lkcl | :) | 19:46 |
| *** octavius <octavius!~octavius@146.90.27.39> has joined #libre-soc | 19:49 | |
| lkcl | programmerjake, adding the instruction as a comment completely fucks things up | 20:45 |
| lkcl | okaaay re-running everything, test_issuer.py nosvp64 | 20:46 |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC | 20:57 | |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc | 20:58 | |
| lkcl | and every unit test in decoder/isa | 21:00 |
| lkcl | nggggh.... | 21:01 |
| lkcl | okaay the majority of tests pass (enough), pysvpdisasm branch is merged, all good | 22:49 |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC | 23:02 | |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc | 23:03 | |
| lkcl | programmerjake, maxu you'll need to resolve, i had to back out the changes you made as they damaged ISACaller | 23:15 |
| *** octavius <octavius!~octavius@146.90.27.39> has quit IRC | 23:34 | |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!