| lkcl | dang, programmerjake, all of those languages are trademarked! | 10:42 |
|---|---|---|
| lkcl | rust is trademarked. java is trademarked. javascript is trademarked. someone *attempted* to trademark webassembly (it was invalidated) | 10:42 |
| programmerjake | the latest rust trademark policy: https://foundation.rust-lang.org/policies/logo-policy-and-media-guide/ | 10:49 |
| programmerjake | since 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 docs | 10:51 |
| programmerjake | afaict | 10:51 |
| programmerjake | we 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 project | 10:52 |
| lkcl | SPIR-V: trademarked | 10:52 |
| lkcl | there's no need to ask them for what amounts to "fair use" | 10:52 |
| programmerjake | since i'm a member of the rust library portable-simd working group | 10:52 |
| lkcl | Trademark 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 permitted | 10:53 |
| programmerjake | asking them if you're worried is what i meant. imho asking isn't necessary in this case, bht it never hurts | 10:53 |
| lkcl | no i'm not worried, but the fact that *all* of these are Trademarked (except WebAssembly) has me on high alert | 10:54 |
| lkcl | meaning, we can't use them as "Heading descriptors" | 10:54 |
| lkcl | we'll have to come up with alternative names, such as "Modulo semantics" or "wrapping semantics" for javascript(tm) | 10:54 |
| lkcl | we're putting this to the OPF ISA WG. | 10:55 |
| lkcl | OPF and IBM's Lawyers *will* go on high alert at the mention of Trademarked property in the Power ISA Specification. | 10:55 |
| lkcl | and a section right at the front of the Power ISA Specification will have to be added: | 10:56 |
| lkcl | Rust is a Trademark of the Rust Foundation | 10:56 |
| lkcl | Java is a Trademark of Oracle | 10:56 |
| lkcl | Javascript is a Trademark of Oracle | 10:56 |
| lkcl | SPIR-V is a Trademark of the Khronos Group | 10:56 |
| lkcl | etc | 10:56 |
| lkcl | et | 10:56 |
| lkcl | cc | 10:56 |
| lkcl | etc | 10:56 |
| lkcl | etc | 10:56 |
| lkcl | frickin ell even LLVM is trademarked https://trademarks.justia.com/867/27/llvm-86727445.html | 10:57 |
| lkcl | dang | 10:58 |
| lkcl | https://github.com/KhronosGroup/SYCL-Docs/blob/SYCL-2020/master/COPYRIGHT.txt | 10:59 |
| openpowerbot | [slack] <github> signin | 10:59 |
| lkcl | toshywoshy, huh? :) ^ | 10:59 |
| programmerjake | i'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 work | 11:03 |
| programmerjake | also, the openpower spec already has bits in one of the registers named something like Java-mode | 11:04 |
| programmerjake | so 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 is | 11:06 |
| lkcl | to repeat: i don't want to put road blocks in the way that cost the OpenPOWER Foundation in Lawyers time | 11:12 |
| lkcl | all headings referring to Trademarks have to go, with headings that refer to the functinoality not a Trademark | 11:13 |
| lkcl | |rust semantics" | 11:13 |
| lkcl | out | 11:13 |
| lkcl | "javascript semantics" | 11:13 |
| lkcl | out | 11:13 |
| lkcl | "java semantics" | 11:13 |
| lkcl | out | 11:13 |
| * midgardian[m]1 is happy for chatlogs | 11:14 | |
| lkcl | OpenPOWER semantics can stay | 11:14 |
| lkcl | IEEE754 semantics can also likely stay although that'll also need checking | 11:14 |
| lkcl | IEEE754 doesn't appear but "IEEE standard" does | 11:15 |
| lkcl | p131 book I v3.1 section 4.1 | 11:16 |
| lkcl | (they define the term "IEEE Standard" to refer to IEEE 754-198somethign | 11:16 |
| lkcl | midgardian[m]1, yeah we couldn't run a project of this size/complexity without them | 11:17 |
| programmerjake | the bit i was referring to is the "Vector Non-Java Mode (NJ)" bit in VSCR | 11:30 |
| octavius | Recently got out my old monitor for the laptop...portrait orientation is amazing! | 13:14 |
| octavius | Actually seeing the whole webpage/irc log/pdf to scale | 13:15 |
| ghostmansd | svp64_rm.mask.eq(SelectableInt(pmask, SVP64RM_MASK_SIZE)) | 15:09 |
| ghostmansd | svp64_rm.subvl.eq(SelectableInt(subvl, SVP64RM_SUBVL_SIZE)) | 15:09 |
| ghostmansd | svp64_rm.ewsrc.eq(SelectableInt(srcwid, SVP64RM_EWSRC_SIZE)) | 15:09 |
| ghostmansd | svp64_rm.elwidth.eq(SelectableInt(destwid, SVP64RM_ELWIDTH_SIZE)) | 15:09 |
| ghostmansd | All this looks quite inconsistent. Why not call the local variables the same we call fields? | 15:10 |
| ghostmansd | I broke on mask != pmask, but the rest is even less consistent. | 15:10 |
| ghostmansd | lkcl, dropped a chunk of copy&paste code in svp64.py; basically there's way more, but this was a really obvious: handling of CR3/CR5 | 15:27 |
| ghostmansd | https://pastebin.com/5URTAMk3 | 15:27 |
| ghostmansd | also 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 |
| ghostmansd | good news: `sv.stw 5.v, 4(1.v)` gets converted to... | 15:29 |
| ghostmansd | 0000000000000000 <.text>: | 15:29 |
| ghostmansd | 0: 05 40 2d 00 svmagic 11520 | 15:29 |
| ghostmansd | 4: 90 20 00 04 stw r1,4(0) | 15:29 |
| ghostmansd | compare to `list ['.long 0x05402d00', 'stw 1, 4(0)']` | 15:30 |
| ghostmansd | I'm going to check more instructions, but hopefully soon the remapping will be completed | 15:30 |
| ghostmansd | once this is ready, I guess I'll raise a standalone task to make disassembly avoid "svmagic", that is, make it a real prefix | 15:31 |
| ghostmansd | this likely won't be easy, though, but have to check in details | 15:31 |
| lkcl | octavius, hoorah :) | 15:43 |
| lkcl | ghostmansd, because there are actually two widths and two masks in some cases | 15:45 |
| lkcl | or, there _were_ going to be *either* one *or* two elwidths, but the spec evolved so that there *are* exactly two elwidths | 15:46 |
| lkcl | [for instructions that have both src and destination registers, that is] | 15:46 |
| lkcl | [and where elwidths actually make sense] | 15:47 |
| lkcl | elwidth overrides do not make sense for CRs, for example | 15:47 |
| lkcl | how can you override a 4-bit CR Field to change its width?? | 15:47 |
| lkcl | 2 bit? | 15:47 |
| lkcl | 1 bit? | 15:47 |
| lkcl | 8 bit? | 15:47 |
| lkcl | all total bollocks. | 15:47 |
| lkcl | predication, you can have *TWO* predicates | 15:48 |
| lkcl | hence the names, "2P" - twin preciation | 15:48 |
| lkcl | "1P" - single predication | 15:48 |
| lkcl | for 1P (single predication), the mask applies to **BOTH** the source **AND** the destination register | 15:49 |
| lkcl | for 2P (twin predication) there is a *SEPARATE* predicate for source and a *SEPARATE* predicate mask for destination | 15:49 |
| lkcl | there is always one predicate, therefore svp64_rm has the name "mask" for this | 15:50 |
| lkcl | but | 15:51 |
| lkcl | when you do *not* have twin-predication, those bits get used for *other purposes* | 15:51 |
| lkcl | if 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 |
| lkcl | but they do not quotes match quotes because they are not available for all circumstances for all instructions | 15:52 |
| lkcl | no, really, please *do not* change the functionality of this code | 15:54 |
| lkcl | https://git.libre-soc.org/?p=openpower-isa.git;a=commitdiff;h=d56564910763a69f113615bedf94022da9457de5 | 15:54 |
| lkcl | you literally destroyed how SVP64 works on CR field numbering with that patch | 15:58 |
| lkcl | - sv_extra = 0b100 | (sv_extra >> 2) | 15:58 |
| lkcl | - sv_extra = sv_extra & 0b11 | 15:59 |
| lkcl | all of those are how the EXTRA2/3 works, and you removed absolutely every single one of them | 15:59 |
| lkcl | making svp64.py completely non-compliant with the specification | 16:00 |
| lkcl | the purpose of svp64.py is to be "obvious", provide comments, and be a strict and clear reference implementation | 16:01 |
| lkcl | speed and optimisation is not just rock-bottom of the list as a priority, it's a *negative* priority because it is a hindrance on clarity | 16:01 |
| lkcl | good call about the inaccurate comments | 16:05 |
| lkcl | + "vector CR %s cannot fit into EXTRA3 %s" % \ | 16:05 |
| lkcl | ok i've stopped freaking out and have understood what you were doing | 16:07 |
| lkcl | it would be better to have the CR Field decoded as a function | 16:07 |
| lkcl | which is called by both cases, with *clear* comments as to what is being called, with what, and why, in each case | 16:08 |
| lkcl | ok, so starting again: | 16:12 |
| lkcl | i don't mind code-reuse for the 5-bit and 3-bit CR cases as long as comments are not removed | 16:13 |
| lkcl | - # encode SV-CR 5-bit field into extra, v3.0field | 16:13 |
| lkcl | - # *sigh* this is the same as 3-bit except the 2 LSBs are | 16:13 |
| lkcl | - # passed through | 16:13 |
| lkcl | that's what freaked me out and caused me to think you'd removed 5-bit mode support for BA/BB/BC/BT | 16:13 |
| lkcl | if you can instead move the extra-creation to a function, and call that function with a comment preamble | 16:14 |
| lkcl | "5-bit CR encoding for BA BB BT etc. is basically identical to 3-bit | 16:14 |
| lkcl | except the bottom 2 LSBs are passed through unaltered | 16:15 |
| lkcl | because those refer to the CR Field (EQ,LT,GT,SO) | 16:15 |
| lkcl | therefore we use the exact same function for creating EXTRA2/3 for CRs | 16: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&paste | 16:24 |
| ghostmansd[m] | Again, https://pastebin.com/5URTAMk3 | 16:24 |
| ghostmansd[m] | These are _all_ differences between CR3 and CR5 | 16: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 |
| lkcl | i know: i worked that out retrospectively | 17:36 |
| lkcl | let me sort it out | 17:36 |
| lkcl | changes to this stuff freaks me out (even when i do it) | 17:37 |
| lkcl | apologies, 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 entirely | 17:41 |
| ghostmansd[m] | That's why I posted diff | 17:45 |
| ghostmansd[m] | I literally took the code, and compared it | 17:46 |
| ghostmansd[m] | Because I've been writing the same stuff in binutils, and it became obvious that the whole thing is mostly the same | 17:46 |
| lkcl | yes, sorry. | 17:49 |
| lkcl | done now. | 17:49 |
| lkcl | https://git.libre-soc.org/?p=openpower-isa.git;a=commitdiff;h=41e7be83b2ce2e91421d59f618b955db5eb824f9 | 17:50 |
| 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 |
| lkcl | i added a link to the spec | 17:50 |
| lkcl | and a preamble on the function, and on its usage | 17: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, star | 17: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 |
| lkcl | :) | 17:53 |
| lkcl | yeah i hadn't read the binutils source code in detail before starting svp64.py so there may be different conventions | 17:54 |
| ghostmansd[m] | Well, that's rather implementation detail. | 17:55 |
| ghostmansd | Almost there... https://pastebin.com/9B45Kt1g | 18:41 |
| ghostmansd | That's diff of two objdumps after both binutils and svp64.py produce the code here: https://pastebin.com/K0w9ySbC | 18:42 |
| ghostmansd | It seems only `svmagic` magic is not complete yet | 18:42 |
| ghostmansd | https://www.youtube.com/watch?v=e1UflvB91nQ | 18:43 |
| ghostmansd | Ok not that magic anymore, seems just like one of extra fields is not set, more debugging is needed... | 19:06 |
| ghostmansd | Aaaaah 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 |
| ghostmansd | OK, I guess it'll be my next target tomorrow. Anyway, we're really close. | 19:12 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!