Wednesday, 2023-01-18

*** tplaten <tplaten!~isengaara@d536cd14.access.ecotel.net> has quit IRC00:28
*** yambo <yambo!~yambo@069-145-120-113.biz.spectrum.com> has joined #libre-soc00:55
*** gnucode <gnucode!~gnucode@user/jab> has quit IRC02:08
*** gnucode <gnucode!~gnucode@user/jab> has joined #libre-soc02:08
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc02:55
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC03:09
*** gnucode <gnucode!~gnucode@user/jab> has quit IRC03:17
programmerjakefound something interesting: https://antmicro.com/blog/2021/09/fpga-interchange-format/03:20
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc03:57
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc06:38
*** openpowerbot <openpowerbot!~openpower@94-226-188-34.access.telenet.be> has quit IRC07:18
*** toshywoshy <toshywoshy!~toshywosh@ptr-377wf33o3bnthuddmycb.18120a2.ip6.access.telenet.be> has quit IRC07:19
*** octavius <octavius!~octavius@92.40.169.24.threembb.co.uk> has joined #libre-soc08:34
octaviusThanks for sharing programmerjake, very interesting read08:39
*** ghostmansd <ghostmansd!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC08:56
*** octavius <octavius!~octavius@92.40.169.24.threembb.co.uk> has quit IRC09:27
*** toshywoshy <toshywoshy!~toshywosh@ptr-377wf33o3bnthuddmycb.18120a2.ip6.access.telenet.be> has joined #libre-soc11:10
*** openpowerbot <openpowerbot!~openpower@94-226-187-44.access.telenet.be> has joined #libre-soc11:15
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC11:41
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.57.85> has joined #libre-soc11:50
*** octavius <octavius!~octavius@92.40.169.25.threembb.co.uk> has joined #libre-soc12:07
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.57.85> has quit IRC12:52
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.172.136> has joined #libre-soc12:53
*** octavius <octavius!~octavius@92.40.169.25.threembb.co.uk> has quit IRC15:23
sadoon[m]Interesting indeed15:35
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.172.136> has quit IRC15:45
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc15:47
*** ghostmansd <ghostmansd!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc16:59
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC17:06
ghostmansdlkcl, sorry, but everything you said about FF mode for CR ops and the CR being read from field is incorrect as it stands in code.17:07
ghostmansdhttps://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/sv/trans/svp64.py;h=c61e92833d696d46c50bf715c898b33a3100aa49;hb=HEAD#l142917:07
ghostmansdI repeat: please fix either the spec or the code.17:08
ghostmansdIf the spec is correct, then tests as they stand, say test_pysvp64dis, should not  work.17:08
ghostmansdFor now, I'm doing it the same way as svp64 does, and leaving a huge pile of FIXME.17:09
ghostmansdSorry, I'm fed up with it, and have no patience discovering the rationale between spec/code inconsistencies.17:09
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc17:34
lkclghostmansd, give me a second to look at it17:45
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC17:45
lkclthe spec is correct - sv/trans/svp64.py may be behind17:46
lkcli've only spent approx... 4 (if that) days on cr_ops17:46
lkclwhereas the rest is 6+ months17:46
lkcl1421             elif failfirst is not False and is_cr:17:47
lkcl1422                 if failfirst in ['RC1', '~RC1']:17:47
lkclyep that is definitely wrong: there cannot be and there never will be ff=RC117:48
lkclif i remember correctly i needed a cr_op mode for something and did a quick hack, which prompted a review (which i told you about a couple days ago)17:49
lkclbut then got pulled to other things17:49
lkclfeel free to rip those lines out completely and replace them with a correct implementation of the spec.17:49
lkclif you want me to do it, i'll need a few hours... call it 1/2 a day, just to make sure.17:51
ghostmansdFor now my intention is to make tests work.17:52
ghostmansdAnything else is to be addressed later.17:52
ghostmansdI already spent way too much time at this task. It turned out way more complex than I really expected.17:53
ghostmansdAt least we now have something for fields to be autogenerated, though.17:53
ghostmansdDo we have a meeting today?17:53
lkclno - in 2 weeks time18:02
lkclexcellent18:02
lkclwell, there is plenty of room to increase budgets18:02
lkcl"making tests work" is a great 1st step, not taking on too much at once18:02
lkclpaul is back only yesterday, i figured it wise to give him a couple weeks before we start back up again.18:03
programmerjakethere is a meeting next tue, so 6 days not 1418:03
programmerjakeyeah18:03
lkclso.... wed 25th.18:04
lkclyes just checked18:04
ghostmansdAha, OK, good. Thanks!18:05
programmerjakethat's the next wed meeting, the next meeting (that i attend) is next tue18:05
ghostmansdI guess the next big task will be "generate the code for specifiers and decode" via some config. I've extended our tables with fields validation and checks for fields. However, all these fields are done manually, and this should be generated from configuration instead.18:08
ghostmansdNo idea yet how to make this configuration in a good form yet. Especially the crap around CR ops which are completely mad.18:08
ghostmansdIs it correct that master CI is broken too?18:10
ghostmansdI see an error for two tests in test_pysvp64dis: test_26_sv_stq_vector_name and test_4_sv_crand. The last one I know how to fix; the former is, wel... interesting.18:11
ghostmansdhttps://salsa.debian.org/Kazan-team/mirrors/openpower-isa/-/jobs/372959418:11
ghostmansdHere's what we have on master...18:12
ghostmansd$ echo "sv.stq *4,16(*5)" | SILENCELOG=true pysvp64asm18:12
ghostmansd.long 0x05400500; stq *4, 16(1) # sv.stq *4,16(*5)18:12
ghostmansdThis is being fixed in insndb branch, I'm investigating it, but I wonder whether it worked before18:14
programmerjakeyes, master ci is broken due to luke deciding it's ok to leave tests broken for a while for things that are being newly added18:26
programmerjakeiirc18:27
programmerjakegenerally what i do is ensure i don't break any tests that were not broken before i modified stuff18:28
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc18:39
ghostmansdOK, about stq. The insndb branch now produces the code `.long 0x05402500; stq 1,16(1) # sv.stq *4,16(*5)`, which seems to be better and more correct. However, this yields another issue with binutils.18:49
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC18:49
ghostmansdStupid IRC, sigh18:49
ghostmansd`/tmp/insndb.s:1: Error: operand out of domain (1 is not a multiple of 2)`18:49
ghostmansdIt seems there's an error upon operand remapping.18:52
programmerjakethe error is that the operand can be encoded but the suffix insn is an illegal encoding -- it works just fine as a svp64 op tho since the register num gets rewritten18:53
programmerjakeseems like a special case that should output .long for the suffix18:54
programmerjakesame thing for all other register pair operands18:55
ghostmansdHmmmm....18:56
ghostmansdWell I could add a trick into pysvp64asm for that18:58
ghostmansdThanks programmerjake!18:58
ghostmansdWe now have a separate style which outputs "backward-compatible disassembly" (that is, a pair of .long and remapped insn, as it used to be)18:59
ghostmansdSo I guess this is the only one affected18:59
programmerjakeeverywhere there's a register pair operand should have the same issue, not just stq19:00
ghostmansdYep, I'm checking the list in fields.txt19:11
ghostmansdThere's quite a lot19:11
ghostmansd6 operands overall19:13
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC20:07
*** gnucode <gnucode!~gnucode@user/jab> has joined #libre-soc20:10
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc20:32
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC20:37
ghostmansdHoly cow, finally the whole disassembly test works!20:45
ghostmansdlkcl, I think I found what got wrong with fail-fist on CRs20:46
ghostmansdThe code swapped 3-bit and 5-bit FF CR RM classes20:46
ghostmansdAnyway, I'm going to wait for CI to finish20:46
ghostmansdLikely the journey isn't over yet20:47
ghostmansdprogrammerjake, does CI need a manual poke?20:49
ghostmansdJobs list is empty: https://salsa.debian.org/Kazan-team/mirrors/openpower-isa/-/jobs20:49
ghostmansdPerhaps I should just wait for some time for CI to start20:50
programmerjakethe mirroring process checks for new git commits every 5min iirc, this is because luke refused to modify git.libre-soc.org to update the mirror git repos when someone pushes to git.libre-soc.org, so i had to resort to polling from the build server...20:52
ghostmansdAh, OK...20:57
ghostmansdI see that the last commit is not there yet; let's wait.20:57
programmerjakeoh, i know why, the internet is currently down at my house, so of course it doesn't work...21:01
programmerjakemy housemate apparently accidentally turned off the power for the router, it should work again shortly21:05
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc21:07
programmerjakehttps://salsa.debian.org/Kazan-team/mirrors/openpower-isa/-/jobs/381828421:08
ghostmansdAh, great! Thank you!21:12
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc22:17
*** gnucode <gnucode!~gnucode@user/jab> has quit IRC23:48
*** gnucode <gnucode!~gnucode@user/jab> has joined #libre-soc23:48

Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!