Friday, 2022-05-20

ghostmansd[m]The issue is that Rc overlaps with 0. Even if the last XO bit is ignored in setvl, it's Rc which gets us in trouble.05:09
ghostmansd[m]setvl last 6 bits can be either 0b0 or 0b1, and 0b1 can also designate svshape now. So, either svshape must have XO 0b11, or there must be a different opcode for either svshape or setvl.05:12
ghostmansd[m]So, yeah, kinda disregard the message about ignored bit, and check minor_22.csv XO/Rc and
ghostmansd[m]Also, it didn't help at all that our CSVs call XO opcode, because it's not obvious immediately they mean XO, not PO. Kinda obvious when you know how it works, but naming sucks.05:14
ghostmansd[m]Or, well, is it internal op? Anyway.07:10
ghostmansd[m]IIRC goes from VHDL?07:10
lkcl-yes... and a "-" means "ignore it precisely because it's Rc"11:43
lkcl-"-" in the bit 31 position means11:43
lkcl-ignore bit 3111:43
lkcl-"-" in the bit 30 position means11:43
lkcl-ignore bit 3011:43
lkcl-    # |0     |6        |11      |16    |21    |25 |26    |31  |11:44
lkcl-    # | PO   |  SVxd   |   SVyd | SVzd | SVRM |vf |   XO      |11:44
lkcl-this would require11:44
lkcl-                                                               00000-11:44
lkcl-31= ***A DASH MEANING IGNORE***11:45
lkcl-that's why i said. look at minor_5.csv and minor_63.csv, they already use "-" to ignore bits11:46
programmerjakeafaict the issue is that two instructions occupy overlapping 32-bit instruction values, so some 32-bit instructions can be validly decoded as both setvl and svshape, not that `-` is misunderstood11:47
programmerjake(going off what ghostmansd[m] said)11:48
ghostmansd[m]Yes, exactly, that's what I mean11:49
ghostmansd[m]Ignore the last bit or not, you have same 6 bits for setvl. and svshape.11:50
lkcl-programmerjake, will you PLEASE consult me before doing git force-master push.11:51
ghostmansd[m]I will check it with dash, perhaps I miss how it works...11:51
lkcl-the reason i have not added you to the gitlab nmigen maintainers is because you haven't demonstrated that you can communicate without making assumptions11:51
ghostmansd[m]But on bit level this does not really depend on whether we ignore bit, does it?11:51
programmerjakeI *didn't* force push11:52
programmerjakeit's a new branch11:52
lkcl-it should not have succeeded otherwise11:52
lkcl-please REMOVE that branch, it should never have succeeded11:52
programmerjakeuuh, why?11:53
lkcl-wait, you can't, i removed everybody's permissions11:53
lkcl-because someone f****d up the commit history with a massive git history rewrite11:53
lkcl-so they're effectively two absolutely and completely different repositories11:53
lkcl-i don't know who did it, but there's absolutely no common commits - at all.11:54
lkcl-keeping them separate is absolutely critical11:54
lkcl-up until i've sorted out the mess that's been made [which wasn't you]11:54
programmerjakewell, the new branch i pushed follows gitlab's git history. it is unrelated to master on don't confuse those two separate branches11:55
* lkcl- stressing out11:55
lkcl-and it's gitlab that has a wildly different set of commits11:55
lkcl-with the exact same commit messages11:55
lkcl-someone f****d things up basically, most likely by doing a full "git commit history rewrite"11:56
programmerjakewell, imho it's best to not do another full git rewrite to try and fix it11:57
lkcl-so by pushing gitlab commits down onto's nmigen repo you've effectively committed an entirely new, wildly different, and completely unrelated project to the same git repo11:57
lkcl-we can't.11:57
lkcl-git commit history rewrites create completely new and arbitrary hashes11:57
programmerjakecompletely unrelated commits, totally related code, so imho it should be fine11:57
lkcl-doing another git commit history rewrite will simply create *yet another* wildly different set of hashes, unrelated to the first and the second11:58
ghostmansd[m]What is the repo?11:58
lkcl-i had to spend literally 3 days going through over 200 commits, comparing them side-by-side.11:58
lkcl-making absolutely certain that nothing had been missed11:58
lkcl-f****g nuisance and i don't want to have to do that again.11:58
programmerjakenmigen.git on libre-soc and
ghostmansd[m]Ah ok I'm safe :-)11:59
lkcl-back to the opcodes.11:59
ghostmansd[m]I did force push into binutils branch11:59
lkcl-ghostmansd[m], but that's code that's not in use and is non-critical12:00
lkcl-this is the absolute lowest-level critical repo to the entire project. we cannot have it f****d up.12:00
programmerjakeso i put the new branch on libre-soc's nmigen.git since iirc you did want all our code on, rather than only on my personal gitlab account12:01
lkcl-setvl = 0b00000 which is currently bits 26-3012:01
lkcl-svshape = 0b0000112:01
ghostmansd[m]Yehyeh, but I started to worry reading all this12:01
lkcl-svremap = 0b0001012:01
lkcl-svstep = 0b0001112:01
lkcl-ghostmansd[m], you're working on something that is a "leaf-node". absolutely nobody - at all - depends on it, right now12:02
lkcl-so you can, in effect, do what you like.12:02
programmerjakeok, technically i force-pushed, but it was only replacing a commit i made 3min earlier12:02
ghostmansd[m]Ok let's discuss 1 thing at a time12:02
lkcl-but the moment that it becomes a dependency, then yes, force-push is not ok12:02
lkcl-so with all those 4 instructions, there's no conflict12:03
programmerjakeicr if it was nmigen.git or some other repo tho12:03
lkcl-bear in mind that we are talking about 4 instructions that are *NOT* up-to-date as far as this page is concerned12:03
lkcl-but please *ignore* that for now12:03
lkcl-focus on those 4 entries in the CSV files12:04
lkcl-the bitsel=(1,5) is bits 26-30 (in MSB0 order)12:04
ghostmansd[m]Again, I'm speaking of updating this instructions12:04
ghostmansd[m]With bitsel (0,5)12:04
lkcl-then all you need is:12:04
programmerjakeso, lkcl, since I did not overwrite anything in nmigen.git and was never planning to can you re-enable my write priveleges?12:05
ghostmansd[m]That's exactly what I said above, that this last bit must be ignored everywhere12:05
lkcl-*later* - when updating to this page - that will change12:06
lkcl-setvl will become 10011-12:06
ghostmansd[m]Do you want to change the insn again?12:06
ghostmansd[m]Ok I literally spent some hours for nothing then :-)12:06
lkcl-svshape will be 01100112:07
lkcl-not yet12:07
lkcl-in increments12:07
ghostmansd[m]Because I debugged what was broken with the commit I had to revert12:07
ghostmansd[m]These increments are bad12:07
lkcl-programmerjake, i removed everyone.12:07
ghostmansd[m]Because they do the code inconsistent12:07
ghostmansd[m]You have one layout in fields.text, other in svp64.py12:07
ghostmansd[m]I'm going through _both_12:08
lkcl-yes, i know.12:08
ghostmansd[m]Please don't change one without changing another, it confuses a lot12:08
lkcl-ah yes, right, sorry12:08
ghostmansd[m]That's why this whole commit I had to revert appeared :-)12:09
ghostmansd[m]I mean, I wanted to keep it consistent12:09
lkcl-yes, i'm not keeping up-to-date because i have to consider the entire table and change it multiple times12:09
lkcl-i've had to reorganise the EXT022 table i think about 10-12 times in the past 10 weeks.12:09
ghostmansd[m]Then failed, then debugged it several hours to get that I have a different instruction12:09
ghostmansd[m]Ok, but perhaps this can be done in a branch or local clone without submitting it?12:10
lkcl-please bear in mind i may have to reorganise the table again.12:10
lkcl-so if you can keep it consistent to what is in but *not* look at the tables that would be good12:10
ghostmansd[m]I mean, I get that you want to update the site and generated code, but we're sharing this code12:10
lkcl-the absolutely critical thing is to keep the unit tests running12:11
lkcl-i know.12:11
ghostmansd[m]Then we'd miss some stuff in binutils12:11
ghostmansd[m]I mean, I also had to move though insns in binutils12:11
lkcl-one thing at a time12:11
ghostmansd[m]So I checked SVP64 and fields.text12:11
ghostmansd[m]And found that some are outdated12:11
lkcl-it is *only* that is inconsistent12:11
lkcl-everything else is consistent and has been for months12:12
lkcl-it's just that the EXT022 is under pressure and needed reorganising12:12
programmerjakewell, i'm going to sleep. lkcl, if you want libre-soc's nmigen repo to contain my work on nmigen then please re-enable write privileges for me. otherwise it'll only be in
programmerjakegn all12:12
ghostmansd[m]I even didn't bother about bitmanip. I've been looking at fields.text and checked for forms.12:12
lkcl-programmerjake, that's fine. i'll sort out the repo later when i've had time to recover the other work at the same time12:12
ghostmansd[m]To make sure they match12:13
lkcl-fortunately the Forms have not changed either12:13
ghostmansd[m]programmerjake, gn12:13
lkcl-when i say "bitmanip" i mean "the table inside the bitmanip page which has a list of opcodes which includes setvl, svshape etc. that is *not* consistent with what is in the csv files"12:14
lkcl-in the bitmanip page there is an entry for bits 26-31 for svshape: "0 11 001"12:14
ghostmansdlkcl, they _did_ change12:14
lkcl-you *must* ignore that for now12:14
ghostmansd`git show 06e8a1940d591d9011772c42ef7a4585e59e2769`12:14
* lkcl- checking 1 sec12:15
ghostmansdso you had 5-bit XO, and now it's 5-bit for SVM and SVRM12:15
lkcl-ghostmansd, drat, yes.12:16
ghostmansdthat's exactly what was changed, and this is the whole reason we discuss12:16
ghostmansdand this caused the commit to to sync it12:16
lkcl-frick ok12:16
ghostmansdand also caused binutils changes12:16
* lkcl- annoyed (with myself)12:16
ghostmansdso, I'm kinda at least want you to choose one thing, 5 bits or 612:17
ghostmansdtwo days down the drain :-)12:17
lkcl-ah no.12:17
lkcl-notice how SVL-Form has not changed?12:18
lkcl-SVL-Form is 5-bit12:18
lkcl-that covers setvl and svstep12:18
ghostmansdfields are different12:18
lkcl-in (and the minor_22.csv) you can *still* use 6-bit.12:19
lkcl-let me sort it out.12:19
ghostmansdI suggest to set - for the last bit12:19
ghostmansdin minor_22.csv12:19
lkcl-let me deal with it12:20
ghostmansdOK :-)12:20
ghostmansd$(git show --stat) should list the stuff to be changed12:20
ghostmansdor, better, $(git show dccc8ad337f5d45e3910e312b6e51c0496e6bd32)12:21
ghostmansdif you have local changes12:21
lkcl-frickin frickin frick. getting a syntax error from power_decoder.py12:29
* lkcl- stressing out12:29
*** lkcl- is now known as lkcl12:29
lkclokaay thank god. it was just an off-by-one error12:33
* lkcl relieved12:33
lkclgaah, both svremap and svshape had been marked as Rc=1 in minor_22.csv12:44
lkclall a bit of a mess12:44
ghostmansd[m]Emmm, why do they need Rc?12:51
ghostmansd[m]They shouldn't have it12:52
lkclcorrect / exactly.12:53
lkclthey are SPR (control) instructions, no destination register12:53
lkclokaay all sorted.12:54
lkcla cascande of four errors there, none of which were caught by the unit tests12:54
lkclquite astounding12:54
lkclwhat i've done is:12:55
lkcl* corrected an error in minor_22.csv bitsel=(1,5) should never have been (1,5) it should have been (1,6)12:55
lkcl* changed the bitsel=(0,6) and correspondingly changed minor_22.csv from 0b00000 to 00000- i.e. from 5 bits to 6 bits and changed to "mask" format (previously binary numbers)12:56
lkcl* removed Rc=1 from svshape and svremap which should never have been there12:56
lkcl* updated the magic constants for the XO fields for svshape and svremap (which are 6-bit) and setvl and svstep (which are 5-bit)12:57
lkcldog's dinner mess, all sorted, now need to calm down somewhat.12:58
* lkcl dehydrated need water12:58
lkclghostmansd[m], you should be good to go. update binutils according to and what's in, fields.text, and minor_22.csv13:20
lkclshould all be consistent now13:20
ghostmansd[m]Thanks lkcl, will take a look later13:22
ghostmansd[m]A lot in one go :-)13:22
ghostmansdCool. Cool cool cool.15:04
markosyay, more instructions in next Arm revision, you know things are going bad when you have 3 *specialized* instructions for memcpy19:32
markosjust for memcpy19:32
markoslkcl, can't wait to use SVP64 on actual hardware...19:34
markoseven FPGA19:34
lkclniice. love the idea of going overboard
lkclreading the article, "preamble alignment etc", that's basically down to the damage caused by SIMD20:34
lkcland is easily fixed with Fail-First Mode in SVE220:34
lkclLD-ST-fail-first allows the hardware to select (and then communicate) the amount that is loaded (or stored)20:35
lkclthe absolute minimum has to be 1 byte (or, 1 element)20:36
lkclbeyond that the micro-architecture can literally choose anything it likes, for any reason it likes, up to the Vector Length VL20:36
lkclwhich obliterates *all* the objections raised in that article, all without adding any extra instructions.20:37
lkclok, in SVP64 it's no new instructions because it's the prefix that specifies "fail-first" mode20:37

Generated by 2.17.1 by Marius Gedminas - find it at!