| *** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC | 00:21 | |
| lkcl | ack. | 00:26 |
|---|---|---|
| lkcl | yyeah it's one of the ones that will fit the multi-pattern thing | 00:27 |
| lkcl | there's a full 32 entries in the CSV file | 00:27 |
| lkcl | otherwise we have to convert the entirety of minor_31.csv XO to "bitpattern" | 00:27 |
| ghostmansd[m] | The issue is with mask. | 00:38 |
| ghostmansd[m] | binutils have the same opcode value. | 00:38 |
| ghostmansd[m] | Anyway, tomorrow. | 00:38 |
| ghostmansd[m] | I suspect it's related to cr_reg and cr_bit, but need to check more. | 00:38 |
| *** octavius <octavius!~octavius@224.147.93.209.dyn.plus.net> has quit IRC | 01:49 | |
| *** sadoon[m] <sadoon[m]!~sadoonunr@2001:470:69fc:105::1:f0fa> has quit IRC | 02:30 | |
| *** jevinskie[m] <jevinskie[m]!~jevinskie@2001:470:69fc:105::bb3> has quit IRC | 02:35 | |
| *** tinybronca[m] <tinybronca[m]!~tinybronc@2001:470:69fc:105::2:1af6> has quit IRC | 02:39 | |
| *** lx0 <lx0!~lxo@gateway/tor-sasl/lxo> has quit IRC | 03:06 | |
| *** lx0 <lx0!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc | 03:07 | |
| *** sadoon[m] <sadoon[m]!~sadoonunr@2001:470:69fc:105::1:f0fa> has joined #libre-soc | 03:19 | |
| *** tplaten <tplaten!~isengaara@55d4441e.access.ecotel.net> has quit IRC | 03:34 | |
| *** tplaten <tplaten!~isengaara@55d44383.access.ecotel.net> has joined #libre-soc | 03:49 | |
| *** lx0 <lx0!~lxo@gateway/tor-sasl/lxo> has quit IRC | 04:01 | |
| *** lx0 <lx0!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc | 04:02 | |
| *** tplaten <tplaten!~isengaara@55d44383.access.ecotel.net> has quit IRC | 05:18 | |
| *** lx0 <lx0!~lxo@gateway/tor-sasl/lxo> has quit IRC | 05:51 | |
| *** lx0 <lx0!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc | 05:52 | |
| *** lx0 <lx0!~lxo@gateway/tor-sasl/lxo> has quit IRC | 05:56 | |
| *** lx0 <lx0!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc | 05:57 | |
| programmerjake | lkcl: reading through transcendentals.mdwn again, I noticed it specifically lists "With thanks to:" and lists everyone but you, implying you wrote the whole thing, which isn't really true. imho it would be better to add you to the list and change the list's title to "Authors/Contributors" or similar, since that doesn't imply only one author. What do you think? | 06:44 |
| lkcl | yep go for it | 06:48 |
| lkcl | good call | 06:48 |
| lkcl | actually it was me who was collating all input, did all the tables, initially. | 06:49 |
| programmerjake | hmm, iirc I did that for the risc-v version | 06:50 |
| lkcl | honestly can't remember. 3+ years ago now (!) | 06:50 |
| programmerjake | I'll change that phrase in the other places it occurs since they probably have the exact same issue | 06:51 |
| lkcl | i remember spending a long time formatting the table with khronos/opencl, and doing the risc-v opcode table | 06:51 |
| lkcl | given you're now working on it i'm happy with "authors" | 06:52 |
| programmerjake | well, not everyone listed actually wrote any of the text, therefore I think contributors is necessary | 06:53 |
| programmerjake | e.g. Andrew Waterman is listed | 06:53 |
| programmerjake | iirc he just supplied some suggestions to the original risc-v one | 06:54 |
| lkcl | yes. as did most people there. | 06:54 |
| lkcl | i collated responses from mailing lists and email. | 06:54 |
| lkcl | they didn't actually do one single edit | 06:55 |
| lkcl | the only people actually authors is you and me. | 06:55 |
| programmerjake | k, I replaced "with thanks to" in openpower/transcendentals.mdwn simple_v_extension/specification.mdwn and ztrans_proposal.mdwn, does that sound good? | 07:10 |
| programmerjake | https://git.libre-soc.org/?p=libreriscv.git;a=commitdiff;h=37181e5b518787335694439350f8d7a6d4a5d444 | 07:12 |
| *** lx0 <lx0!~lxo@gateway/tor-sasl/lxo> has quit IRC | 07:45 | |
| *** lx0 <lx0!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc | 07:46 | |
| *** lx0 <lx0!~lxo@gateway/tor-sasl/lxo> has quit IRC | 07:48 | |
| *** lx0 <lx0!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc | 07:48 | |
| *** lx0 <lx0!~lxo@gateway/tor-sasl/lxo> has quit IRC | 07:53 | |
| *** lx0 <lx0!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc | 07:55 | |
| *** lx0 <lx0!~lxo@gateway/tor-sasl/lxo> has quit IRC | 08:12 | |
| *** lx0 <lx0!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc | 08:13 | |
| *** lx0 <lx0!~lxo@gateway/tor-sasl/lxo> has quit IRC | 08:53 | |
| *** lx0 <lx0!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc | 08:54 | |
| *** lx0 <lx0!~lxo@gateway/tor-sasl/lxo> has quit IRC | 09:14 | |
| *** lx0 <lx0!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc | 09:15 | |
| programmerjake | ghostmansd: sorry -- more fptrans ops, we forgot to add them to fptrans, so I just now added them to fptrans, they still need to be allocated XO values and added to the CSVs, see https://bugs.libre-soc.org/show_bug.cgi?id=899#c0 and https://bugs.libre-soc.org/show_bug.cgi?id=923 | 09:31 |
| *** jevinskie[m] <jevinskie[m]!~jevinskie@2001:470:69fc:105::bb3> has joined #libre-soc | 10:03 | |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc | 10:24 | |
| ghostmansd | lkcl, what the merged value and mask you'd expect here? https://pastebin.com/mREefx6L | 11:01 |
| ghostmansd | This is what we get now: FieldsOpcode(value=0x7c00001e, mask=0xfc0007fe) | 11:03 |
| ghostmansd | The fields we look at are: [(0x0000001f, [0:5]), (0x0000000f, [21:30])] | 11:04 |
| ghostmansd | I found that we don't use suffix field from insndb. What'd be the right way to use it? | 11:06 |
| ghostmansd[m] | minor_31 table is the only one which uses suffix. lkcl, it'd be great if you could explain what suffix is and how to adopt it to "opcode" function and FieldsOpcodeClass. | 11:32 |
| ghostmansd | minor_31.csv,31,21:30,0b101,integer | 11:44 |
| ghostmansd | 0b0000001111,CR,OP_ISEL,RA_OR_ZERO,RB,NONE,RT,BC,NONE,0,0,ZERO,0,NONE,0,0,0,0,0,0,NONE,0,1,isel,A, | 11:44 |
| ghostmansd | 0b0000101111,CR,OP_ISEL,RA_OR_ZERO,RB,NONE,RT,BC,NONE,0,0,ZERO,0,NONE,0,0,0,0,0,0,NONE,0,1,isel,A, | 11:44 |
| sadoon[m] | My debian repo mirror seems incomplete but just adding it locally has sped up builds while I work on completing the mirror | 12:02 |
| sadoon[m] | It's now churning | 12:02 |
| sadoon[m] | Do we have gcc that builds for ppc64le without any vector extensions by any chance? | 12:02 |
| sadoon[m] | I also forgot to add ccache but that can be done later | 12:03 |
| sadoon[m] | lkcl: forgot to tag you re: gcc without vectors | 12:03 |
| lkcl | sadoon[m], gis a min to answer ghostmansd | 12:41 |
| sadoon[m] | sure | 12:41 |
| lkcl | ghostmansd, ok isel p89 section 3.3.12 | 12:41 |
| lkcl | 15 / | 12:41 |
| lkcl | 26 31 | 12:41 |
| lkcl | so bits 26:30 = 15 | 12:42 |
| lkcl | there are 32 entries with bits 21:25 cycling *right* the way through 00000 to 11111 | 12:42 |
| lkcl | so we can deduce that the idea there is, "ignore the BC field bits 21:26" | 12:43 |
| lkcl | BC | 12:43 |
| lkcl | 21 26 | 12:43 |
| lkcl | therefore | 12:43 |
| lkcl | mask = 26:30 == 0b111111 | 12:43 |
| lkcl | val = 26:30 == 0b011111 | 12:43 |
| lkcl | sadoon[m], you just specify -mnoaltivec -mnovsx | 12:44 |
| sadoon[m] | Unfortunately as you know, with debian that is almost impossible to guarantee to work | 12:44 |
| lkcl | no we don't have a pre-compiled gcc which has those as defaults | 12:44 |
| sadoon[m] | Certain packages will not abide | 12:44 |
| sadoon[m] | But that can be done I assume right? | 12:45 |
| lkcl | build a version of gcc that has those as defaults? i don't see why not | 12:45 |
| sadoon[m] | awesome | 12:45 |
| lkcl | it has to be done at some point | 12:45 |
| lkcl | its prefix should be | 12:45 |
| lkcl | ppc64lesffs- | 12:46 |
| sadoon[m] | I'll handle it when building specifically for libre-soc | 12:46 |
| lkcl | SFFS is the name of the Compliance Level | 12:46 |
| sadoon[m] | nice | 12:46 |
| lkcl | Scalar Fixed Floatingpoint Subset | 12:46 |
| lkcl | there's also SFS which is without FP but we're not going that far :) | 12:46 |
| lkcl | watch out for Quad-Floating-Point which has to be dropped as well | 12:47 |
| lkcl | sorry | 12:47 |
| lkcl | powerpc64lesffs-linux-gnu- | 12:47 |
| lkcl | that's the triplet | 12:47 |
| lkcl | -mfloat128 Enable IEEE 128-bit floating point via the | 12:48 |
| lkcl | __float128 keyword. | 12:48 |
| lkcl | -mfloat128-hardware Enable using IEEE 128-bit floating point | 12:48 |
| sadoon[m] | Alright | 12:49 |
| lkcl | so probably | 12:49 |
| lkcl | -mno-float128-hardware at the very least | 12:49 |
| lkcl | toshywoshy, how did you deal/cope with this? :) | 12:49 |
| sadoon[m] | so -mnoaltivec -mnosvx -mno-float128-hardware | 12:49 |
| lkcl | yes almost definitely except -mnovsx not nosvx :) | 12:50 |
| sadoon[m] | right :P | 12:50 |
| lkcl | if you drop __float128 keyword that might cause problems | 12:50 |
| lkcl | but see how it goes | 12:50 |
| sadoon[m] | probably the software that will heavily depend on that stuff is things like ffmpeg and co. | 12:51 |
| toshywoshy | so I have been working on pcc64lesffs | 12:51 |
| sadoon[m] | I don't think it'll be a problem to start, considering the goal is a usable linux system at first | 12:51 |
| toshywoshy | it will be a miniroot, at least that is what I am calling it for now | 12:52 |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC | 12:55 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.42.170> has joined #libre-soc | 12:55 | |
| toshywoshy | I build with "-mnoaltivec -mnovsx -mnodirect-move -mnocrypto -mnoquad-memory -mnoquad-memory-atomic -mnopower8-fusion -mnovrsave -mnofloat128 -mnofloat128-hardware -mnoisel -mnohtm" | 12:56 |
| ghostmansd[m] | lkcl, what'd be the right way to fix it in generic way with FieldsOpcode and `def opcode`? | 12:57 |
| toshywoshy | that is what I found in gcc documentation and as it is building on a stripped down qemu, I want to be specific for now | 12:57 |
| ghostmansd[m] | I thought about adopting the mask, so that all its fields where dynamic operands are, become zeroes | 12:58 |
| ghostmansd[m] | But this is sort of hack | 12:58 |
| ghostmansd[m] | Also, it's strange that we have opcode range 21:30, but some fields are occupied by operands | 12:59 |
| lkcl | yes. | 12:59 |
| lkcl | think again in terms of switch/case statements | 12:59 |
| lkcl | if *all* 32 permutations cover BC then it is *as if* there was only the one | 12:59 |
| lkcl | it's not a hack | 13:00 |
| lkcl | it's a special-case that really does need to be detected | 13:00 |
| lkcl | .... yes. | 13:00 |
| lkcl | it can be done with sets | 13:00 |
| ghostmansd[m] | So you think that, when we construct opcode from fields, we need the way to tell "but hey, for this particular instruction, exclude this and that range from mask and opcode, operands are here" | 13:01 |
| ghostmansd[m] | Is it right? | 13:01 |
| lkcl | i think it can be algorithmically detected to reduce the mask | 13:02 |
| lkcl | it shouldn't have to be hard-coded/special-cased | 13:02 |
| lkcl | it *should* be possible to do 1 bit at a time, repeated recursively | 13:03 |
| lkcl | group by things-that-match-zero and things-that-match-one | 13:03 |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.42.170> has quit IRC | 13:04 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.42.170> has joined #libre-soc | 13:04 | |
| lkcl | i know there's an algorithm somewhere in there :) | 13:04 |
| ghostmansd | lkcl, I didn't mean some special case for isel. I mean that we'd do this for any instruction. | 13:07 |
| ghostmansd | There are no groups or recursion needed, though, and doesn't seem like any required. | 13:08 |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.42.170> has quit IRC | 13:08 | |
| lkcl | yes. | 13:08 |
| lkcl | yes agreed: for any instruction. | 13:09 |
| lkcl | the "gotcha" you have to watch out for: svshape would *not* be reduced-mask | 13:09 |
| lkcl | that's the kicker, it's the one to watch out for | 13:09 |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc | 13:09 | |
| lkcl | because the two combinations in the middle, 0b1000 and ob1001 | 13:10 |
| lkcl | toshywoshy, are you able to help / participate in a non-confidential opcode with general topics "how to reduce opcode pressure" discussion before tuesday 13th? | 13:12 |
| ghostmansd | > because the two combinations in the middle, 0b1000 and ob1001 | 13:12 |
| lkcl | i know it's short notice | 13:13 |
| lkcl | ghostmansd, those two are allocated to svshape2. | 13:13 |
| ghostmansd | I'll check these specifically | 13:13 |
| ghostmansd | but these should be fine, since, again, this is on a per-insn basis | 13:13 |
| ghostmansd | the names are different and we have multirecord for both svshape and svshape2 | 13:13 |
| ghostmansd | these don't overlap in insndb | 13:14 |
| lkcl | i *know* there's an algorithm that can spot redundant mask-bits. it shouldn't be necessary to hack it special-case | 13:14 |
| ghostmansd | or, well, shouldn't | 13:14 |
| ghostmansd | OK let me play around this code | 13:14 |
| lkcl | i know. | 13:14 |
| lkcl | ha. | 13:14 |
| lkcl | ok so you have the single-value, right? | 13:15 |
| lkcl | you've found all the "common" bits. | 13:15 |
| lkcl | the common bits between these | 13:15 |
| lkcl | 0101-011001,VL, | 13:15 |
| lkcl | 0110-011001,VL,O | 13:15 |
| lkcl | 1011-011001,VL,OP | 13:15 |
| lkcl | it's | 13:15 |
| lkcl | -----011001 | 13:15 |
| lkcl | so it's dead simple: | 13:15 |
| lkcl | mask that out (in a temporary) | 13:16 |
| lkcl | and you are left with analysing | 13:16 |
| lkcl | 0101------ | 13:16 |
| lkcl | 9110------ | 13:16 |
| lkcl | 1011------- | 13:16 |
| lkcl | now | 13:16 |
| lkcl | what you *then* do is also very simple | 13:16 |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC | 13:16 | |
| lkcl | first you count the number of bits (4) in this case | 13:17 |
| lkcl | so you know to expect 16 permutations. | 13:17 |
| lkcl | and | 13:17 |
| lkcl | you also know therefore that there will be 8 with zero and 8 with 1 | 13:17 |
| lkcl | therefore | 13:17 |
| lkcl | you can take the 1st bit, and break down into 2 lists | 13:18 |
| lkcl | one where bit 0 is 0 | 13:18 |
| lkcl | one where bit 0 is 1 | 13:18 |
| lkcl | if they are *EXACTLY* 8 in each list: | 13:18 |
| lkcl | ta-daaaaa you can ELIMINATE that mask-bit | 13:18 |
| lkcl | now you are at | 13:18 |
| lkcl | -101------ | 13:18 |
| toshywoshy | lkcl: yes I think so, I am in the middle of some other work, but in about 2 hours that should be done | 13:18 |
| lkcl | -110------ | 13:18 |
| lkcl | toshywoshy, an initial call with you would be good then we need to arrange a team time. can you send calendar/zoom/jitsi/whatever invite to me and david? | 13:19 |
| lkcl | (when you're ready) | 13:19 |
| lkcl | ghostmansd, then you can move to the next bit | 13:19 |
| lkcl | for isel i expect that algorithm to *succeed* and wipe out all 32 entries | 13:20 |
| lkcl | for svshape/svshape2 it should *fail* because svshape2. | 13:20 |
| lkcl | the number of entries will be *7* when they should be *8* | 13:20 |
| lkcl | ta-daaa :) | 13:20 |
| ghostmansd | Frankly cutting out dynamic operands looks by order of magnitude simpler | 13:21 |
| lkcl | awww i really liked that algorithm | 13:23 |
| lkcl | it's almost certainly a recipe somewhere online | 13:23 |
| ghostmansd | isel (6, 7, 8, 9, 10) | 13:29 |
| ghostmansd | isel (11, 12, 13, 14, 15) | 13:29 |
| ghostmansd | isel (16, 17, 18, 19, 20) | 13:29 |
| ghostmansd | isel (21, 22, 23, 24, 25) | 13:29 |
| ghostmansd | that's dynamic operand ranges for isel | 13:29 |
| ghostmansd | I guess if we cut out these bits from the result mask then we're done | 13:30 |
| lkcl | no, it's only (21, 22, 23, 24, 25). the field named "BC" | 13:30 |
| ghostmansd | this is generic, we can get operands for any instruction | 13:30 |
| lkcl | the others are ignored | 13:31 |
| ghostmansd | I speak about ignored | 13:31 |
| lkcl | ah yes :) | 13:31 |
| lkcl | ah... no | 13:31 |
| lkcl | (21, 22, 23, 24, 25) *isn't* ignored... but should be | 13:31 |
| ghostmansd | all should be ignored | 13:32 |
| lkcl | the algorithm above will auto-identify them | 13:32 |
| lkcl | yyes true | 13:32 |
| lkcl | i mean | 13:32 |
| ghostmansd | but current code assumes that BC is part of opcode | 13:32 |
| lkcl | insn_db.csv minor_31 entry *already* ignores 6..20 | 13:32 |
| ghostmansd | exactly because it doesn't give a shit about dynamic operands | 13:32 |
| ghostmansd | Well in this sense yes | 13:32 |
| lkcl | minor_31.csv,31,21:30,0b101,integer | 13:32 |
| ghostmansd | 0b0000001111,CR,OP_ISEL,RA_OR_ZERO,RB,NONE,RT,BC,NONE,0,0,ZERO,0,NONE,0,0,0,0,0,0,NONE,0,1,isel,A, | 13:32 |
| ghostmansd | but it doesn't ignores first bits here ^ | 13:32 |
| lkcl | which from insndb.csv is bits 21-30 | 13:33 |
| ghostmansd | it thinks, "oh my, you shown these as opcode!" | 13:33 |
| ghostmansd | and puts these as an established value/mask for opcode | 13:33 |
| ghostmansd | never giving a single fuck about the fact these are operands | 13:33 |
| ghostmansd | because, well, all entries in minor_31.csv have 9 bits | 13:34 |
| ghostmansd | they don't have a way to tell the code "hey, you know what, isel has some of these shiny 21:30 bits reserved for operands" | 13:34 |
| lkcl | 10 :) | 13:34 |
| ghostmansd | can you follow me | 13:34 |
| lkcl | 21-30 inclusive :) | 13:34 |
| ghostmansd | ? | 13:34 |
| ghostmansd | yehyeh | 13:34 |
| ghostmansd | no matter | 13:34 |
| ghostmansd | I don't even think about count | 13:34 |
| lkcl | there are only two types of problems in computing | 13:35 |
| ghostmansd | but still, do you get what I mean? | 13:35 |
| lkcl | overflow | 13:35 |
| lkcl | binary | 13:35 |
| ghostmansd | yeah | 13:35 |
| lkcl | and off-by-one errors | 13:35 |
| ghostmansd | MSB0: things done simple | 13:35 |
| ghostmansd | (except for the fact they're not) | 13:35 |
| * lkcl MSB0 headbanging | 13:35 | |
| lkcl | ok so what's the quick-hack? | 13:36 |
| ghostmansd | I think checking which bits are for dynamic operands is the best shot | 13:36 |
| lkcl | ahh right | 13:36 |
| ghostmansd | we already consider static operands to explicitly toggle some bits to be parts of opcode | 13:36 |
| lkcl | so you use the fact that it's 32 entries fitting the full 5 bits of BC? | 13:36 |
| lkcl | 2^5=32 | 13:37 |
| lkcl | BLAT | 13:37 |
| ghostmansd | I don't understand the question | 13:37 |
| ghostmansd | anyway, as I mentioned | 13:37 |
| lkcl | BC is bits 21:25 | 13:37 |
| lkcl | isel RT,RA,RB,BC | 13:37 |
| lkcl | 31 RT RA RB BC 15 / | 13:37 |
| lkcl | 0 6 11 16 21 26 31 | 13:37 |
| ghostmansd | current code just blindly takes the whole opcode it got from csv | 13:37 |
| ghostmansd | and doesn't bother to check whether it should use all bits there | 13:38 |
| ghostmansd | the whole CSV structure implies it should | 13:38 |
| ghostmansd | but in fact for isel (maybe others too) some of these fields are _not_ opcode | 13:38 |
| lkcl | yes. | 13:38 |
| ghostmansd | or, well, some of these _bits_ correspond to _operands_ | 13:38 |
| ghostmansd | so this is the reason why the algorithm as it stands is incorrect | 13:39 |
| ghostmansd | and leads to wrong results | 13:39 |
| lkcl | yes. and you have to have *exactly* 2^{length-of-operand} entries in the switch/case to say so | 13:39 |
| lkcl | it is *guaranteed* that to get that field to be ignored you *absolutely must* have 2^{length-of-operand} entries in the database | 13:39 |
| lkcl | BC is 5 bits | 13:39 |
| lkcl | therefore there are 2^5=32 entries | 13:40 |
| lkcl | svshape is 4 bits | 13:40 |
| lkcl | therefore there should be 2^4=16 entries but there are *NOT* 16 entries there are only 14. | 13:40 |
| ghostmansd | again: it has nothing to do with BC or isel or svshape; this is a general fault. | 13:40 |
| ghostmansd | The code _must_ consider which operands are present in mask (static, those which are _part_ of the opcode) | 13:41 |
| ghostmansd | ...and which are absent (dynamic) | 13:41 |
| lkcl | indeed. so that was why i suggested the algorithm for auto-detecting the dynamic parts | 13:41 |
| ghostmansd | This is not obvious. | 13:41 |
| lkcl | the current scheme has already detected the static part | 13:41 |
| lkcl | i know :) i'm thinking it through, sitting here with a monster headache, sigh | 13:42 |
| ghostmansd | However, when you see below "if bit is in static_operand: mask[bit] = 1" | 13:42 |
| lkcl | (not a metaphor) | 13:42 |
| ghostmansd | then if you see "if bit in dynamic_operand: mask[bit] = 0" | 13:42 |
| ghostmansd | it is crystal clear what happens | 13:42 |
| lkcl | yes. | 13:42 |
| lkcl | i think we are likely talking about exactly the same thing | 13:42 |
| ghostmansd | especially if you recall you're in the code which constructs the opcode and its mask | 13:43 |
| ghostmansd | yeah likely | 13:43 |
| ghostmansd | but in different terms | 13:43 |
| lkcl | tell you what, go for it. | 13:43 |
| * lkcl have to get on, lots to do | 13:43 | |
| ghostmansd | give yourself a rest | 13:43 |
| ghostmansd | there's no point working if you're exhausted | 13:44 |
| ghostmansd | I'll think how to make this code good. We have even more reasons to do it. | 13:49 |
| ghostmansd | You probably recall pysvp64asm custom instructions? | 13:49 |
| ghostmansd | There's no point at all in them at this stage. And, cough, even in outputting "vanilla" instructions. | 13:50 |
| ghostmansd | We have _that_ much information that we can build a real assembler. | 13:50 |
| ghostmansd | Or well, in our case, rather, translator. | 13:50 |
| ghostmansd | This needs at least assemble() method for each operand type, but, other than that, it's almost near. | 13:51 |
| *** octavius <octavius!~octavius@244.147.93.209.dyn.plus.net> has joined #libre-soc | 13:52 | |
| lkcl | hooraaay | 13:58 |
| ghostmansd | That said, I won't do it in this scope, this still a damn big task and I cannot be distracted at this point. | 14:00 |
| lkcl | nnope | 14:03 |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc | 14:07 | |
| ghostmansd | sigh | 14:40 |
| ghostmansd | Luke you don't really have to do this whitespace cleanup this way | 14:40 |
| ghostmansd | I do it the way I did for a reason | 14:40 |
| ghostmansd | in no way this is a cleanup, it actually hurts | 14:40 |
| ghostmansd | - sv_extra, field = crf_extra(etype, | 14:41 |
| ghostmansd | - rname, extra_idx, regmode, field, extras) | 14:41 |
| ghostmansd | + sv_extra, field = crf_extra(etype, rname, extra_idx, | 14:41 |
| ghostmansd | + regmode, field, extras) | 14:41 |
| ghostmansd | Now assume the name of the function changes | 14:41 |
| ghostmansd | Or the return value changes | 14:41 |
| ghostmansd | What next? Yet another cleanup? | 14:41 |
| ghostmansd | Please stop doing this, it _hurts_ the maintainability. | 14:41 |
| ghostmansd | You literally force to do work twice. | 14:42 |
| ghostmansd | Simply indent one level, that's simple and sweet. In some cases -- two (e.g. split if statement). | 14:42 |
| ghostmansd | If the editor does it for you, please, replace this option with something sane. | 14:47 |
| ghostmansd | Found more issues in our CSVs with insndb: rldcl/rldcr should have MDS form. Pushed to master. | 15:00 |
| lkcl | ghostmansd, it's actually an alignment with autopep8 - the bracket is the marker - and after 20 years i've gotten used to it | 15:00 |
| lkcl | i've always been confused by non-vertical-whitespace-layout (over 25 years) | 15:01 |
| ghostmansd | Not anything written in pep8 should be considered as ultimate guide. | 15:01 |
| lkcl | ooo MD/MDS-Form mistake, ooo | 15:01 |
| lkcl | let me double-check that | 15:01 |
| ghostmansd | It's MDS in spec. | 15:02 |
| ghostmansd | And MDS in mdwn. | 15:02 |
| lkcl | ahh okaay. | 15:02 |
| ghostmansd | We should cross-check it, too. | 15:02 |
| lkcl | yes i remember adding the Forms to CSV, by hand | 15:02 |
| ghostmansd | Perhaps one day I'll add some validation inside the record. | 15:02 |
| lkcl | Rotate Left Doubleword then Clear Left | 15:02 |
| lkcl | MDS-form | 15:02 |
| lkcl | rldcl | 15:02 |
| lkcl | Rotate Left Doubleword then Clear Right | 15:03 |
| lkcl | MDS-form | 15:03 |
| lkcl | rldcr | 15:03 |
| lkcl | yep all good | 15:03 |
| lkcl | let me re-run unit tests to make absolutely sure | 15:03 |
| ghostmansd | I wouldn't have pushed any change in CSVs to master otherwise. | 15:03 |
| ghostmansd | This bit is too critical to fuck up. | 15:03 |
| lkcl | ohh yes | 15:03 |
| ghostmansd | Perhaps there are more, I'm still checking. This is slow and annoying process. | 15:04 |
| ghostmansd | Found by an accident, now re-using the same happy accident over and over again. | 15:04 |
| lkcl | now imagine what it was like the first time | 15:04 |
| lkcl | when there were like 25+ mistakes / missing-things in the v3.0B spec... | 15:04 |
| lkcl | it's taken months - so don't make it a critical-path priority | 15:05 |
| ghostmansd | It's currently a show stopper if there are some fields declared but not present. | 15:07 |
| ghostmansd | This was exactly how I found it -- RB was reported in operands but was missing in fields. | 15:07 |
| ghostmansd | So I checked the form, and -- boom! -- it was wrong. | 15:07 |
| ghostmansd | This now has to be priority #1. No other option. | 15:07 |
| lkcl | urk | 15:09 |
| lkcl | ha, this is actually good | 15:09 |
| lkcl | hmmm | 15:09 |
| lkcl | a suite of instructions is needed. unit-test style. using openpower/simulator/program.py's Program() generate_instructions() function | 15:10 |
| lkcl | and throwing them through pysvp64dis | 15:10 |
| ghostmansd | andi./andis. are wrong too | 15:11 |
| lkcl | urrrr | 15:11 |
| ghostmansd | they should've been D form | 15:11 |
| ghostmansd | AND Immediate Shifted D-form | 15:11 |
| ghostmansd | AND Immediate D-form | 15:11 |
| lkcl | want me to do it? | 15:11 |
| ghostmansd | no that's fine | 15:11 |
| lkcl | ok | 15:11 |
| ghostmansd | it's actually good because it helps me somewhat to ensure all operands/fields are OK | 15:11 |
| lkcl | yehyeh | 15:11 |
| ghostmansd | I'm basically running my code and whenever it fails look at the spec | 15:11 |
| lkcl | y'know what? i'll write that mini-test-program | 15:12 |
| ghostmansd | which one? | 15:12 |
| lkcl | it won't take 5 mins | 15:12 |
| ghostmansd | you mean validation? | 15:12 |
| lkcl | test_pysvp64dis.py using program.py's Program() | 15:12 |
| lkcl | and an SVP64Asm() instance | 15:12 |
| ghostmansd | aaaah | 15:12 |
| ghostmansd | this one | 15:12 |
| ghostmansd | good thing, appreciate that | 15:13 |
| ghostmansd | ternlogi is fucked too | 15:13 |
| ghostmansd | I'm currently checking why | 15:14 |
| ghostmansd | eeeeeehm what the | 15:14 |
| ghostmansd | all of RT/RA/RB are empty | 15:14 |
| lkcl | 1 sec | 15:15 |
| ghostmansd | ??? | 15:15 |
| ghostmansd | no TLI form?? | 15:15 |
| ghostmansd | ah yeah here it is | 15:15 |
| ghostmansd | hm this one should be fine, what the hell | 15:16 |
| ghostmansd | ternlogi | 15:16 |
| ghostmansd | Form.TLI | 15:16 |
| ghostmansd | DynamicOperandGPR(name='RT') | 15:16 |
| ghostmansd | DynamicOperandGPR(name='RA') | 15:16 |
| ghostmansd | DynamicOperandGPR(name='RB') | 15:16 |
| ghostmansd | DynamicOperand(name='TLI') | 15:16 |
| ghostmansd | [(True, 0x00000005, [0:5]), (True, 0x00000000, [21:31]), (False, 0, None), (False, 0, None), (False, 0, None), (False, 0, (21, 22, 23, 24, 25, 26, 27, 28))] | 15:16 |
| ghostmansd | None stands for "hey I couldn't find the operand in fields.text" | 15:16 |
| lkcl | gimme sec | 15:16 |
| ghostmansd | sure | 15:17 |
| lkcl | yep i know why | 15:17 |
| lkcl | not added to fields.txt | 15:17 |
| ghostmansd | ah, RT needs Formats: TLI | 15:17 |
| ghostmansd | yep? | 15:17 |
| lkcl | on it | 15:17 |
| ghostmansd | OK :-) | 15:18 |
| ghostmansd | I also understood already | 15:18 |
| ghostmansd | feel free to push, ping me to rebase my branch | 15:18 |
| ghostmansd | all three, RT, RA, RB | 15:18 |
| lkcl | done | 15:19 |
| ghostmansd | thanks! | 15:21 |
| ghostmansd | OK, more: rldicl, setb, svshape2, fishmv | 15:41 |
| ghostmansd | please especially check fishmv changes: I had to introduce the field based on how I understood what it does | 15:42 |
| lkcl | ermmm.ermermerm... | 15:43 |
| lkcl | nope can't do that | 15:43 |
| lkcl | 1 sec | 15:44 |
| lkcl | ok "D" is one of those exceptions, like target_addr and DCMX | 15:44 |
| ghostmansd | fp32[16:31] <- d0 || d1 || d2 | 15:45 |
| ghostmansd | How comes? | 15:45 |
| lkcl | yes. so that's why d0 d1 d2 exist | 15:45 |
| lkcl | but | 15:45 |
| lkcl | like target_addr | 15:45 |
| ghostmansd | but this is the same | 15:45 |
| ghostmansd | as concatenating these | 15:45 |
| lkcl | the "D" is... | 15:45 |
| lkcl | yes it is (that's deliberate) | 15:45 |
| lkcl | but D is in a totally different order | 15:46 |
| ghostmansd | what do you mean? | 15:46 |
| lkcl | d0,d1,d2 (16:25,11:15,31) | 15:46 |
| lkcl | Immediate fields that are concatenated to specify a | 15:46 |
| lkcl | 16-bit signed two's complement integer which is | 15:46 |
| lkcl | sign-extended to 64 bits. | 15:46 |
| lkcl | Formats: DX | 15:46 |
| ghostmansd | declaring one huge D in order as d0,d1,d2 are followed looks the same | 15:47 |
| lkcl | note d0 d1 d2 | 15:47 |
| lkcl | note the bit-order | 15:47 |
| ghostmansd | Aaah fuck | 15:47 |
| lkcl | d0 = 16:25 | 15:47 |
| lkcl | ... | 15:47 |
| ghostmansd | yeah now I see | 15:47 |
| lkcl | yyep | 15:47 |
| ghostmansd | Hm | 15:47 |
| lkcl | has to be a custom field, like target_addr | 15:47 |
| ghostmansd | Why don't simply use D? | 15:47 |
| lkcl | because that doesn't match with existing HDL | 15:47 |
| lkcl | which would mean an addition of MUXes | 15:48 |
| ghostmansd | it has to do with some hardware limitations? | 15:48 |
| lkcl | which is expensive in gates | 15:48 |
| lkcl | whereas | 15:48 |
| lkcl | using the *existing* d0||d1||d2 | 15:48 |
| lkcl | that HDL path (existing gates) can be used | 15:48 |
| ghostmansd | OK gotcha | 15:48 |
| lkcl | it's not like software | 15:48 |
| ghostmansd | OK then, please update it as you mentioned above | 15:48 |
| lkcl | done, i reverted the addition of D | 15:48 |
| lkcl | it has to be done like target_addr. | 15:49 |
| lkcl | there will be... maybe 1-2 more like that | 15:49 |
| lkcl | ,0,svshape2,SVM2,,1 | 15:49 |
| ghostmansd | please keep the commit name! | 15:49 |
| lkcl | well spotted | 15:49 |
| ghostmansd | this is totally essential | 15:49 |
| ghostmansd | otherwise won't work | 15:49 |
| ghostmansd | won't move | 15:50 |
| lkcl | huhn? don't quite follow | 15:50 |
| ghostmansd | Author: Dmitry Selyutin <ghostmansd@gmail.com> | 15:50 |
| ghostmansd | Date: Fri Sep 9 17:28:30 2022 +0300 | 15:50 |
| ghostmansd | 15:50 | |
| ghostmansd | fields.text: this fish ain't moving | 15:50 |
| lkcl | do you mean "when running git revert xyz"? | 15:50 |
| ghostmansd | ah OK it's kept | 15:50 |
| ghostmansd | just wanted to keep it for lulz | 15:51 |
| lkcl | :) | 15:51 |
| ghostmansd | OK I think I went through all of them | 15:51 |
| ghostmansd | please ping me when fish moves | 15:52 |
| lkcl | it's done. | 15:52 |
| lkcl | you'll need to now add it as a custom field | 15:52 |
| lkcl | like target_addr | 15:52 |
| ghostmansd | Ah OK | 15:53 |
| lkcl | when any other d0||d1||d2 instruction comes along, the same custom-D-Field will be needed there, too | 15:53 |
| lkcl | addpcis | 15:54 |
| lkcl | D <- d0||d1||d2 | 15:54 |
| lkcl | that's where i got the idea for d0/1/2 from | 15:54 |
| lkcl | huhn? | 15:56 |
| lkcl | enumerating the list of instructions from load() actually manages to... ahh the file needs a seek back to zero | 15:56 |
| lkcl | i need to add a "short" option to insn.disassemble() | 16:00 |
| lkcl | to get only the operation, not the hex | 16:00 |
| ghostmansd | what do you mean by operation? | 16:01 |
| ghostmansd | ah got it | 16:01 |
| lkcl | 19 24 2f 5b svshape2 12,1,15,4,0,0 | 16:01 |
| lkcl | i need just | 16:01 |
| lkcl | svshape2 12,1,15,4,0,0 | 16:01 |
| ghostmansd | better add some method perhaps | 16:01 |
| ghostmansd | bu up to you | 16:01 |
| lkcl | btw there's an off-by-one on that 4 (should have been 5) | 16:02 |
| lkcl | but that's not surprising, it's one of those SVd thingies | 16:02 |
| ghostmansd | there's already verbose argument | 16:02 |
| ghostmansd | yes | 16:02 |
| lkcl | i need a "totally short" arg | 16:02 |
| ghostmansd | this will need a separate operand | 16:02 |
| ghostmansd | lol | 16:02 |
| lkcl | indeed. later | 16:02 |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC | 16:09 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.42.55> has joined #libre-soc | 16:10 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.42.55> has quit IRC | 16:18 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.42.55> has joined #libre-soc | 16:18 | |
| ghostmansd[m] | Perhaps we need level | 16:19 |
| ghostmansd[m] | Not short and verbose | 16:19 |
| programmerjake | turns out SVP64-Single is in the wiki, gitweb grep is case sensitive (with no apparent option for case insensitive). it still has no explanation of what it actually does tho... | 16:19 |
| ghostmansd[m] | Please do it as enum | 16:19 |
| lkcl | ghostmansd[m], i'm in a rush, i'll get to it later if you suggest something better | 16:20 |
| lkcl | programmerjake, yes correct. it's to make it possible to reach all the regs | 16:21 |
| lkcl | and is a *scalar*-only instruction (single, duh) | 16:21 |
| lkcl | but can still have predication (one bit) | 16:21 |
| lkcl | and element-width overrides | 16:21 |
| lkcl | only single-predication not twin-predication | 16:22 |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.42.55> has quit IRC | 16:22 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc | 16:23 | |
| programmerjake | hmm, ok...imho it wouldn't need a full 24-bit rm then, 20-ish bits should be completely sufficient, and save tons of encoding space | 16:23 |
| lkcl | unfortunately 4-bits per reg are needed (CR fields) | 16:24 |
| lkcl | so that's a minimum 4x3 = 12 bits | 16:24 |
| programmerjake | i was counting 12-bits of reg fields -- 3 each for 4 madd args | 16:25 |
| ghostmansd | def disassemble(self, insn, record, field, verbose=False, indent="", | 16:25 |
| ghostmansd | short=False): | 16:25 |
| ghostmansd | Luke will you PLEASE stop doing this?? | 16:25 |
| ghostmansd | FUCK | 16:25 |
| lkcl | ghostmansd, i don't know what convention you need me to use | 16:25 |
| lkcl | and i'm on the clock | 16:25 |
| lkcl | so i must apologise, but please don't go nuts about it - please be patient and just set them to what you want/need | 16:26 |
| ghostmansd | exactly as I asked: simply indent 1 level, 2 if there's something indented below | 16:26 |
| lkcl | i *have* to keep to under 80 chars | 16:26 |
| ghostmansd | Yes but not the cost of turning it into a crap | 16:26 |
| ghostmansd | sigh | 16:26 |
| ghostmansd | I'll fix it | 16:26 |
| lkcl | but this is a completely different convention from everything i've used for 20 years | 16:26 |
| lkcl | appreciated. | 16:27 |
| lkcl | got meeting in 3mins hence why i'm rushing | 16:27 |
| ghostmansd | you don't need short everywhere BTW :-) | 16:27 |
| ghostmansd | Aaaah I see, you used it in operands too | 16:27 |
| programmerjake | imho it's better to just use autopep8 and not argue with each other about it...even if it's not our favorite, it's mostly consistent and automated... | 16:28 |
| programmerjake | and because it's the de-facto python style, most will have an easier time reading it | 16:30 |
| ghostmansd | it turns code into the shit with these idiotic spaces | 16:30 |
| ghostmansd | so no, it's not | 16:30 |
| ghostmansd | if there's an option to tune it -- I'm OK | 16:31 |
| programmerjake | lkcl: if your meeting's about opcode space, please look at https://bugs.libre-soc.org/show_bug.cgi?id=924#c1 | 16:31 |
| ghostmansd | Don't even try to convince me this is readable | 16:33 |
| ghostmansd | def disassemble(self, insn, record, verbose=False, prefix="", indent="", | 16:33 |
| ghostmansd | short=False): | 16:33 |
| programmerjake | i actually think all the indentation is better because both it's visually lined up with other relevant parts, and it's automated so you don't have to manually line anything up | 16:33 |
| ghostmansd | it is NOT | 16:33 |
| ghostmansd | and it's not maintainable | 16:33 |
| programmerjake | well, if i were reading this in a monospace font, it looks fine to me... | 16:34 |
| ghostmansd | again: unless this is enforced by repository, I won't support it | 16:34 |
| ghostmansd | OK put it to monospace font | 16:34 |
| ghostmansd | what the fuck do you think I have in editor, Comic Sans? | 16:34 |
| ghostmansd | obviously it's monospace | 16:34 |
| programmerjake | no, i meant in irc | 16:34 |
| ghostmansd | it looks awful anywhere | 16:35 |
| ghostmansd | again: if you want me to follow this idiotic pattern, then enforce it | 16:35 |
| ghostmansd | otherwise I won't do something which makes code less readable in my opinion | 16:35 |
| programmerjake | uuh, is that really what autopep8 put out? looks like it's missing some spaces on the first line you posted... | 16:37 |
| programmerjake | the arguments on the 2nd line are supposed to be lined up with the lparen or the comma after self... | 16:37 |
| ghostmansd | src/openpower/decoder/power_insn.py:600 | 16:37 |
| ghostmansd | perhaps that's not autopep8 | 16:38 |
| ghostmansd | anyway, if autopep8 aligns in a similar fashion, this is wrong | 16:38 |
| ghostmansd | because it is not maintainable | 16:38 |
| ghostmansd | again: such idiotic indentation depends on function results, on naming, and other factors | 16:38 |
| ghostmansd | compared to that, a fixed indentation has no such limits | 16:39 |
| ghostmansd | indent once unless there's an indentation below already; if there's, indent twice | 16:39 |
| ghostmansd | it's as simple as it gets | 16:39 |
| programmerjake | never seen autopep8 put out that particular atrocity... | 16:40 |
| ghostmansd | no bullshit like "OK name's 5 characters so I'll put 5 + 1 spaces" | 16:40 |
| ghostmansd | it's not autopep8, this is a common sense | 16:40 |
| programmerjake | it's usually pretty reasonable, tho it likes to line up with stuff (which you seem to dislike). | 16:41 |
| ghostmansd | if you use some tools for autoformatting -- please tune then appropriately to keep it readable AND maintainable | 16:41 |
| ghostmansd | it's like indenting names and types in structures | 16:41 |
| ghostmansd | or indenting by name and = sign | 16:41 |
| programmerjake | i use autoformatting tools, but i've tuned them to usually only format lines i'm modifying anyway... | 16:42 |
| ghostmansd | it's much more than some brain-dead autopep8 | 16:42 |
| ghostmansd | indentation must be systematic | 16:42 |
| ghostmansd | sure there might be some flexibility | 16:42 |
| ghostmansd | but for sure it should not be fragile and dependent on factors like length of variable name or function arguments or other idiotic reasons | 16:43 |
| ghostmansd | OK rant's over | 16:43 |
| programmerjake | autopep8 is particularly braindead for an autoformatter imho, it should be more like rustfmt where you can type any arbitrary junk whitespace wherever and it always outputs the same thing (or nearly always) -- kinda like canonicalizing it. | 16:44 |
| programmerjake | also if autopep8 needs to split a line, it tends to pick terrible spots to split it | 16:47 |
| ghostmansd | idk | 16:47 |
| ghostmansd | I used gofmt | 16:47 |
| ghostmansd | I don't like go or its formatter | 16:47 |
| ghostmansd | but it was enforced | 16:48 |
| ghostmansd | and there it made sense | 16:48 |
| programmerjake | gofmt is much more like rustfmt where basically everyone uses it, unlike c where it's like a rite of passage for beginning programmers to invent their own incompatible format | 16:49 |
| ghostmansd | well for C it can also be enforced | 16:50 |
| ghostmansd | and in some project IS | 16:50 |
| programmerjake | yeah, but in at least the textbook i read they basically said to invent your own style. imho that's terrible advice -- consistency is waay better and clang-format probably supports the consistent style so you don't have to take twice as long to get the spacing just right | 16:52 |
| ghostmansd | C is just somewhat more liberal I think | 16:54 |
| ghostmansd | but at least even the code in book which suggests to invent your style is more readable than the spacing produced by pep8 | 16:55 |
| programmerjake | imho it just makes it harder to read if every line of code has it's own unique style | 16:55 |
| programmerjake | imho autopep8's output is pretty readable, as long as you manually break lines yourself where it messes up | 16:56 |
| programmerjake | example output: https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/test/algorithms/svp64_utf_8_validation.py;h=afcbde6809917ba138a15dad733ade4411b75a3e;hb=HEAD | 16:57 |
| programmerjake | idk if anyone noticed...Global Foundaries released a 180nm open source PDK: https://opensource.googleblog.com/2022/08/GlobalFoundries-joins-Googles-open-source-silicon-initiative.html | 17:04 |
| ghostmansd | I don't say it's unreadable (or, well, perhaps it sometimes is, but that's not my point). I say it is not maintainable unless enforced. | 17:09 |
| ghostmansd | 57 AllActualErrors = (TooLong | TooShort | Overlong2 | Surrogate | | 17:09 |
| ghostmansd | 58 Overlong3 | Overlong4OrTooLarge | TooLarge) | 17:09 |
| ghostmansd | If one day length of any of these fields changes, you'll have to update two lines | 17:09 |
| ghostmansd | Or even the whole thing will be fucked by autoformatter, depending on moon phase. | 17:09 |
| ghostmansd | AllActualErrors = (TooLong | TooShort | Overlong2 | Surrogate | | 17:10 |
| ghostmansd | Overlong3 | Overlong4OrTooLarge | TooLarge) | 17:10 |
| ghostmansd | SomeActualErrors = (TooLong | TooShort | Overlong2 | Surrogate | | 17:10 |
| ghostmansd | Overlong3 | Overlong4OrTooLarge | TooLarge) | 17:10 |
| ghostmansd | Due to a single byte you already have to touch the line below. | 17:10 |
| programmerjake | well, at least for me, it's enforced, because i have my editor set up to format on save | 17:14 |
| programmerjake | imho lkcl needs format on save too... | 17:15 |
| *** octavius <octavius!~octavius@244.147.93.209.dyn.plus.net> has quit IRC | 17:23 | |
| ghostmansd | > I say it is not maintainable unless enforced. | 17:27 |
| ghostmansd | I don't say suck spacing is sane even if enforced. | 17:27 |
| ghostmansd | lkcl, I switched the whole thing to verbosity levels | 17:28 |
| ghostmansd | Perhaps we'll have more information to pass there, or maybe even fiter stuff one day via some mask. | 17:28 |
| ghostmansd | But it's still better to having two mutually exclusive options -- short and verbose -- as arguments in fuctions. | 17:29 |
| ghostmansd | lkcl, about the fishmv: perhaps you'd like to name argument differently, to avoid confusion? D naturally makes one think of, well, D. target_addr, on the other hand, had the advantage it was clearly unusual even by its name. | 17:51 |
| *** markos <markos!~Konstanti@static062038151250.dsl.hol.gr> has quit IRC | 17:58 | |
| *** markos <markos!~Konstanti@static062038151250.dsl.hol.gr> has joined #libre-soc | 17:59 | |
| ghostmansd | For now I went with D; there also was fmvis. | 18:27 |
| *** octavius <octavius!~octavius@244.147.93.209.dyn.plus.net> has joined #libre-soc | 19:08 | |
| lkcl | it is completely ironic that autopep8, in this one area, is a total screw-up. | 19:21 |
| lkcl | whewwww one meeting over, then another one | 19:21 |
| lkcl | then a long message trying to... | 19:21 |
| * lkcl head spinning | 19:21 | |
| lkcl | ghostmansd, https://git.libre-soc.org/?p=openpower-isa.git;a=commitdiff;h=1a2a6df22531a9009c960da0183508e4ffbec12d | 19:24 |
| lkcl | okaay | 19:24 |
| lkcl | so now there's an actual unit test for addi and svshape2 as starting points | 19:24 |
| ghostmansd | aaaaaand actually this is the one I'm debugging now :-) | 19:24 |
| lkcl | haha | 19:25 |
| ghostmansd | it's not matched (perhaps matched in master, though; I didn't check it in master) | 19:25 |
| lkcl | correct, it doesn't match | 19:27 |
| lkcl | that's SVd being reported off-by-one | 19:27 |
| ghostmansd | not only this I think | 19:29 |
| ghostmansd | the entire opcode looks doomed too | 19:29 |
| ghostmansd | damn, I finally gave up and printed some tables to calculate bits | 19:30 |
| ghostmansd | was too lazy to draw them by hand | 19:30 |
| lkcl | doomed, dooomed i say | 19:51 |
| lkcl | ghostmansd, unfortunately, D is already in use by addpcis | 20:07 |
| lkcl | and that's part of the spec | 20:07 |
| ghostmansd | Sorry, I'm out of context. What do you mean? I haven't touched the reverted commit. | 20:07 |
| ghostmansd | Instead I just did this: | 20:08 |
| lkcl | fishmv RT,D | 20:08 |
| ghostmansd | "fishmv": {"D": DynamicOperandDDX}, | 20:08 |
| lkcl | addpcis RT,D | 20:08 |
| ghostmansd | "fmvis": {"D": DynamicOperandDDX}, | 20:08 |
| lkcl | p66 v3.0C "Add PC Immediate Shifted" | 20:08 |
| lkcl | section 3.3.9 | 20:08 |
| lkcl | so that'll also need | 20:10 |
| lkcl | "addpcis": {"D": DynamicOperandDDX}, | 20:11 |
| ghostmansd | Ah OK | 20:19 |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC | 23:50 | |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!