| markos | ok, finally, fmvis tests pass, I'm able to load float immediates, I couldn't make it work before because I was stupidly trying to make it work with expected_regs, but I needed to use expected_fprs :) | 10:18 |
|---|---|---|
| markos | lkcl, I'm ready to commit, I saw in the bug report that you want me to commit minor_22.csv separately, but the rest should all go in one commit, right? | 10:18 |
| markos | ie, test cases, etc | 10:18 |
| lkcl | markos, doh :) | 10:58 |
| lkcl | if you've everything just commit it | 10:59 |
| markos | ok | 11:00 |
| markos | uhm, I still have the https git url | 11:04 |
| markos | is there a git+ssh or should I do https auth? | 11:05 |
| markos | I think I've already sent the ssh pubkey | 11:05 |
| programmerjake | assuming you mean openpower-isa.git, just use ssh://gitolite3@git.libre-soc.org:922/openpower-isa.git | 11:13 |
| programmerjake | just replace the https url in .git/config | 11:13 |
| markos | yup, that one, this worked, thanks | 11:14 |
| markos | git commit 51ebd21 | 11:15 |
| programmerjake | yw | 11:15 |
| markos | ok, first commit, so if I've done anything really bad, please be gentle :) | 11:15 |
| programmerjake | ci in case you're curious: https://salsa.debian.org/Kazan-team/mirrors/openpower-isa/-/jobs/3038706 | 11:19 |
| programmerjake | ci was broken before, so, no, you're not responsible for having broken it | 11:27 |
| markos | ah nice | 11:51 |
| markos | good to know | 11:52 |
| markos | what CI software is this? | 11:52 |
| markos | been struggling with jenkins so far, it gets the job done but when I try to do anything advanced I get in trouble | 11:53 |
| markos | ah wait, I only did the fmvis, not the 2nd half variant | 11:54 |
| lkcl | markos, fantastic, i'll take a look shortly, i'm just in the middle of replying to jacob bachmeyer | 12:01 |
| lkcl | programmerjake, thx for sorting things for markos | 12:02 |
| markos | now that I got the hang of it, what's the 2nd variant supposed to do? | 12:02 |
| lkcl | jb was on the riscv-isa-dev mailing list back in 2018 (and even before) | 12:02 |
| lkcl | loading in the lower half immediate into the same register you just wrote the top half into | 12:02 |
| lkcl | so it's actually a read-modify-write instruction | 12:03 |
| markos | but keeping the first half? | 12:03 |
| markos | so essentially with a fmvis+ 2nd variant one can load a full 32-bit float constant? | 12:04 |
| markos | what's the name of the 2nd variant again? :) | 12:04 |
| lkcl | yes. | 12:06 |
| lkcl | *not* fishmv :) | 12:07 |
| markos | fmvish? | 12:07 |
| lkcl | https://libre-soc.org/openpower/sv/int_fp_mv/ | 12:07 |
| lkcl | haha i like that one | 12:07 |
| lkcl | sooort-of vaguely, if you maybe feel inclined, mv the FP reg for me? | 12:08 |
| lkcl | i *think* i have added RS as an "OUT" for you already, in advance, here.... 1 sec... | 12:08 |
| markos | sure, just tell me where to do that, things have changed in the code lately as I see | 12:09 |
| lkcl | https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/decoder/power_enums.py;h=a5e928806aedae9ce3cae898fd744cd693c5f7f7;hb=51ebd21c50d53275e8dd828a997433175b6dd2a2#l520 | 12:09 |
| lkcl | yep, all good | 12:09 |
| lkcl | and it's also an in1 | 12:10 |
| lkcl | https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/decoder/power_enums.py;h=a5e928806aedae9ce3cae898fd744cd693c5f7f7;hb=51ebd21c50d53275e8dd828a997433175b6dd2a2#l474 | 12:10 |
| lkcl | so this is relevant for the minor_22.csv | 12:10 |
| lkcl | you need to specify RS *twice* | 12:10 |
| lkcl | once in the in1 column | 12:10 |
| lkcl | once in the out column | 12:10 |
| markos | like in fmvis | 12:10 |
| markos | you mean FRS | 12:10 |
| lkcl | ah, yes, sorry. | 12:11 |
| lkcl | 1 sec... | 12:11 |
| lkcl | did i add FRS to out? yes | 12:11 |
| markos | I guess so, otherwise the tests wouldn't pass :) | 12:11 |
| lkcl | ahh... err... fmvis it's both an in and out? that's... err... | 12:11 |
| markos | you said I had to do that | 12:12 |
| markos | as in1 can't be an SI | 12:12 |
| lkcl | rrright, ok, fmvis is not a read-modify-write because the upper parts are zero'd | 12:12 |
| lkcl | yes, but i was probably referring to fishmv needing to be read-modify-write not fmvis, apologies if that wasn't clear | 12:12 |
| lkcl | it does mean that you can literally cut/paste the fmvis line in minor_22.csv though :) | 12:13 |
| markos | ok, that's good | 12:13 |
| markos | but I'm confused, which one is it now, fishmv, frlsi or fmvish? :) | 12:13 |
| lkcl | but you _will_ have to recompile (pywriter noall av) | 12:13 |
| lkcl | frlsi. | 12:14 |
| markos | ok, yes ofc | 12:14 |
| lkcl | as in the spec | 12:14 |
| lkcl | the pywriter compiler actually reads all of the CSV files in order to identify which registers are read and which are written to | 12:14 |
| lkcl | and actually creates function-call parameters with the incoming registers as arguments if they are in in1/2/3. | 12:15 |
| lkcl | so what you should find, if you inspect decoder/isa/av.py, is that after making in1=NONE for fmvis, that the RS argument magically disappears | 12:16 |
| lkcl | have you looked at the auto-generated compiler output from pywriter at all? i occasionally put in debug print() statements in it to see what the hell's going on | 12:17 |
| markos | yes all the time, that's how I found out that the FRPs were actually changed by fmvis :) | 12:19 |
| markos | it's hard to follow, but all the info is there | 12:20 |
| markos | interesting | 12:21 |
| markos | these 2 make for an interesting feature | 12:21 |
| lkcl | yeah, i made sure every bit-level operation is dumped out, because, well, this is the only way you find out if you made bit-level mistake | 12:22 |
| lkcl | s | 12:22 |
| markos | you could load the top-half of some constants | 12:22 |
| markos | and with flrsi you could use the result of fmvis and generate a ton of fp full constants with the lower-half changing only | 12:22 |
| markos | where FRS is different than RS | 12:23 |
| markos | er, where OUT != IN1 | 12:23 |
| markos | hm, wait | 12:24 |
| markos | a few days ago, you told me to use 3 operands, now I see 2 | 12:24 |
| markos | in fact, flrsi could use 3 | 12:24 |
| markos | flrsi OUT, IN, imm | 12:25 |
| markos | and IN might be different than OUT, for the above reason | 12:25 |
| markos | eg. say you have the following constants | 12:25 |
| markos | 0x41298733 and 0x41298742 | 12:25 |
| markos | fmvis would load 0x41290000 to eg. reg 3 | 12:26 |
| markos | and you use flrsi 4, 3, 0x8733 and flrsi 3, 3, 0x8742 | 12:26 |
| markos | and voila | 12:26 |
| markos | you have 2 fp constants loaded with 2 instructions only | 12:27 |
| lkcl | no, there's nowhere near enough space in 32-bit to do that. unfortunately. | 12:27 |
| lkcl | hence why flrsi is an (extremely rare / unique) load-modify-write | 12:28 |
| markos | ok, I see | 12:28 |
| lkcl | + # V3.0B 1.6.6 DX-FORM | 12:28 |
| lkcl | + # |0 |6 |7|8|9 |10 |11|12|13 |15|16|17 |26|27 |31 | | 12:28 |
| lkcl | + # | PO | FRS | d1 | d0 | XO |d2 | | 12:28 |
| lkcl | where would the 2nd register fit? | 12:28 |
| lkcl | 16-bits of immediate is *really* expensive | 12:29 |
| markos | ah I see | 12:29 |
| lkcl | there's such an insane amount to consider with ISA development! | 12:31 |
| markos | ok, I fixed minor_22.csv and put NONE for in1, changed the syntax, ran the sv_analysis, power_fields.py, etc but now the test complains that I supplied 2 values instead of 3, what do I have to update? | 12:44 |
| markos | never mind | 12:45 |
| markos | stupid me, found it | 12:45 |
| lkcl | :) | 12:45 |
| lkcl | funny this IRC chat system isn't it. | 12:45 |
| lkcl | it's like a magic debug system | 12:45 |
| lkcl | you only have to type out the problem and voila! you find the solution! | 12:46 |
| lkcl | ghostmansd[m] was doing that routinely, a few months back | 12:46 |
| markos | for it's been years and I'm still doing it | 12:46 |
| markos | ^for me | 12:46 |
| ghostmansd[m] | lkcl, markos, yeah I'm probably the most affirmative example this magic system works | 12:50 |
| lkcl | markos, do drop that in as a separate commit *before* proceeding to flrsi, with suitable explanation | 12:51 |
| lkcl | it's definitely fitting the "one purpose, one commit". | 12:51 |
| lkcl | where the previous one was also same, and nice, because it's everything-in-one. | 12:51 |
| lkcl | i'm going to add it to the list of examples "how to add an instruction" | 12:52 |
| lkcl | general rule, if you're ever tempted to use the word "and" in a commit message, stop immediately :) | 12:54 |
| * lkcl frickin mental headache, have to deal with it | 12:55 | |
| ghostmansd[m] | > stop immediately | 12:56 |
| ghostmansd[m] | ...and use a semicolon, for God's sake! | 12:56 |
| * lkcl snorts | 13:22 | |
| markos | hm, no, that wasn't it, apparently method av() in svp64.py needs 3 operands (RT, RA, RB), so if I want just 2, then I have to provide my own method or I am missing something | 13:39 |
| markos | and I did wrong anyway, because I have added fmvis both in the custom_insns array AND the list of insns handled by av | 13:43 |
| markos | obviously the av one worked as it was able to handle the conversion automatically | 13:43 |
| markos | but needs 3 operands | 13:44 |
| markos | File "/home/markos/src/openpower-isa/src/openpower/sv/trans/svp64.py", line 324, in av | 13:44 |
| markos | (RT, RA, RB) = fields | 13:44 |
| markos | ValueError: not enough values to unpack (expected 3, got 2) | 13:44 |
| markos | I think I got it | 13:56 |
| lkcl | markos, av is specifically designed for the group of instructions maxs/maxu/minu etc. | 14:08 |
| lkcl | which very specifically are X-Form | 14:08 |
| lkcl | don't for goodness sake try to use the av() function for anything else | 14:08 |
| lkcl | for (name, XO) in ( | 14:10 |
| lkcl | ("maxs" , 0b0111001110), | 14:10 |
| lkcl | ... | 14:10 |
| lkcl | ... | 14:10 |
| lkcl | CUSTOM_INSNS[name] = functools.partial(av, XO=XO, Rc=False) | 14:10 |
| lkcl | i see what you've done | 14:11 |
| lkcl | you added *two* decoders. | 14:11 |
| lkcl | 1. | 14:11 |
| lkcl | CUSTOM_INSNS = {} | 14:11 |
| lkcl | for (name, hook) in ( | 14:11 |
| lkcl | ("fmvis", fmvis) | 14:11 |
| lkcl | ): | 14:11 |
| lkcl | CUSTOM_INSNS[name] = functools.partial(hook, Rc=False) | 14:11 |
| lkcl | which is the correct location | 14:11 |
| lkcl | notice how functools.partial applies the extra arguments? | 14:13 |
| lkcl | (this is python higher-order-programming btw, i've not really used functools.partial before, i'm not so keen on it but it works) | 14:14 |
| lkcl | basically it creates a function which calls a function but adding extra arguments specified as *args to partial | 14:14 |
| lkcl | therefore if you have this: | 14:14 |
| markos | yes, fixed it now and added custom_insn for fmvis and it works ok now with 2 operands | 14:14 |
| lkcl | excellent. | 14:14 |
| lkcl | you should really just have | 14:15 |
| lkcl | CUSTOM_INSNS["fmvis"] = fmvis | 14:15 |
| lkcl | because there's no Rc=1 mode for fmvis | 14:15 |
| lkcl | and remove this as well | 14:16 |
| lkcl | for (name, XO) in ( | 14:16 |
| lkcl | ("fmvis" , 0b0000000011), | 14:16 |
| lkcl | <------ | 14:16 |
| lkcl | ): | 14:16 |
| lkcl | CUSTOM_INSNS[name] = functools.partial(av, XO=XO, Rc=False) | 14:16 |
| lkcl | whoops | 14:16 |
| lkcl | ("fmvis" , 0b0000000011), <----- | 14:16 |
| markos | yup, done | 14:17 |
| lkcl | magic | 14:17 |
| lkcl | after a while it kinda makes sense, you know? | 14:17 |
| markos | it does | 14:17 |
| lkcl | ghostmansd[m] did the synthesis of those parsers. a few weeks ago trans/svp64.py was a bucket-load of repeated cut/paste code | 14:18 |
| lkcl | strictly speaking *all* of those can (and really should) be replaced by fully-automated parsing | 14:18 |
| lkcl | after all, those fields (and offsets) are straight out of the machine-readable fields.txt file | 14:18 |
| lkcl | the gotcha is the XO Field is not. | 14:19 |
| lkcl | which is in the CSV files in a not-so-easy-to-get-at format | 14:19 |
| ghostmansd[m] | This all should be generated, yes. I mentioned it that many times that I cannot even count. | 14:20 |
| ghostmansd[m] | But this needs that much time to do it elegantly that I surrendered. | 14:20 |
| lkcl | in power_decoder.py if the XO-opcode-recognition can be recognised then it should be doable | 14:20 |
| ghostmansd[m] | But, on the other hand, I simply could not look at these copy&paste anymore, especially considering it was wrong in some parts. | 14:21 |
| lkcl | sigh, yes. | 14:21 |
| ghostmansd[m] | So I did something intermediate: a hack which simplified it at least somewhat. | 14:21 |
| lkcl | we broke the rule not to have everything auto-generated. | 14:21 |
| lkcl | i started as a quick hack to add one instruction and it kinda got out of hand :) | 14:21 |
| ghostmansd[m] | Yeah. Anyway, we still can generate it. Even if we broke the rule, we should unbreak it eventually. :-) | 14:22 |
| markos | ok, committed a fix, tht should do it | 14:22 |
| markos | now on to flrsi | 14:22 |
| ghostmansd[m] | And I have ideas and plans on this part. | 14:22 |
| ghostmansd[m] | Because, after all, this _is_ our reference. | 14:23 |
| ghostmansd[m] | I mean pysvp64asm. | 14:23 |
| lkcl | markos, fantastic, looks great | 14:23 |
| lkcl | ghostmansd[m], muhahahah. | 14:23 |
| lkcl | yes it is | 14:23 |
| lkcl | it's also supposed to be the easy way to check that the spec's correct. | 14:24 |
| ghostmansd[m] | Yes, exactly. | 14:24 |
| ghostmansd[m] | And, even, if it wasn't... anything that can be generated must be generated. | 14:25 |
| ghostmansd[m] | Programmers are notoriously bad ad typing the stuff by themselves. If this crap can be grouped in one place, and be propagated to other pieces by means of generator reusing the common code, this is much better: we'll end up with single source of truth. | 14:27 |
| lkcl | markos, ah - just looking at these https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/test/alu/fmvis_cases.py;hb=HEAD | 14:29 |
| lkcl | Power ISA stores FP32 numbers in *FP64* format | 14:29 |
| lkcl | hence why, if you look at the pseudocode in https://libre-soc.org/openpower/sv/int_fp_mv/ | 14:30 |
| lkcl | i put this: | 14:30 |
| lkcl | bf16 = d0 || d1 || d2 | 14:30 |
| lkcl | fp32 = bf16 || [0]*16 | 14:30 |
| lkcl | FRS = Single_to_Double(fp32) | 14:30 |
| lkcl | and that's almost exactly the pseudocode that needs to go into av.mdwn | 14:31 |
| lkcl | (ok bf16 <- d0 || d1 || d2) | 14:31 |
| lkcl | also | 14:32 |
| lkcl | it's DX-Form, where you've added X-Form | 14:32 |
| markos | so the checks need to check against 64-bit values? | 14:32 |
| lkcl | yes | 14:32 |
| markos | apologies, probably left-over from copy-paste | 14:32 |
| lkcl | ok i am just about waking up now (cutting through a lot of pain) | 14:32 |
| lkcl | https://libre-soc.org/openpower/sv/int_fp_mv/ | 14:33 |
| lkcl | fmvis fits with DX-Form: | 14:33 |
| lkcl | 0-56-1011-1516-2526-3031Form | 14:33 |
| lkcl | MajorFRSd1d0XOd2DX-Form | 14:33 |
| lkcl | where in https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=openpower/isa/av.mdwn;hb=HEAD | 14:33 |
| lkcl | you have added it as X-Form | 14:33 |
| lkcl | 211 X-Form | 14:33 |
| lkcl | 212 | 14:33 |
| lkcl | 213 * fmvis FRS,SI | 14:33 |
| markos | fixing this now | 14:33 |
| lkcl | the Single_to_Double function i got the wrong name | 14:34 |
| lkcl | it *should* be dropped into the namespace of the compiled code, av.py, via an @decorator, from helpers.py | 14:34 |
| * lkcl can't off top-of-my-head recall the full details, 1 sec | 14:35 | |
| lkcl | ok i don't think we have a DOUBLE2SINGLE function urrr | 14:36 |
| lkcl | wait, ah! yes | 14:36 |
| lkcl | it's, ha, from the Power ISA spec | 14:36 |
| lkcl | and is again auto-generated via the compiler, ha. been 8 months since i did that. | 14:37 |
| lkcl | ./openpower/decoder/isafunctions/double2single.py: def DOUBLE2SINGLE(self, FR): | 14:37 |
| lkcl | hang on... sorry, that's double2single, you want single2double | 14:38 |
| lkcl | ah screw it | 14:38 |
| lkcl | just drop the bits into the right places :) | 14:38 |
| lkcl | e = FRS[1:12] | 14:38 |
| lkcl | m = FRS[12:64] | 14:38 |
| lkcl | s = FRS[0] | 14:38 |
| markos | I think it should be e = FRS[1:11] | 14:40 |
| lkcl | yes, that was python numbering | 14:41 |
| lkcl | ah damnit it does need conversion. | 14:42 |
| lkcl | frickin frick. where's that damn function, i know it's around somewhere | 14:42 |
| lkcl | got it. | 14:43 |
| lkcl | just "DOUBLE()" | 14:43 |
| markos | on it now | 14:45 |
| * lkcl updating the wiki page to match | 14:46 | |
| lkcl | some context: https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=openpower/isafunctions/double2single.mdwn;hb=HEAD | 14:49 |
| lkcl | these are actually extracted from the Power ISA spec | 14:49 |
| lkcl | (Appendix A.1 Book I) | 14:49 |
| lkcl | and they're, surpriise, machine-readable executable code. | 14:49 |
| lkcl | you can see the results in openpower/decoder/isafunctions/double2single.py | 14:50 |
| lkcl | and those three functions all get dropped into the namespace of the simulator for you to use | 14:50 |
| lkcl | by... mmm... | 14:50 |
| lkcl | multiply-inheriting in ISACaller, i believe | 14:50 |
| lkcl | if you have a look at test_caller_svp64_dct.py | 14:51 |
| lkcl | you'll see how i hack-job-instantiated a *separate* helper instance in order to get at the damn functions "stand-alone", so as to be able to use them to test the expected results | 14:51 |
| lkcl | otherwise you have to piss about doing the bit-level decoding manually | 14:52 |
| lkcl | https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/decoder/isa/test_caller_svp64_dct.py;hb=HEAD | 14:52 |
| lkcl | initially i was really dismayed by what IBM's done here, storing FP32 in FP64 format | 14:53 |
| lkcl | but then i realised that, actually, you can *use* the FP32 instructions as "faster" ones when accuracy doesn't matter... | 14:53 |
| lkcl | ... oh and not have to piss about with explicit opcodes converting from FP32 to FP64 and back, the data's *already and always* in FP64 format, in the FP registers | 14:54 |
| markos | ok, committed a fix, tests pass now, form, pseudo-code fixed and test values are now 64-bit | 14:58 |
| markos | I *think* I have got it right this time | 14:59 |
| markos | ok, eureka moment, initially I thought that av.mwdn was "just" documentation, now I realized that it actually autogenerates the code for the instructions, duh | 15:10 |
| markos | ok, just realized that it's veeeery easy to mistype frlsi to flrsi and waste many minutes trying to figure out the problem | 15:31 |
| markos | since we're in the design phase, I'd suggest we change the name | 15:31 |
| markos | it was right in front of my eyes and I kept missing ti | 15:31 |
| markos | it | 15:31 |
| lkcl | i really like fishmv :) | 15:42 |
| markos | when is RM-2P-1S1D.csv updated? | 15:43 |
| lkcl | yees, hooray, you got it - yes it's really *not* "just documentation" | 15:43 |
| lkcl | when you run sv_analysis | 15:43 |
| markos | ok, because something must have been fixed with the latest changes and it's now removed from there | 15:43 |
| lkcl | which creates CSV files, which we then commit. it's one of the extremely rare circumstances for committing auto-generated output | 15:43 |
| lkcl | if it's removed then it's simply not a recognised pattern by sv_analysis.py | 15:44 |
| lkcl | which i'll have to fix | 15:44 |
| lkcl | 1 sec | 15:44 |
| lkcl | leave it with me | 15:44 |
| lkcl | +DX-Form | 15:45 |
| lkcl | 15:45 | |
| lkcl | * fmvis FRS,SI | 15:45 |
| lkcl | 15:45 | |
| lkcl | you need to update the declaration of fmvis as well | 15:45 |
| lkcl | (again, because, as you appreciated, now, that's used by the compilers) | 15:45 |
| markos | apologies for bothering you with all that seemingly trivial stuff, but really it's all new to me | 15:46 |
| lkcl | but... ehmmm... 1 sec... | 15:46 |
| lkcl | have to find a DX-Form instruction in the Power ISA spec... | 15:46 |
| lkcl | addpcis | 15:46 |
| lkcl | ah. | 15:46 |
| lkcl | ok | 15:47 |
| lkcl | it does actually reconstruct D manually. damn. | 15:47 |
| lkcl | that's really annoying of the ISA architects to have done that | 15:47 |
| lkcl | p66 Power ISA v3.0C | 15:47 |
| markos | +1 for fishmv btw, much harder to mistype this | 15:50 |
| lkcl | plus, mikey liked it https://twitter.com/lkcl/status/1532363606716817408 | 15:51 |
| markos | so, ok to commit RM-2P-1S1D.csv with removed fmvis? | 15:55 |
| * lkcl something odd going on with fmvis | 15:55 | |
| markos | or is there something missing? | 15:55 |
| * lkcl tracking it down | 15:55 | |
| markos | I have the suspicion that I'm doing the expected_fprs handling in the wrong way | 15:55 |
| lkcl | look at test_caller_svp64_dct.py for how it should be handled | 15:56 |
| lkcl | i'm not getting any debug log messages | 15:56 |
| lkcl | leave it with me to investigate | 15:56 |
| markos | ok | 15:56 |
| lkcl | post-processed name NONE .long NONE | 15:57 |
| lkcl | illegal .long NONE | 15:57 |
| lkcl | ah that's a clue | 15:57 |
| lkcl | XO=00011 all good... | 15:59 |
| lkcl | ok, the fmvis function in svp64.py, annoyingly, is an exception-to-the-rule | 16:00 |
| lkcl | everything else is clean but this one isn't, sigh | 16:01 |
| markos | what did I do wrong? | 16:04 |
| lkcl | nothing i could have predicted, 1 sec | 16:04 |
| lkcl | the only other DX-Form instruction, addpcis, is one that's not been implemented yet | 16:05 |
| lkcl | no don't commit the sv_analysis csv change | 16:07 |
| lkcl | i reverted the removal of FRS as in1 | 16:07 |
| lkcl | FRS is definitely an in1 | 16:07 |
| lkcl | wait... | 16:08 |
| lkcl | frick | 16:08 |
| lkcl | no you're right | 16:08 |
| lkcl | markos, fyi, have a look here | 16:09 |
| lkcl | https://git.libre-soc.org/?p=openpower-isa.git;a=commitdiff;h=c23a608e97a14e18564e806f1a2921cdeb079606 | 16:09 |
| lkcl | i'm still working out why it's call .long NONE | 16:10 |
| lkcl | obviously that should be call fmvis in the log output | 16:10 |
| lkcl | time to print out the binary of an fmvis instruction.... | 16:10 |
| markos | damn | 16:11 |
| lkcl | opcode, fields substed ['fmvis', '5,65535'] fmvis ['5', '65535'] | 16:11 |
| lkcl | fmvis 0b1011000101111110111111111100111 | 16:11 |
| lkcl | https://git.libre-soc.org/?p=openpower-isa.git;a=commitdiff;h=47835dbedc58dfab1ec1643981f76a478610fa72 | 16:12 |
| lkcl | really we should have unit tests in svp64.py not these hand-botch-jobs i started adding 2 years ago | 16:12 |
| lkcl | ahh i think i know what it is | 16:13 |
| lkcl | the pattern-recognition in minor_22.csv is from bits 21..31 | 16:13 |
| lkcl | XO for fmvis is in bits 26 to *30* not 26 to 31... | 16:14 |
| lkcl | and you have: | 16:14 |
| lkcl | ------00011,ALU,OP_FMVIS,FRS | 16:14 |
| lkcl | that's offset by one | 16:14 |
| lkcl | it should be | 16:14 |
| lkcl | -----00011-,ALU,OP_FMVIS,FRS | 16:14 |
| lkcl | hooray! now we are cooking with gas | 16:15 |
| ghostmansd[m] | Folks, am I right that you're adding a new instruction to svp64.py? | 16:15 |
| lkcl | ghostmansd[m], yyyep. | 16:16 |
| lkcl | fmvis. | 16:16 |
| ghostmansd[m] | > hooray! now we are cooking with gas | 16:16 |
| lkcl | markos, https://git.libre-soc.org/?p=openpower-isa.git;a=commitdiff;h=1e6d95e1658526d2bda5a7b2714c3d735e8eee07 | 16:16 |
| lkcl | ghostmansd[m], ha ha | 16:16 |
| ghostmansd[m] | lkcl, you're literally pushing me to make a joke about Gazprom | 16:16 |
| lkcl | it's an english expression | 16:16 |
| lkcl | don't hold back... | 16:16 |
| ghostmansd[m] | :-D | 16:16 |
| ghostmansd[m] | We actually also call it gas | 16:16 |
| ghostmansd[m] | Or, rather, gaz | 16:17 |
| ghostmansd[m] | But pronounced the same | 16:17 |
| lkcl | https://www.urbandictionary.com/define.php?term=cooking%20with%20gas | 16:17 |
| ghostmansd[m] | Wow | 16:17 |
| lkcl | https://english.stackexchange.com/questions/25897/origin-of-the-phrase-now-were-cooking-with | 16:17 |
| ghostmansd[m] | For me cooking with gas is quite fast, to be honest | 16:17 |
| ghostmansd[m] | Ah OK got it | 16:18 |
| ghostmansd[m] | Funny | 16:18 |
| lkcl | it dates back to 1940s apparently, when gas stoves started replacing wood stoves in 1915 | 16:18 |
| lkcl | :) | 16:18 |
| ghostmansd[m] | Ok, so you need the new insn in gas, right? | 16:18 |
| lkcl | yyeah, we do | 16:19 |
| * lkcl head spinning slightly... | 16:19 | |
| lkcl | too many things at once | 16:19 |
| lkcl | markos, a quick debug-print in av.py, you'll be delighted to hear, is producing the right answer(s) | 16:21 |
| lkcl | http://weitz.de/ieee/ | 16:22 |
| markos | hooray! | 16:22 |
| lkcl | not actually being checked though, working that out | 16:25 |
| lkcl | markos, can i leave it with you to add what 0x2122 is, in FP? | 16:28 |
| lkcl | i need to add fprs to ExpectedState | 16:28 |
| markos | yes, I've added more tests that involve common fp constants like pi, etc | 16:28 |
| lkcl | https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/test/state.py;hb=HEAD | 16:29 |
| lkcl | please do a git pull | 16:29 |
| markos | ftr, pi is 0x400921fb54442d18 in 64-bit :) | 16:29 |
| lkcl | the only reason it's "passing" is because ExpectedState() has zero GPRs | 16:29 |
| lkcl | and this instruction doesn't modify GPRs | 16:29 |
| markos | I thought that expected_fprs was not doing what I thought it did | 16:30 |
| markos | I'll follow the tests from svp64 | 16:30 |
| lkcl | you're passing it in as the first argument to add_cases() which is actually the GPRs | 16:31 |
| lkcl | yes good idea. | 16:31 |
| lkcl | it's very different (and slower) but probably a better first template to use | 16:31 |
| lkcl | including the _check_regs() function whih you can see in test_caller_svp64_dct.py | 16:32 |
| lkcl | haha i love that you know pi in IEEE754 hex format | 16:32 |
| lkcl | actually, can you leave it as-is> | 16:34 |
| lkcl | ? | 16:34 |
| lkcl | it will make a good test of the ExpectedState modifications i'm just doing | 16:34 |
| markos | I think I'll change 0x2122 turns out it's a ridiculously small number, 4.19e-320 | 16:35 |
| markos | was just a random hex value I entered | 16:35 |
| lkcl | ridiculous numbers are good! | 16:35 |
| markos | ok then | 16:36 |
| lkcl | okaay done | 16:37 |
| lkcl | can you take a look? | 16:37 |
| markos | looking at it now | 16:38 |
| lkcl | equal (expected) '.long 0x58e01f46'. got 3c00000000000000 expected 4000000000000000 at pc c 4 | 16:39 |
| lkcl | hooray! | 16:39 |
| lkcl | fp reg 5 is detected as an incorrect value! | 16:39 |
| markos | :) | 16:40 |
| lkcl | that's odd (and almost certainly wrong) | 16:40 |
| lkcl | http://weitz.de/ieee/ | 16:40 |
| lkcl | 0x3C00000000000000 | 16:40 |
| lkcl | is 1.0842021724855044E-19 | 16:41 |
| lkcl | time to put some debug-prints in av.py | 16:41 |
| lkcl | def op_fmvis(self): | 16:42 |
| lkcl | print ("d0 d1 d2", d0, d1, d2) | 16:42 |
| lkcl | i get | 16:42 |
| lkcl | d0 d1 d2 SelectableInt(value=0x80, bits=10) SelectableInt(value=0x0, bits=5) SelectableInt(value=0x0, bits=1) | 16:42 |
| lkcl | d0 is 0x80 which is 0b1000_0000 | 16:43 |
| lkcl | 8-bit | 16:43 |
| lkcl | when converted to FP32 that ends up as | 16:43 |
| lkcl | double SelectableInt(value=0x20000000, bits=32) | 16:43 |
| lkcl | which is wrong | 16:43 |
| lkcl | it should be 0x4000_0000 | 16:43 |
| lkcl | i almost certainly have an off-by-one in svp64.py | 16:44 |
| lkcl | one of these | 16:44 |
| lkcl | # first split imm into d1, d0 and d2. sigh | 16:44 |
| lkcl | d2 = (imm & 1) # LSB (0) | 16:44 |
| lkcl | d1 = (imm >> 1) & 0b11111 # bits 1-5 | 16:44 |
| lkcl | d0 = (imm >> 6) # MSBs 6-15 | 16:44 |
| markos | ok, I can work it out if you like | 16:44 |
| lkcl | yes please | 16:44 |
| markos | np | 16:44 |
| lkcl | now we've got feedback it should be a breeze | 16:44 |
| markos | yup, same with flrsi/fishmv :) | 16:45 |
| lkcl | sorry, i didn't know that DX-Form was non-standard | 16:45 |
| lkcl | yes. should be plain sailing from here | 16:45 |
| lkcl | ghostmansd[m], another english expression | 16:45 |
| markos | it's ok, glad to have offered the incentive to implement this :) | 16:45 |
| lkcl | https://dictionary.cambridge.org/dictionary/english/be-plain-sailing | 16:45 |
| lkcl | :) | 16:45 |
| lkcl | it would have made my life easier for test_caller_svp64_dct.py as well, sigh | 16:46 |
| markos | maybe intime refactor some of that code around it, it would help me learn the code in depth too | 16:49 |
| markos | lkcl, ok I see a possible issue in DOUBLE() | 17:58 |
| tplaten | I assume that an IcarusOrangecrabPlatform is needed, since I want to simulate the changes needed for OrangeCrab. | 17:59 |
| markos | I'm setting the immediate value to 0x4009 which if converted to double 0x4009000000000000, it would convert to 3.125 | 17:59 |
| markos | but double converts it to value=0x4001200000000000 | 18:00 |
| markos | I checked the av.py code and added some prints | 18:00 |
| markos | print("d0, d1, d2", d0, d1, d2) | 18:00 |
| markos | bf16 = concat(d0, d1, d2) | 18:00 |
| markos | print("bf16", bf16) | 18:00 |
| markos | fp32 = concat(bf16, concat(0, repeat=16)) | 18:00 |
| markos | print("fp32", fp32) | 18:00 |
| markos | FRS = self.DOUBLE(fp32) | 18:00 |
| markos | print("FRS", FRS) | 18:00 |
| markos | return (FRS,) | 18:00 |
| markos | bf16, fp32 print out fine, 0x4009, 0x40090000 | 18:00 |
| markos | but FRS gives the wrong value | 18:01 |
| tplaten | Im now comparing gram/gram/simulation/crg.py with ls2/src/ecp5_crg.py, then | 18:20 |
| tplaten | adding support for the simulated orangecrab to gram/gram/simulation/crg.py | 18:23 |
| programmerjake | markos, 0x4001200000000000 is the correct double value for immediate 0x4009, the immediate is the top half of f32, not f64. i can't tell if you already figured that out... | 19:10 |
| programmerjake | that's because f64 has a larger exponent field | 19:13 |
| tplaten | Im had a look at ECPIX5CRG and found out that a | 19:21 |
| tplaten | Synchronous Release Global Set/Reset Interface | 19:21 |
| tplaten | Instance("SGSR", i_CLK=ClockSignal("rawclk"), i_GSR=gsr1) | 19:21 |
| tplaten | In ls2 no SGSR is used, reset is handled a different way | 19:21 |
| tplaten | no I was wrong, it is used, but where does the reset signal come from on the orangecrab | 19:23 |
| tplaten | and part of the crg code is duplicated, that makes everything hard to maintain. | 19:27 |
| tplaten | class PLL is also duplicated, I was unable to see any changes here. But in the CRG there are too many changes | 19:45 |
| ghostmansd[m] | lkcl, so, on binutils side, the next targets are: 1) sync with svp64.py again; 2) support prefix for disassembler; 3) test svp64.py and binutils | 20:04 |
| ghostmansd[m] | That's w/o opening the tasks in bugzilla, just as I recalled; everything correct? | 20:04 |
| lkcl | ghostmansd[m], looks about right, although not having bugzilla tasks makes me twitchy | 20:17 |
| lkcl | i wonder... | 20:17 |
| lkcl | i think we can get away with raising a new binutils budget under the cavatools grant | 20:17 |
| lkcl | markos, that's why i used the helper-routines in test_caller_svp64_dct.py (and others) because you can perform FP64-hex to python-float and check what the hell's going on | 20:50 |
| markos | programmerjake, if it was a larger value perhaps, but 0x4009/3.125 has exponent set to 1.0 so I don't think this is a correct explanation | 21:45 |
| markos | in fact, setting manually a double value to 0x40012 produces a double close to 2.14062 | 21:48 |
| markos | so it's definitely not a correct double value | 21:49 |
| markos | sorry, I meant setting it to 0x4001200000000000 | 21:49 |
| markos | anyway, I'll investigate this further | 21:51 |
| octavius | meeting in 8min markos, programmerjake, toshywoshy, cesar | 21:52 |
| programmerjake | but bf16 0x4009 *isn't* 3.125 | 22:34 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!