Message ID | 20240302051601.53649-1-richard.henderson@linaro.org |
---|---|
Headers | show |
Series | target/sparc: Implement VIS4 | expand |
On 02/03/2024 05:15, Richard Henderson wrote: > I whipped this up over the Christmas break, but I'm just now > getting around to posting. I have not attempted to model the > newer cpus that have these features, but it is possible to > enable the features manually via -cpu properties. > > Possibly the first 6 or 7 patches should be taken sooner than > later because they fix bugs in existing VIS[12] code. > > I remove cpu_fpr[], so that we can use gvec on the same memory. > > r~ Nice! Since all of my SPARC bits and pieces are done with QEMU sun4m/sun4u, I don't really have much in the way that can test the newer VIS instructions. Do you have any particular suite that you've been using for testing, or future plans for particular CPUs? Generally I'm okay for this to be merged if there is a way for the new VIS instructions to be easily tested, given that they're not currently enabled by default. > Richard Henderson (41): > linux-user/sparc: Add more hwcap bits for sparc64 > target/sparc: Fix FEXPAND > target/sparc: Fix FMUL8x16 > target/sparc: Fix FMUL8x16A{U,L} > target/sparc: Fix FMULD8*X16 > target/sparc: Fix FPMERGE > target/sparc: Split out do_ms16b > target/sparc: Perform DFPREG/QFPREG in decodetree > target/sparc: Remove gen_dest_fpr_D > target/sparc: Remove cpu_fpr[] > target/sparc: Use gvec for VIS1 parallel add/sub > target/sparc: Implement FMAf extension > target/sparc: Add feature bits for VIS 3 > target/sparc: Implement ADDXC, ADDXCcc > target/sparc: Implement CMASK instructions > target/sparc: Implement FCHKSM16 > target/sparc: Implement FHADD, FHSUB, FNHADD, FNADD > target/sparc: Implement FNMUL > target/sparc: Implement FLCMP > target/sparc: Implement FMEAN16 > target/sparc: Implement FPADD64 FPSUB64 > target/sparc: Implement FPADDS, FPSUBS > target/sparc: Implement FPCMPEQ8, FPCMPNE8, FPCMPULE8, FPCMPUGT8 > target/sparc: Implement FSLL, FSRL, FSRA, FSLAS > target/sparc: Implement LDXEFSR > target/sparc: Implement LZCNT > target/sparc: Implement MOVsTOw, MOVdTOx, MOVwTOs, MOVxTOd > target/sparc: Implement PDISTN > target/sparc: Implement UMULXHI > target/sparc: Implement XMULX > target/sparc: Enable VIS3 feature bit > target/sparc: Implement IMA extension > target/sparc: Add feature bit for VIS4 > target/sparc: Implement FALIGNDATAi > target/sparc: Implement 8-bit FPADD, FPADDS, and FPADDUS > target/sparc: Implement VIS4 comparisons > target/sparc: Implement FPMIN, FPMAX > target/sparc: Implement SUBXC, SUBXCcc > target/sparc: Implement MWAIT > target/sparc: Implement monitor asis > target/sparc: Enable VIS4 feature bit > > target/sparc/asi.h | 4 + > target/sparc/helper.h | 36 +- > linux-user/elfload.c | 51 +- > target/sparc/cpu.c | 12 + > target/sparc/fop_helper.c | 104 ++++ > target/sparc/ldst_helper.c | 4 + > target/sparc/translate.c | 960 +++++++++++++++++++++++++++++---- > target/sparc/vis_helper.c | 526 +++++++++++------- > target/sparc/cpu-feature.h.inc | 4 + > target/sparc/insns.decode | 338 +++++++++--- > 10 files changed, 1626 insertions(+), 413 deletions(-) ATB, Mark.
On 02/03/2024 05:15, Richard Henderson wrote: > I whipped this up over the Christmas break, but I'm just now > getting around to posting. I have not attempted to model the > newer cpus that have these features, but it is possible to > enable the features manually via -cpu properties. > > Possibly the first 6 or 7 patches should be taken sooner than > later because they fix bugs in existing VIS[12] code. > > I remove cpu_fpr[], so that we can use gvec on the same memory. > > > r~ > > > Richard Henderson (41): > linux-user/sparc: Add more hwcap bits for sparc64 > target/sparc: Fix FEXPAND > target/sparc: Fix FMUL8x16 > target/sparc: Fix FMUL8x16A{U,L} > target/sparc: Fix FMULD8*X16 > target/sparc: Fix FPMERGE > target/sparc: Split out do_ms16b > target/sparc: Perform DFPREG/QFPREG in decodetree > target/sparc: Remove gen_dest_fpr_D > target/sparc: Remove cpu_fpr[] > target/sparc: Use gvec for VIS1 parallel add/sub > target/sparc: Implement FMAf extension > target/sparc: Add feature bits for VIS 3 > target/sparc: Implement ADDXC, ADDXCcc > target/sparc: Implement CMASK instructions > target/sparc: Implement FCHKSM16 > target/sparc: Implement FHADD, FHSUB, FNHADD, FNADD > target/sparc: Implement FNMUL > target/sparc: Implement FLCMP > target/sparc: Implement FMEAN16 > target/sparc: Implement FPADD64 FPSUB64 > target/sparc: Implement FPADDS, FPSUBS > target/sparc: Implement FPCMPEQ8, FPCMPNE8, FPCMPULE8, FPCMPUGT8 > target/sparc: Implement FSLL, FSRL, FSRA, FSLAS > target/sparc: Implement LDXEFSR > target/sparc: Implement LZCNT > target/sparc: Implement MOVsTOw, MOVdTOx, MOVwTOs, MOVxTOd > target/sparc: Implement PDISTN > target/sparc: Implement UMULXHI > target/sparc: Implement XMULX > target/sparc: Enable VIS3 feature bit > target/sparc: Implement IMA extension > target/sparc: Add feature bit for VIS4 > target/sparc: Implement FALIGNDATAi > target/sparc: Implement 8-bit FPADD, FPADDS, and FPADDUS > target/sparc: Implement VIS4 comparisons > target/sparc: Implement FPMIN, FPMAX > target/sparc: Implement SUBXC, SUBXCcc > target/sparc: Implement MWAIT > target/sparc: Implement monitor asis > target/sparc: Enable VIS4 feature bit > > target/sparc/asi.h | 4 + > target/sparc/helper.h | 36 +- > linux-user/elfload.c | 51 +- > target/sparc/cpu.c | 12 + > target/sparc/fop_helper.c | 104 ++++ > target/sparc/ldst_helper.c | 4 + > target/sparc/translate.c | 960 +++++++++++++++++++++++++++++---- > target/sparc/vis_helper.c | 526 +++++++++++------- > target/sparc/cpu-feature.h.inc | 4 + > target/sparc/insns.decode | 338 +++++++++--- > 10 files changed, 1626 insertions(+), 413 deletions(-) I've applied the first 6 patches to my qemu-sparc branch, since I believe these are the up-to-date version of the patches posted for https://gitlab.com/qemu-project/qemu/-/issues/1901. No objections here about the remainder of the series, other than that I don't have an easy/obvious way to test the new instructions... ATB, Mark.
On 4/29/24 13:52, Mark Cave-Ayland wrote: > No objections here about the remainder of the series, other than that I don't have an > easy/obvious way to test the new instructions... I was thinking about adding support to RISU, but the gcc compile farm sparc machines have been down for ages, so no way to generate the reference traces. r~
On 29/04/2024 22:02, Richard Henderson wrote: > On 4/29/24 13:52, Mark Cave-Ayland wrote: >> No objections here about the remainder of the series, other than that I don't have >> an easy/obvious way to test the new instructions... > > I was thinking about adding support to RISU, but the gcc compile farm sparc machines > have been down for ages, so no way to generate the reference traces. Ah that's frustrating. I've just pinged the debian-sparc folk to see if anyone there can offer any insight or an alternative. ATB, Mark.
On 4/29/24 23:02, Richard Henderson wrote: > On 4/29/24 13:52, Mark Cave-Ayland wrote: >> No objections here about the remainder of the series, other than that I don't have an >> easy/obvious way to test the new instructions... > > I was thinking about adding support to RISU, but the gcc compile farm sparc machines have > been down for ages, so no way to generate the reference traces. Update: I have successfully ported RISU to Sparc64, Solaris and Linux. There is a limitation in that I cannot find how to extract %gsr from the signal frame, which is unfortunate, but I can work around that for now. I have added descriptions of VIS1 instructions to RISU, and it turns out we have failures relative to a Sparc M8. I have not yet analyzed these failures, but it proves the effort was not wasted. :-) I'll clean up these patches and post them here when I next get some downtime. r~
On 15/05/2024 16:30, Richard Henderson wrote: > On 4/29/24 23:02, Richard Henderson wrote: >> On 4/29/24 13:52, Mark Cave-Ayland wrote: >>> No objections here about the remainder of the series, other than that I don't have >>> an easy/obvious way to test the new instructions... >> >> I was thinking about adding support to RISU, but the gcc compile farm sparc >> machines have been down for ages, so no way to generate the reference traces. > > Update: I have successfully ported RISU to Sparc64, Solaris and Linux. There is a > limitation in that I cannot find how to extract %gsr from the signal frame, which is > unfortunate, but I can work around that for now. > > I have added descriptions of VIS1 instructions to RISU, and it turns out we have > failures relative to a Sparc M8. I have not yet analyzed these failures, but it > proves the effort was not wasted. :-) > > I'll clean up these patches and post them here when I next get some downtime. > > r~ That's great news, thanks for the update. I've had confirmation that there is work underway to repair the SPARC hardware hosting Linux for the gcc buildfarm, so hopefully it will be back in service soon. ATB, Mark.