Friday, 2022-05-13

ghostmansdlkcl, I've raised the task on the code generation, but I'm not quite sure which task should be considered a parental one in terms of budget. It started as binutils task, but it'd be great if we could re-use the generator for other needs, e.g. clang, or other C stuff. I see no real obstacles there.\09:37
ghostmansdThe code generation task:
ghostmansdI've initially assigned the parent as (binutils), but perhaps (gcc, binutils and assembly macros) is a better candidate.09:38
ghostmansdSo, for now, I switched to 577. Please let me know your thoughts.09:39
ghostmansdGood news, with the patch I did for this pcrel adjustments, I'm able to proceed with adding operands.09:57
ghostmansdBy the way, I must admit, the code author did everything to keep fields as re-usable as possible.09:57
ghostmansdUnless we resort to these tricks, we hit the assertion:;a=blob;f=gas/config/tc-ppc.c;h=4ca7f659110135bcfe1b10c3e8d59d51536fc285;hb=refs/heads/svp64#l1664.10:00
ghostmansdOf course, we could be "smart" and have some non-null callbacks... :-)10:00
ghostmansdYou know, ideally, even this crap could be generated. We could parse the vanilla binutils table, collect all it has, then generate a new stuff. But this would take more time than simply proceeding on a step-by-step basis.10:03
ghostmansdFWIW, we now have svremap in binutils, hooray.10:03
ghostmansdI have an impression we should not consider fsins/fcoss/ternlogi/grev* as part of stuff added only with SVP64. Is it right that we'd better reserve a standalone table for these? Is it right we should reserve a standalone compiler switch for them, also active when -mlibresoc is present?10:47
ghostmansdlkcl programmerjake ^^^10:50
ghostmansdPerhaps -mfuture is OK as compiler switch, still this will need a separate PPC_OPCODE_${OPCODE}.10:53
ghostmansdAlso, perhaps I've already asked this, but, still: should we include Power10 or Power9? IIRC the answer was Power9.10:53
programmerjakeyeah, fsins/fcoss/ternlogi/grev* are not technically part of svp64, so they'd be a separate flag, but included in -mlibresoc11:03
programmerjakecurrently we're based on power9-level aka. isa v3.0c. once openpower has the licensing and other stuff done for v3.1, we may want to move to that, though that would require implementing the new scalar 64-bit instructions such as paddi. imho we should move to v3.1 eventually.11:06
ghostmansd[m]Thanks programmerjake!11:21
* lkcl catching up12:45
lkclok, so there's a binutils bugreport, therefore anything related to binutils (especially things already done for which we're doing sub-milestones) is a sub-bug of 550.12:47
ghostmansd[m]I've been thinking this might be more than binutils, but that's perhaps for the future deeds :-)12:50
ghostmansd[m]I'm on the phone, could you, please, also adjust the budget respectively?12:50
lkclyehyeh willdo12:52
lkclthe idea is, you've already done the work, therefore to get paid the task needs to be declared 100% completed12:53
lkcl"future work" would therefore *need* to be a different bugreport... unless you want yet more delay because of lumping things together12:54
lkclduplicate operand detection! nice! and also slightly annoying... oh hang on, yes, of course, you can just #define to something already declared12:55
lkcl3972 #define SVme TO12:55
lkclahh, like that :)12:55
lkcltotally not commented and documented but neat12:56
lkclyes fsins/fcoss/etc./etc. these are definitely to be considered 32-bit instructions12:56
lkclbut they are *DRAFT* 32-bit instructions12:57
lkcli raised this with the OpenPOWER Foundation Board of Directors because i do not wish us to be responsible for creating another opcode-conflict nightmare12:58
ghostmansd[m]Yeah, perfectly reasonable12:58
lkcli've been advocating for RISC-V to avoid this issue, and they have blatantly disregarded my advice12:58
ghostmansd[m]Let me call the table "draft", then?12:58
lkcl[and get everything they deserve as a result]12:58
lkclhowever it would be... extremely hypocritical of me to then not advocate the same thing now that we are doing Power ISA12:59
lkcleven if it's an "inconvenience" for us12:59
ghostmansd[m]Well, for binutils this is a minor inconvenience, and adding these costs almost nothing... I hope Power Foundation accepts these13:00
openpowerbot[mattermost] <lkcl> it's the implications of being a high-profile prominent open source project13:07
openpowerbot[mattermost] <lkcl> "oh, it went into binutils? oh, it must be official and approved by the OPF, then"13:07
openpowerbot[mattermost] <lkcl> they have enough communications / outreach / disconnect problems as it is13:08
openpowerbot[mattermost] <lkcl> plus, as i explained in the binutils-dev post, the grey area is this "high-profile mass-volume usage" of a Sandbox Opcode EXT02213:09
openpowerbot[mattermost] <lkcl> in my opinion neither the RISC-V Foundation nor OPF have properly thought through - and then defined - what happens when multiple *high-profile* products use the "custom" Sandbox EXT022 opcode13:10
openpowerbot[mattermost] <lkcl> imagine we get the funding for the 8-core processor that can take on intel and amd for i7/i9 performance13:10
openpowerbot[mattermost] <lkcl> it becomes a mass-volume CPU utilised in Edge-Node compute, laptops, desktops and business towers across the world13:11
openpowerbot[mattermost] <lkcl> but13:11
openpowerbot[mattermost] <lkcl> strictly speaking we have done nothing wrong. we complied with the spec.13:13
openpowerbot[mattermost] <lkcl> it has this tiny little niggle: it dominates the entirety of EXT022 "because the standard says using EXT022 is okay for custom opcode usage"13:13
openpowerbot[mattermost] <lkcl> hundreds of thousands of developers start using binutils and gcc with the support for EXT02213:13
openpowerbot[mattermost] <lkcl> 2 years later another vendor comes along, with just the same high-profile CPU situation13:14
openpowerbot[mattermost] <lkcl> again using EXT02213:14
openpowerbot[mattermost] <lkcl> they look at binutils and gcc and go, "oh s*** there's these people been already dominating EXT022 for 2 years, our processors are now totally incompatible"13:15
openpowerbot[mattermost] <lkcl> and it's game over.13:16
openpowerbot[mattermost] <lkcl> now, if we were doing a *proprietary* product, maintaining our own *private* hard-fork of binutils and gcc? absolutely no problem whatsoever.13:18
openpowerbot[mattermost] <lkcl> because *upstream* does not end up getting "poisoned / dominated"13:18
ghostmansd[m]Doesn't PowerPC has something like CPUID/MSR to determine how stuff works and turn it on/off?13:24
ghostmansd[m]I mean, such discrepancies are dictated by CPUIDs and MSRs in x86 world.13:24
openpowerbot[mattermost] <lkcl> PCR - Program Compatibility Register.13:24
openpowerbot[mattermost] <lkcl> it's optional13:24
openpowerbot[mattermost] <lkcl> and here's the thing: anything that's "optional" in a standard has to be done in a very specific controlled fashion that leaves no possibility for ambiguity or conflict should the "option" be exercised, either way13:25
openpowerbot[mattermost] <lkcl> unnnnfortunately...13:25
openpowerbot[mattermost] <lkcl> "optional choosing not to bother" in this case opens up the nightmare-conflict scenario13:26
openpowerbot[mattermost] <lkcl> and thus, by definition, makes the Power ISA "not a good specification"13:26
ghostmansd[m]How can the stuff which determines compatibility layer be optional?13:26
openpowerbot[mattermost] <lkcl> or, "a good one in all other respects but flawed in this regard"13:26
ghostmansd[m]This is a totally crappy idea.13:26
ghostmansd[m]Oh well, can I programmatically determine the absense of PCR?13:27
openpowerbot[mattermost] <lkcl> of course.  or, at least, you should be able to13:29
openpowerbot[mattermost] <lkcl> wait... you mean in binutils?  you can't do that: cross-compiling, remember?13:30
ghostmansd[m]No, I mean outside of it13:35
ghostmansd[m]For anyone running the code on PowerPC13:35
ghostmansd[m]Like with CPUID/MSR13:35
lkcloh, yes.13:36
ghostmansd[m]I've though, and I came to conclusion that I can already submit RFP for 883. I don't see stuff which must necessarily be done in scope of binutils so that we're able to proceed. One piece that I see is generating operands along with macros and stuff, but this is a big task, since this bit must likely also parse the C code from vanilla binutils.14:04
ghostmansd[m]Or, at least, consider stuff from vanilla binutils.14:05
ghostmansd[m]So, this is a big separate task.14:05
ghostmansd[m]Luke, what do you think?14:05
ghostmansd[m]As you see with stuff like #define SVme TO, this is a bit tricky for autogeneration, and needs to consider vanilla code as well14:08
lkclyes i'd agree 883 is good14:46
lkclthat's a total pain. a workaround is an explicit table back in ( which lists the redefinitions.14:47
lkclcesar, first picture of the black hole at the centre of our universe!
cesarNot the universe... The Milky Way.17:31
programmerjakesaw that yesterday...neat! wasn't expecting the brighter areas on the top/bottom...17:34
programmerjakerunning cvc5 on fpmul_test.smt2 as well...23:43

Generated by 2.17.1 by Marius Gedminas - find it at!