Message ID | 20200821205050.29066-1-jcmvbkbc@gmail.com |
---|---|
State | New |
Headers | show |
On 8/21/20 10:50 PM, Max Filippov wrote: > Hi Peter, > > please pull the following batch of updates for target/xtensa. > > Changes v1->v2: > - rebase on top of build system changes, resolve trivial conflicts > in the last two patches that add new files. > > The following changes since commit f86d9a093dada588889bde5582c7ec320487c4b8: > > Merge remote-tracking branch 'remotes/stefanha/tags/block-pull-request' into staging (2020-08-21 17:26:52 +0100) > > are available in the Git repository at: > > git://github.com/OSLL/qemu-xtensa.git tags/20200821-xtensa > > for you to fetch changes up to c621b4142bf1ff8c663811c10bd1628481e494a6: > > target/xtensa: import DSP3400 core (2020-08-21 12:56:45 -0700) > > ---------------------------------------------------------------- > target/xtensa updates for 5.2: > > - add NMI support; > - add DFPU option implementation; > - update FPU tests to support both FPU2000 and DFPU; > - add example cores with FPU2000 and DFPU. > > ---------------------------------------------------------------- > Max Filippov (24): > target/xtensa: make opcode properties more dynamic > target/xtensa: implement NMI support > softfloat: make NO_SIGNALING_NANS runtime property > softfloat: pass float_status pointer to pickNaN > softfloat: add xtensa specialization for pickNaNMulAdd > target/xtensa: add geometry to xtensa_get_regfile_by_name > target/xtensa: support copying registers up to 64 bits wide > target/xtensa: rename FPU2000 translators and helpers > target/xtensa: move FSR/FCR register accessors > target/xtensa: don't access BR regfile directly > target/xtensa: add DFPU option > target/xtensa: add DFPU registers and opcodes > target/xtensa: implement FPU division and square root > tests/tcg/xtensa: fix test execution on ISS > tests/tcg/xtensa: update test_fp0_arith for DFPU > tests/tcg/xtensa: expand madd tests > tests/tcg/xtensa: update test_fp0_conv for DFPU > tests/tcg/xtensa: update test_fp1 for DFPU > tests/tcg/xtensa: update test_lsc for DFPU > tests/tcg/xtensa: add fp0 div and sqrt tests > tests/tcg/xtensa: test double precision load/store > tests/tcg/xtensa: add DFP0 arithmetic tests > target/xtensa: import de233_fpu core > target/xtensa: import DSP3400 core > > fpu/softfloat-specialize.c.inc | 286 +- > fpu/softfloat.c | 2 +- > hw/xtensa/pic_cpu.c | 6 +- > include/fpu/softfloat-helpers.h | 10 + > include/fpu/softfloat-types.h | 8 +- > target/xtensa/core-de233_fpu.c | 58 + > target/xtensa/core-de233_fpu/core-isa.h | 727 + > target/xtensa/core-de233_fpu/core-matmap.h | 717 + > target/xtensa/core-de233_fpu/gdb-config.c.inc | 277 + > target/xtensa/core-de233_fpu/xtensa-modules.c.inc | 20758 +++ > target/xtensa/core-dsp3400.c | 58 + > target/xtensa/core-dsp3400/core-isa.h | 452 + > target/xtensa/core-dsp3400/core-matmap.h | 312 + > target/xtensa/core-dsp3400/gdb-config.c.inc | 400 + > target/xtensa/core-dsp3400/xtensa-modules.c.inc | 171906 +++++++++++++++++++ 3.12MiB of generated data... Where does that come from? Some submodule? Can't we regenerate? This seems very similar to what the decodetree.py script generates. I'm asking because IIRC we have been reluctant to accept the hexagon port due to its big generated imported data (beside the licensing issues). Thanks, Phil. > target/xtensa/cpu.c | 5 + > target/xtensa/cpu.h | 14 +- > target/xtensa/exc_helper.c | 23 +- > target/xtensa/fpu_helper.c | 342 +- > target/xtensa/helper.c | 4 +- > target/xtensa/helper.h | 58 +- > target/xtensa/meson.build | 2 + > target/xtensa/overlay_tool.h | 30 +- > target/xtensa/translate.c | 1979 +- > tests/tcg/xtensa/fpu.h | 142 + > tests/tcg/xtensa/macros.inc | 10 +- > tests/tcg/xtensa/test_dfp0_arith.S | 162 + > tests/tcg/xtensa/test_fp0_arith.S | 282 +- > tests/tcg/xtensa/test_fp0_conv.S | 299 +- > tests/tcg/xtensa/test_fp0_div.S | 82 + > tests/tcg/xtensa/test_fp0_sqrt.S | 76 + > tests/tcg/xtensa/test_fp1.S | 62 +- > tests/tcg/xtensa/test_lsc.S | 170 +- > 33 files changed, 198888 insertions(+), 831 deletions(-) > create mode 100644 target/xtensa/core-de233_fpu.c > create mode 100644 target/xtensa/core-de233_fpu/core-isa.h > create mode 100644 target/xtensa/core-de233_fpu/core-matmap.h > create mode 100644 target/xtensa/core-de233_fpu/gdb-config.c.inc > create mode 100644 target/xtensa/core-de233_fpu/xtensa-modules.c.inc > create mode 100644 target/xtensa/core-dsp3400.c > create mode 100644 target/xtensa/core-dsp3400/core-isa.h > create mode 100644 target/xtensa/core-dsp3400/core-matmap.h > create mode 100644 target/xtensa/core-dsp3400/gdb-config.c.inc > create mode 100644 target/xtensa/core-dsp3400/xtensa-modules.c.inc > create mode 100644 tests/tcg/xtensa/fpu.h > create mode 100644 tests/tcg/xtensa/test_dfp0_arith.S > create mode 100644 tests/tcg/xtensa/test_fp0_div.S > create mode 100644 tests/tcg/xtensa/test_fp0_sqrt.S >
On Sat, Aug 22, 2020 at 3:20 AM Philippe Mathieu-Daudé <f4bug@amsat.org> wrote: > On 8/21/20 10:50 PM, Max Filippov wrote: > > please pull the following batch of updates for target/xtensa. > > 3.12MiB of generated data... > > Where does that come from? Generated by xtensa processor generator, as one of many output artifacts. > Some submodule? Are you suggesting to move it to a submodule? It sure can be done. > Can't we regenerate? Not at the moment. And probably not retroactively for older configurations. > This seems very similar to what the decodetree.py script generates. Yes.
> -----Original Message----- > From: Philippe Mathieu-Daudé <philippe.mathieu.daude@gmail.com> On > Behalf Of Philippe Mathieu-Daudé > Sent: Saturday, August 22, 2020 4:21 AM > To: Max Filippov <jcmvbkbc@gmail.com>; qemu-devel@nongnu.org > Cc: Peter Maydell <peter.maydell@linaro.org>; Richard Henderson > <rth@twiddle.net>; Taylor Simpson <tsimpson@quicinc.com> > Subject: Re: [PULL v2 00/24] target/xtensa updates for 5.2 > > > I'm asking because IIRC we have been reluctant to accept the hexagon > port due to its big generated imported data (beside the licensing > issues). > I wasn't aware of any licensing issues with the Hexagon port. Could you elaborate? Thanks, Taylor
On Sat, 22 Aug 2020 at 20:48, Max Filippov <jcmvbkbc@gmail.com> wrote: > > On Sat, Aug 22, 2020 at 3:20 AM Philippe Mathieu-Daudé <f4bug@amsat.org> wrote: > > On 8/21/20 10:50 PM, Max Filippov wrote: > > > please pull the following batch of updates for target/xtensa. > > > > 3.12MiB of generated data... > > > > Where does that come from? > > Generated by xtensa processor generator, as one of many output artifacts. Is there anything different with the source for these cores compared to the ones we already have in the tree, or are these just "more cores, generated the same way as the old ones" ? thanks -- PMM
On Mon, Aug 24, 2020 at 2:33 PM Peter Maydell <peter.maydell@linaro.org> wrote: > On Sat, 22 Aug 2020 at 20:48, Max Filippov <jcmvbkbc@gmail.com> wrote: > > On Sat, Aug 22, 2020 at 3:20 AM Philippe Mathieu-Daudé <f4bug@amsat.org> wrote: > > > > > > Where does that come from? > > > > Generated by xtensa processor generator, as one of many output artifacts. > > Is there anything different with the source for these cores > compared to the ones we already have in the tree, or are > these just "more cores, generated the same way as the old ones" ? They are generated the same way as the old ones, but they have different configurations: they support FPU2000 and DFPU opcodes implemented earlier in this series. I've added them to enable testing of these opcodes. de233_fpu is supposed to be a platform for further xtensa gcc development.
On Mon, 24 Aug 2020 at 22:54, Max Filippov <jcmvbkbc@gmail.com> wrote: > > On Mon, Aug 24, 2020 at 2:33 PM Peter Maydell <peter.maydell@linaro.org> wrote: > > On Sat, 22 Aug 2020 at 20:48, Max Filippov <jcmvbkbc@gmail.com> wrote: > > > On Sat, Aug 22, 2020 at 3:20 AM Philippe Mathieu-Daudé <f4bug@amsat.org> wrote: > > > > > > > > Where does that come from? > > > > > > Generated by xtensa processor generator, as one of many output artifacts. > > > > Is there anything different with the source for these cores > > compared to the ones we already have in the tree, or are > > these just "more cores, generated the same way as the old ones" ? > > They are generated the same way as the old ones, but they have different > configurations: they support FPU2000 and DFPU opcodes implemented > earlier in this series. I've added them to enable testing of these opcodes. > de233_fpu is supposed to be a platform for further xtensa gcc development. OK, in that case I don't see any reason why we should keep them out of the tree. Which isn't to shut down the point Philippe has raised about generated sources, just that there's not much need to block this pullreq while we have that conversation since it's not a change from the status-quo. Applied, thanks. Please update the changelog at https://wiki.qemu.org/ChangeLog/5.2 for any user-visible changes. -- PMM