| ghostmansd-pc | Hi Luke, I recall that we discussed we might create the documentation for adding a new instruction, based on task 656. What I don't recall is whether we created a ticket in bugzilla, though. Should I raise it, or we have something ready? | 08:11 |
|---|---|---|
| ghostmansd-pc | I also remember that I haven't completed firststeps guide yet, so I'll complete that one next week. | 08:11 |
| ghostmansd-pc | So I actually think of this sequence next week: 1) complete firststeps doc; 2) complete first-instruction doc; 3) move to tests. | 08:12 |
| ghostmansd-pc | Does this schedule work for you? Please, let me know, if these must be done in other way round. | 08:13 |
| lkcl | no not created yet | 09:55 |
| lkcl | do go ahead | 09:56 |
| lkcl | cross-link using "see also" field (otherwise bugs are isolated and a pain to find) | 09:56 |
| programmerjake | addg6s is used for doing a BCD addition, like x86's daa instruction: https://www.felixcloutier.com/x86/daa | 10:10 |
| programmerjake | afaict to do a bcd add of a and b, you do `add r, a, b` then `addg6s t, a, b` then `add r, r, t` | 10:15 |
| programmerjake | I just discovered x86 has something kinda like SV's 128 registers: https://www.felixcloutier.com/x86/v4fmaddps:v4fnmaddps | 10:21 |
| programmerjake | takes 4 512-bit registers in sequence and does fmas | 10:21 |
| lkcl | the actual difference between AVX-512, SVE2 and Cray-style Vector ISAs is, sadly, one instruction: setvl. | 10:24 |
| lkcl | if x86 and ARM added *one instruction*, setvl, which took VL and created a hidden predicate mask ((1<<VL)-1), they'd *have* Cray-style Vectors | 10:24 |
| lkcl | because they already have predicate masks it's a no-brainer at the hardware level | 10:25 |
| lkcl | that hidden mask gets ANDed with any explicitly-given predicate mask arguments (if any) and err... that's it. | 10:25 |
| lkcl | ghostmansd, i've an idea of a [boring, mundane] task for you that will need you to go over every single line of the pseudocode of every single instruction, if you're interested | 10:26 |
| programmerjake | yeah, though I was referring more to the using-a-sequence-of-consecutive-registers that SV is using | 10:27 |
| ghostmansd | Would you like to re-check these? | 10:27 |
| lkcl | i could do it - very quickly - but i feel that it would be advantageous for you to actually have to do a "line-by-line read" of every single instruction's pseudocode, paying attention to all of them and doing a simple(ish) adaptation | 10:28 |
| lkcl | programmerjake: am just waking up :) | 10:28 |
| lkcl | programmerjake, can you drop that insight about add6gs into #656? | 10:28 |
| lkcl | ghostmansd: recheck "these"? what is "these"? sorry, no context there | 10:29 |
| lkcl | (will continue explaining about the runthrough of all pseudocode) | 10:32 |
| lkcl | we are doing a Vector ISA, where the "Vector context" can specify an over-ride on the source and destination register width. | 10:32 |
| lkcl | "add RT, RA, RB" says "add the 64 bit registers RA and RB and put it into the 64 bit RT register" | 10:33 |
| lkcl | "sv.add/sw=16/ew=8 RT, RA, RB" says, "take only 16 bits of RA and RB, add as 16 bits, then truncate to 8 and place ONLY 8 BITS into RT" | 10:34 |
| lkcl | (that example is much more meaningful the other way round, or when "Saturation" mode is enabled) | 10:34 |
| lkcl | but... | 10:34 |
| lkcl | all the pseudocode assumes [0:63] | 10:34 |
| lkcl | not: [0:SOURCE_REGISTER_LENGTH-1] | 10:35 |
| lkcl | or [0:DESTINATION_REGISTER_LENGTH-1] | 10:35 |
| lkcl | therefore | 10:35 |
| programmerjake | well, have fun everyone, I'm off to sleep | 10:35 |
| lkcl | we need to go over eeeeevvvverryyyyy single frickin line of the pseudocode, changing pretty much 100% of them to remove all hard-coded [0:63] and replacing them | 10:35 |
| lkcl | eek, you're up at night! :) | 10:36 |
| lkcl | night jacob | 10:36 |
| lkcl | now, whilst it sounds "by rote", it's actually an opportunity for you to go sequentially through the pseudocode, and by doing a (relatively simple) task on each of them, you will become familiar _with_ every single one of the instructions. | 10:37 |
| programmerjake | note that global search/replace will likely make mistakes, hence the need to go over it by hand | 10:39 |
| ghostmansd | I mean if you want me to compare each and every instruction with ISA docs | 10:39 |
| lkcl | ghostmansd: no, i don't mean thatm because we've spent 18+ months writing unit tests that tell us that the pseudocode is correct. | 11:49 |
| lkcl | we need to *modify* the pseudocode - and later submit the element-width changes upstream to the ISA WG - to allow the width of all pseudocode operations to be DYNAMICALLY specified... at runtime. | 11:50 |
| lkcl | example, here: | 11:52 |
| lkcl | https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=openpower/isa/fixedlogical.mdwn;h=c57491178262d62b53269d13d0ac8479f40a5098;hb=cd99a39cc763bfe1aa30b1bfa3b477761caa049f#l35 | 11:52 |
| lkcl | RA <- (RS) | ([0]*48 || UI) | 11:52 |
| lkcl | needs to be changed to: | 11:52 |
| lkcl | RA <- (RS) | ([0]*(SOURCE_REGISTER_WIDTH-16) || UI) | 11:53 |
| lkcl | or, more accurately | 11:53 |
| lkcl | RA <- (RS) | ([0]*MAX(0,(SOURCE_REGISTER_WIDTH-16)) || UI) | 11:53 |
| lkcl | why? | 11:53 |
| lkcl | because the source width and destination width we are permitting - in SVP64 - to be OVER-RIDDEN AT RUNTIME | 11:54 |
| lkcl | extsb: | 11:55 |
| lkcl | https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=openpower/isa/fixedlogical.mdwn;h=c57491178262d62b53269d13d0ac8479f40a5098;hb=cd99a39cc763bfe1aa30b1bfa3b477761caa049f#l226 | 11:55 |
| lkcl | s <- (RS)[56] | 11:55 |
| lkcl | becomes | 11:55 |
| lkcl | s <- (RS)[SOURCE_REGISTER_WIDTH-8] | 11:56 |
| lkcl | or, more accurately: | 11:56 |
| lkcl | if SOURCE_REGISTER_WIDTH == 8 then | 11:56 |
| lkcl | RT <- RS | 11:56 |
| lkcl | else | 11:56 |
| lkcl | ... | 11:56 |
| lkcl | ... | 11:56 |
| lkcl | .... | 11:56 |
| lkcl | RA[56:63] <- (RS)[56:63] | 11:58 |
| lkcl | becomes | 11:58 |
| lkcl | RA[DEST_REGISTER_WIDTH-8:DEST_REGISTER_WIDTH-1] <- (RS)[SOURCE_REGISTER_WIDTH:SOURCE_REGISTER_WIDTH-1] | 11:58 |
| lkcl | cntlz | 11:58 |
| lkcl | https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=openpower/isa/fixedlogical.mdwn;h=c57491178262d62b53269d13d0ac8479f40a5098;hb=cd99a39cc763bfe1aa30b1bfa3b477761caa049f#l260 | 11:58 |
| lkcl | becomes | 11:58 |
| lkcl | do while n < SOURCE_REGISTER_WIDTH | 11:58 |
| lkcl | instead of | 11:58 |
| lkcl | do while n < 64 | 11:58 |
| lkcl | etc. | 11:59 |
| lkcl | etc. | 11:59 |
| lkcl | etc. | 11:59 |
| lkcl | etc. | 11:59 |
| lkcl | every operation gets REDESIGNED to be DYNAMICALLY capable of ALL registers being 8, 16, 32 or 64 bit | 12:00 |
| lkcl | however the whole purpose of inviting you to do this task is so that you *have* to go over every single one of the instructions. | 12:04 |
| lkcl | consequently you will become familiar with them all, in a "fingers typing at keys" way. | 12:05 |
| lkcl | whereas if you just "read the spec and compare the words", this is nowhere near as effective, you will get brain-fuzz within 10 minutes, from going over 200+ pages of staring at screens without actually doing any actual "activity" :) | 12:06 |
| lkcl | ghostmansd, however, important to say: there is no rush on that. | 15:55 |
| ghostmansd | lkcl: Ok, I think I got the idea. Could you, please, raise the relevant task and post a summary there? | 16:17 |
| lkcl | willdo. | 16:17 |
| ghostmansd | I will take a look at it, with a low priority. | 16:17 |
| ghostmansd | Thank you! | 16:17 |
| lkcl | i think there might be one already, it's been planned for several months | 16:17 |
| ghostmansd | I'm just wondering, how SOURCE_REGISTER_WIDTH is changed? You said it's runtime property, but what's the actual way? | 16:35 |
| ghostmansd | I mean, other ISAs I've been looking at have different instructions depending on register width. | 16:35 |
| ghostmansd | The mnemonics might be the same (even this depends on assembly syntax, though), but opcodes are different. | 16:36 |
| ghostmansd | Ah, ok, I messed sv.add/sw=1y/ew=8 | 16:37 |
| ghostmansd | *missed | 16:37 |
| lkcl | :) | 17:34 |
| jn | btw, i'm making another attempt at cleaning up the unit tests. WIP here: https://gitlab.com/neuschaefer/soc/-/commits/ci | 17:59 |
| lkcl | jn: if you'd like to help i'd much rather you used git.libre-soc.org rather than an external non-audited repository. | 18:14 |
| lkcl | we are under Audit Conditions for both protection against patent trolls and also from NLnet's Privacy and Enhanced Trust Programme | 18:15 |
| jn | should i push my commits on git.l-s.o when i'm reasonably sure they're good? (which is roughly now) | 18:15 |
| jn | in other development communities there's the option of pushing code somewhere, where it will be seen bit isn't directly on the master branch, and i'm very used to it, so i'm still figuring the libre-soc workflow out | 18:16 |
| lkcl | now we have to discuss them, it's a problem, because in the future, when someone comes along and audits these IRC discussions, they will see, "err where is this gitlab.com source code? gitlab is no longer operational / gitlab had a DMCA takedown notice / gitlab was taken over by a proprietary company and the source is no longer available" | 18:17 |
| jn | oh, i see | 18:17 |
| jn | i'll avoid starting discussions about externally hosted code | 18:18 |
| lkcl | so, can you send me an ssh public key, i'll add you to the repo. you've been around long enough, i assume you're happy with the Charter? http://libre-soc.org/charter | 18:19 |
| jn | we've already done the ssh key thing; i'll re-read the charter, in case i forgot part of it | 18:20 |
| lkcl | ah ok great. | 18:20 |
| lkcl | then i'll add you to the soc repo. | 18:20 |
| lkcl | we don't use relative imports btw | 18:20 |
| lkcl | and nothing in "unused" matters, does not need time spent on it | 18:20 |
| lkcl | sigh, i can't discuss the changes that _do_ matter because i can't refer to an external source code repository. | 18:21 |
| lkcl | jn: ah, cool, you're already added | 18:22 |
| lkcl | you can check with "ssh gitolite3@git.libre-soc.org" | 18:22 |
| lkcl | DO NOT type a password if that fails. | 18:22 |
| lkcl | fail2ban will instantly ban you when it notices a failed password entry in /var/log/auth.log | 18:23 |
| programmerjake | port 922, not 22 | 18:23 |
| lkcl | (there are that many attempts to break in to libre-soc.org over ssh) | 18:23 |
| lkcl | yes, port 922. it's in HDL_workflow, how to edit ~/.ssh/config | 18:23 |
| jn | my gitolite setup works, all good | 18:23 |
| lkcl | jn: if you create a temporary branch (i hate branches) we can do a review and cherry-pick | 18:24 |
| jn | ok, good, will do. | 18:24 |
| lkcl | so, summary: | 18:24 |
| lkcl | 1) create temporary branch | 18:24 |
| programmerjake | or, do what I do and change all git remotes to ssh://gitolite3@git.libre-soc.org:922/soc.git or similar | 18:24 |
| lkcl | 2) don't use relative imports | 18:24 |
| lkcl | 3) anything in "unused" can be ignored completely. it's 3-year-old code, there only for reference | 18:25 |
| jn | temporary branch: https://git.libre-soc.org/?p=soc.git;a=shortlog;h=refs/heads/jn-tests | 18:26 |
| lkcl | 4) unit tests that fail, leaving them *as* failed, is "good" rather than "bad" | 18:26 |
| lkcl | excellent | 18:26 |
| lkcl | https://git.libre-soc.org/?p=soc.git;a=blobdiff;f=src/soc/simple/test/test_microwatt.py;h=3405bb4f3c44a8f94e2359afe0b9cead4a76423b;hp=b89867e480c06afcb83acbefd451db32e08653de;hb=4c8bed4eef558f4aff60b9c8426b8fbc1e1211eb;hpb=400eab497f4e1399075d0721ace375318d03226b | 18:27 |
| lkcl | good | 18:27 |
| lkcl | https://git.libre-soc.org/?p=soc.git;a=commitdiff;h=cad2fe8a590289a9be53719cb13a04c7abfba653 | 18:27 |
| lkcl | no diffs found there (?) | 18:27 |
| lkcl | https://git.libre-soc.org/?p=soc.git;a=commitdiff;h=400eab497f4e1399075d0721ace375318d03226b | 18:27 |
| lkcl | good | 18:27 |
| lkcl | https://git.libre-soc.org/?p=soc.git;a=commitdiff;h=c74e3015f1fe553b9120413c02ec89f9150fb423 | 18:27 |
| lkcl | drop that one. unnecessary. it's "unused" for a reason, as in "we aren't going to use it, so running it is not important, and it's never going to be installed in any package / distribution" | 18:28 |
| jn | oops, the empty commit is probably because i got distracted | 18:29 |
| lkcl | :) | 18:29 |
| lkcl | https://git.libre-soc.org/?p=soc.git;a=commitdiff;h=243e80326b06379a3214792f876d741ecf113fe1 | 18:29 |
| lkcl | good idea | 18:29 |
| jn | the issue with the unused dir is that the tests are still run and make noises | 18:29 |
| lkcl | https://git.libre-soc.org/?p=soc.git;a=commitdiff;h=662bf37049e5c813709228edb8a0b59af81ff1d3 | 18:29 |
| lkcl | right, this one is important *not* to skip these. | 18:29 |
| lkcl | tests that fail are GOOD. | 18:29 |
| lkcl | stopping them from running is a SERIOUS problem.... because then we think, "oh look, everything passes, we can ship the code" | 18:30 |
| lkcl | and spend USD 6 million on Foundry Masks only to find afterwards, when they don't work, that a unit test which showed some code failed had been SKIPPED. | 18:30 |
| jn | i'd prefer to use a test decorator that says "this one is known to fail sometimes, still run it but don't act surprised". but i haven't seen one like it in the unittest library | 18:30 |
| lkcl | yehyeh, me neither. i think it's just "against the grain". | 18:31 |
| lkcl | i.e. unit tests that fail is not a problem, because the catching of the exception (and reporting it) does not prevent *other* unit tests from failing. | 18:31 |
| lkcl | https://git.libre-soc.org/?p=soc.git;a=commitdiff;h=04423dd2be70bc4553d2e5d194b6a39fcf9047c4 | 18:31 |
| lkcl | good | 18:31 |
| lkcl | https://git.libre-soc.org/?p=soc.git;a=commitdiff;h=2255fb7c3918425ac786184aaef853f130d797dd | 18:32 |
| lkcl | no. we don't use relative imports. they are an absolute nuisance. | 18:32 |
| jn | ok, so the right thing would a full-path import? | 18:32 |
| lkcl | we run with "python3 setup.py develop" and then use full imports, which work from *any* position in the chain. | 18:32 |
| jn | ok | 18:33 |
| lkcl | well, i'm surprised it's not using the local directory | 18:33 |
| lkcl | as in: it's always been my understanding that python looks, as a first priority, in the same directory as the file with the "import" statement in it. | 18:33 |
| lkcl | but, it's "unused" so it's not relevant anyway | 18:34 |
| lkcl | https://git.libre-soc.org/?p=soc.git;a=blob;f=src/unused/simulator/test_sim.py;h=ff784f4170ecd0d05d463fc9aca8a68672150da8;hb=55f03506b16113b14339086f2c905f3f97645e70 | 18:34 |
| lkcl | ???? | 18:34 |
| lkcl | what on earth is that doing in "unused"??? | 18:34 |
| lkcl | that shouldn't be there *at all* | 18:34 |
| lkcl | could you check to see if that's a copy of openpower-isa/decoder/simulator/test_sim.py? | 18:35 |
| lkcl | it looks like it's a much older version, so should actually be deleted | 18:36 |
| jn | the move happened in https://git.libre-soc.org/?p=soc.git;a=commitdiff;h=32a529f4e7558a4da2d6d510b3be004be7ffa72d | 18:37 |
| lkcl | ngggh :) | 18:38 |
| lkcl | it's a copy of the qemu test_sim.py, i'll delete it | 18:38 |
| jn | alright | 18:38 |
| lkcl | ok so there's some great stuff here. | 18:40 |
| lkcl | does anyone know how to do cherry-pick with preserving commit attribution? | 18:40 |
| lkcl | or is that automatic? | 18:40 |
| lkcl | apparently https://stackoverflow.com/questions/61055041/git-cherry-pick-built-in-option-to-keep-original-committer-author | 18:41 |
| jn | AFAIK cherry-pick will automatically preserve the Author field and set the Committer field to your identity | 18:41 |
| jn | many of the remaining failing tests (which i didn't address) run into a timeout | 18:42 |
| lkcl | yes, that sounds about right. some of them are very long. some will genuinely be timing out. | 18:42 |
| jn | to name some examples: soc.experiment.test.test_dcbz_pi.test_dcbz_addr_zero, soc.experiment.test.test_compalu_multi.test_compunit, test_div_pipe_core (soc.fu.div.test.test_pipe_ilang.TestPipeIlang) | 18:43 |
| lkcl | dcbz we expect | 18:43 |
| lkcl | div one is just looooong | 18:43 |
| lkcl | ilang might be just also taking a long time | 18:44 |
| jn | the timeout is currently 2 minutes per test | 18:44 |
| lkcl | for DIV tests that may not be long enough | 18:44 |
| lkcl | ok all good. cherry-picked and pushed | 18:47 |
| jn | in some cases, e.g. soc.experiment.test.test_ldst_pi_misalign.test_misalign_mmu it doesn't look like a long test, so i'm wondering if they're hitting a pathological case for performance | 18:48 |
| jn | alrightm thanks! | 18:48 |
| jn | s/m/,/ | 18:49 |
| lkcl | jn: more likely, just breaking. | 18:49 |
| lkcl | that's raising an exception, and we haven't added exceptions yet. | 18:50 |
| jn | ah , i see | 18:50 |
| lkcl | jn: good stuff. keep it coming :) | 19:17 |
| jn | :-) | 19:20 |
| cesar | lkcl: I'd suggest creating a git tag on the hash that corresponds to the chip that was taped out. | 23:02 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!