lkcl | programmerjake, we can't invent new encodings where bits 10-15 must be zero | 00: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 |
lkcl | that's fine | 00:35 |
lkcl | although 13-15 should be "//" | 00:35 |
lkcl | this one isn't | 00: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 |
lkcl | bits 11-15 must be "//" (indicating "don't look at them") | 00:36 |
programmerjake | rust's asking for feedback on their new draft trademark policy: https://rust-lang.zulipchat.com/#narrow/stream/335408-foundation/topic/Trademarks/near/347532899 | 00:36 |
programmerjake | I chose those encodings specifically so bits 11-15 can be treated like an expanded opcode, which it effectively is | 00:38 |
programmerjake | hence why it uses FRB/RB instead of RA | 00:38 |
programmerjake | since that's what the other expanded opcode insns use | 00:38 |
lkcl | yes i know - that's an entire new discussion because it's setting an entirely new precedent | 00:39 |
lkcl | so it needs to go - to be replaced by "//" | 00:39 |
lkcl | programmerjake, 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 |
programmerjake | well, 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 not | 00:41 |
lkcl | that's an entire discussion i absolutely do not want to get into right now with them | 00:41 |
programmerjake | idk, i didn't look at the rust thing yet | 00:41 |
lkcl | if *IBM* brings it up then i'll go with it | 00:41 |
lkcl | but please listen: i have *too much to do*, i do not want to get into detailed discussions with them or with you about this | 00:42 |
lkcl | there is an extremely important critical hard deadline coming up that i cannot disclose other than it exists | 00:42 |
lkcl | so please, use "//" and remove mention of any *additional* ideas regarding expanding opcode encoding ok? | 00:43 |
programmerjake | so, wait, it's ok to mention this idea, or is this idea included in "additional" | 00:44 |
lkcl | no, no mention at all | 00:45 |
lkcl | i don't want it raised by the ISA WG during discussions of *this* RFC | 00:45 |
lkcl | please remove all mention | 00:46 |
programmerjake | k, will do | 00:46 |
lkcl | a *new* RFC - to *discuss* the possibility of using reserved allocation bits - is ok (on a much lower priority - not for now) | 00:46 |
lkcl | the complexification of the Decoder that results can then be evaluated (and it's... bad) | 00:47 |
lkcl | thank you jacob | 00:48 |
programmerjake | well, 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-compat | 00:48 |
programmerjake | so if they release v3.2 with // then they can't go back unless they add a new PCR bit or something | 00:49 |
lkcl | i know. not [entirely] our problem | 08:42 |
lkcl | programmerjake, the general use of the include thing for the rfcs is _great_. | 09:04 |
lkcl | ironic that i wrote the program that does it, sigh | 09:05 |
lkcl | then forgot about it (doh) | 09:05 |
programmerjake | it needed some fixing and enhancement...i changed the paths to absolute (based off `__file__`) and added makefile dependency tracking output (*.d) | 09:12 |
programmerjake | https://git.libre-soc.org/?p=libreriscv.git;a=commitdiff;h=fba04aa8ae27751053f558ad0a1a48784e578d0d | 09:14 |
programmerjake | i didn't add automatic dependency tracking to openpower/Makefile, that can be done separately | 09:15 |
programmerjake | mostly just `-include $(deps)` | 09:16 |
programmerjake | where deps is the list of generated .d files | 09:16 |
*** lx0 <lx0!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc | 09:47 | |
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC | 09:48 | |
*** lx0 <lx0!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc | 09:55 | |
lkcl | dependency-tracking is a great idea | 10:23 |
programmerjake | only issue is it always generates the .d files if missing, even for make clean | 10:32 |
lkcl | doh. that's usually what "make realclean" is for. i forget the voodoo incantation for it but there should be plenty examples | 10:35 |
lkcl | long 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=1051 | 11:00 |
lkcl | with columns "is this vectoriseable, what's it's priority (EXT0nn, EXT2nn, EXT022), what RFC is it in" | 11:01 |
lkcl | etc. etc | 11:01 |
lkcl | what wiki page is it in (full URL) | 11:02 |
lkcl | because 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 |
lkcl | this RFC is a workaround that [perfectly reasonable and rational] problem | 11:03 |
*** markos <markos!~Konstanti@static062038151250.dsl.hol.gr> has quit IRC | 12:40 | |
*** octavius <octavius!~octavius@92.40.217.68.threembb.co.uk> has joined #libre-soc | 13:00 | |
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 13:30 | |
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.164.21> has joined #libre-soc | 13:31 | |
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.164.21> has quit IRC | 15:46 | |
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 15:47 | |
*** octavius <octavius!~octavius@92.40.217.68.threembb.co.uk> has quit IRC | 16:52 | |
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 18:32 | |
*** ghostmansd <ghostmansd!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 19:00 | |
ghostmansd | Hi folks! | 19:00 |
ghostmansd | Luke, I have a question which I think should be addressed to you... this is regarding commit f56024fb535ffb81958a1624d7f57e62047848f0 in openpower-isa. | 19:00 |
ghostmansd | I 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 |
ghostmansd | cf. `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#l3184 | 19:03 |
ghostmansd | I'm updating binutils with (quite limited!) support for these specifiers for task 976: https://bugs.libre-soc.org/show_bug.cgi?id=976 | 19:04 |
ghostmansd | By "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 |
ghostmansd | Then, 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 |
lkcl | i'm not at this extremely late stage going to be adding new specifiers | 19:34 |
lkcl | the implications are too massive and require weeks of work for each one | 19:34 |
*** markos <markos!~Konstanti@62.74.12.142> has joined #libre-soc | 19:34 | |
lkcl | my 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/walking | 19:35 |
lkcl | (i think it's called a SAX walker in XML terminology) | 19:36 |
lkcl | where you don't _explicitly_ walk the entire instruction database and do-something | 19:36 |
lkcl | you 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 |
lkcl | you know the sort of thing i mean | 19:37 |
lkcl | i just had to re-update power_decoder2.py and power_decoder_svp64_rm.py and it was... painfully laborious | 19:37 |
* lkcl waves hello | 19:38 | |
*** markos <markos!~Konstanti@62.74.12.142> has quit IRC | 19:50 | |
programmerjake | lkcl: 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 |
programmerjake | no, they aren't paying you | 19:53 |
programmerjake | assuming you can read as fast as me, i expect it to take <10-15min to read and type feedback | 19:54 |
programmerjake | it doesn't have to happen today, but please do do it before the deadline | 19:55 |
programmerjake | feedback form (contains link to draft doc near bottom): https://docs.google.com/forms/d/e/1FAIpQLSdaM4pdWFsLJ8GHIUFIhepuq0lfTg_b0mJ-hvwPdHa4UTRaAg/viewform?usp=sf_link | 19:57 |
programmerjake | the deadline is april 16 at 5pm PDT | 20:02 |
*** markos <markos!~Konstanti@62.74.12.142> has joined #libre-soc | 20:09 | |
*** markos <markos!~Konstanti@62.74.12.142> has quit IRC | 20:23 | |
*** markos <markos!~Konstanti@62.74.12.142> has joined #libre-soc | 20:38 | |
*** markos <markos!~Konstanti@62.74.12.142> has quit IRC | 20:54 | |
programmerjake | this is important because we are publicly using rust for kazan (and probably other stuff) and because I want to eventually add svp64 support to rustc | 22:19 |
programmerjake | if 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/347738642 | 22:26 |
*** gnucode <gnucode!~gnucode@user/jab> has joined #libre-soc | 23:05 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!