Thursday, 2022-05-26

lkcldang, programmerjake, all of those languages are trademarked!10:42
lkclrust is trademarked. java is trademarked. javascript is trademarked. someone *attempted* to trademark webassembly (it was invalidated)10:42
programmerjakethe latest rust trademark policy:
programmerjakesince we're referring to rust as part of a specification (documentation), that'll likely be covered by the explicit permission grant they have for referring to rust in docs10:51
programmerjakewe could ask them, i'd be quite surprised if they don't say yes, that's fine. also, i am sorta part of the Rust project10:52
lkclSPIR-V: trademarked10:52
lkclthere's no need to ask them for what amounts to "fair use"10:52
programmerjakesince i'm a member of the rust library portable-simd working group10:52
lkclTrademark Law has a provision that if you literally cannot refer to something except by its Trademark, in order to do something as simple as mention it, then that is permitted10:53
programmerjakeasking them if you're worried is what i meant. imho asking isn't necessary in this case, bht it never hurts10:53
lkclno i'm not worried, but the fact that *all* of these are Trademarked (except WebAssembly) has me on high alert10:54
lkclmeaning, we can't use them as "Heading descriptors"10:54
lkclwe'll have to come up with alternative names, such as "Modulo semantics" or "wrapping semantics" for javascript(tm)10:54
lkclwe're putting this to the OPF ISA WG.10:55
lkclOPF and IBM's Lawyers *will* go on high alert at the mention of Trademarked property in the Power ISA Specification.10:55
lkcland a section right at the front of the Power ISA Specification will have to be added:10:56
lkclRust is a Trademark of the Rust Foundation10:56
lkclJava is a Trademark of Oracle10:56
lkclJavascript is a Trademark of Oracle10:56
lkclSPIR-V is a Trademark of the Khronos Group10:56
lkclfrickin ell even LLVM is trademarked
openpowerbot[slack] <github> signin10:59
lkcltoshywoshy, huh? :) ^10:59
programmerjakei'd guess slack lets you send commands in chat to do stuff on github, but you need to be signed-in to github for that to work11:03
programmerjakealso, the openpower spec already has bits in one of the registers named something like Java-mode11:04
programmerjakeso i think there won't be a problem to have Rust mode especially since Rust is much more likely to grant us a trademark license if we need it than oracle is11:06
lkclto repeat: i don't want to put road blocks in the way that cost the OpenPOWER Foundation in Lawyers time11:12
lkclall headings referring to Trademarks have to go, with headings that refer to the functinoality not a Trademark11:13
lkcl|rust semantics"11:13
lkcl"javascript semantics"11:13
lkcl"java semantics"11:13
* midgardian[m]1 is happy for chatlogs11:14
lkclOpenPOWER semantics can stay11:14
lkclIEEE754 semantics can also likely stay although that'll also need checking11:14
lkclIEEE754 doesn't appear but "IEEE standard" does11:15
lkclp131 book I v3.1 section 4.111:16
lkcl(they define the term "IEEE Standard" to refer to IEEE 754-198somethign11:16
lkclmidgardian[m]1, yeah we couldn't run a project of this size/complexity without them11:17
programmerjakethe bit i was referring to is the "Vector Non-Java Mode (NJ)" bit in VSCR11:30
octaviusRecently got out my old monitor for the laptop...portrait orientation is amazing!13:14
octaviusActually seeing the whole webpage/irc log/pdf to scale13:15
ghostmansdsvp64_rm.mask.eq(SelectableInt(pmask, SVP64RM_MASK_SIZE))15:09
ghostmansdsvp64_rm.subvl.eq(SelectableInt(subvl, SVP64RM_SUBVL_SIZE))15:09
ghostmansdsvp64_rm.ewsrc.eq(SelectableInt(srcwid, SVP64RM_EWSRC_SIZE))15:09
ghostmansdsvp64_rm.elwidth.eq(SelectableInt(destwid, SVP64RM_ELWIDTH_SIZE))15:09
ghostmansdAll this looks quite inconsistent. Why not call the local variables the same we call fields?15:10
ghostmansdI broke on mask != pmask, but the rest is even less consistent.15:10
ghostmansdlkcl, dropped a chunk of copy&paste code in; basically there's way more, but this was a really obvious: handling of CR3/CR515:27
ghostmansdalso it is really annoying that prefix was output without leading zeroes, as `.long 0x%x`; I've changed it to `.long 0x%08x`, I have no patience counting zeroes.15:28
ghostmansdgood news: `sv.stw 5.v, 4(1.v)` gets converted to...15:29
ghostmansd0000000000000000 <.text>:15:29
ghostmansd   0:   05 40 2d 00     svmagic 1152015:29
ghostmansd   4:   90 20 00 04     stw     r1,4(0)15:29
ghostmansdcompare to `list ['.long 0x05402d00', 'stw 1, 4(0)']`15:30
ghostmansdI'm going to check more instructions, but hopefully soon the remapping will be completed15:30
ghostmansdonce this is ready, I guess I'll raise a standalone task to make disassembly avoid "svmagic", that is, make it a real prefix15:31
ghostmansdthis likely won't be easy, though, but have to check in details15:31
lkcloctavius, hoorah :)15:43
lkclghostmansd, because there are actually two widths and two masks in some cases15:45
lkclor, there _were_ going to be *either* one *or* two elwidths, but the spec evolved so that there *are* exactly two elwidths15:46
lkcl[for instructions that have both src and destination registers, that is]15:46
lkcl[and where elwidths actually make sense]15:47
lkclelwidth overrides do not make sense for CRs, for example15:47
lkclhow can you override a 4-bit CR Field to change its width??15:47
lkcl2 bit?15:47
lkcl1 bit?15:47
lkcl8 bit?15:47
lkclall total bollocks.15:47
lkclpredication, you can have *TWO* predicates15:48
lkclhence the names, "2P" - twin preciation15:48
lkcl"1P" - single predication15:48
lkclfor 1P (single predication), the mask applies to **BOTH** the source **AND** the destination register15:49
lkclfor 2P (twin predication) there is a *SEPARATE* predicate for source and a *SEPARATE* predicate mask for destination15:49
lkclthere is always one predicate, therefore svp64_rm has the name "mask" for this15:50
lkclwhen you do *not* have twin-predication, those bits get used for *other purposes*15:51
lkclif this did not happen - if those bits were not used for other purposes under some circumstances - then you would be justified in saying "the fields do not match the local variables"15:52
lkclbut they do not quotes match quotes because they are not available for all circumstances for all instructions15:52
lkclno, really, please *do not* change the functionality of this code15:54
lkclyou literally destroyed how SVP64 works on CR field numbering with that patch15:58
lkcl-                        sv_extra = 0b100 | (sv_extra >> 2)15:58
lkcl-                        sv_extra = sv_extra & 0b1115:59
lkclall of those are how the EXTRA2/3 works, and you removed absolutely every single one of them15:59
lkclmaking completely non-compliant with the specification16:00
lkclthe purpose of is to be "obvious", provide comments, and be a strict and clear reference implementation16:01
lkclspeed and optimisation is not just rock-bottom of the list as a priority, it's a *negative* priority because it is a hindrance on clarity16:01
lkclgood call about the inaccurate comments16:05
lkcl+                            "vector CR %s cannot fit into EXTRA3 %s" % \16:05
lkclok i've stopped freaking out and have understood what you were doing16:07
lkclit would be better to have the CR Field decoded as a function16:07
lkclwhich is called by both cases, with *clear* comments as to what is being called, with what, and why, in each case16:08
lkclok, so starting again:16:12
lkcli don't mind code-reuse for the 5-bit and 3-bit CR cases as long as comments are not removed16:13
lkcl-            # encode SV-CR 5-bit field into extra, v3.0field16:13
lkcl-            # *sigh* this is the same as 3-bit except the 2 LSBs are16:13
lkcl-            # passed through16:13
lkclthat's what freaked me out and caused me to think you'd removed 5-bit mode support for BA/BB/BC/BT16:13
lkclif you can instead move the extra-creation to a function, and call that function with a comment preamble16:14
lkcl"5-bit CR encoding for BA BB BT etc. is basically identical to 3-bit16:14
lkclexcept the bottom 2 LSBs are passed through unaltered16:15
lkclbecause those refer to the CR Field (EQ,LT,GT,SO)16:15
lkcltherefore we use the exact same function for creating EXTRA2/3 for CRs16:16
lkcl(that last sentence was the important one but the rest of the comments is context for it)16:16
ghostmansd[m]Why and how the code is destroyed?16:24
ghostmansd[m]It is literally the same but w/o copy&paste16:24
ghostmansd[m]These are _all_ differences between CR3 and CR516:24
ghostmansd[m]If you think that copy&paste adds any clarity here — I don't agree. Quite the opposite, it hides the fact that the whole difference is that you shift two bits, dot.16:26
ghostmansd[m]And, therefore, the two bits are handled specifically for the 5-bit form. However, except for these two bits, the rest is totally the same.16:27
ghostmansd[m]Write it with couple of functions or with a pair of if statements, it does _not_ change the fact these are identical.16:28
ghostmansd[m]Except for the two bits mentioned above.16:28
ghostmansd[m]Ok, so it was an obvious copy&paste, and now you made it worse by hiding this copy&paste between comments here and there.16:52
lkcli know: i worked that out retrospectively17:36
lkcllet me sort it out17:36
lkclchanges to this stuff freaks me out (even when i do it)17:37
lkclapologies, i only saw a set of "-"s in the patch, and from the comments being removed as well thought you were removing 5-bit CR encoding entirely17:41
ghostmansd[m]That's why I posted diff17:45
ghostmansd[m]I literally took the code, and compared it17:46
ghostmansd[m]Because I've been writing the same stuff in binutils, and it became obvious that the whole thing is mostly the same17:46
lkclyes, sorry.17:49
lkcldone now.17:49
ghostmansd[m]So the patch _is_ correct, and also is much more readable than what was there before. Not even comments deleted. Perhaps I could add a few, but it'd only explain the code, and the code was self-speaking. I don't really think "let's shift by two for CR 5-bit" is clearer than "if rtype == "CR5": x << 2". :-)17:50
lkcli added a link to the spec17:50
lkcland a preamble on the function, and on its usage17:50
ghostmansd[m]Yeah that's what I said: you can decorate it with funcs or comments, sure. But it is the same. :-)17:51
ghostmansd[m]Ok, star17:51
ghostmansd[m]Much more readable and now with comments, thanks!17:52
ghostmansd[m]I'm going to steal the comment into binutils :-)17:52
ghostmansd[m]I think I'll have to re-word it a bit. Binutils does things differently and doesn't use register names.17:53
ghostmansd[m]I mean, I check for a specific set of operands flags instead.17:53
lkclyeah i hadn't read the binutils source code in detail before starting so there may be different conventions17:54
ghostmansd[m]Well, that's rather implementation detail.17:55
ghostmansdAlmost there...
ghostmansdThat's diff of two objdumps after both binutils and produce the code here:
ghostmansdIt seems only `svmagic` magic is not complete yet18:42
ghostmansdOk not that magic anymore, seems just like one of extra fields is not set, more debugging is needed...19:06
ghostmansdAaaaah right, that mapping where I must convert the register into its EXTRA. OK, yeah, I forgot about it when I got stunned by CRs.19:11
ghostmansdOK, I guess it'll be my next target tomorrow. Anyway, we're really close.19:12

Generated by 2.17.1 by Marius Gedminas - find it at!