Wednesday, 2022-07-06

programmerjakelkcl: you assigned payments of 750+250 but a total budget of 800 for
programmerjakeplease fix it....not sure which you intended08:43
lkclprogrammerjake, working on it.  i reopened it, just emailing you a pdf screenshot08:55
lkcli'll do a review of the non-HTTP-submittable ones08:56
lkclso you can put something in08:57
programmerjakeok...was i not supposed to submit the cryptorouter one via email 2 weeks ago?08:59
lkclthat's one that has a secret URL, now09:00
programmerjakedid it have a secret url 2 weeks ago?09:02
lkclyyyyes, something like that09:02
programmerjakehmm, maybe we should email someone at nlnet so they can make sure it doesn't get lost09:03
lkclerrr which seems to now be broken. er09:03
lkcli reviewed 3, all good09:04
programmerjakelkcl, do you think i should send an email to prevent that rfp i sent 2 weeks ago from getting lost?09:38
programmerjakei'll work on the new stuff in #882 tomorrow09:39
lkclprogrammerjake, no, they'll be dealing with it09:39
lkclsensible. bit late tonight09:40
programmerjakelkcl, one more rfp for you to check -- 2019-10-032-MoU-Jacob Lifshay-The Libre RISC-V SoC, Formal Correctness Proofs09:47
lkclthat one's quite big, so would best have the totals09:47
lkclnuts.  2019-10-046 is the one that i've got the secret URL for09:48
lkclemail already sent so don't worry about it09:48
programmerjakei'll manually calculate totals for it then...don't want to wait for writing a bunch of code09:49
programmerjakeactually, they're all part of #196, so i don't think a separate total is necessary09:51
programmerjakelkcl, sound good?09:51
lkclah! well spotted09:59
lkclthen yes, put that at the end of the notes.09:59
lkcllet me review it10:00
lkclprogrammerjake, yep all good.10:03
programmerjakesent for review10:04
lkclexplicitly put10:06
lkcl "total EUR 7450 is part of Milestone 196"10:06
lkclotherwise they have to hunt in a separate place for the amount10:06
lkcllook at the PDF screenshot i sent you10:06
programmerjakeok, though they can just read the total further up...10:07
lkclthat's what they have to manually fill in, and if the.10:07
lkclnooo, that's precisely and exactly what is inconvenient10:07
lkcl"they can just"10:07
lkclmeans they have to exert energy and spend time doing so10:07
programmerjakeis this fine:10:10
programmerjakeeverything (eur 7450) is part of MoU Milestone10:10
programmerjake[Bug #196](
programmerjakelkcl ^10:11
lkclmaarnin octavius13:49
lkcloh wait, it's 2pm :)13:49
octaviusmorning lkcl13:49
octaviusAh, good afternoon13:49
lkcloctavius, i'm updating the pinmux submodule after that gpio error is fixed14:23
octaviuslkcl, added a few more links to the spec, however "svfparith" and "svfixedarith" are pointing to page 1 (I've seen this issue with other links). Do you know how to fix this?16:03
octaviusAlso, what do you want to do with links for pages that aren't in the spec (sv/implementation, sv/fcvt, etc.)?16:04
octaviusAh, I think I'm figuring out why the links are going to page 1, will fix now16:13
octaviusAn interesting issue in the hyperlink naming I noticed, is that the expected name is different if there's a reference to it from another directory16:32
octaviusfor example, svp64/appendix turns into "svp64ux2fappendix" and sv/svp64/appendix turns into "svux2fsvp64ux2fappendix"16:35
octaviusBut it looks like the issue might be with the branches.mdwn file (it uses both links)16:36
octaviusSo for every dir level, the auto-gen link adds the [dir]ux2f prefix16:37
lkclso add the extra hyperlinks to the top-level .tex16:41
lkclsome of these double-names i am removing16:42
lkclyes, you can't control what hyperlinks pandoc creates, but you can add extra hyperlink targets (multiple if necessary)17:04
lkcl"/" in any markdown pagelink is substituted "ux2f"17:05
lkcltherefore you can work out precisely and exactly what hyperlink to put into the top-level .tex17:05
octaviusYep, thanks17:06
octaviusAs for links to pages we haven't added, what to do with those?17:06
octaviusFor example: sv/example_dep_matrices17:07
octaviussv.tex, Other section has a bunch of links17:08
lkclignore them17:14
lkclif you look at the contents you'll find they're not useful17:14
lkcli.e. "are not a specification"17:14
octaviusAh ok17:14
lkcli.e. "in no way would you ever submit them to the OPF ISA WG for inclusion in the Power ISA Specification"17:14
ghostmansdHi folks. What's the official way to update our sources?17:59
octaviusWhat sources?18:00
ghostmansdopenpower-isa in particular, plus anything related.18:00
ghostmansdAny fucking time I try to run tests I meet erros like `ModuleNotFoundError: No module named 'nmigen.sim'`, or `ImportError: cannot import name 'GTKWColor' from 'vcd.gtkw' (/usr/local/lib/python3.7/dist-packages/pyvcd-0.1.7-py3.7.egg/vcd/`.18:00
lkclahh ok.18:00
ghostmansdI mean, it's been a while, and since then I only did git pull origin master --rebase.18:00
lkcl"officially", use the dev-env-setup scripts18:00
ghostmansdBut won't it mean that I have to reinstall all from the scratch?18:01
octaviusOnce it's installed you usually just "git pull"18:01
ghostmansdI mean, I'm aware of dev-env-setup, but it starts the whole process.18:01
ghostmansd> just git pull18:01
ghostmansdapparently not18:01
lkclthat will almost certainly be because of the fucking irritating fact that the Trademarked github nmigen repository is being cyber-squatted18:01
ghostmansdFWIW, I'm on Talos18:02
ghostmansdBut this also is a problem on my usual box18:02
lkclyou'll almost certainly have been hit by pip3 fucking well pulling in shit that you didn't ask for18:02
lkclyes it's very irritating, but you just have to be very patient, there's not a lot we can do about it18:02
ghostmansdanyway, I checked the only test which launched successfully: test_caller_svstate.py18:02
ghostmansdAnd I did a change which allows crap like *fv018:03
ghostmansdThat is, any macro can be used as register name18:03
lkclyou *must not* let pip3 go and do arbitrary random downloads off the internet18:03
ghostmansdAs long as it can be expanded to integer.18:03
ghostmansd(I mean 884)18:03
ghostmansdI needed this, because I need the to be on par with binutils18:04
lkclghostmansd, run this command:18:04
lkcl$ pip3 list | grep nmigen18:04
ghostmansd...and guess what? binutils can already handle it!18:04
lkclit should be something like:18:04
lkclnmigen                          0.3.dev361+g9ce40c1.dirty18:04
lkclnmigen-boards                   0.1.dev203+gacb0280.dirty18:04
lkclnmigen-soc                      0.1.dev47+g5ba0d2518:04
lkclnmigen-stdio                    0.1.dev6+gaf01aba18:04
lkclit should **NOT** have "nmigen         0.2"18:04
ghostmansdhere's the fucker: nmigen                 0.2                 /usr/local/lib/python3.7/dist-packages/nmigen-0.2-py3.7.egg18:04
lkcltrash it18:04
ghostmansddone `sudo pip3 uninstall nmigen` under chroot18:05
ghostmansd(BTW you dropped my admin powers, right?)18:05
ghostmansdso that I won't fuck stuff whilst not being under chroot18:06
lkclthen don't *whatever you do* use "python3 develop" *without* also adding "--no-deps"18:06
lkclyyyeees i did18:06
lkclso you should do "python3 develop --no-deps"18:06
lkclyou *can* still do "sudo bash"... *within* the chroot18:07
lkclhaving had pip3 "damage" your environment, you may now need to check the dependencies listed in setup.py18:07
lkcland explicitly restore the specific listed versions18:08
lkclfor that, you *can* use "python3 develop" in the nmigen directory18:08
programmerjakeschroot generally copies /etc/passwd and stuff from outside the chroot, so if you lose sudo access there, you likely will lose it inside the chroot too18:08
lkcland it should restore things like the correct version of pyvcd etc.18:08
ghostmansdperhaps it'd be simpler to install stuff from scratch, eh?18:09
lkclghostmansd, weeelll... it shouldn't be necessary.18:09
ghostmansdI pushed the commit for now, I checked it on a local mp3 assembly and est_caller_svstate.py18:10
lkcloh nice. macro support in regs.18:11
ghostmansdalso checking test_caller_svp64.py18:11
ghostmansdlkcl, yeah I needed this18:11
ghostmansdI'm now checking how macros work in binutils18:11
lkclit _shouuuld_ have just worked with the existing macro "support" in svp64.py18:11
lkclconfirmed, works18:12
ghostmansdand I converted this mp3_0_apply_window_float_basicsv.s into a "new" form18:12
lkcl$ python3 decoder/isa/ >& /tmp/f18:12 is ok18:12
ghostmansdI guess I broke nothing18:12
ghostmansd(or should I say hope)18:12
ghostmansdOK let me know if this commit must go down the drain18:13
ghostmansdI'll continue with binutils for now18:13
lkclworks great18:13
lkcli'll run a few more18:13
ghostmansdthe approach is as idiotic and straightforward, but should work, yeah18:13
ghostmansdI mean, this was the most quick and dirty thing I managed to do to not waste time there :-)18:14
lkcl$ python3 decoder/isa/ >& /tmp/f18:14
ghostmansdBTW we magically got ".machine libresoc" directive support :-)18:15
ghostmansdOK I found some discrepancy between binutils and pysvp64asm, I'll check this, but macros seem to work18:16 no errors18:16
lkclno "damage" done, always a good thing18:16
ghostmansdI'll fix the discrepancy and make sure we're able to compile this mp3 assembly18:16
lkclif that also compiles with binutils that's a big damn deal18:16
ghostmansdthis already compiles :-)18:17
lkclis the object file the same, though?18:17
ghostmansdthat's the issue I meant18:17
lkclah :)18:17
ghostmansdthis is the discrepancy, some bits differ18:17
ghostmansdI guess remap is doomed :-)18:17
lkcldooomed, doomed i say18:18
ghostmansdupdated media/audio/mp3/mp3_0_apply_window_float_basicsv.s to a new notation18:34
lkclthat looks alright18:35
ghostmansdverified this way: 1) run pysvp64asm on old version; 2) compile the output to a new object; 3) do the same for a new; 4) compare18:35
ghostmansd(compare objects obviously, either binaries or objdumps)18:35
ghostmansdI haven't switched to .machine libresoc yet, maybe later18:36
lkclyyeah you'd need to get pysvp64asm to ignore that18:36
lkclwhich is easy enough18:36
ghostmansd[m]I think pysvp64 is not an issue here.18:48
ghostmansd[m]It likely already ignores it.18:49
ghostmansd[m]The real issue is that we should compile this code with either binutils only...18:49
lkclyyeah i'd prefer not to depend on it.18:49
lkclbut if it exists, and has -mlibresoc, carries out a binary comparison18:50
lkclexactly as you just did, except automated18:50
ghostmansd[m]if we'd like to use either, we must be able to compile it with either libresoc or power9+pysvp64asm18:51
ghostmansd[m]I guess this should be done on build level: we must detect whether we have binutils18:51
lkclmarkos is planning almost certainly to use binutils *not* pysvp64asm because of macro support18:52
ghostmansd[m]Well I'd use binutils everywhere as long as it can be ensured it has the same binary output as our etalon.19:04
ghostmansd[m]Because this is de facto standard.19:04
lkcli'm just reticent to make it a hard dependency19:34
lkcli'll likely get over it :)19:35
lkclprogrammerjake, btw there's no build instructions anywhere for bitwuzla20:13
lkcli got cvc5 installed manually a month ago20:13
lkclieee754fp proofs fail because bitwuzla isn't available20:14
programmerjakelook in the .gitlab-ci.yml, those build instructions work just fine for me23:19
lkclwhich .gitlab-ci.yml?23:20
lkclwhich repository?23:20
lkclnobody uses those to perform local machine installations23:20
lkclwe need *build* scripts23:20
lkclnot manual instructions23:21
programmerjakein ieee754fpu23:21
programmerjakealso see:
openpowerbot[slack] <github> signin23:21
programmerjakewell, those instructions work just fine for me, they can be added to dev-env-setup23:22
programmerjakeas a build script23:23

Generated by 2.17.1 by Marius Gedminas - find it at!