Re: [PATCH-for-6.1?] target/mips: Remove MOVZ/MOVN opcodes from Loongson 2E

On Mon, 2 Aug 2021, Philippe Mathieu-Daudé wrote: > > At least this trivial program: > > > > int main(void) > > { > > asm volatile(".set push; .set mips4; movn $0,$0,$0; .set pop"); > > return 0; > > } > > > > does not trap on actual hardware. > > Thank you very much for your time and

Re: [PATCH-for-6.1?] target/mips: Remove MOVZ/MOVN opcodes from Loongson 2E

On Mon, 2 Aug 2021, Philippe Mathieu-Daudé wrote: > > Per the "Godson-2E User Manual v0.6", the Loongson 2E processor > > does not implement the MOVZ/MOVN instructions > > I'm confused because I can't find MOVZ/MOVN in the 2E manual and > the 2F explicits the difference. However looking at

Re: [RFC PATCH 32/42] docker: Add gentoo-mipsr5900el-cross image

On Wed, 17 Mar 2021, Philippe Mathieu-Daudé wrote: > Maciej, I tried your suggestion as follow: > > $ mipsel-linux-gnu-gcc --version > mipsel-linux-gnu-gcc (Debian 8.3.0-2) 8.3.0 > Copyright (C) 2018 Free Software Foundation, Inc. > This is free software; see the source for copying conditions.

Re: [RFC PATCH 32/42] docker: Add gentoo-mipsr5900el-cross image

On Fri, 12 Mar 2021, Philippe Mathieu-Daudé wrote: > > but your two options to > > choose from are: > > > > 1. Build for the soft-float ABI (`-msoft-float') where any FP calculations > >are compiled such as to be made by the CPU using integer arithmetic. > > With the Debian toolchain I

Re: [RFC PATCH 32/42] docker: Add gentoo-mipsr5900el-cross image

On Fri, 12 Mar 2021, Philippe Mathieu-Daudé wrote: > >>> Is there any way we can do this with a distro that isn't Gentoo > >>> so that we can get a container build that is fast enough to be > >>> useful for CI ? > > Using the Debian cross image I get: > >

Re: [RFC PATCH 28/42] target/mips/tx79: Move RDHWR usermode kludge to trans_SQ()

On Tue, 16 Feb 2021, Fredrik Noring wrote: > > Not that it's odd (the final address is masked, remember), but that it a > > store > > to an address in the zero page. > > The address always resolves to 0xe83b (then masked) in 32-bit KSEG2, > because rt is always $3 and rd is always $29 so

Re: [RFC PATCH 41/42] tests/acceptance: Test R5900 CPU with BusyBox from Sony PS2

On Mon, 15 Feb 2021, Fredrik Noring wrote: > For n32, there's a provisional patch that needs reworking to get merged > (to have libc emulate DMULT etc. rather than the kernel/QEMU).[1] FWIW I think standard `-march=mips3' n32 Linux binaries need to work with the R5900, and therefore the kernel

Re: [PATCH-for-5.2?] target/mips/translate: Check R6 reserved encoding for Load Linked Word

On Tue, 8 Dec 2020, Philippe Mathieu-Daudé wrote: > Duh I hit that again, read the patch again, looks correct. I guess > I got confused myself reviewing the offending patch... > So I'm applying this patch to mips-next queue, using > Fixes: d9224450208 ("target-mips: Tighten ISA level checks")

Re: [PATCH 3/4] default-configs: Support o32 ABI with 64-bit MIPS CPUs

On Thu, 19 Nov 2020, Philippe Mathieu-Daudé wrote: > MIPS o32 ABI on 64-bit CPUs looks like a ILP32-on-64bit data > model, allowing 64-bit arithmetic and data movement instructions. > > This is the default ABI used by the "Sony Linux Toolkit for > Playstation 2". Please don't, not at least

Re: [Qemu-devel] [RFC PATCH 0/2] docker: Add gentoo-mipsr5900el-cross image

On Mon, 19 Nov 2018, Fredrik Noring wrote: > > The first patch adds a cross toolchain for the R5900 MIPS. > > It is working correctly but the patches provided by Fredrik in [1] don't > > have proper S-o-b, thus it is tagged RFC. > > Fredrik: any update on the status of those patches upstream? >

Re: [Qemu-devel] [PATCH 0/2] linux-user/mips: Support the n32 ABI for the R5900

On Fri, 9 Nov 2018, Maciej W. Rozycki wrote: > > Some readelf results: > > > > mips64el/stretch > > > > Magic: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 > > Class: ELF64 > > Flags: 0x8007, noreorder, pic, cpic, mips64r2 > &g

Re: [Qemu-devel] [PATCH v2 4/6] target/mips: Fix decoding mechanism of special R5900 opcodes

On Fri, 9 Nov 2018, Aleksandar Markovic wrote: > > > I think that the best solution that you exclude DDIV, DDIVU, DMULT, DMULTU > > > in a separate patch - there is no document to support their inclusion. > > > > As Maciej noted, the 64-bit MIPS Linux psABI is indivisible, so how could > > your

Re: [Qemu-devel] [PATCH 0/2] linux-user/mips: Support the n32 ABI for the R5900

On Fri, 9 Nov 2018, Laurent Vivier wrote: > > I believe MIPS64 Debian is all n32. > > Some readelf results: > > mips64el/stretch > > Magic: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 > Class: ELF64 > Flags: 0x8007, noreorder, pic, cpic, mips64r2 Hmm, that's weird --

Re: [Qemu-devel] [PATCH 0/2] linux-user/mips: Support the n32 ABI for the R5900

On Fri, 9 Nov 2018, Laurent Vivier wrote: > if you have time, o32 & n32 support needs to be reworked. > > We have two binaries qemu-mips and qemu-mipsn32 sharing the same ELF > mask/magic. > > As n32 identifies a kernel ABI version, we should have only one binary > for qemu-mips and

Re: [Qemu-devel] [PATCH v2 4/6] target/mips: Fix decoding mechanism of special R5900 opcodes

On Fri, 9 Nov 2018, Aleksandar Markovic wrote: > > ... and DMULT, DMULTU, DDIV and DDIVU > > are part of the MIPS III ISA. They are emulated in user mode to support > > generic MIPS III programs. > > Pure MIPS III executables should not be a concern of the R5900 > emulation, but R5900

Re: [Qemu-devel] [PATCH v2 4/6] target/mips: Fix decoding mechanism of special R5900 opcodes

On Thu, 8 Nov 2018, Fredrik Noring wrote: > > Fredrik, do you know by any chance if a document exists that would justify > > inclusion of non-R5900 DMULT, DMULTU, DDIV, DDIVU in R5900 executables by > > gcc for R5900? Is it included by cross-gcc or by native gcc, or by both? > > > > I think gcc

Re: [Qemu-devel] [PATCH 1/2] target/mips: Fix decoding mechanism of R5900 MFLO1, MFHI1, MTLO1 and MTHI1

On Mon, 5 Nov 2018, Fredrik Noring wrote: > where ac can range from 0 to 3. Do you have a link to a better reference, > by chance, that isn't tied to microMIPS? Here: you'll find everything you need I believe. HTH, Maciej

Re: [Qemu-devel] [PATCH 1/2] target/mips: Fix decoding mechanism of R5900 MFLO1, MFHI1, MTLO1 and MTHI1

On Sun, 4 Nov 2018, Fredrik Noring wrote: > It appears the correct function is tcg_gen_mov_tl because the TX79 manual > says > > MFHI: GPR[rd]63..0 <- HI63..0 > MFLO: GPR[rd]63..0 <- LO63..0 > MTHI: HI63..0 <- GPR[rs]63..0 > MTLO: LO63..0 <- GPR[rs]63..0 >

Re: [Qemu-devel] [PATCH] target/mips: Support Toshiba specific three-operand MADD and MADDU

On Mon, 29 Oct 2018, Aleksandar Markovic wrote: > > > Without TARGET_MIPS64, we can't say we emulate R5900 - we are emulating > > > some other CPU that never existed. > > > > > > Convince me that I am wrong. > > > > R5900 O32 is usable. > > Absolutely not. This kind of emulation infidelity

Re: [Qemu-devel] [PATCH] target/mips: Support Toshiba specific three-operand MADD and MADDU

On Sun, 28 Oct 2018, Aleksandar Markovic wrote: > I truly need your help here. As you can conclude from the discussion, > R5900 folks (anybody correct me if I am wrong) have some problems using > any ABI other than O32. The maximum the R5900 can support is the n32 ABI, owing to 32-bit virtual

Re: [Qemu-devel] [PATCH v8 00/38] target/mips: Limited support for the R5900

On Fri, 26 Oct 2018, Richard Henderson wrote: > > Overall this source file is clearly a modified copy of an ancient version > > of the opcode table included with the opcodes library from binutils and I > > think it would benefit from a refresh. > > You can't do that because of GPL v3, sadly.

Re: [Qemu-devel] [PATCH v8 00/38] target/mips: Limited support for the R5900

Hi Fredrik, > > NB all but pipeline 1 instructions of these are also implemented by other > > members of the TXx9 family. They seem to be referred to as just "multiply > > and multiply-add instructions" in the TX79 manual (cf Section B.3.1). > > Would > > ASE_TOSHIBA_MMI -- TX79 128-bit

Re: [Qemu-devel] [PATCH v8 00/38] target/mips: Limited support for the R5900

Hi Fredrik, > > > Option 3: Extend the mips_opcode::membership field. > > > > It's trivial to extend the field to uint64_t. > > Is the membership field intended to be used? The opcodes for CLZ and CLO > clash with the R5900 opcodes for MADD1 and MADDU1, resulting in incorrect > disassembly of

Re: [Qemu-devel] [PATCH v8 00/38] target/mips: Limited support for the R5900

Hi Fredrik, > > target/mips/translate.c:4888:38: error: passing argument 3 of > > ‘tcg_gen_add2_i32’ from incompatible pointer type > > [-Werror=incompatible-pointer-types] > > tcg_gen_add2_i32(t2, t3, cpu_LO[acc], cpu_HI[acc], t2, t3); > >

Re: [Qemu-devel] [PATCH v8 00/38] target/mips: Limited support for the R5900

On Mon, 22 Oct 2018, Maciej W. Rozycki wrote: > Hi Maciej, What an odd copy & paste thinko! I can't believe I addressed myself in the opening of my e-mail. :) Maciej

Re: [Qemu-devel] [PATCH v8 00/38] target/mips: Limited support for the R5900

Hi Maciej, > > I added ASE_MMI flag along with INSN_R5900, I think this fits better in > > the overall MIPS for QEMU design. > > Maciej -- can we add "MMI" under "ASEs implemented" in the kernel too, > even if it is a vendor-specific architecture extension that normally > isn't counted as an

Re: [Qemu-devel] [PATCH v5 6/8] target/mips: Define the R5900 CPU

Hi Fredrik, > > The C790 is a follow-up to the R5900. The R5900 has an FPU that is not > > compliant to the IEEE 754 standard for floating-point arithmetic. It > > doesn't implement exceptions, infinities, NaNs or denormals. It doesn't > > implement the the double format either, but that

Re: [Qemu-devel] [PATCH] target/mips: Support Toshiba specific three-operand MADD and MADDU

On Tue, 16 Oct 2018, Fredrik Noring wrote: > > I would not implement r5900 for mips32 in that case, > > I would implement it only for TARGET_MIPS64. > > R5900 Linux implements the O32 ABI, which is why 32-bit QEMU user-mode is > very useful. Perhaps a better alternative is to define the MMI

Re: [Qemu-devel] [PATCH] target/mips: Support Toshiba specific three-operand MADD and MADDU

On Tue, 16 Oct 2018, Fredrik Noring wrote: > One option is to create a new array such as > > static TCGv_i64 mmi_gpr[32]; > > that represents the upper 64 bits of each GPR. Then cpu_gpr must be of > a 64-bit type too, even when QEMU runs in 32-bit user mode. The R5900 > does not implement

Re: [Qemu-devel] [PATCH] target/mips: Support Toshiba specific three-operand MADD and MADDU

On Sun, 14 Oct 2018, Philippe Mathieu-Daudé wrote: > > > +gen_move_low32(cpu_LO[acc], t2); > > > +gen_move_high32(cpu_HI[acc], t2); > > > +if (rd) { > > > +gen_move_low32(cpu_gpr[rd], t2); > > > > As above, are LO, HI and GPR[rd] sign-extended

Re: [Qemu-devel] [PATCH v6 2/7] target/mips: Support R5900 specific three-operand MULT and MULTU

On Sun, 30 Sep 2018, Philippe Mathieu-Daudé wrote: > > TX79 do not implement DMULT or DMULTU, the Tx49 does and they do support > > the extra `rd' operand there[1]. Still no DMADD or DMADDU though. > > As does the TX39. Umm, the TX39 is 32-bit and does not have 64-bit instructions, so it

Re: [Qemu-devel] [PATCH v6 2/7] target/mips: Support R5900 specific three-operand MULT and MULTU

On Sun, 30 Sep 2018, Philippe Mathieu-Daudé wrote: > >> I'd use: > >> > >>MIPS_INVAL("mul/div Toshiba"); > > > > But just like `gen_mul_vr54xx' this function doesn't handle division! > > Per the commit message, I understood this function would eventually > handle "the R5900

Re: [Qemu-devel] [PATCH v6 2/7] target/mips: Support R5900 specific three-operand MULT and MULTU

On Sun, 30 Sep 2018, Philippe Mathieu-Daudé wrote: > > +MIPS_INVAL("mul R5900"); > > I'd use: > >MIPS_INVAL("mul/div Toshiba"); But just like `gen_mul_vr54xx' this function doesn't handle division! > > @@ -22378,6 +22449,8 @@ static void

Re: [Qemu-devel] [PATCH v5 2/8] target/mips: Support R5900 specific three-operand MULT and MULTU

On Fri, 28 Sep 2018, Philippe Mathieu-Daudé wrote: > > What's wrong with `gen_mul_r5900' anyway? > > I plan to use this function (adding MADD/MADDU) for R3900 based cores > (which don't seemt related to Emotion Engine). Fair enough. I reached for documentation and these instructions seem to

Re: [Qemu-devel] [PATCH v5 2/8] target/mips: Support R5900 specific three-operand MULT and MULTU

On Fri, 28 Sep 2018, Philippe Mathieu-Daudé wrote: > > > Note, these instructions are also valid on the R3900 (which also has > > > MADD/MADDU). > > > > > > Would gen_mul_toshiba() be a better common name? I don't like it but > > > can't think of another. > > > > I propose gen_mul_3op, since its

Re: [Qemu-devel] [PATCH v5 2/8] target/mips: Support R5900 specific three-operand MULT and MULTU

On Thu, 27 Sep 2018, Philippe Mathieu-Daudé wrote: > > +static void gen_mul_r5900(DisasContext *ctx, uint32_t opc, > > + int acc, int rd, int rs, int rt) > > Since we have acc = 0 we can directly use cpu_LO[0] and cpu_HI[0], > removing needs for an 'acc' argument.

Re: [Qemu-devel] [PATCH v5 6/8] target/mips: Define the R5900 CPU

On Tue, 25 Sep 2018, Philippe Mathieu-Daudé wrote: > >From the DS: > > The C790 core has the following features: > - Large on-chip caches > • Instruction cache: 32KB, 2-way set associative > • Data cache: 32KB, 2-way set-associative (with write-back

Re: [Qemu-devel] [PATCH v5 6/8] target/mips: Define the R5900 CPU

On Mon, 24 Sep 2018, Philippe Mathieu-Daudé wrote: > >> >From the DS: > >> > >> The C790 core has the following features: > >>- Large on-chip caches > >> • Instruction cache: 32KB, 2-way set associative > >> • Data cache: 32KB, 2-way set-associative (with write-back protocol) > >> >

Re: [Qemu-devel] [PATCH v5 0/8] target/mips: Support R5900 GCC programs in user mode

On Sun, 23 Sep 2018, Fredrik Noring wrote: > > Patch 4 will break bisect on clang builds. The reason for this is that > > clang treats unused functions as errors. Therefore, patch 4 must be merged > > with some of subsequent patches that contain first invocation of the > > function currently

Re: [Qemu-devel] [PATCH v5 6/8] target/mips: Define the R5900 CPU

Hi Philippe, > > diff --git a/target/mips/translate_init.inc.c > > b/target/mips/translate_init.inc.c > > index b3320b9dc7..71fd83de06 100644 > > --- a/target/mips/translate_init.inc.c > > +++ b/target/mips/translate_init.inc.c > > @@ -410,6 +410,53 @@ const mips_def_t mips_defs[] = > >

Re: [Qemu-devel] [PATCH v4 5/8] target/mips: R5900 DMULT[U], DDIV[U], LL, SC, LLD and SCD are user only

Hi Fredrik, > I agree, that is important too. I will post an updated v5 soon. Another > alternative change is to define check_insn_opc_user_only as > > static inline void check_insn_opc_user_only(DisasContext *ctx, int flags) > { > #ifndef CONFIG_USER_ONLY > check_insn_opc_removed(ctx,

Re: [Qemu-devel] [PATCH v4 5/8] target/mips: R5900 DMULT[U], DDIV[U], LL, SC, LLD and SCD are user only

Hi Fredrik, Nitpicking here, but I think it's what makes code clean and pleasant to read. On Sun, 16 Sep 2018, Fredrik Noring wrote: > diff --git a/target/mips/translate.c b/target/mips/translate.c > index 77d678353e..327e96307b 100644 > --- a/target/mips/translate.c > +++

Re: [Qemu-devel] [PATCH v3] target/mips: Support R5900 GCC programs in user mode

Hi Fredrik, > Many thanks for your review, Maciej, You are welcome! > > Eventually you'll have to remove all these instructions (plus LL and SC) > > from the system emulation mode. In fact I think it would make sense to do > > that right away, because I believe it will be a reasonably

Re: [Qemu-devel] [PATCH v2] target/mips: Initial support for MIPS R5900

Hi Fredrik, > Aleksandar, Aurelien, Maciej -- are you happy with this initial v2 patch? I have been more thorough on this occasion, and I do hope I have caught everything. See the notes below, in addition to what the others wrote. Please apply to v3 accordingly; I started writing this

Re: [Qemu-devel] [PATCH v2] target/mips: Initial support for MIPS R5900

Hi Fredrik, > Aleksandar, Aurelien, Maciej -- are you happy with this initial v2 patch? I have skimmed over and I have a couple of comments. I'll try to finalise them ASAP, however I'm currently at the GNU Tools Cauldron and much of my time is taken by the event. Maciej

Re: [Qemu-devel] [RFC] target/mips: Initial support for MIPS R5900

On Sat, 7 Jul 2018, Fredrik Noring wrote: > The MIPS R5900 is normally taken to be MIPS3, but it has MOVN, MOVZ and PREF > defined in MIPS4 which is why ISA_MIPS4 is chosen for this patch. It also has several instructions removed, so I don't think you can really just mark it MIPS IV without

Re: [Qemu-devel] [PATCH v6 8/9] target-mips: Add nan2008 flavor of <CEIL|CVT|FLOOR|ROUND|TRUNC>.<L|W>.<S|D>

On Mon, 20 Jun 2016, Aleksandar Markovic wrote: > This patch is about NaN-2008 flavor of Mips instructions CEIL, CVT, > FLOOR, ROUND, TRUNC only (its title is "Add nan2008 flavor..."). > > Legacy-NaN flavors of the same Mips instructions already operate > correctly, and there is nothing to be

Re: [Qemu-devel] [PATCH v6 8/9] target-mips: Add nan2008 flavor of <CEIL|CVT|FLOOR|ROUND|TRUNC>.<L|W>.<S|D>

On Tue, 14 Jun 2016, Leon Alrae wrote: > > 1. A bug fix for SoftFloat legacy-NaN (original) MIPS support, which has > >been there probably since forever (i.e. since the MIPS target was added > >to QEMU). > > I've just done another round of review and as far as I can tell these >

Re: [Qemu-devel] [PATCH v6 8/9] target-mips: Add nan2008 flavor of <CEIL|CVT|FLOOR|ROUND|TRUNC>.<L|W>.<S|D>

On Fri, 10 Jun 2016, Aleksandar Markovic wrote: > The changes that make QEMU behavior the same as hardware behavior (in > relation to CEIL, CVT, FLOOR, ROUND, TRUNC Mips instructions) are > already contained in this patch. Good, however that means that you've really combined two logically

Re: [Qemu-devel] [PATCH v6 8/9] target-mips: Add nan2008 flavor of <CEIL|CVT|FLOOR|ROUND|TRUNC>.<L|W>.<S|D>

On Fri, 10 Jun 2016, Aleksandar Markovic wrote: > I referred to SoftFloat library in QEMU code, and the case "Operand is > smaller than INT_MIN" is different between SoftFloat and Mips-B, while > the case "Operand is a NaN" is different between SoftFloat and Mips-A. Ah, but then you just can

Re: [Qemu-devel] [PATCH] configure: Use $(..) instead of deprecated `..`

On Wed, 8 Jun 2016, Eric Blake wrote: > > Unlike `..` the $(..) Bourne shell construct is not fully portable, some > > implementations do not recognise it. > > All POSIX implementations support it. The only shell that doesn't is > from Solaris /bin/sh, and that pre-dates modern OpenSolaris

Re: [Qemu-devel] [PATCH] configure: Use $(..) instead of deprecated `..`

On Wed, 8 Jun 2016, Stefan Weil wrote: > > Unlike `..` the $(..) Bourne shell construct is not fully portable, some > > implementations do not recognise it. Consequently this change potentially > > breaks building QEMU on some systems, possibly in a non-obvious way, as > > there's no

Re: [Qemu-devel] [PATCH] configure: Use $(..) instead of deprecated `..`

On Mon, 16 May 2016, Stefan Weil wrote: > This fixes these warnings from shellcheck: > > ^-- SC2006: Use $(..) instead of deprecated `..` > > Signed-off-by: Stefan Weil > --- > > More warnings from shellcheck for configure and other files > will be handled by later

Re: [Qemu-devel] [PATCH v6 8/9] target-mips: Add nan2008 flavor of <CEIL|CVT|FLOOR|ROUND|TRUNC>.<L|W>.<S|D>

On Mon, 16 May 2016, Aleksandar Markovic wrote: > Here one can distinguish three cases: > > CASE MIPS-A: (FCR31.NAN2008 == 1) > >1. Operand is a NaN, result should be 0; >2. Operand is larger than INT_MAX, result should be INT_MAX; >2. Operand is smaller than INT_MIN, result should

Re: [Qemu-devel] [PATCH v5 7/9] target-mips: Add nan2008 flavor of <CEIL|CVT|FLOOR|ROUND|TRUNC>.<L|W>.<S|D>

On Wed, 4 May 2016, Aleksandar Markovic wrote: > > > @@ -8919,7 +8920,11 @@ static void gen_farith (DisasContext *ctx, enum > > > fopcode op1, > > > TCGv_i64 fp64 = tcg_temp_new_i64(); > > > > > > gen_load_fpr32(ctx, fp32, fs); > > > -

Re: [Qemu-devel] [PATCH v5 5/9] target-mips: Activate IEEE 274-2008 signaling NaN bit meaning

On Mon, 25 Apr 2016, Aleksandar Markovic wrote: > No, nothing is lost. The plan is to add this functionality at a later time. OK then, as you prefer. Although I find the order somewhat odd as r5+ is a special case of r3. Maciej

Re: [Qemu-devel] [PATCH v5 5/9] target-mips: Activate IEEE 274-2008 signaling NaN bit meaning

On Mon, 18 Apr 2016, Aleksandar Markovic wrote: > Functions mips_cpu_reset() and msa_reset() are updated so that flag > snan_bit_is_one is properly set for any Mips FPU/MSA configuration. > For main FPUs, CPUs with FCR31's FCR31_NAN2008 bit set will invoke > set_snan_bit_is_one(0). For MSA, as it

Re: [Qemu-devel] [PATCH 0/2] target-mips: Initiate IEEE 754-2008 support for Mips

On Thu, 7 Apr 2016, Aleksandar Markovic wrote: > This patch series is based on the original set of patches proposed by Maciej > Rozycki: http://lists.nongnu.org/archive/html/qemu-devel/2014-12/msg00968.html Please try and spell out my name in full, thank you. Maciej

Re: [Qemu-devel] Memory mapping on MIPS

On Mon, 22 Feb 2016, Igor R wrote: > What should happen if I map KSEG2 directly as a continuation of KSEG1, > i.e. substitute TLB lookup with "address - (int32_t)KSEG1_BASE"? Guest > Linux seems to work correctly (but maybe it's just a matter of luck?). The 32-bit MIPS port of Linux uses KSEG2

Re: [Qemu-devel] [PATCH 14/15] tcg-mips: Use mipsr6 instructions in branches

On Tue, 9 Feb 2016, Richard Henderson wrote: > > So to be correct + efficient, it should only put the nop in if the next > > generated instruction is a CTI. I imagine that would be a bit messy / > > fragile, but maybe doable? I haven't looked too deeply. > > Ouch, I didn't notice this about

Re: [Qemu-devel] [PATCH] target-mips: silence NaNs for cvt.s.d and cvt.d.s

On Sun, 6 Dec 2015, Aurelien Jarno wrote: > cvt.s.d and cvt.d.s are FP operations and thus need to convert input > sNaN into corresponding qNaN. Explicitely use the floatXX_maybe_silence_nan > functions for that as the floatXX_to_floatXX functions do not do that. > > Cc: Leon Alrae

Re: [Qemu-devel] [PATCH v2] target-mips: remove wrong checks for recip.fmt and rsqrt.fmt

On Mon, 19 Oct 2015, Leon Alrae wrote: > >> Instructions recip.{s|d} and rsqrt.{s|d} do not require 64-bit FPU neither > >> they require any particular mode for its FPU. This patch removes the checks > >> that may break a program that uses these instructions. > > > > That is correct. That said

Re: [Qemu-devel] [PATCH pic32 v2 4/5] Two new processor variants: M4K and microAptivP.

On Wed, 1 Jul 2015, Aurelien Jarno wrote: diff --git a/target-mips/translate_init.c b/target-mips/translate_init.c index ddfaff8..430a547 100644 --- a/target-mips/translate_init.c +++ b/target-mips/translate_init.c @@ -232,6 +232,52 @@ static const mips_def_t mips_defs[] =

Re: [Qemu-devel] [PATCH pic32 v2 2/5] Fixed random index generation for TLBWR instruction. It was not quite random and did not skip Wired entries.

On Wed, 1 Jul 2015, Aurelien Jarno wrote: Secondly, I don't think calling random() is the correct thing to do. It's an expensive function that is not thread safe. Quoting the specification: Within the required constraints of the upper and lower bounds, the manner in which the processor

Re: [Qemu-devel] [PATCH] target-mips: add ERETNC instruction and Config5.LLB bit

On Fri, 5 Jun 2015, Leon Alrae wrote: As a side note, I have seen that you have added a check for MIPS2 to the ERET instruction. This is correct, but given in practice we don't emulate any MIPS1 CPU, I do wonder if it's not the time to make MIPS2 the basic instruction set and remove all

Re: [Qemu-devel] [PATCH v3 2/2] semihosting: add --semihosting-config arg sub-argument

On Thu, 21 May 2015, Liviu Ionescu wrote: p.s. and I think there are major differences between using -append to pass arguments to the kernel and passing arguments to semihosting, this being one of the reasons for suggesting a new command. Out of curiosity, why do you think there are

Re: [Qemu-devel] [PATCH v3 2/2] target-mips: Misaligned memory accesses for MSA

On Thu, 14 May 2015, Leon Alrae wrote: I don't think we have. The specification is a bit unclear I must admit and it also defines the details of vector load and store operations as implementation dependent, so there's no further clarification. This is specified in MIPS Architecture

Re: [Qemu-devel] [PATCH v3 2/2] target-mips: Misaligned memory accesses for MSA

On Wed, 13 May 2015, Leon Alrae wrote: Certainly we do. It's all in softmmu_template.h. I believe the problem is that MSA vector register's size is 16-bytes (this DATA_SIZE isn't supported in softmmu_template) and MSA load/store is supposed to be atomic. Not really AFAICT. Here's what

Re: [Qemu-devel] [PATCH v3 2/2] target-mips: Misaligned memory accesses for MSA

On Wed, 13 May 2015, Richard Henderson wrote: +static inline void ensure_atomic_msa_block_access(CPUMIPSState *env, + target_ulong addr, + int rw, +

Re: [Qemu-devel] [PATCH v3 2/2] target-mips: Misaligned memory accesses for MSA

On Wed, 13 May 2015, Richard Henderson wrote: I believe the problem is that MSA vector register's size is 16-bytes (this DATA_SIZE isn't supported in softmmu_template) and MSA load/store is supposed to be atomic. Not really AFAICT. Here's what the specification says[1]: The

Re: [Qemu-devel] [PATCH 2/3] ppc64-softmmu: Remove unsupported FDC from config

On Wed, 11 Mar 2015, Alexander Graf wrote: So if you know how to get working floppy disk with qemu-system-ppc64, that would help me a lot in rejecting requests from libvirt folks :) Thanks :) I don't think you want floppy disk emulation on -M pseries at all. In fact, you only ever want

Re: [Qemu-devel] mfocrf missing on e500v2

On Fri, 6 Mar 2015, Alexander Graf wrote: I've finally managed to check out why my e500v2 automated tests fail to run. Apparently they break because autotest wants to execute target code and runs into an illegal instruction while doing that: Program received signal SIGILL, Illegal

Re: [Qemu-devel] mfocrf missing on e500v2

On Fri, 6 Mar 2015, Alexander Graf wrote: And lo and behold, I really couldn't find any reference to mfocrf in the e500v2 spec. Do real e500 processors trap on this operation as well? The illegal instruction I posted about above was when running qemu *on* e500v2, because TCG emits

Re: [Qemu-devel] [PATCH 2/2] target-mips: add missing MSA and correct FP in VMState

On Thu, 19 Feb 2015, Leon Alrae wrote: Surely these fp_status fields are simply implementation of the architectural CSR registers? IMO you shouldn't store things related to TCG state, but always how the architecture represents it. That way you're free to change the TCG

Re: [Qemu-devel] [PATCH] target-mips: fix CP0.BadVAddr by stopping translation on Address error

On Thu, 19 Feb 2015, Leon Alrae wrote: I think this deserves a better description as it is about the specific case of an unaligned standard MIPS instruction fetch. Address Error exceptions can also happen for other reasons: unaligned data accesses or any accesses outside memory

Re: [Qemu-devel] [PATCH 7/7] target-mips: Add IEEE 754-2008 features support

On Tue, 9 Dec 2014, Maciej W. Rozycki wrote: Index: qemu-git-trunk/target-mips/op_helper.c === --- qemu-git-trunk.orig/target-mips/op_helper.c 2014-12-08 23:22:12.0 + +++ qemu-git-trunk/target-mips/op_helper.c

Re: [Qemu-devel] [PULL 06/37] target-ppc: VXSQRT Should Not Be Set for NaNs

On Wed, 7 Jan 2015, Alexander Graf wrote: diff --git a/target-ppc/fpu_helper.c b/target-ppc/fpu_helper.c index 7f74466..81db60f 100644 --- a/target-ppc/fpu_helper.c +++ b/target-ppc/fpu_helper.c @@ -920,14 +923,16 @@ uint64_t helper_fsqrt(CPUPPCState *env, uint64_t arg) farg.ll =

Re: [Qemu-devel] [PATCH v2 1/2] target-mips: Rework ABIs to allow all required configurations

On Mon, 9 Feb 2015, Peter Maydell wrote: I'm not sure if it's a good idea to change the meaning of linux-user qemu-mips64 and qemu-mips64el, this will cause unnecessary confusion in my opinion. I think we’d be better off leaving it consistent across QEMU versions. Well, this is an

Re: [Qemu-devel] [PATCH 7/7] target-mips: Add IEEE 754-2008 features support

On Tue, 10 Feb 2015, Leon Alrae wrote: These cases could be addressed by either replacing subtraction from 0.0 with multiplication by -1.0, or by tweaking the rounding mode as needed temporarily. Given that the computational cost of multiplication is uncertain and likely higher or at

Re: [Qemu-devel] [PATCH 7/7] target-mips: Add IEEE 754-2008 features support

On Mon, 9 Feb 2015, Leon Alrae wrote: +if (info-elf_flags EF_MIPS_NAN2008) +env-active_fpu.fcr31 |= +(1 FCR31_NAN2008) env-active_fpu.fcr31_rw_bitmask; +else +env-active_fpu.fcr31 = +~((1 FCR31_NAN2008)

Re: [Qemu-devel] [PATCH v2 1/2] target-mips: Rework ABIs to allow all required configurations

On Mon, 9 Feb 2015, Leon Alrae wrote: Rework the MIPS ABIs and CPU emulations available according to the following target list: - mips|mipsel -- 32-bit CPUs only, system and user emulation mode, o32 user ABI, - mips64|mips64el -- 32-bit and 64-bit

Re: [Qemu-devel] [PATCH 1/7] softfloat: Fix sNaN handling in FP conversion operations

On Fri, 6 Feb 2015, Maciej W. Rozycki wrote: I think this means that: (1) we want to put handling of silencing the signaling NaNs into the NaN conversion functions themselves (since it's too late to do it correctly once the commonNaNtoFloat16 function has thrown away data

Re: [Qemu-devel] [PATCH 1/7] softfloat: Fix sNaN handling in FP conversion operations

On Fri, 6 Feb 2015, Peter Maydell wrote: What I think would make sense here is instead of say `float32_to_float64' making a call to `float64_maybe_silence_nan' directly, we'd have a static inline function or a macro called say `float64_convert_silence_nan' invoked where the former is in

Re: [Qemu-devel] [PATCH 1/7] softfloat: Fix sNaN handling in FP conversion operations

encountered in floating-point format conversions, in the usual manner. References: [1] IEEE Standard for Floating-Point Arithmetic, IEEE Computer Society, IEEE Std 754-2008, 29 August 2008, pp. 21-22 [2] same, p. 37 [3] same, p. 30 Signed-off-by: Maciej W. Rozycki ma

Re: [Qemu-devel] [PATCH v2 6/7] softfloat: Add SoftFloat status `nan2008_mode' flag

On Thu, 5 Feb 2015, Peter Maydell wrote: Index: qemu-git-trunk/fpu/softfloat-specialize.h === --- qemu-git-trunk.orig/fpu/softfloat-specialize.h 2014-12-11 22:42:41.128934304 + +++

Re: [Qemu-devel] [PATCH 0/7] MIPS: IEEE 754-2008 features support

On Tue, 3 Feb 2015, Thomas Schwinge wrote: I think Thomas, being the writer of the majority of code comprising these patches Too bad that Git doesn't allow for listing several authors. ;-) I believe `Signed-off-by' serves this purpose: The Signed-off-by: tag indicates that the signer

Re: [Qemu-devel] [PATCH v2 3/7] softfloat: Convert `*_default_nan' variables into inline functions

On Sat, 31 Jan 2015, Peter Maydell wrote: Hmm, so perhaps my idea for a later improvement: Eventually we might want to move the new inline functions into a separate header to be included from softfloat.h instead of softfloat.c, but let's make changes one step at a time.

Re: [Qemu-devel] [PATCH v2 3/7] softfloat: Convert `*_default_nan' variables into inline functions

On Fri, 30 Jan 2015, Peter Maydell wrote: Hmm, so perhaps my idea for a later improvement: Eventually we might want to move the new inline functions into a separate header to be included from softfloat.h instead of softfloat.c, but let's make changes one step at a time. will

Re: [Qemu-devel] [PATCH v2 3/7] softfloat: Convert `*_default_nan' variables into inline functions

On Fri, 30 Jan 2015, Leon Alrae wrote: @@ -760,6 +760,6 @@ static inline int float128_is_any_nan(fl /* | The pattern for a default generated quadruple-precision NaN.

Re: [Qemu-devel] [PATCH] target-mips: use CP0EnLo_XI instead of magic number

On Thu, 29 Jan 2015, Leon Alrae wrote: And do we want to have CP0C3_LPA set in the few templates that do in the first place? AFAICT we don't really implement LPA so this bit will confuse software. Of course implementing it would be another option, not very complicated AFAICS, and if

Re: [Qemu-devel] [PATCH] target-mips: use CP0EnLo_XI instead of magic number

On Mon, 26 Jan 2015, Leon Alrae wrote: Signed-off-by: Leon Alrae leon.al...@imgtec.com --- Enthusiastically: Reviewed-by: Maciej W. Rozycki ma...@linux-mips.org However... diff --git a/target-mips/translate.c b/target-mips/translate.c index 635192c..77d89be 100644 --- a/target-mips

Re: [Qemu-devel] Qemu with GDB - Query

On Sat, 24 Jan 2015, manish tiwari wrote: I am new to QEMU and trying to attach gdb with qemu on powepc host. I have tried below options qemu-system-ppc -enable-kvm -nographic -m 512 -M ppce500 -cpu e500mc -gdb tcp::1234 -s -S -kernel uImage -initrd rootfs.ext2.gz -append root=/dev/ram

Re: [Qemu-devel] [PATCH] target-mips: ll and lld cause AdEL exception for unaligned address

On Mon, 26 Jan 2015, Leon Alrae wrote: Signed-off-by: Leon Alrae leon.al...@imgtec.com --- Reviewed-by: Maciej W. Rozycki ma...@linux-mips.org Maciej

Re: [Qemu-devel] [PATCH] target-mips: fix CP0.BadVAddr by stopping translation on Address error

On Mon, 26 Jan 2015, Leon Alrae wrote: BadVAddr is supposed to capture the most recent address that caused the exception. Currently this is not happening as translation is not stopped and BadVAddr is updated with subsequent addresses. Signed-off-by: Leon Alrae leon.al...@imgtec.com --- I

Re: [Qemu-devel] [PATCH] target-mips: fix detection of the end of the page during translation

--- I'm not sure if you need this, but just in case it helps anyhow. Reviewed-by: Maciej W. Rozycki ma...@linux-mips.org diff --git a/target-mips/translate.c b/target-mips/translate.c index e9d86b2..f33c10c 100644 --- a/target-mips/translate.c +++ b/target-mips/translate.c @@ -19103,6

Re: [Qemu-devel] [PATCH] target-mips: Clean up switch fall through after commit fecd264

On Tue, 20 Jan 2015, Peter Maydell wrote: In this particular case, this part of the file is fine and the problem is simply that this patch as it stands introduces a single line (the one above) that's not indented correctly. The only fix required is to delete one space in the line added by the

Re: [Qemu-devel] [PATCH] target-mips: Clean up switch fall through after commit fecd264

On Tue, 20 Jan 2015, Markus Armbruster wrote: diff --git a/target-mips/translate.c b/target-mips/translate.c index e9d86b2..8abc12b 100644 --- a/target-mips/translate.c +++ b/target-mips/translate.c @@ -18729,6 +18729,7 @@ static void decode_opc(CPUMIPSState *env, DisasContext *ctx)

Re: [Qemu-devel] [PATCH 2/2] m48t59: add mem_base value to m48t59_init_isa()

On Mon, 19 Jan 2015, Paolo Bonzini wrote: The reason I asked is simply because ISA devices never do MMIO (apart for the VGA window). You mean in the QEMU world? At least physical SCSI and Ethernet adapters had a MMIO space for the onboard ROM. Uh right, ROMs count as MMIO too.

Re: [Qemu-devel] [PATCH] target-mips: add CPU definition for MIPS-II

On Tue, 25 Nov 2014, Vasileios Kalintiris wrote: Add mips2-generic among CPU definitions for MIPS. Signed-off-by: Vasileios Kalintiris vasileios.kalinti...@imgtec.com --- target-mips/translate_init.c | 23 +++ 1 file changed, 23 insertions(+) diff --git

[Qemu-devel] [PATCH] target-mips: Make CP0.Status.CU1 read-only for the 5Kc and 5KEc processors

Signed-off-by: Maciej W. Rozycki ma...@codesourcery.com --- Hi, As we discussed previously, please apply. [This got stuck in postponed e-mail, I thought I had sent it already.] Maciej qemu-mips-5kc-cu1.diff Index: qemu-git-trunk/target-mips/translate_init.c

  1   2   3   >