| lkcl | tests ran, rebase good | 00:42 |
|---|---|---|
| lkcl | ghostmansd[m], all good with CR5/CR3. needs cleanup (tomorrow!) but works | 01:45 |
| lkcl | https://git.libre-soc.org/?p=openpower-isa.git;a=commitdiff;h=b49d42520dbba44d6fc5421b57ea1202ed47252d | 01:45 |
| lkcl | cesar, markos, ghostmansd[m], sorry message went out couple days ago, late-notice on IRC https://bugs.libre-soc.org/show_bug.cgi?id=924 | 01:47 |
| lkcl | is everyone good for a meeting 17:00 UTC (about 15 hours from now) | 01:48 |
| lkcl | target is to put in the ls001 External RFC *by monday evening latest* | 01:48 |
| lkcl | some cleanup on CR5Operand and CR3Operand is needed, all that code desperately needs a common base class | 02:16 |
| ghostmansd[m] | Wow Luke thanks for help! | 07:35 |
| ghostmansd[m] | I'll make the cleanup and adopt it somehow into the base class | 07:35 |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc | 08:22 | |
| ghostmansd | Luke, what do vshift, sshift and spshft stand for, and where did one of them lost i? :-D | 08:49 |
| ghostmansd | OK refactoring this a bit | 10:28 |
| lkcl | look at the diff. | 10:30 |
| lkcl | @@ -651,11 +651,16 @@ class GPRFPROperand(RegisterOperand): | 10:30 |
| lkcl | if vector: | 10:30 |
| lkcl | - value = ((value << 2) | spec) | 10:30 |
| lkcl | + value = ((value << vshift) | (spec<<spshft)) | 10:30 |
| lkcl | else: | 10:30 |
| lkcl | - value = ((spec << 5) | value) | 10:30 |
| lkcl | + value = ((spec << sshift) | value) | 10:30 |
| lkcl | then i took the comments above | 10:31 |
| *** tplaten <tplaten!~isengaara@d536b130.access.ecotel.net> has joined #libre-soc | 10:31 | |
| lkcl | https://libre-soc.org/irclog/%23libre-soc.2022-09-10.log.html#t2022-09-10T21:55:15 | 10:31 |
| lkcl | did an "A is to B, as C is to D" analysis | 10:32 |
| lkcl | and came up with equivalent numbers | 10:32 |
| lkcl | it was late - i think in my mind i called then "vshift vector shift" | 10:32 |
| lkcl | "sshift scalar shift" | 10:32 |
| lkcl | "spshift spec shift" | 10:32 |
| lkcl | i suspect it will be possible to do this | 10:33 |
| lkcl | class CR3Operand(SomeBaseClass): | 10:33 |
| lkcl | vshift = 4 | 10:33 |
| lkcl | sshift = 3 | 10:33 |
| lkcl | spshift = 2 | 10:33 |
| lkcl | which is static class-variable allocation | 10:33 |
| lkcl | but still use them as "self.sshift" etc. | 10:34 |
| lkcl | i have vague recollections that static class-variables can still be accessed "self." rather than needing to be accessed by class-name | 10:34 |
| ghostmansd[m] | These are same for both | 10:35 |
| lkcl | but if you look *really* closely | 10:35 |
| ghostmansd[m] | Only lsbs differ | 10:35 |
| lkcl | you'll be able to see that *all* those numbers are actually derivable entirely from len(value) (value.bits) | 10:35 |
| lkcl | including this: | 10:35 |
| lkcl | + span = (span[0:3] + spec_span + ('{0}', '{0}') + span[3:5]) | 10:36 |
| lkcl | becomes | 10:36 |
| lkcl | + span = (span[0:3] + spec_span + spshift * ('{0}',) + span[3:5]) | 10:36 |
| ghostmansd | https://pastebin.com/hHBRxrQj | 10:36 |
| lkcl | but spshift = 5-len(value) | 10:36 |
| ghostmansd | That's literally the diff between these two classes | 10:36 |
| lkcl | yyep. | 10:36 |
| lkcl | precisely. | 10:37 |
| lkcl | so that can be one of the parameters. | 10:37 |
| lkcl | or even basically it's spshift | 10:37 |
| lkcl | that number value.value>>2 is spshift | 10:37 |
| lkcl | span-shift | 10:37 |
| lkcl | aaaallll that information, vshift sshift spshift | 10:38 |
| lkcl | is aalllll derivable from len(value) | 10:38 |
| ghostmansd[m] | I've been rather thinking of remembering and discarding 2 bits, then calling the common code, the adding | 10:38 |
| ghostmansd[m] | *then adding | 10:38 |
| lkcl | if you set spshift to zero for GPR/FPR/5-bit-CR | 10:39 |
| lkcl | that idea becomes redundant / moot | 10:39 |
| lkcl | because you would remove ZERO lsbs and shift value.value *by* zero | 10:39 |
| lkcl | anyway. i leave it with you | 10:40 |
| ghostmansd | Aaah I see you also touched the code for GPRFPR | 10:41 |
| ghostmansd | That part I missed | 10:41 |
| ghostmansd | So you suggest unifying ALL of these | 10:41 |
| ghostmansd | Where each one will provide the shifts | 10:41 |
| lkcl | yes. | 10:42 |
| lkcl | no | 10:42 |
| ghostmansd | lol | 10:42 |
| lkcl | you can *calculate* all of them from len(value) (aka value.bits) | 10:42 |
| ghostmansd | yes to first no to second? | 10:42 |
| ghostmansd | OK | 10:43 |
| lkcl | correct :) | 10:44 |
| ghostmansd | These are all register operands, it just happens that some of them are 3-bit | 10:44 |
| lkcl | and some of them have a couple of LSBs which need to be left alone (passed through), yes | 10:45 |
| ghostmansd | OK, got it! | 10:45 |
| ghostmansd | I'll do it | 10:45 |
| ghostmansd | Many thanks for making this code, it's much clearer now | 10:46 |
| lkcl | ah i just realised i got this wrong | 10:47 |
| lkcl | <lkcl> + span = (span[0:3] + spec_span + spshift * ('{0}',) + span[3:5]) | 10:47 |
| lkcl | *thinks*... | 10:47 |
| lkcl | no it's right. it's spshift. | 10:48 |
| lkcl | let me drop in some comments | 10:48 |
| ghostmansd | sure | 10:52 |
| *** octavius <octavius!~octavius@175.209.147.147.dyn.plus.net> has joined #libre-soc | 10:53 | |
| lkcl | ok done | 10:54 |
| lkcl | now CR5Operand class should *be* the one (only) class needed | 10:54 |
| lkcl | i leave it to you to check these | 10:55 |
| lkcl | sshift = 3 # len(value) aka value.bits | 10:55 |
| lkcl | vshift = 4 # 7-sshift | 10:55 |
| lkcl | spshft = 2 # 5-sshift | 10:55 |
| lkcl | there's only one parameter needed, spshft | 10:55 |
| lkcl | yep i've confused the parameter which does the lsbs | 10:56 |
| lkcl | damn 1 sec | 10:56 |
| lkcl | ok corrected. | 10:58 |
| lkcl | a new parameter, lsbshf. | 10:58 |
| lkcl | this is the *only* one that needs to be passed in as a parameter, it distinguishes 5-bit CRnum from 3-bit CRfield-num | 10:59 |
| ghostmansd | it actually complicated the stuff :-) | 11:04 |
| ghostmansd | but OK | 11:05 |
| lkcl | :) | 11:06 |
| lkcl | fortunately it's all the _same_ complicated stuff :) | 11:07 |
| *** octavius <octavius!~octavius@175.209.147.147.dyn.plus.net> has quit IRC | 11:13 | |
| cesar | lkcl: I'm OK with a meeting at 17:00 UTC today. | 11:13 |
| lkcl | cesar, great. sorry it's short notice | 11:14 |
| ghostmansd[m] | I'll join too | 11:16 |
| lkcl | brilliant | 11:16 |
| lkcl | toshywoshy, we've 5 people, you want to do the calendar-invite? email addresses on https://bugs.libre-soc.org/show_bug.cgi?id=924 probably not paul :) | 11:17 |
| lkcl | markos, ya good? or are you enjoying your weekend, like sane people? :) | 11:17 |
| lkcl | this is timezones | 11:19 |
| lkcl | https://www.timeanddate.com/worldclock/converter.html?iso=20220911T170000&p1=tz_gmt&p2=tz_bst&p3=tz_msk&p4=47&p5=179&p6=224&p7=16 | 11:19 |
| lkcl | ah wait added sao paulo as well | 11:20 |
| lkcl | https://www.timeanddate.com/worldclock/converter.html?iso=20220911T170000&p1=tz_gmt&p2=tz_bst&p3=tz_msk&p4=47&p5=179&p6=224&p7=16&p8=233 | 11:20 |
| ghostmansd | lkcl, there's more | 11:25 |
| ghostmansd | the span also differs | 11:25 |
| ghostmansd | GPR vs CR3 | 11:26 |
| ghostmansd | https://pastebin.com/5e9PECvv | 11:26 |
| ghostmansd | CR3 vs CR5 | 11:30 |
| ghostmansd | https://pastebin.com/wSpaZvaX | 11:30 |
| ghostmansd | OK shshft is the same, so there's no span differences... | 11:31 |
| ghostmansd | CR3 vs CR5, better diff https://pastebin.com/G62u6uPA | 11:35 |
| ghostmansd | I guess lsbshf is incorrect | 11:36 |
| ghostmansd | + lsbshf = 0 | 11:36 |
| ghostmansd | + lsbmsk = (1<<lsbshf)-1 | 11:36 |
| lkcl | lsbshf should be zero for CR3 | 11:36 |
| ghostmansd | Should be 2 | 11:36 |
| lkcl | no, it's definitely 0 for CR3 | 11:37 |
| lkcl | because there are no LSBs to remove | 11:37 |
| lkcl | the LSBs refer to the bit *in* the CR Field. EQ LT GT SO | 11:37 |
| lkcl | 0b00=EQ | 11:37 |
| lkcl | 0b01=LT | 11:37 |
| lkcl | 0b10=GT | 11:37 |
| lkcl | 0b11=SO | 11:37 |
| lkcl | i think. | 11:37 |
| lkcl | sigh | 11:37 |
| ghostmansd | https://pastebin.com/G62u6uPA | 11:37 |
| ghostmansd | this is diff between cr3 and cr5 | 11:38 |
| lkcl | 1 sec | 11:38 |
| ghostmansd | diff -u cr3 cr5 | 11:38 |
| lkcl | argh errr... | 11:38 |
| ghostmansd | I cleaned the code a bit but you get the idea | 11:39 |
| lkcl | yep | 11:39 |
| lkcl | https://git.libre-soc.org/?p=openpower-isa.git;a=commitdiff;h=bbb6fc0c0a0c0b1877242057ec3f11fc4a6359fe | 11:39 |
| ghostmansd | Yeah so 2, OK | 11:39 |
| lkcl | <lkcl> lsbshf should be zero for CR3 | 11:39 |
| ghostmansd | that's a relief :-) | 11:39 |
| lkcl | i had it at zero for *CR5*, whoops | 11:39 |
| ghostmansd | OK got it, just got surprised it was CR5 | 11:40 |
| ghostmansd | OK | 11:40 |
| lkcl | these reaaallly need proper unit tests | 11:44 |
| *** tplaten <tplaten!~isengaara@d536b130.access.ecotel.net> has quit IRC | 11:44 | |
| lkcl | i got the ball rolling with test_pysvp64dis.py | 11:44 |
| lkcl | but for some unknown reason addpcis gets converted to a .long | 11:44 |
| ghostmansd[m] | You missed my message | 11:45 |
| ghostmansd[m] | We don't have addpcis | 11:45 |
| ghostmansd[m] | So obviously it won't be found | 11:45 |
| ghostmansd[m] | Nothing to find :-) | 11:45 |
| lkcl | but it still should not be converted to .long | 11:45 |
| ghostmansd[m] | How come? Anything unknown is converted. | 11:46 |
| lkcl | - addpcis 12,5 | 11:46 |
| lkcl | + .long 0x4d820005 | 11:46 |
| lkcl | FAIL: test_2_d_custom_op (__main__.SVSTATETestCase) [addpcis] | 11:46 |
| lkcl | it worked as of when i first created that test | 11:46 |
| ghostmansd[m] | If db[self] or db[self.suffix] gets nothing, it goes to .long | 11:46 |
| lkcl | then 2 days later it didn't | 11:46 |
| ghostmansd[m] | Hmmmmm | 11:46 |
| lkcl | ahh ok | 11:46 |
| lkcl | right | 11:46 |
| lkcl | let me "fix" that | 11:47 |
| lkcl | oo-err maybe not | 11:48 |
| lkcl | INSN_addpcis => (ALU, NONE, OP_ADD, CIA, CONST_DXHI4, NONE, RT, '0', '0', '0', '0', ZERO, '0', NONE, '0', '0', '0', '0', '0', '0', NONE, '0', '0', NONE), | 11:48 |
| lkcl | in microwatt | 11:48 |
| lkcl | in1=CIA (moo?!) | 11:48 |
| lkcl | in2=DXHI4 | 11:48 |
| * lkcl scared! | 11:48 | |
| ghostmansd[m] | WAT | 11:49 |
| lkcl | yeah :) | 11:49 |
| ghostmansd[m] | Should be d0, d1, d2 | 11:49 |
| ghostmansd[m] | Like with fish move | 11:49 |
| lkcl | yyyyep | 11:50 |
| lkcl | it's a minor_19.... | 11:50 |
| lkcl | urrrr and it's one of those multi-pattern ones sigh | 11:50 |
| lkcl | sigh first convert all of minor_19 to bitpattern | 11:51 |
| lkcl | then run all unit tests... | 11:53 |
| lkcl | cool! | 12:00 |
| lkcl | it worked! | 12:00 |
| lkcl | python3 src/openpower/sv/trans/test_pysvp64dis.py > /tmp/f | 12:01 |
| lkcl | ghostmansd[m], https://git.libre-soc.org/?p=openpower-isa.git;a=commitdiff;h=69ab0fd0be302b3096e692d49af0e577c9df07fc | 12:03 |
| ghostmansd | oooh cool | 12:06 |
| ghostmansd | - span = (span + spec_span) | 12:08 |
| ghostmansd | + span = (span[0:3] + spec_span + (spshft * ('{0}',)) + span[3:5]) | 12:08 |
| ghostmansd | This is a tricky part between GPR and CR3 | 12:08 |
| ghostmansd | if vector: | 12:08 |
| ghostmansd | value = ((value << vshift) | (spec<<spshft)) | 12:08 |
| ghostmansd | - span = (span + spec_span) | 12:08 |
| ghostmansd | + span = (span[0:3] + spec_span + (spshft * ('{0}',)) + span[3:5]) | 12:08 |
| ghostmansd | else: | 12:08 |
| ghostmansd | value = ((spec << sshift) | value) | 12:08 |
| ghostmansd | - span = (spec_span + span) | 12:08 |
| ghostmansd | + span = ((spshft * ('{0}',)) + spec_span + span) | 12:08 |
| ghostmansd | Hmm... Perhaps this can vary depending on len(value). | 12:09 |
| lkcl | almost certainly yes | 12:24 |
| lkcl | it matches exactly what happens in value = ..... | 12:25 |
| ghostmansd | Yeah I know | 12:25 |
| ghostmansd | Just not sure how to make it common due to the fact that span[3:5] goes to the end | 12:25 |
| lkcl | perhaps if value was expressed in the same way (without the <<) it might be clearer, might be not | 12:25 |
| lkcl | that's the 2 LSBs hum hum | 12:26 |
| lkcl | hum hum it's assuming len(span)==5 | 12:27 |
| lkcl | which urk is wrong for CR3Operand | 12:28 |
| lkcl | urk | 12:28 |
| ghostmansd | so there should be none span[3:5] for CR3, eh? | 12:44 |
| ghostmansd | only for CR5 | 12:44 |
| ghostmansd | Yeah it seems this span in the end is from LSBs | 12:47 |
| lkcl | that makes sense | 13:18 |
| lkcl | make tests then rebase | 13:25 |
| markos | lkcl, sorry was out for lunch with family, is it still on for 17:00 UTC? | 13:31 |
| ghostmansd | lkcl, I think I refactored CRs | 13:43 |
| ghostmansd | I'm not sure about `vector_shift = (2 + (5 - value.bits))` and stuff below. Subtracting it from 5 does not seems like the best option. | 13:44 |
| ghostmansd | Keep in mind though that we don't have these expressive instruments in C. So perhaps later I'll refactor it again so that it generates the fields automatically for C. | 13:47 |
| ghostmansd | If I'll write something like this for binutils, they will for sure ban me from mailing thread. :-) | 13:48 |
| lkcl | markos, yes | 14:32 |
| * lkcl pokes toshywoshy, calendar invite jitsi url? | 14:32 | |
| lkcl | ghostmansd, | 14:33 |
| lkcl | - sv.isel 12,2,3,*483 | 14:33 |
| lkcl | ? ^^^ | 14:33 |
| lkcl | + sv.isel 12,2,3,*99 | 14:33 |
| lkcl | ? ^^ | 14:33 |
| lkcl | : instruction does not match 'sv.isel 12,2,3,*99' expected 'sv.isel 12,2,3,*483' | 14:33 |
| lkcl | python3 src/openpower/sv/trans/test_pysvp64dis.py > /tmp/f | 14:34 |
| lkcl | that's in latest dis branch | 14:34 |
| lkcl | whereas current master works | 14:34 |
| ghostmansd[m] | Damn. I forgot to pull on Talos. | 14:51 |
| lkcl | new sv.crand test added as well (which is broken in master) | 14:55 |
| lkcl | i didn't look at it last night, only 5-bit | 14:55 |
| *** tplaten <tplaten!~isengaara@d536b130.access.ecotel.net> has joined #libre-soc | 14:55 | |
| ghostmansd | ??? | 15:00 |
| toshywoshy | sorry, just looking again at irc, can we move it to 18:00 UTC please | 15:01 |
| lkcl | it was like 3am. i ran the unit tests on sv.isel but not sv.crand | 15:01 |
| lkcl | ... sure | 15:01 |
| lkcl | toshywoshy, sure not a problem | 15:02 |
| ghostmansd | no-no lkcl, that's not related to crand | 15:02 |
| lkcl | i'll ping everyone | 15:02 |
| lkcl | ghostmansd, ahhh | 15:02 |
| ghostmansd | echo -n -e "\xc0\x00\x40\x05\xde\x19\x82\x7d" | python3 src/openpower/sv/trans/pysvp64dis.py | 15:02 |
| ghostmansd | c0 00 40 05 sv.isel r12,r2,r3,*99 | 15:02 |
| ghostmansd | de 19 82 7d | 15:02 |
| ghostmansd | It's related to this bit | 15:02 |
| lkcl | https://www.timeanddate.com/worldclock/converter.html?iso=20220911T180000&p1=tz_gmt&p2=tz_bst&p3=tz_msk&p4=47&p5=179&p6=224&p7=16&p8=233 | 15:03 |
| ghostmansd | what the deuce | 15:03 |
| toshywoshy | ok, sending the invite | 15:04 |
| lkcl | cesar, programmerjake, markos, ghostmansd, toshywoshy asked to move to 1 hour later ^ | 15:04 |
| lkcl | toshywoshy, thx | 15:04 |
| tplaten | I had a look at ls2/simsoc.fst, there is activity on the wishbone bus that goes to the uart, but there is no activity on the tx line in gtkwave. I used the coldboot/coldboot.bin program for this test. | 15:04 |
| lkcl | tplaten, you maaay be running into SYSCON not giving out the right information | 15:06 |
| lkcl | or | 15:06 |
| lkcl | not using the right version of uart16550 | 15:06 |
| ghostmansd | Ah wait I see, *483 expected | 15:06 |
| ghostmansd | mmm... is it even legal? | 15:07 |
| programmerjake | lkcl, etc.: new time is fine with me | 15:08 |
| tplaten | yes, maybe. How is syscon generated? | 15:08 |
| lkcl | it's not generated it's static compile-time information, read-only. | 15:10 |
| ghostmansd | Ladies and gentlemen, this man is innocent! | 15:10 |
| ghostmansd | .long 0x054000c0; isel 12, 2, 3, 31 # sv.isel 12,2,3,*483 | 15:10 |
| ghostmansd | .long 0x054000c0; isel 12, 2, 3, 7 # sv.isel 12,2,3,*99 | 15:10 |
| ghostmansd | It's pysvp64asm error not to check for operands | 15:10 |
| ghostmansd | The disassembler gets the same results. | 15:10 |
| ghostmansd | aaaah wait... | 15:10 |
| ghostmansd | hell | 15:10 |
| ghostmansd | 31, not 7 | 15:10 |
| ghostmansd | OK | 15:10 |
| ghostmansd | innocent! | 15:11 |
| lkcl | tplaten, https://git.libre-soc.org/?p=soc.git;a=blob;f=src/soc/bus/syscon.py;hb=HEAD | 15:11 |
| lkcl | ghostmansd, deep joy :) | 15:11 |
| lkcl | ghostmansd, master-branch still gets *99 right... | 15:11 |
| tplaten | I also tested using verilator, and it does work in this case. | 15:14 |
| tplaten | maybe I am using the wrong version of uart16550 | 15:19 |
| tplaten | When I do git remote show origin, I get https://github.com/freecores/uart16550, git pull shows Already up to date. | 16:22 |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC | 16:39 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.43.169> has joined #libre-soc | 16:40 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.43.169> has quit IRC | 16:50 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc | 16:51 | |
| *** octavius <octavius!~octavius@213.147.93.209.dyn.plus.net> has joined #libre-soc | 16:58 | |
| octavius | ah ok, the meeting's been moved | 17:00 |
| octavius | Thought it was going to be at 5pm. Just got back from driving, good to have some rest XD | 17:01 |
| ghostmansd | lkcl, I think I've done it | 17:25 |
| ghostmansd | I haven't checked crand yet, though | 17:26 |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC | 17:32 | |
| tplaten | My MicrowattSYSCON is: | 17:32 |
| tplaten | sys_clk_freq 50000000.0 | 17:32 |
| tplaten | core_clk_freq 100000000.0 | 17:32 |
| tplaten | mem_clk_freq 50000000.0 | 17:32 |
| tplaten | has_uart True | 17:32 |
| tplaten | spi_offset None | 17:32 |
| tplaten | dram_addr 0 | 17:32 |
| tplaten | uart_is_16550 True | 17:32 |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.168.225> has joined #libre-soc | 17:33 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.168.225> has quit IRC | 17:44 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc | 17:45 | |
| tplaten | I think I have found the error: In simsoctb.v I read "Generate 100 Mhz clock", but my design has 50 Mhz | 17:52 |
| ghostmansd | lkcl, as for crand: we don't support BRANCH or CR units yet. The code cannot match the mode. | 18:16 |
| ghostmansd | You mentioned that neither CR nor BRANCH are ready. I can adopt code from https://libre-soc.org/openpower/sv/branches/ and https://libre-soc.org/openpower/sv/cr_ops/ if you want. | 18:20 |
| ghostmansd[m] | I'll be late, hopefully in 5-10 minutes | 18:52 |
| *** tplaten <tplaten!~isengaara@d536b130.access.ecotel.net> has quit IRC | 20:14 | |
| programmerjake | lkcl: update ext58/63 opcode counts -- so 58 10-bit xo ops in fptrans | 20:24 |
| lkcl | programmerjake, ack | 20:34 |
| programmerjake | thx! | 20:34 |
| lkcl | ghostmansd[m], "doh" on crops. of course. | 20:34 |
| lkcl | i kept these separate | 20:34 |
| lkcl | "an additional 8 instructions" .... (fminss/fmaxss, fminmag/fmaxmag) | 20:34 |
| ghostmansd | I fixed the error for recognizing the mode | 20:35 |
| ghostmansd | Basically added the stub | 20:35 |
| ghostmansd | Yet another difficult part is this BA_BB crap. | 20:35 |
| lkcl | you're saying there's 58 *without* those 8-or-so? | 20:35 |
| lkcl | ghostmansd, awesome. | 20:35 |
| lkcl | sigh, yes i know. | 20:35 |
| ghostmansd | Can we start with adding cr_out2? | 20:35 |
| ghostmansd | Because then it'd work automatically. | 20:35 |
| lkcl | basically really BA and BB should be split into in1/in2/in3, it is a major hack | 20:35 |
| ghostmansd | It simply cannot match either BA or BB with BA_BB. | 20:36 |
| ghostmansd | But, if these are split, it will be matched. | 20:36 |
| lkcl | mmm stress just don't break PowerDecoder2 | 20:36 |
| lkcl | hang on | 20:36 |
| lkcl | class DecodeCRIn(Elaboratable): | 20:37 |
| lkcl | with m.Case(CRInSel.BA_BB): | 20:37 |
| lkcl | comb += self.cr_bitfield.data.eq(self.dec.BA[2:5]) | 20:37 |
| lkcl | comb += self.cr_bitfield.ok.eq(1) | 20:37 |
| lkcl | comb += self.cr_bitfield_b.data.eq(self.dec.BB[2:5]) | 20:37 |
| lkcl | comb += self.cr_bitfield_b.ok.eq(1) | 20:37 |
| lkcl | comb += self.cr_bitfield_o.data.eq(self.dec.BT[2:5]) | 20:37 |
| lkcl | comb += self.cr_bitfield_o.ok.eq(1) | 20:37 |
| lkcl | i'm reluctant to change that but it can be done | 20:37 |
| programmerjake | fptrans includes max/min/fmod/remainder now, it totals 58 10-bit xo values, so 116 instructions due to f*/f*s | 20:37 |
| lkcl | ghostmansd, yep no please don't do it - it involves too many changes to PowerDecoder2 right now | 20:38 |
| programmerjake | (basically easiest to look at the table and count the holes, then subtract from 64) | 20:38 |
| lkcl | programmerjake, ok i want to keep them as a separate group | 20:38 |
| lkcl | as they're IEEE754-2019 specific | 20:39 |
| ghostmansd | OK, but please let's plan this change. | 20:39 |
| ghostmansd | I'll do some sort of awful hackery now, but this is essential. | 20:39 |
| lkcl | ghostmansd, ack | 20:39 |
| programmerjake | actually, it includes all of ieee 754-2008/2019 and x86-style fmin/max | 20:39 |
| lkcl | just... not right now :) | 20:39 |
| ghostmansd | lkcl, OK :-) | 20:40 |
| programmerjake | fmin/max is 8 xo, fmin/maxmag is another 8 xo, so without either of those it's 42 xo | 20:42 |
| lkcl | ack | 20:43 |
| lkcl | is that *per 59/63*? | 20:43 |
| lkcl | 16 for 59 | 20:43 |
| lkcl | 16 for 63? | 20:43 |
| programmerjake | yes | 20:43 |
| lkcl | ok | 20:43 |
| programmerjake | all fptrans ops have identical xo for f*/f*s variants | 20:44 |
| programmerjake | so the opcode table is just shared between 59/63 | 20:45 |
| programmerjake | lkcl: the min/max ops are *not* all ieee 754-2019, some are ieee 754-2008 and some are x86 maxss style | 20:47 |
| programmerjake | in particular, 1/2 of the xo are -2019, 1/4 are -2008 and 1/4 are x86 maxss-style (fminc/fmaxc, borrowing *c* from vsx) | 20:51 |
| lkcl | not going to worry about it | 20:59 |
| lkcl | put that in the bugreport | 20:59 |
| lkcl | #923 | 21:00 |
| programmerjake | uuh, idk why it needs to go in #923, it's already in the wiki in the opcode tables... | 21:02 |
| programmerjake | i was more worried about factual correctness of https://git.libre-soc.org/?p=libreriscv.git;a=commitdiff;h=286420a80dbf56f6ada5bd180e7723cddefe540b | 21:03 |
| lkcl | yep not going to worry about it | 21:04 |
| programmerjake | k | 21:04 |
| lkcl | if it's already in #923 that some are 2008 and some 2019 that's for them to read and find out | 21:04 |
| lkcl | ghostmansd, a cheat would be to pre-process the csv files to add some new columns. | 21:07 |
| ghostmansd | Hmmmmm | 21:07 |
| ghostmansd | I haven't thought about it | 21:07 |
| ghostmansd | But this looks like the best option | 21:08 |
| ghostmansd | I'm already trying to adopt the code for about two hours in total, and it's really tricky | 21:08 |
| lkcl | just watch out for sv_analysis (etc) not freaking out | 21:08 |
| ghostmansd | Yeah, let's totally cheat. | 21:08 |
| lkcl | :) | 21:08 |
| * lkcl quick break | 21:09 | |
| ghostmansd | No I think I'll do it on the level where we already got the data but haven't converted it to dictionary yet. | 21:09 |
| lkcl | head spinning | 21:09 |
| lkcl | ohh yehyeh good call | 21:09 |
| ghostmansd | IIRC sv_analysis doesn't use power_insn | 21:09 |
| ghostmansd | s/dictionary/dataclass | 21:09 |
| ghostmansd | OK at the point where we actually got a dictionary but don't have an object yet | 21:09 |
| ghostmansd | I mentioned cr_out2, I was wrong, cr_in2 I think it should be. | 21:10 |
| ghostmansd | Or CR out can be such too? | 21:11 |
| ghostmansd | I don't see it in CSVs, but hypothetically | 21:11 |
| ghostmansd | [[!tag opf_rfc]] is it expected in the end of RFC? | 21:18 |
| ghostmansd | lkcl, you'll like it: after this trick, `sv.crand *16,*2,*33` immediately started working. | 21:46 |
| ghostmansd | The scalar version doesn't work yet (`sv.crand 12,2,33`). | 21:47 |
| lkcl | oleeeee | 21:47 |
| lkcl | yes, so it appears on the rfc list | 21:48 |
| lkcl | yes actually cr_in1/2/3 | 21:48 |
| lkcl | wait no | 21:48 |
| lkcl | cr_in1/2 and cr_out | 21:48 |
| lkcl | with m.Case(CRInSel.BA_BB): | 21:48 |
| lkcl | comb += self.cr_bitfield.data.eq(self.dec.BA[2:5]) | 21:48 |
| lkcl | comb += self.cr_bitfield_b.data.eq(self.dec.BB[2:5]) | 21:48 |
| lkcl | comb += self.cr_bitfield_o.data.eq(self.dec.BT[2:5]) | 21:49 |
| lkcl | so you can fake-drop BA into existing cr_in | 21:49 |
| lkcl | but need to create a 2nd fake-column... yes, cr_in2 .... which you put BB | 21:50 |
| lkcl | if you create a new CRin2Sel to match it, that will help when it comes to modifying PowerDecoder2 | 21:51 |
| lkcl | its only 2 options shoud be NONE and BB | 21:51 |
| lkcl | you'll also sigh need a new option on CRInSel: BA | 21:51 |
| lkcl | i'll do it | 21:51 |
| ghostmansd | cf last changes | 21:54 |
| ghostmansd | there's cr_in2 | 21:55 |
| ghostmansd | I added BB and BA to CRInSel, though | 21:55 |
| ghostmansd | lkcl ^ | 21:56 |
| ghostmansd | Am I right that we need a custom operand, like target_addr? | 21:56 |
| ghostmansd | It seems this cuts 2 bits from each BT/BA/BB | 21:57 |
| lkcl | no it really shouldn't | 21:58 |
| lkcl | i know why the microwatt team did it | 21:58 |
| lkcl | they didn't want to add just one extra column to the CSV files *just* for those cr* group of instructions | 21:58 |
| lkcl | they're the only ones that use BA BB BT i believe | 21:58 |
| ghostmansd | eeek! | 21:59 |
| lkcl | p40 v3.0C section 2.5.1 | 21:59 |
| ghostmansd | so many fuss for these | 21:59 |
| ghostmansd | anyway, if we're careful, things will work even this way | 21:59 |
| ghostmansd | lkcl, about the opcode matching. It turns out that we need to circumvent this for binutils, too. | 22:02 |
| ghostmansd | sv_binutils.py script stopped working due to the fact that binutils need a SINGLE opcode and a SINGLE mask | 22:02 |
| ghostmansd | and, well... we have MANY. | 22:02 |
| ghostmansd | Reproducer, if you're curious: `python src/openpower/sv/sv_binutils.py include/opcode/ppc-svp64-gen.h` | 22:03 |
| lkcl | deep joy | 22:03 |
| lkcl | hey there's this thing for merging to one opcode... :) | 22:03 |
| lkcl | but won't work for svshape, oh well | 22:04 |
| ghostmansd | Still it might depend on order | 22:04 |
| ghostmansd | Yes | 22:04 |
| ghostmansd | That said... We have hack for svshape in binutils. | 22:04 |
| ghostmansd | But I don't like it. | 22:04 |
| ghostmansd | Moreover, I'm more and more inclined to think that one day we might perhaps replace main binutils table. | 22:05 |
| ghostmansd | (don't ever tell it to anyone!) | 22:05 |
| ghostmansd | Anyway. | 22:06 |
| ghostmansd | What we might do is to have a big list of opcodes, expressed as static const uint32_t[]. | 22:06 |
| ghostmansd | Or rather uint64_t, since that's what they use. | 22:07 |
| ghostmansd | And for each struct svp64_record, we might have a pointer to some section there, plus size. | 22:07 |
| ghostmansd | Basically offset for the first opcode and count of them. | 22:07 |
| ghostmansd | Obviously code is totally unready for such experiments. They use huge static table, sorted by the opcode. | 22:08 |
| ghostmansd | Anyway, I'll return to binutils only when we're ready on disassembly part. | 22:09 |
| ghostmansd | I'd rather prefer to even start it after refactoring assembly, but, damn, these time constraints. | 22:10 |
| lkcl | sigh i know | 22:11 |
| lkcl | well things still continue (and $) | 22:11 |
| lkcl | btw do remember we can define tasks as "completed" by cutting down their definition | 22:12 |
| ghostmansd | Yeah I will reserve this as a last resort :-) | 22:12 |
| ghostmansd | I could go with "providing a solid and rapid basis for binutils disassembly", lol | 22:12 |
| ghostmansd | (not as rapid in terms of how much time it takes to create it, eh?) | 22:13 |
| ghostmansd | but rapid in terms "fuck look they just cut the fields by names and indices, what a drama!" | 22:13 |
| ghostmansd | I cannot really resist to an idea that the whole `struct svp64_ctx` goes down the drain and is replaced with a single 64-bit `struct svp64_insn` with getters and setters. | 22:14 |
| ghostmansd | MAGA really stands for "make assembly great again!" | 22:15 |
| lkcl | gooood :) | 22:15 |
| ghostmansd | lkcl, FYI, I rebased over the change you did to enums | 22:17 |
| ghostmansd | lkcl, I thought more. We really can generate list of opcodes. | 22:21 |
| ghostmansd | We do use our own lookup function. We lookup in both tables, vanilla powerpc_opcodes and our svp64_records. | 22:24 |
| ghostmansd | So, we can employ whatever form we need. | 22:24 |
| ghostmansd | For disassembly. | 22:24 |
| ghostmansd | For assembly, we lookup in both tables, too (hashed), but use the opcode from binutils table. | 22:25 |
| ghostmansd | For old vanilla instructions it works; for new ones, we just have to be careful (svshape2, I'm looking at you!). | 22:26 |
| *** lkcl <lkcl!lkcl@freebnc.bnc4you.xyz> has quit IRC | 22:27 | |
| ghostmansd | So, here: https://pastebin.com/gj7BjK7n | 22:28 |
| ghostmansd | ...we can just check not a single opcode but multiple ones. | 22:32 |
| ghostmansd | Not sure which one should be considered for a assembly when (if) we start generating this. Probably the crap I produced by merge function. | 22:33 |
| ghostmansd | Because for assembly we don't need to lookup opcodes; we only need PO, XO and static fields, both in opcode and mask form. | 22:33 |
| ghostmansd[m] | Hopefully one last note today: some modes re-use the fields (e.g. elwidth). I think we should rather have multiple different RM layouts. | 22:40 |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC | 22:53 | |
| *** alain <alain!~alain@mob-194-230-147-190.cgn.sunrise.net> has joined #libre-soc | 23:17 | |
| *** alain <alain!~alain@mob-194-230-147-190.cgn.sunrise.net> has left #libre-soc | 23:17 | |
| octavius | lkcl, is there meant to be extra indentation in the example assembler code? | 23:42 |
| octavius | For example in the DCT section, all but the first line have extra indentation | 23:43 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!