| ghostmansd | lkcl, 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 |
|---|---|---|
| ghostmansd | The code generation task: https://bugs.libre-soc.org/show_bug.cgi?id=833 | 09:38 |
| ghostmansd | I've initially assigned the parent as https://bugs.libre-soc.org/show_bug.cgi?id=550 (binutils), but perhaps https://bugs.libre-soc.org/show_bug.cgi?id=577 (gcc, binutils and assembly macros) is a better candidate. | 09:38 |
| ghostmansd | So, for now, I switched to 577. Please let me know your thoughts. | 09:39 |
| ghostmansd | Good news, with the patch I did for this pcrel adjustments, I'm able to proceed with adding operands. | 09:57 |
| ghostmansd | By the way, I must admit, the code author did everything to keep fields as re-usable as possible. | 09:57 |
| ghostmansd | https://git.libre-soc.org/?p=binutils-gdb.git;a=blob;f=opcodes/ppc-opc.c;h=4a94703d2d3a968aa96628a5a6ee9bb15a10a7a6;hb=refs/heads/svp64#l3972 | 09:59 |
| ghostmansd | Unless we resort to these tricks, we hit the assertion: https://git.libre-soc.org/?p=binutils-gdb.git;a=blob;f=gas/config/tc-ppc.c;h=4ca7f659110135bcfe1b10c3e8d59d51536fc285;hb=refs/heads/svp64#l1664. | 10:00 |
| ghostmansd | Of course, we could be "smart" and have some non-null callbacks... :-) | 10:00 |
| ghostmansd | You 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 |
| ghostmansd | FWIW, we now have svremap in binutils, hooray. | 10:03 |
| programmerjake | yay! | 10:04 |
| ghostmansd | I 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 |
| ghostmansd | lkcl programmerjake ^^^ | 10:50 |
| ghostmansd | Perhaps -mfuture is OK as compiler switch, still this will need a separate PPC_OPCODE_${OPCODE}. | 10:53 |
| ghostmansd | Also, perhaps I've already asked this, but, still: should we include Power10 or Power9? IIRC the answer was Power9. | 10:53 |
| programmerjake | yeah, fsins/fcoss/ternlogi/grev* are not technically part of svp64, so they'd be a separate flag, but included in -mlibresoc | 11:03 |
| programmerjake | currently 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 up | 12:45 | |
| lkcl | ok, 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 |
| lkcl | yehyeh willdo | 12:52 |
| lkcl | the idea is, you've already done the work, therefore to get paid the task needs to be declared 100% completed | 12:53 |
| lkcl | "future work" would therefore *need* to be a different bugreport... unless you want yet more delay because of lumping things together | 12:54 |
| lkcl | duplicate operand detection! nice! and also slightly annoying... oh hang on, yes, of course, you can just #define to something already declared | 12:55 |
| lkcl | 3972 #define SVme TO | 12:55 |
| lkcl | ahh, like that :) | 12:55 |
| lkcl | totally not commented and documented but neat | 12:56 |
| lkcl | yes fsins/fcoss/etc./etc. these are definitely to be considered 32-bit instructions | 12:56 |
| lkcl | but they are *DRAFT* 32-bit instructions | 12:57 |
| lkcl | i raised this with the OpenPOWER Foundation Board of Directors because i do not wish us to be responsible for creating another opcode-conflict nightmare | 12:58 |
| ghostmansd[m] | Yeah, perfectly reasonable | 12:58 |
| lkcl | i've been advocating for RISC-V to avoid this issue, and they have blatantly disregarded my advice | 12:58 |
| ghostmansd[m] | Let me call the table "draft", then? | 12:58 |
| lkcl | [and get everything they deserve as a result] | 12:58 |
| lkcl | however it would be... extremely hypocritical of me to then not advocate the same thing now that we are doing Power ISA | 12:59 |
| lkcl | even if it's an "inconvenience" for us | 12:59 |
| ghostmansd[m] | Well, for binutils this is a minor inconvenience, and adding these costs almost nothing... I hope Power Foundation accepts these | 13:00 |
| openpowerbot | [mattermost] <lkcl> it's the implications of being a high-profile prominent open source project | 13: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 is | 13: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 EXT022 | 13: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 opcode | 13:10 |
| openpowerbot | [mattermost] <lkcl> imagine we get the funding for the 8-core processor that can take on intel and amd for i7/i9 performance | 13:10 |
| openpowerbot | [mattermost] <lkcl> it becomes a mass-volume CPU utilised in Edge-Node compute, laptops, desktops and business towers across the world | 13:11 |
| openpowerbot | [mattermost] <lkcl> but | 13: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 EXT022 | 13:13 |
| openpowerbot | [mattermost] <lkcl> 2 years later another vendor comes along, with just the same high-profile CPU situation | 13:14 |
| openpowerbot | [mattermost] <lkcl> again using EXT022 | 13: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 optional | 13: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 way | 13:25 |
| openpowerbot | [mattermost] <lkcl> unnnnfortunately... | 13:25 |
| openpowerbot | [mattermost] <lkcl> "optional choosing not to bother" in this case opens up the nightmare-conflict scenario | 13: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 to | 13: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 it | 13:35 |
| ghostmansd[m] | For anyone running the code on PowerPC | 13:35 |
| ghostmansd[m] | Like with CPUID/MSR | 13:35 |
| lkcl | oh, 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 well | 14:08 |
| lkcl | yes i'd agree 883 is good | 14:46 |
| lkcl | that's a total pain. a workaround is an explicit table back in sv_analysis.py (sv_binutils.py?) which lists the redefinitions. | 14:47 |
| lkcl | cesar, first picture of the black hole at the centre of our universe! https://archive.ph/Rficz | 17:29 |
| cesar | Indeed. | 17:30 |
| cesar | Not the universe... The Milky Way. | 17:31 |
| programmerjake | saw that yesterday...neat! wasn't expecting the brighter areas on the top/bottom... | 17:34 |
| programmerjake | running cvc5 on fpmul_test.smt2 as well... | 23:43 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!