| 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 https://pastebin.com/9fw0QivT | 05:13 |
| 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 means | 11:43 |
| lkcl- | ignore bit 31 | 11:43 |
| lkcl- | "-" in the bit 30 position means | 11:43 |
| lkcl- | ignore bit 30 | 11: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 require | 11:44 |
| lkcl- | 00000- | 11:44 |
| lkcl- | 26=0 | 11:44 |
| lkcl- | 27=0 | 11:44 |
| lkcl- | 28=0 | 11:44 |
| lkcl- | 29=0 | 11:44 |
| lkcl- | 30=0 | 11:45 |
| 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 bits | 11:46 |
| programmerjake | afaict 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 misunderstood | 11:47 |
| programmerjake | (going off what ghostmansd[m] said) | 11:48 |
| ghostmansd[m] | Yes, exactly, that's what I mean | 11: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 assumptions | 11:51 |
| ghostmansd[m] | But on bit level this does not really depend on whether we ignore bit, does it? | 11:51 |
| programmerjake | I *didn't* force push | 11:52 |
| programmerjake | it's a new branch | 11:52 |
| lkcl- | it should not have succeeded otherwise | 11:52 |
| lkcl- | please REMOVE that branch, it should never have succeeded | 11:52 |
| programmerjake | uuh, why? | 11:53 |
| lkcl- | wait, you can't, i removed everybody's permissions | 11:53 |
| lkcl- | because someone f****d up the commit history with a massive git history rewrite | 11:53 |
| lkcl- | so they're effectively two absolutely and completely different repositories | 11: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 critical | 11:54 |
| lkcl- | up until i've sorted out the mess that's been made [which wasn't you] | 11:54 |
| programmerjake | well, the new branch i pushed follows gitlab's git history. it is unrelated to master on git.libre-soc.org...and don't confuse those two separate branches | 11:55 |
| * lkcl- stressing out | 11:55 | |
| lkcl- | precisely. | 11:55 |
| lkcl- | and it's gitlab that has a wildly different set of commits | 11:55 |
| lkcl- | with the exact same commit messages | 11:55 |
| lkcl- | someone f****d things up basically, most likely by doing a full "git commit history rewrite" | 11:56 |
| programmerjake | well, imho it's best to not do another full git rewrite to try and fix it | 11:57 |
| lkcl- | so by pushing gitlab commits down onto git.libre-soc.org's nmigen repo you've effectively committed an entirely new, wildly different, and completely unrelated project to the same git repo | 11:57 |
| lkcl- | we can't. | 11:57 |
| lkcl- | git commit history rewrites create completely new and arbitrary hashes | 11:57 |
| programmerjake | completely unrelated commits, totally related code, so imho it should be fine | 11:57 |
| lkcl- | doing another git commit history rewrite will simply create *yet another* wildly different set of hashes, unrelated to the first and the second | 11: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 missed | 11:58 |
| lkcl- | f****g nuisance and i don't want to have to do that again. | 11:58 |
| lkcl- | nmigen | 11:59 |
| programmerjake | nmigen.git on libre-soc and gitlab.com/nmigen/nmigen | 11:59 |
| lkcl- | anyway | 11:59 |
| ghostmansd[m] | Ah ok I'm safe :-) | 11:59 |
| lkcl- | back to the opcodes. | 11:59 |
| ghostmansd[m] | I did force push into binutils branch | 11:59 |
| lkcl- | ghostmansd[m], but that's code that's not in use and is non-critical | 12:00 |
| lkcl- | this is the absolute lowest-level critical repo to the entire project. we cannot have it f****d up. | 12:00 |
| programmerjake | so i put the new branch on libre-soc's nmigen.git since iirc you did want all our code on git.libre.soc.org, rather than only on my personal gitlab account | 12:01 |
| lkcl- | setvl = 0b00000 which is currently bits 26-30 | 12:01 |
| lkcl- | svshape = 0b00001 | 12:01 |
| ghostmansd[m] | Yehyeh, but I started to worry reading all this | 12:01 |
| lkcl- | svremap = 0b00010 | 12:01 |
| lkcl- | svstep = 0b00011 | 12:01 |
| lkcl- | ghostmansd[m], you're working on something that is a "leaf-node". absolutely nobody - at all - depends on it, right now | 12:02 |
| lkcl- | so you can, in effect, do what you like. | 12:02 |
| programmerjake | ok, technically i force-pushed, but it was only replacing a commit i made 3min earlier | 12:02 |
| ghostmansd[m] | Ok let's discuss 1 thing at a time | 12:02 |
| lkcl- | but the moment that it becomes a dependency, then yes, force-push is not ok | 12:02 |
| lkcl- | so with all those 4 instructions, there's no conflict | 12:03 |
| programmerjake | icr if it was nmigen.git or some other repo tho | 12:03 |
| lkcl- | bear in mind that we are talking about 4 instructions that are *NOT* up-to-date as far as this page is concerned | 12:03 |
| lkcl- | https://libre-soc.org/openpower/sv/bitmanip/ | 12:03 |
| lkcl- | but please *ignore* that for now | 12:03 |
| lkcl- | focus on those 4 entries in the CSV files | 12:04 |
| lkcl- | the bitsel=(1,5) is bits 26-30 (in MSB0 order) | 12:04 |
| ghostmansd[m] | Again, I'm speaking of updating this instructions | 12:04 |
| ghostmansd[m] | With bitsel (0,5) | 12:04 |
| lkcl- | then all you need is: | 12:04 |
| lkcl- | setvl=00000- | 12:05 |
| lkcl- | svshape=000001- | 12:05 |
| lkcl- | svstep=00010- | 12:05 |
| programmerjake | so, 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] | Exactly | 12:05 |
| ghostmansd[m] | That's exactly what I said above, that this last bit must be ignored everywhere | 12:05 |
| lkcl- | yes. | 12:05 |
| lkcl- | *later* - when updating to this page https://libre-soc.org/openpower/sv/bitmanip/ - that will change | 12: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 011001 | 12:07 |
| lkcl- | not yet | 12:07 |
| lkcl- | in increments | 12:07 |
| ghostmansd[m] | Because I debugged what was broken with the commit I had to revert | 12:07 |
| ghostmansd[m] | sigh | 12:07 |
| ghostmansd[m] | These increments are bad | 12:07 |
| lkcl- | programmerjake, i removed everyone. | 12:07 |
| ghostmansd[m] | Because they do the code inconsistent | 12:07 |
| ghostmansd[m] | You have one layout in fields.text, other in svp64.py | 12: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 lot | 12:08 |
| lkcl- | exactly | 12:08 |
| lkcl- | ah yes, right, sorry | 12: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 consistent | 12:09 |
| lkcl- | yes, i'm not keeping up-to-date because i have to consider the entire table and change it multiple times | 12: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 instruction | 12: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 svp64.py but *not* look at the tables https://libre-soc.org/openpower/sv/bitmanip/ that would be good | 12:10 |
| ghostmansd[m] | I mean, I get that you want to update the site and generated code, but we're sharing this code | 12:10 |
| lkcl- | the absolutely critical thing is to keep the unit tests running | 12:11 |
| lkcl- | i know. | 12:11 |
| ghostmansd[m] | Then we'd miss some stuff in binutils | 12:11 |
| ghostmansd[m] | I mean, I also had to move though insns in binutils | 12:11 |
| lkcl- | one thing at a time | 12:11 |
| ghostmansd[m] | So I checked SVP64 and fields.text | 12:11 |
| ghostmansd[m] | And found that some are outdated | 12:11 |
| lkcl- | no | 12:11 |
| lkcl- | it is *only* https://libre-soc.org/openpower/sv/bitmanip/ that is inconsistent | 12:11 |
| lkcl- | everything else is consistent and has been for months | 12:12 |
| lkcl- | it's just that the EXT022 is under pressure and needed reorganising | 12:12 |
| programmerjake | well, 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 gitlab.com/programmerjake/nmigen | 12:12 |
| programmerjake | gn all | 12: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 git.libre-soc.org repo later when i've had time to recover the other work at the same time | 12:12 |
| ghostmansd[m] | To make sure they match | 12:13 |
| lkcl- | fortunately the Forms have not changed either | 12:13 |
| ghostmansd[m] | programmerjake, gn | 12: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 |
| ghostmansd | lkcl, they _did_ change | 12:14 |
| lkcl- | you *must* ignore that for now | 12:14 |
| ghostmansd | `git show 06e8a1940d591d9011772c42ef7a4585e59e2769` | 12:14 |
| * lkcl- checking 1 sec | 12:15 | |
| ghostmansd | so you had 5-bit XO, and now it's 5-bit for SVM and SVRM | 12:15 |
| lkcl- | ghostmansd, drat, yes. | 12:16 |
| ghostmansd | that's exactly what was changed, and this is the whole reason we discuss | 12:16 |
| ghostmansd | and this caused the commit to svp64.py to sync it | 12:16 |
| lkcl- | frick ok | 12:16 |
| ghostmansd | and also caused binutils changes | 12:16 |
| * lkcl- annoyed (with myself) | 12:16 | |
| ghostmansd | so, I'm kinda at least want you to choose one thing, 5 bits or 6 | 12:17 |
| ghostmansd | two days down the drain :-) | 12:17 |
| lkcl- | ah no. | 12:17 |
| lkcl- | right. | 12:17 |
| lkcl- | ok | 12:17 |
| lkcl- | notice how SVL-Form has not changed? | 12:18 |
| lkcl- | SVL-Form is 5-bit | 12:18 |
| lkcl- | that covers setvl and svstep | 12:18 |
| ghostmansd | fields are different | 12:18 |
| lkcl- | in power_decoder.py (and the minor_22.csv) you can *still* use 6-bit. | 12:19 |
| lkcl- | ok. | 12:19 |
| lkcl- | frick. | 12:19 |
| lkcl- | let me sort it out. | 12:19 |
| ghostmansd | I suggest to set - for the last bit | 12:19 |
| ghostmansd | in minor_22.csv | 12:19 |
| lkcl- | yes. | 12:20 |
| lkcl- | let me deal with it | 12:20 |
| ghostmansd | OK :-) | 12:20 |
| ghostmansd | $(git show --stat) should list the stuff to be changed | 12:20 |
| ghostmansd | or, better, $(git show dccc8ad337f5d45e3910e312b6e51c0496e6bd32) | 12:21 |
| ghostmansd | if you have local changes | 12:21 |
| lkcl- | frickin frickin frick. getting a syntax error from power_decoder.py | 12:29 |
| * lkcl- stressing out | 12:29 | |
| *** lkcl- is now known as lkcl | 12:29 | |
| lkcl | okaay thank god. it was just an off-by-one error | 12:33 |
| * lkcl relieved | 12:33 | |
| lkcl | gaah, both svremap and svshape had been marked as Rc=1 in minor_22.csv | 12:44 |
| lkcl | all a bit of a mess | 12:44 |
| ghostmansd[m] | Emmm, why do they need Rc? | 12:51 |
| ghostmansd[m] | They shouldn't have it | 12:52 |
| lkcl | correct / exactly. | 12:53 |
| lkcl | they are SPR (control) instructions, no destination register | 12:53 |
| lkcl | okaay all sorted. | 12:54 |
| lkcl | a cascande of four errors there, none of which were caught by the unit tests | 12:54 |
| lkcl | quite astounding | 12:54 |
| lkcl | what i've done is: | 12:55 |
| lkcl | * corrected an error in power_decode.py 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 there | 12: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 |
| lkcl | dog's dinner mess, all sorted, now need to calm down somewhat. | 12:58 |
| * lkcl dehydrated need water | 12:58 | |
| lkcl | ghostmansd[m], you should be good to go. update binutils according to https://libre-soc.org/openpower/sv/bitmanip/ and what's in svp64.py, fields.text, and minor_22.csv | 13:20 |
| lkcl | should all be consistent now | 13:20 |
| ghostmansd[m] | Thanks lkcl, will take a look later | 13:22 |
| ghostmansd[m] | A lot in one go :-) | 13:22 |
| ghostmansd | https://pastebin.com/BSxPGV5H | 15:04 |
| ghostmansd | Cool. Cool cool cool. | 15:04 |
| lkcl | briilliant | 15:13 |
| markos | yay, more instructions in next Arm revision, you know things are going bad when you have 3 *specialized* instructions for memcpy | 19:32 |
| markos | just for memcpy | 19:32 |
| markos | lkcl, can't wait to use SVP64 on actual hardware... | 19:34 |
| markos | even FPGA | 19:34 |
| lkcl | niice. love the idea of going overboard https://news.ycombinator.com/item?id=28601386 | 20:31 |
| lkcl | https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/arm-a-profile-architecture-developments-2021 | 20:32 |
| lkcl | reading the article, "preamble alignment etc", that's basically down to the damage caused by SIMD | 20:34 |
| lkcl | and is easily fixed with Fail-First Mode in SVE2 | 20:34 |
| lkcl | LD-ST-fail-first allows the hardware to select (and then communicate) the amount that is loaded (or stored) | 20:35 |
| lkcl | the absolute minimum has to be 1 byte (or, 1 element) | 20:36 |
| lkcl | beyond that the micro-architecture can literally choose anything it likes, for any reason it likes, up to the Vector Length VL | 20:36 |
| lkcl | which obliterates *all* the objections raised in that article, all without adding any extra instructions. | 20:37 |
| lkcl | ok, in SVP64 it's no new instructions because it's the prefix that specifies "fail-first" mode | 20:37 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!