Friday, 2023-04-07

lkclprogrammerjake, we can't invent new encodings where bits 10-15 must be zero00:34
lkcl| 0-5 | 6-10 | 11-12 | 13-15 | 16-20 | 21-30 | 31 | Form   |00:35
lkcl| PO  | FRT  | IT    | 0     | RB    | XO    | Rc | X-Form |00:35
lkclthat's fine00:35
lkclalthough 13-15 should be "//"00:35
lkclthis one isn't00:35
lkcl| 0-5 | 6-10 | 11-15 | 16-20 | 21-30 | 31 | Form   |00:35
lkcl| PO  | FRT  | 0     | RB    | XO    | Rc | X-Form |00:35
lkclbits 11-15 must be "//" (indicating "don't look at them")00:36
programmerjakerust's asking for feedback on their new draft trademark policy: https://rust-lang.zulipchat.com/#narrow/stream/335408-foundation/topic/Trademarks/near/34753289900:36
programmerjakeI chose those encodings specifically so bits 11-15 can be treated like an expanded opcode, which it effectively is00:38
programmerjakehence why it uses FRB/RB instead of RA00:38
programmerjakesince that's what the other expanded opcode insns use00:38
lkclyes i know - that's an entire new discussion because it's setting an entirely new precedent00:39
lkclso it needs to go - to be replaced by "//"00:39
lkclprogrammerjake, are they also offering to pay for the cost of time taken to advise them, or are they expecting to sponge off of the expertise of others?00:41
programmerjakewell, it's pretty trivial to substitute // for 0 if the isa wg decides to do that, imho they should stay as 0 and we can add a unresolved question regarding expanded opcode encoding or not00:41
lkclthat's an entire discussion i absolutely do not want to get into right now with them00:41
programmerjakeidk, i didn't look at the rust thing yet00:41
lkclif *IBM* brings it up then i'll go with it00:41
lkclbut please listen: i have *too much to do*, i do not want to get into detailed discussions with them or with you about this00:42
lkclthere is an extremely important critical hard deadline coming up that i cannot disclose other than it exists00:42
lkclso please, use "//" and remove mention of any *additional* ideas regarding expanding opcode encoding ok?00:43
programmerjakeso, wait, it's ok to mention this idea, or is this idea included in "additional"00:44
lkclno, no mention at all00:45
lkcli don't want it raised by the ISA WG during discussions of *this* RFC00:45
lkclplease remove all mention00:46
programmerjakek, will do00:46
lkcla *new* RFC - to *discuss* the possibility of using reserved allocation bits - is ok (on a much lower priority - not for now)00:46
lkclthe complexification of the Decoder that results can then be evaluated (and it's... bad)00:47
lkclthank you jacob00:48
programmerjakewell, those reserved bits can't be retconned into being 0 and other values being illegal, since valid (but non-preferred) insns then become illegal, breaking back-compat00:48
programmerjakeso if they release v3.2 with // then they can't go back unless they add a new PCR bit or something00:49
lkcli know. not [entirely] our problem08:42
lkclprogrammerjake, the general use of the include thing for the rfcs is _great_.09:04
lkclironic that i wrote the program that does it, sigh09:05
lkclthen forgot about it (doh)09:05
programmerjakeit needed some fixing and enhancement...i changed the paths to absolute (based off `__file__`) and added makefile dependency tracking output (*.d)09:12
programmerjakehttps://git.libre-soc.org/?p=libreriscv.git;a=commitdiff;h=fba04aa8ae27751053f558ad0a1a48784e578d0d09:14
programmerjakei didn't add automatic dependency tracking to openpower/Makefile, that can be done separately09:15
programmerjakemostly just `-include $(deps)`09:16
programmerjakewhere deps is the list of generated .d files09:16
*** lx0 <lx0!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc09:47
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC09:48
*** lx0 <lx0!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc09:55
lkcldependency-tracking is a great idea10:23
programmerjakeonly issue is it always generates the .d files if missing, even for make clean10:32
lkcldoh. that's usually what "make realclean" is for. i forget the voodoo incantation for it but there should be plenty examples10:35
lkcllong story short, folks, we need to do a *full* listing - and review - of the entire suite of opcodes intended to be released https://bugs.libre-soc.org/show_bug.cgi?id=105111:00
lkclwith columns "is this vectoriseable, what's it's priority (EXT0nn, EXT2nn, EXT022), what RFC is it in"11:01
lkcletc. etc11:01
lkclwhat wiki page is it in (full URL)11:02
lkclbecause then it goes through to the OPF ISA WG, and IBM employees will get "advance notice" where at the moment they're going to be smacked with things they just cannot have looked at "because not ISA WG and not internal to IBM"11:03
lkclthis RFC is a workaround that [perfectly reasonable and rational] problem11:03
*** markos <markos!~Konstanti@static062038151250.dsl.hol.gr> has quit IRC12:40
*** octavius <octavius!~octavius@92.40.217.68.threembb.co.uk> has joined #libre-soc13:00
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC13:30
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.164.21> has joined #libre-soc13:31
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.164.21> has quit IRC15:46
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc15:47
*** octavius <octavius!~octavius@92.40.217.68.threembb.co.uk> has quit IRC16:52
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC18:32
*** ghostmansd <ghostmansd!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc19:00
ghostmansdHi folks!19:00
ghostmansdLuke, I have a question which I think should be addressed to you... this is regarding commit f56024fb535ffb81958a1624d7f57e62047848f0 in openpower-isa.19:00
ghostmansdI see that there's a modes refactoring on the way. With this in mind, are all specifiers from power_insn.py still actual?19:02
ghostmansdcf. `class Specifiers(tuple)` here: https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/decoder/power_insn.py;h=51c56054b4c9d12aa026e505513b4b83c8ac57eb;hb=refs/heads/master#l318419:03
ghostmansdI'm updating binutils with (quite limited!) support for these specifiers for task 976: https://bugs.libre-soc.org/show_bug.cgi?id=97619:04
ghostmansdBy "quite limited" I mean the following: I will add all these specifiers plus the parsing of their parameters (if any) to binutils, but won't add the real encoding yet, since this goes well beyond the scope of 976.19:07
ghostmansdThen, in scope of 1003 (https://bugs.libre-soc.org/show_bug.cgi?id=1003), I will think about whether we can re-use bits of insndb to actually generate these for binutils, too.19:08
lkcli'm not at this extremely late stage going to be adding new specifiers19:34
lkclthe implications are too massive and require weeks of work for each one19:34
*** markos <markos!~Konstanti@62.74.12.142> has joined #libre-soc19:34
lkclmy feeling is that at some point - sooner rather than later - we need a node-walker-printer system similar to that deployed in the standard python libraries for HTML and XML parsing/walking19:35
lkcl(i think it's called a SAX walker in XML terminology)19:36
lkclwhere you don't _explicitly_ walk the entire instruction database and do-something19:36
lkclyou call an *object* on encountering "feature-X", notifying the *object* "i encountered feature-X, here's the associated data, *you* do something with it"19:37
lkclyou know the sort of thing i mean19:37
lkcli just had to re-update power_decoder2.py and power_decoder_svp64_rm.py and it was... painfully laborious19:37
* lkcl waves hello19:38
*** markos <markos!~Konstanti@62.74.12.142> has quit IRC19:50
programmerjakelkcl: please do review the rust trademark license draft, even if you don't read all of it you can check the 4.1 "Uses we consider non-infringing" and 4.2 "Uses for which we are granting a license" sections and submit feedback on just that (iirc those were the main sections you had problems with in the past)19:52
programmerjakeno, they aren't paying you19:53
programmerjakeassuming you can read as fast as me, i expect it to take <10-15min to read and type feedback19:54
programmerjakeit doesn't have to happen today, but please do do it before the deadline19:55
programmerjakefeedback form (contains link to draft doc near bottom): https://docs.google.com/forms/d/e/1FAIpQLSdaM4pdWFsLJ8GHIUFIhepuq0lfTg_b0mJ-hvwPdHa4UTRaAg/viewform?usp=sf_link19:57
programmerjakethe deadline is april 16 at 5pm PDT20:02
*** markos <markos!~Konstanti@62.74.12.142> has joined #libre-soc20:09
*** markos <markos!~Konstanti@62.74.12.142> has quit IRC20:23
*** markos <markos!~Konstanti@62.74.12.142> has joined #libre-soc20:38
*** markos <markos!~Konstanti@62.74.12.142> has quit IRC20:54
programmerjakethis is important because we are publicly using rust for kazan (and probably other stuff) and because I want to eventually add svp64 support to rustc22:19
programmerjakeif you don't get around to it, others are submitting feedback similar to what i think you'd have to say: https://rust-lang.zulipchat.com/#narrow/stream/335408-foundation/topic/.E2.9C.94.20Trademarks/near/34773864222:26
*** gnucode <gnucode!~gnucode@user/jab> has joined #libre-soc23:05

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