| Las[m] | lkcl: Are the instructions for building the data used in soclayout/experiments9 documented anywhere? | 11:08 |
|---|---|---|
| lkcl | Las[m], 1 sec | 11:14 |
| lkcl | run this script | 11:15 |
| lkcl | https://git.libre-soc.org/?p=soclayout.git;a=blob;f=experiments9/build_full_4ksram.sh;h=050c7190f6ee0dc77b2b81eb9779772b9ffb85f1;hb=HEAD | 11:15 |
| lkcl | however | 11:15 |
| lkcl | bear in mind it takes NINETY MINUTES on high-end hardware with 32 GB of DDR4 RAM and NVMe SSDs | 11:16 |
| lkcl | by contrast | 11:16 |
| Las[m] | lkcl: I meant building the *data* used | 11:16 |
| Las[m] | as in | 11:16 |
| Las[m] | producing it | 11:16 |
| lkcl | alliance-check-toolkit go.sh takes around 20 minutes | 11:16 |
| lkcl | what do you mean by "data"? | 11:16 |
| Las[m] | You told me that you have some data you've generated and committed to that repository | 11:17 |
| lkcl | do you mean "the HDL verilog"? | 11:17 |
| Las[m] | Likely yeah | 11:17 |
| lkcl | yes, HDL verilog which was auto-generated by litex | 11:17 |
| lkcl | 1 sec | 11:17 |
| Las[m] | How do you get that? | 11:17 |
| Las[m] | BTW, what hardware are you using that `go.sh` takes around 20 minutes? | 11:18 |
| lkcl | https://git.libre-soc.org/?p=libresoc-litex.git;a=blob;f=Makefile;h=1bfeeb3e7747128f2886a762cad0a3d11ac29109;hb=6efd2e59703f6f0747435f97030e8a463233457f | 11:18 |
| lkcl | 4.8 ghz 8-core i9, 64 GB of 2400 mhz DDR4 RAM, and a 2 TB 2500 MB/s NVMe SSD | 11:18 |
| lkcl | a donated laptop that cost USD *FIVE THOUSAND* | 11:19 |
| lkcl | in the libresoc-litex git repo, run "make ls1804k" | 11:19 |
| lkcl | that will run the peripheral generator | 11:20 |
| lkcl | the step before_ that_ is to run this: | 11:20 |
| lkcl | https://git.libre-soc.org/?p=soc.git;a=blob;f=Makefile;h=3d4ea62db5a779f896d1f59665014783681f0523;hb=75bdc1747f32a4fb6cf848ed8b5c68ef2f683f4c#l53 | 11:20 |
| lkcl | "make ls180_4k_verilog" | 11:20 |
| Las[m] | lkcl: My Ryzen 5 1600 with 16 GB of RAM and some slow NVMe SSD took the same amount of time lol | 11:21 |
| Las[m] | Are you sure your laptop isn't throttling? | 11:21 |
| lkcl | that runs the nmigen-to-verilog conversion on the SoC, generating the core | 11:21 |
| Las[m] | I don't think it even took 20 minutes for `go.sh` | 11:21 |
| lkcl | Las[m], most things are only run single-core | 11:21 |
| lkcl | and yes, it usually throttles due to temperature | 11:21 |
| Las[m] | Well that explains that | 11:22 |
| lkcl | or, more to the point, i deliberately throttle it so that the laptop doesn't overheat | 11:22 |
| Las[m] | I think it's a nice laptop, but I honestly think laptops like that are a bad design choice | 11:22 |
| Las[m] | Just get a good stationary desktop which you can SSH into with your cheap laptop | 11:22 |
| lkcl | i can't carry a desktop machine on an airplane | 11:22 |
| lkcl | and i move locations typically once every eight months | 11:23 |
| Las[m] | You can ssh from airplanes nowadays | 11:23 |
| lkcl | that's about 80 times so far | 11:23 |
| lkcl | so, first step: | 11:23 |
| lkcl | build the verilog from nmigen | 11:23 |
| lkcl | second step: | 11:24 |
| lkcl | build the litex peripheral set | 11:24 |
| lkcl | third step: | 11:24 |
| lkcl | copy that into the soclayout | 11:24 |
| lkcl | fourth step: | 11:24 |
| lkcl | compile it to GDS-II | 11:24 |
| lkcl | Jean-Paul Chaput advised taking a snapshot of the full auto-generated source so that it's fully reproducible | 11:25 |
| lkcl | ghostmansd, all good with fixedstore | 11:26 |
| lkcl | will double-check with a manual read-through, and cherry-pick them over | 11:26 |
| lkcl | err ah ok you've already updated the master branch. | 11:27 |
| lkcl | i'll do a read-through then, just to make sure | 11:28 |
| lkcl | yep, all good. very simple/straightforward | 11:29 |
| Las[m] | Thanks. | 11:29 |
| ghostmansd | lkcl: thank you! I hope to dedicate some time today to update comparisons. | 11:31 |
| ghostmansd | Likely in the evening, when all the family falls asleep :-D | 11:31 |
| lkcl | ghostmansd: star. that one's intriguing. cmpeqb is particularly odd and needs special-casing | 11:32 |
| lkcl | :) | 11:32 |
| ghostmansd | Sometimes I feel like I'm doing something against the law, given the time and modus operandi | 11:32 |
| lkcl | sorry, cmprb. the range-comparison one | 11:32 |
| lkcl | it's really odd, isn't it? | 11:32 |
| lkcl | i get that all the time | 11:32 |
| ghostmansd | Yep. Like I'm a real gangsta, not a monkey-coder | 11:33 |
| lkcl | like, "are we even allowed to do something that is basically telling Intel, ARM, NVIDIA, AMD: you don't control everything any more"? | 11:33 |
| lkcl | nobody's stopped us so far, and NLnet's even paying for it, so... pffh :) | 11:34 |
| ghostmansd | lol, they're kinda like Moriarty, if we continue this analogy | 11:39 |
| ghostmansd | BTW so far nobody reached me from NLnet | 11:39 |
| ghostmansd | Should I reach them on my own? | 11:40 |
| lkcl | ah, right, ok, so there's an RFP process, we have to write (and email them). they deal with 100 projects so don't exactly have the time to contact people | 11:44 |
| lkcl | ha, great. page has this, i can jump straight to the bugreports. excellent | 11:45 |
| lkcl | ghostmansd, i've sent you the RFP template for both | 12:05 |
| lkcl | if you can fill them in and cc maciej then that saves him some work and he'll be happy | 12:06 |
| lkcl | because they're 50-50 (for this one) so he can literally send the exact same email with a different bank account and address | 12:06 |
| lkcl | but please send *me* the RFP for review *BEFORE* sending it to NLnet | 12:07 |
| lkcl | just without your home address and bank account | 12:07 |
| lkcl | did you get a transferwise online bank account? i can't remember | 12:08 |
| lkcl | if you haven't, do use this link http://transferwise.com/u/marier50 | 12:08 |
| kylel | grretings lkcl | 13:34 |
| lkcl | kylel, hii | 13:48 |
| kylel | Well where to now? | 13:48 |
| lkcl | you've been over that "first steps" thing? made some changes to the pseudocode and then got the corresponding unit test to "pass"? | 13:49 |
| lkcl | (then put it back again obviously :) ) | 13:50 |
| kylel | Yeah, he did nice work on that article. | 13:50 |
| lkcl | yeh it's really readable. | 13:50 |
| lkcl | awesome | 13:50 |
| * lkcl trying to think | 13:51 | |
| lkcl | we're missing some unit tests on rotate operations, i think | 13:51 |
| lkcl | there's a stack of them for running the HDL | 13:52 |
| lkcl | but none for testing the simulator | 13:52 |
| lkcl | where we check the *actual* results | 13:52 |
| lkcl | rather than assume that either the simulator *or* the HDL is correct | 13:53 |
| lkcl | how do you bootstrap up from that situation? | 13:53 |
| lkcl | how do you verify a simulator which is going to be used to confirm functionality (by comparison)... that the simulator *itself* is correct? | 13:53 |
| lkcl | we have these | 13:54 |
| lkcl | https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/test/shift_rot/shift_rot_cases.py;hb=HEAD | 13:54 |
| lkcl | but nothing _here_ | 13:55 |
| lkcl | https://git.libre-soc.org/?p=openpower-isa.git;a=tree;f=src/openpower/decoder/isa;h=95a2937086966062b7021335783290cc9a4ecf72;hb=HEAD | 13:55 |
| lkcl | which checks that the results of shift operations in the *simulator* are actually correct | 13:55 |
| lkcl | "boring" as it is, it's actually extremely important. if we can't rely on the simulator, that it gets correct results, we're pretty much royally screwed | 13:59 |
| kylel | At this stage in my life, I find boring good sometimes ;-) | 13:59 |
| lkcl | :) | 13:59 |
| lkcl | boring but strategically critically important, remember? | 14:00 |
| lkcl | so we need a test_caller_shiftrot.py | 14:00 |
| kylel | Indeed. A screwup here is quite costly. | 14:00 |
| kylel | And I was just going to ask so in short, a test caller. | 14:00 |
| lkcl | like... "USD 6 million on production mask" costly | 14:00 |
| lkcl | yes. | 14:00 |
| lkcl | if you wanted something a bit more "exciting" we have a long-term goal of abstracting out the entire unit test infrastructure | 14:01 |
| lkcl | so that there's: | 14:01 |
| lkcl | * a set of expected results | 14:01 |
| lkcl | * a "way-to-call-anything-that-executes-Power-ISA" | 14:01 |
| lkcl | * a "runner-of-said-executer" in a step-by-step fashion (one instruction at a time) | 14:02 |
| lkcl | * a "comparator-of-two-or-more-such-steppers" | 14:02 |
| lkcl | finally | 14:02 |
| lkcl | * a "comparator-against-the-above-mentioned-expected-results" | 14:02 |
| lkcl | the idea here being, there's a standard API by which we can check execution against *qemu* | 14:03 |
| lkcl | or... microwatt | 14:03 |
| lkcl | or... power-gem5 | 14:03 |
| lkcl | or... ssh-into-an-IBM-POWER9-system-and-remote-gdb-single-step | 14:03 |
| lkcl | but before that i'd suggest first actually getting used to the existing infrastructure | 14:04 |
| lkcl | which *can* already run co-simulation single-stepping against qemu (horribly slowly, mind) | 14:04 |
| lkcl | https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/decoder/isa/test_caller_svp64_bc.py;h=5378040085995813070ccaa9cbe28a1add9a5e81;hb=HEAD | 14:04 |
| lkcl | you can see a very very basic function, "check_regs" | 14:05 |
| lkcl | another version of that same function, here, which isn't even called (sigh) | 14:05 |
| lkcl | https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/decoder/isa/test_caller_fp.py;h=615ff5d5efda3b685487d3d603a2017b4d3bdbaf;hb=HEAD | 14:05 |
| lkcl | instead, you can see a bunch of manual self.assertEqual() calls | 14:05 |
| lkcl | which, guess what, is the brain-dead way to do it | 14:06 |
| kylel | so a rot caller it is | 14:08 |
| lkcl | awesome | 14:09 |
| kylel | a good exercise | 14:09 |
| lkcl | btw i'm just splitting out ISATestRunner into decoder/isa/test_runner.py | 14:09 |
| lkcl | done. | 14:11 |
| lkcl | so there's no danger of accidentally copying ISATestRunner (formerly in test_caller.py) multiple times by accidental cut/paste | 14:12 |
| kylel | cool | 14:13 |
| lkcl | kylel, feel free to make it *real* boring, by literally by-rote copying each case from shift_rot_cases.py | 14:13 |
| lkcl | however if you make it "generic" (random input, rather than fixed values) you'll probably likely need to write a python-based version of the Power ISA shift-rot operations | 14:14 |
| lkcl | which... well... if you choose to do that, i don't mind at all, but if you do, please do cross-reference them in the comments to the relevant Power ISA v3.0B specification section and page number | 14:14 |
| lkcl | https://ftp.libre-soc.org/PowerISA_public.v3.0B.pdf | 14:15 |
| lkcl | like, | 14:15 |
| lkcl | """rwlwinm implementation for test purposes. implements Power ISA v3.0B Book I Section 3.3.14.1 p102""" | 14:17 |
| kylel | Got an example for that? | 14:18 |
| lkcl | i don't mind either way, if you do something "brain-dead" (fixed, static values) or a more generic version | 14:18 |
| lkcl | well, the majority of tests are brain-dead static values | 14:18 |
| lkcl | e.g. 1 sec | 14:18 |
| lkcl | https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/decoder/isa/test_caller.py;h=8d2c0020c9d23a0ad311dce95e967a658dec074a;hb=HEAD#l167 | 14:19 |
| lkcl | i mean, we _know_ 0x1234 + 0x4321 = 0x5555 so, duh, it's blindingly obvious | 14:19 |
| kylel | right | 14:20 |
| lkcl | but for when i did the SVP64 Discrete Cosine Transform whoooaaaa | 14:20 |
| lkcl | no way was i going to calculate a DCT "by hand" | 14:20 |
| lkcl | so i wrote a python-version of DCT (actually, adapted Nayuki's simple DCT code) | 14:20 |
| lkcl | and extracted the "expected" values after running the simulator | 14:21 |
| lkcl | https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/decoder/isa/test_caller_svp64_dct.py;h=61bf549437006ba47d2863a0fd8679d773b1206a;hb=HEAD#l363 | 14:21 |
| lkcl | compare expected against actual, if false assert. | 14:21 |
| lkcl | so does that give you some increasing levels of sophistication to choose from, and work towards? | 14:22 |
| kylel | Yes indeed, thank you. | 14:23 |
| lkcl | :) | 14:23 |
| lkcl | ok cool. need food here. | 14:23 |
| kylel | Quick question, why the change to xlen? | 14:23 |
| lkcl | ahh quick question, but not quick answer :) | 14:24 |
| kylel | ahh no biggie, go eat ;-) | 14:24 |
| lkcl | SVP64 has the ability to *override* the register width | 14:24 |
| lkcl | 1 sec, finding link... | 14:24 |
| lkcl | https://libre-soc.org/openpower/sv/overview/#index6h1 | 14:24 |
| lkcl | that one's an important document for understanding the (DRAFT) Vector System we're dropping on top of Power ISA v3.0B as the scalar "base". | 14:25 |
| kylel | gotcha | 14:26 |
| lkcl | look up the x86 "REP" instruction, for the basic concept, then "inject" that concept with a massive boost of Cray-style Vector steroids | 14:26 |
| lkcl | :) | 14:26 |
| ghostmansd-pc | > https://libre-soc.org/irclog/%23libre-soc.2021-09-04.log.html#t2021-09-04T14:09:44 | 17:52 |
| ghostmansd-pc | switched test_caller_bcd.py | 17:53 |
| ghostmansd-pc | hm, not yet, gotta think about pdecode instance | 17:54 |
| ghostmansd-pc | ok, test_caller_bcd tests are in progress... checking test_caller meanwhile... | 18:01 |
| ghostmansd-pc | both test_caller and test_caller_bcd work; had to teach run_tst to take custom pdecode2 instance | 18:10 |
| ghostmansd-pc | pushed into master | 18:10 |
| ghostmansd-pc | A question on comparisons. Based on L field, the operation is either on 32-bit values (if L=0), or 64-bit (L=1). Should we do the following: if L=0, operate on half of XLEN, otherwise operate on full XLEN? | 18:21 |
| lkcl | ghostmansd-pc: ahh excellent. hmm we had that at one point already... ah ha! ok i see | 18:35 |
| ghostmansd-pc | cmprb would work only on 32-bit and 64-bit based on what I see | 18:36 |
| lkcl | passing in a pdecode2 as an option, excellent | 18:36 |
| lkcl | yes, totally. | 18:36 |
| ghostmansd-pc | and cmpeqb, as you mentioned, must be rewritten | 18:36 |
| lkcl | let me just check again | 18:36 |
| ghostmansd-pc | at the same time... specs explicitly mention the behavior is undefined in 32-bit mode | 18:37 |
| lkcl | cmprb would work when elwidth=32/elwidth=64 | 18:37 |
| lkcl | but be "UNDEFINED" if elwidth=16/8 | 18:37 |
| lkcl | so it would still be the "XLEN-8:XLEN-1" trick | 18:38 |
| ghostmansd-pc | > cmprb would work when elwidth=32/elwidth=64 | 18:38 |
| ghostmansd-pc | yep, that's what I said :-) | 18:38 |
| lkcl | :) | 18:38 |
| lkcl | cmpeqb on the other hand could use a loop for i = 0 to (XLEN/8)-1 | 18:39 |
| lkcl | reducing down to a single-byte "cmp" on elwidth=8 | 18:39 |
| ghostmansd-pc | ah, I see... | 18:40 |
| lkcl | cmpli, L=0/1, using half of XLEN? that's a really good idea | 18:40 |
| ghostmansd-pc | so we compare as much bytes as available in RB, but always take only one byte from RA? | 18:41 |
| ghostmansd-pc | yep | 18:41 |
| lkcl | i can see that being very useful, even for elwidth=8, where you check only 4 bits | 18:41 |
| ghostmansd-pc | you might opt to take a look at xlen branch | 18:41 |
| lkcl | yes, as many bytes... ah ok :) | 18:41 |
| ghostmansd-pc | I've just updated it | 18:41 |
| ghostmansd-pc | will now check the test_issuer.py | 18:41 |
| lkcl | cmpli great | 18:42 |
| ghostmansd-pc | FWIW... why on Earth they all are called fixed${something}, but we also have comparefixed? | 18:43 |
| lkcl | i don't know! | 18:44 |
| lkcl | a minor fault in reality? | 18:44 |
| * lkcl running test_cr_compunit.py | 18:45 | |
| lkcl | all good | 18:45 |
| lkcl | now to actually check whether cmpli etc are in it :) | 18:45 |
| ghostmansd-pc | test_issuer.py is in progress | 18:45 |
| lkcl | ./test/alu/alu_cases.py: def case_cmpeqb(self): | 18:46 |
| lkcl | ./test/alu/alu_cases.py: lst = ["cmpeqb cr1, 1, 2"] | 18:46 |
| ghostmansd-pc | oops, forgot to update cmpeqb | 18:46 |
| ghostmansd-pc | loop needed | 18:46 |
| * lkcl reading the diffs... | 18:46 | |
| lkcl | cmpli looks good | 18:47 |
| lkcl | cmp looks good | 18:47 |
| lkcl | cmpl sorry, right, yes, looks good | 18:48 |
| lkcl | cmpli... complicated... ah. right. that will break when elwidth=8 | 18:48 |
| lkcl | XLEN-16 will go *negative* when XLEN=8 | 18:50 |
| lkcl | drat. drat-drat-drat. are there any others like that? | 18:50 |
| ghostmansd-pc | force updated xlen with cmpeqb | 18:51 |
| ghostmansd-pc | yep | 18:51 |
| lkcl | ack | 18:51 |
| ghostmansd-pc | but actually actually only cmprb and cmpli are not "flexible" | 18:52 |
| lkcl | find . -name "*.mdwn" | xargs grep "XLEN-16" | 18:52 |
| lkcl | fixedload and fixedstore, those are UNDEFINED behaviour ones | 18:52 |
| ghostmansd-pc | yep | 18:53 |
| lkcl | there's a couple of fixedlogical ones | 18:53 |
| ghostmansd-pc | that's why I bothered so much about the semantics :-) | 18:53 |
| ghostmansd-pc | whether they should operate on 1/4 of register, or should deal with 16 bits | 18:54 |
| lkcl | andi, ori, xori | 18:54 |
| lkcl | yeeehh | 18:54 |
| lkcl | ok will raise a separate bugreport for all these | 18:54 |
| ghostmansd-pc | because, well, if we'd written the spec, I'd rather go with 1/4 of register | 18:54 |
| lkcl | cmpl looks good | 18:55 |
| ghostmansd-pc | (which becomes 2 bits in 8, but hey) | 18:55 |
| lkcl | cmprb looks good | 18:55 |
| lkcl | well, we have to think, "is that useful"? | 18:55 |
| lkcl | for a Vector Processor / 3D GPU | 18:56 |
| ghostmansd-pc | perhaps dealing with nibbles on 16-bit might sometimes be, but I wouldn't bet on it | 18:56 |
| lkcl | which is going to be doing 3D Shader binaries (games etc.), Video Processing, etc. | 18:56 |
| lkcl | and probably (sigh) AI | 18:57 |
| ghostmansd-pc | well, those actually tend to use things like BF16 and FP16 | 18:57 |
| ghostmansd-pc | so yep, operations on individual 16-bit values might be good | 18:57 |
| ghostmansd-pc | though they generally prefer to operate on pack of those | 18:58 |
| lkcl | funny that, we're adding BF16/FP16 | 18:58 |
| ghostmansd-pc | e.g FMA | 18:58 |
| lkcl | funny that, we're allowing Vectorised FP16/BF16... | 18:59 |
| lkcl | :) | 18:59 |
| ghostmansd-pc | :-D | 18:59 |
| ghostmansd-pc | test_issuer is still running... | 18:59 |
| ghostmansd-pc | never surrender | 18:59 |
| lkcl | i'm doing test_cr_compunit.py and test_alu_compunit.py | 18:59 |
| lkcl | they run waaay quicker | 18:59 |
| lkcl | pass | 19:00 |
| ghostmansd-pc | that's OK when you know what to launch :-) | 19:00 |
| lkcl | pass | 19:00 |
| lkcl | now you do, too | 19:00 |
| lkcl | oo. | 19:00 |
| lkcl | ah. | 19:00 |
| ghostmansd-pc | since I lacked this information, I chose the obvious option | 19:00 |
| lkcl | cmpeqb failed | 19:00 |
| lkcl | well, i actually didn't know | 19:00 |
| lkcl | i did "find . -name "*.py" | xargs grep cmpeqb" | 19:00 |
| ghostmansd-pc | https://libre-soc.org/irclog/%23libre-soc.2021-09-04.log.html#t2021-09-04T18:51:07 | 19:00 |
| ghostmansd-pc | did you take the recent one? | 19:01 |
| lkcl | and test/alu/alu_cases.py came up | 19:01 |
| lkcl | i believe so, yes. | 19:01 |
| lkcl | whoops didn't run pywriter noall fixedarith | 19:01 |
| lkcl | doh | 19:01 |
| ghostmansd-pc | looks like the loop is the cause | 19:02 |
| ghostmansd-pc | I checked on version which I forgot to update | 19:02 |
| lkcl | urr i'm not seeing a cmpeqb here | 19:03 |
| lkcl | https://git.libre-soc.org/?p=openpower-isa.git;a=shortlog;h=refs/heads/xlen | 19:03 |
| ghostmansd-pc | heck | 19:04 |
| ghostmansd-pc | it got merged with the last commit | 19:04 |
| lkcl | whoops :) | 19:04 |
| lkcl | i'd use an if statement there | 19:05 |
| lkcl | if src1=RB[..] match <- 1 | 19:05 |
| lkcl | on one line | 19:05 |
| lkcl | ohhh i see | 19:05 |
| ghostmansd-pc | please re-check | 19:05 |
| lkcl | match <- 0b1 | 19:05 |
| ghostmansd-pc | match should be 0 | 19:06 |
| lkcl | as the initial var.... yes :) | 19:06 |
| ghostmansd-pc | lol | 19:06 |
| ghostmansd-pc | shared mind | 19:06 |
| ghostmansd-pc | pushed the update | 19:06 |
| lkcl | got it | 19:06 |
| lkcl | ran pywriter on fixedarith by mistake sigh | 19:06 |
| ghostmansd-pc | lol | 19:07 |
| ghostmansd-pc | it's all that damned guide! | 19:07 |
| lkcl | all good | 19:07 |
| ghostmansd-pc | I also hit the same issue | 19:07 |
| lkcl | it's pressing up-arrow on a bash terminal not enough times wot dunnit | 19:07 |
| ghostmansd-pc | after writing that tutorial I kept writing fixedarith for a while | 19:07 |
| lkcl | all good | 19:07 |
| lkcl | passes | 19:07 |
| ghostmansd-pc | File "/usr/lib/python3.9/unittest/case.py", line 500, in subTest | 19:08 |
| ghostmansd-pc | AttributeError: 'NoneType' object has no attribute 'success | 19:08 |
| ghostmansd-pc | ??? | 19:08 |
| ghostmansd-pc | python3 ./src/soc/fu/compunits/test/test_cr_compunit.py | 19:08 |
| lkcl | ehn?? | 19:08 |
| ghostmansd-pc | ah, it looks like it hit ctrl+c | 19:08 |
| lkcl | moo? | 19:08 |
| lkcl | oh well that's ok then | 19:08 |
| lkcl | bizarre | 19:09 |
| lkcl | ok happy with those, to push over to master branch when you're ready | 19:09 |
| lkcl | i'll run test_issuer.py here as well | 19:09 |
| lkcl | btw you're running it with the nosvp64 option right? saves a loootta time | 19:10 |
| ghostmansd-pc | checked cr_compunit | 19:10 |
| ghostmansd-pc | checking test_issuer | 19:10 |
| ghostmansd-pc | thanks for reminder on nosvp64 | 19:10 |
| lkcl | and also test_alu_compunit.py | 19:10 |
| ghostmansd-pc | last time ran w/o it | 19:10 |
| ghostmansd-pc | doesn't test_issuer include test_alu_compunit and test_cr_compunit? | 19:11 |
| * lkcl trying to remember why cmpeqb is in ALU | 19:11 | |
| lkcl | it does | 19:11 |
| lkcl | but it also includes.... logical ldst general branch etc. etc. etc. | 19:11 |
| lkcl | div mul... it's why it takes ages | 19:11 |
| ghostmansd-pc | ah, ok, so test_alu_compunit and test_cr_compunit are for quick checks, gotcha | 19:12 |
| lkcl | yehyeh | 19:12 |
| lkcl | much quicker because they don't even deal with regfiles. | 19:12 |
| lkcl | they're literally testing a raw pipeline | 19:12 |
| lkcl | test_issuer.py all good | 19:23 |
| ghostmansd-pc | test_issuer works | 19:26 |
| ghostmansd-pc | lok | 19:26 |
| ghostmansd-pc | lol | 19:26 |
| ghostmansd-pc | ok, I'm now rebasing the master | 19:26 |
| ghostmansd-pc | pushed! | 19:27 |
| ghostmansd-pc | so far so good | 19:28 |
| lkcl | excellent | 19:28 |
| ghostmansd-pc | what our next steps? | 19:28 |
| ghostmansd-pc | I've been thinking of madd tests | 19:28 |
| ghostmansd-pc | but I'm open to your suggestions | 19:28 |
| lkcl | yyeah they're not implemented in the HDL at the moment | 19:28 |
| lkcl | so yes would need some openpower-isa unit tests before being able to proceed | 19:28 |
| lkcl | go for it, raise a bugreport (or see if one exists) | 19:29 |
| lkcl | make sure to always cross-ref to at least one other vaguely-relevant bugreport | 19:29 |
| ghostmansd-pc | I guess most of things we dealt with don't have tests in openpower-isa, except for fixedarith | 19:29 |
| lkcl | ah 681 already exists | 19:30 |
| lkcl | it's a bit sporadic / piecemeal | 19:30 |
| lkcl | one of the reasons i asked kylel if he could do some shiftrot ones | 19:31 |
| ghostmansd-pc | yep, got it | 19:31 |
| * lkcl will check what else needs converting | 19:32 | |
| ghostmansd-pc | I think I'll start with madd and will also re-visit those I modified for XLEN | 19:32 |
| lkcl | bcd.mdwn | 19:32 |
| ghostmansd-pc | ah, yes | 19:32 |
| ghostmansd-pc | totally forgot about it | 19:32 |
| ghostmansd-pc | these are a bit weird | 19:32 |
| lkcl | yes | 19:33 |
| ghostmansd-pc | (well, we knew it, but this time I'm not about semantics) | 19:33 |
| ghostmansd-pc | these deal with AT LEAST 12 or 10 bits at once | 19:33 |
| lkcl | yehyeh | 19:33 |
| ghostmansd-pc | generally speaking, as many 10/12 bits as fits in the register | 19:33 |
| ghostmansd-pc | so I suspect xlen=8 is already the outsider | 19:34 |
| lkcl | that's going to be fun | 19:34 |
| ghostmansd-pc | as for xlen=16, it's up to 1 | 19:34 |
| lkcl | where the heck is isel | 19:34 |
| ghostmansd-pc | what's isel? | 19:34 |
| lkcl | fixedtrap | 19:35 |
| lkcl | return a ? b : c | 19:35 |
| lkcl | twi and tdi need converting to XLEN/2 | 19:36 |
| * lkcl need to get up and walk about | 19:38 | |
| ghostmansd-pc | em, tdi doesn't have bits | 19:38 |
| ghostmansd-pc | other than TO[XXX], which I have no idea what means | 19:38 |
| ghostmansd-pc | twi has it, though | 19:38 |
| ghostmansd-pc | same is tw | 19:39 |
| ghostmansd-pc | this makes tw and twi | 19:39 |
| lkcl | yes i meant tw and twi sorr | 20:14 |
| lkcl | y | 20:14 |
| ghostmansd | lkcl: I already have transferwise account, but it's tied to my primary e-mail | 21:15 |
| lkcl | yes, a transferwise *account* is not the same as a transferwise *bank* account. | 21:38 |
| lkcl | NLnet can make wire transfers directly to a transferwise *bank* account with zero bank transfer fees incurred... *if* that transferwise *bank* account is in Europe. | 21:39 |
| lkcl | which you can do - online - by applying for a transferwise *bank* account and asking for it to be in EUR | 21:39 |
| lkcl | if you choose to do that, you get more $ (no bank transfer fees) | 21:40 |
| rsc | Well, bank transfers must be free when sender's and recipient's banks are in SEPA region and both bank accounts are hold in EUR currency. | 21:42 |
| rsc | And note, SEPA != Europe. | 21:43 |
| rsc | (and of course the sender has no way to figure out in which currency the recipient's account is hold) | 21:44 |
| lkcl | whiich is why, registering on transferwise for a *bank* account and applying for a EUR currency *bank* account results in zero transfer fees. | 21:48 |
| lkcl | thx rsc | 21:48 |
| rsc | Yes. But usually (German) banks are charging for additional bank accounts. | 21:48 |
| rsc | (not to forget for devise bank accounts, e.g USD) | 21:48 |
| rsc | And if you're in non-EUR, but SEPA, these banks usually charge separately for EUR bank account ;-( | 21:49 |
| ghostmansd | I _think_ I have some account in EUR | 22:44 |
| ghostmansd | I'm not sure whether it's bank or not, but I have some fields like IBAN and BIC, along with my name | 22:45 |
| ghostmansd | There are even options for those, including SEPA | 22:46 |
| ghostmansd | Actually I will have to pay some fees anyway, since ultimately one day I'll have to convert it to national currency :-) | 22:46 |
| ghostmansd | I think what I have is called "Euro account" | 22:48 |
| lkcl | ok that sounds perfect | 22:52 |
| lkcl | yes, but at least with transferwise they charge the middle rate | 22:52 |
| ghostmansd | When I check the requisites, they tell there are two options, one for European Union/ SEPA zone, and one for outside | 22:52 |
| ghostmansd | Or should I say "for outsiders", lol | 22:52 |
| ghostmansd | I guess fees-wise, that'd be the latter | 22:53 |
| ghostmansd | So, if I understood correctly, I must supply the EU/SEPA details to NLNet? | 22:54 |
| lkcl | that would be better, yes. | 22:54 |
| ghostmansd | off-topic: Luke, what do you think of XLEN-based logicals? I really would like to avoid a custom case for XLEN=8. | 22:55 |
| lkcl | yehhh i know | 22:55 |
| ghostmansd | That said, 2 bits for XLEN=8 is strange as well... | 22:55 |
| lkcl | it's likely unavoidable, because xori for XLEN=8 is actually useful | 22:55 |
| ghostmansd | But at least fits the overall idea | 22:55 |
| ghostmansd | But they ultimately concatenate bits | 22:55 |
| ghostmansd | Even if we use 8 bits of UI, that, along with other concatenated, makes more than 8 bits | 22:56 |
| ghostmansd | Or do you suggest to take 8 bits of result? | 22:56 |
| lkcl | exactly, which means the concatenation has to go... | 22:56 |
| lkcl | ... yes | 22:56 |
| ghostmansd | It'd be great if you wrote an example | 22:57 |
| lkcl | effectively it's reg[0..7] XOR UI[0..7] | 22:57 |
| ghostmansd | And, especially, the intended use case | 22:57 |
| lkcl | or (sigh) reg[0..7] XOR UI[8:15] because UI will still be 16-bit and in MSB0 numbering you grab the lower byte with 8..15 | 22:58 |
| ghostmansd | Whenever possible, it'd be great to have a unified semantics. | 22:58 |
| ghostmansd | That's why I thought of crap like "take 1/4 of width" | 22:58 |
| lkcl | if XLEN=8 then | 22:59 |
| lkcl | RA <- (RS) ^ UI[8:15] | 22:59 |
| ghostmansd | "then take owl eyes, bat wings, throw in a bowl, and wait for a full moon" | 22:59 |
| lkcl | except that's meaningless / not useful unfortunately. | 23:00 |
| lkcl | :) | 23:00 |
| * lkcl cackles | 23:00 | |
| lkcl | https://bugs.libre-soc.org/show_bug.cgi?id=684#c6 | 23:00 |
| ghostmansd | Yep, usability is really limited :-D | 23:00 |
| ghostmansd | 2 bits per poor man | 23:01 |
| ghostmansd | "I took 2 bits of those 16 you used to encode the instruction" | 23:01 |
| ghostmansd | I guess they'd say the ISA is implemented by total assholes | 23:01 |
| lkcl | or we took acid | 23:02 |
| ghostmansd | :-D | 23:02 |
| ghostmansd | Indeed, that'd explain such ISA | 23:02 |
| ghostmansd | I liked the MP | 23:02 |
| ghostmansd | Quite well explanatory | 23:02 |
| ghostmansd | I meant the reference you posted | 23:03 |
| * lkcl was wondering what MP was... | 23:03 | |
| ghostmansd | Perhaps should be present in Appendix C | 23:03 |
| lkcl | oh you mean the monty python youtube video? | 23:03 |
| lkcl | ha i must find something... | 23:03 |
| ghostmansd | Monty Python | 23:03 |
| ghostmansd | Yep | 23:04 |
| lkcl | https://twitter.com/ppcinstructions | 23:04 |
| ghostmansd | mscdfr - Means Something Completely Different For r0 | 23:04 |
| ghostmansd | AAAAAAAAAAA | 23:05 |
| lkcl | https://twitter.com/ppcinstructions/status/557641420987990016 | 23:05 |
| ghostmansd | I wish something like this is done for x86 | 23:05 |
| lkcl | there really is an instruction "eieio" in ppc64 | 23:05 |
| ghostmansd | cast programmerjake! | 23:05 |
| lkcl | twerk | 23:05 |
| ghostmansd | vcfucc is instruction of our choice | 23:06 |
| lkcl | trap word extended and rotate keyboard | 23:06 |
| ghostmansd | That's actually brilliant | 23:06 |
| lkcl | there's also a ppc64 instruction called "dozi" | 23:06 |
| ghostmansd | I guess we have a reference guide, lol | 23:06 |
| lkcl | for real | 23:07 |
| lkcl | difference or zero immediate | 23:07 |
| lkcl | sadly it's been retired around Power ISA v2.07 | 23:07 |
| ghostmansd | Such an opportunity lost... | 23:08 |
| lkcl | https://www.ibm.com/docs/en/aix/7.2?topic=set-eieio-enforce-in-order-execution-io-instruction | 23:08 |
| ghostmansd | Didn't quite get, is it some kind of barrier? | 23:09 |
| ghostmansd | https://youtu.be/O4RNIUrLLH0 | 23:10 |
| jn | ghostmansd: https://twitter.com/x86instructions/ exists, but it contains other chatter besides funny instruction names | 23:10 |
| ghostmansd | With a moo-moo here and a moo-moo there | 23:10 |
| ghostmansd | https://twitter.com/x86instructions/status/1272662575344308224?s=20 | 23:13 |
| ghostmansd | Lol, that's probably the best | 23:13 |
| ghostmansd | Ok it's 1 AM here | 23:14 |
| ghostmansd | Should have some rest | 23:14 |
| ghostmansd | Thanks for moments of good and healthy laugh (probably not, since, sigh, only real psychopaths like programmers can laught at this, most people would really struggle at this) | 23:17 |
| ghostmansd | Bye! | 23:17 |
| jn | eh, don't worry, programmer culture is culture too :) | 23:19 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!