Hi Maciej,
> I'm not sure if every single random vendor-specific instruction (or a
> bunch of) deserves its own ASE designation, be it internal or externally
> exposed. I think the MMI set being a substantial architectural feature
> makes sense to be shown in /proc/cpuinfo (in Linux), but I d
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.
On 10/25/18 7:03 PM, Maciej W. Rozycki 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.
r~
Hi Maciej,
> > 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 MADD1 and MADDU1. For example:
> >
> > 0x70853020 madd1 a2,a0,a1 disassembles into clz a2 or a1,a0
> >
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 mul
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 MA
Hi Richard,
> > 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 MADD1 and MADDU1
On 10/23/18 9:37 PM, Fredrik Noring wrote:
> Hi Peter, Aleksandar,
>
>> Hi: I get compile errors on 32-bit hosts:
>>
>> /home/petmay01/qemu-for-merges/disas/mips.c:615:35: error: large
>> integer implicitly truncated to unsigned type [-Werror=overflow]
>> #define INSN_5900 0x1
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);
> > ^~
Hi Peter, Aleksandar,
> Hi: I get compile errors on 32-bit hosts:
>
> /home/petmay01/qemu-for-merges/disas/mips.c:615:35: error: large
> integer implicitly truncated to unsigned type [-Werror=overflow]
> #define INSN_5900 0x1
>^
> /home/
Hi Maciej,
> 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);
> ^~
Would you
Hi Maciej,
> I have no authority to approve such a change for the kernel, but it looks
> reasonable to me and I will support you with it, with one reservation
> however. As this is an ISA extension in the vendor-specific space, I
> think it belongs to a vendor-specific namespace, so as to mak
On Mon, Oct 22, 2018 at 3:34 PM Aleksandar Markovic
wrote:
> > From: Fredrik Noring
> > Subject: [PATCH v8 00/38] target/mips: Limited support for the R5900
> >
> I experienced some build errors (see the end of this mail), so I had to
> exclude some patches, but all others are fine, and had my "
On 22/10/18 20:40, Maciej W. Rozycki wrote:
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. :)
Haha when I saw your mail I thought "weird, there is another Maciej
involved in this M
Hi Aleksandar,
> Pull request with 32 patches from this series is already sent, and I would
> like to avoid sending v2 of that request. Let's wait for some time until
> the pull request is hopefully accepted. There will be most likely another
> one at the beginning of the next week.
>
> We are ap
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
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 ASE?
> From: Fredrik Noring
>
> Subject: Re: [PATCH v8 00/38] target/mips: Limited support for the R5900
>
> Many thanks, Aleksandar,
>
> > 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 implem
Many thanks, Aleksandar,
> 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 AS
> From: Fredrik Noring
> Subject: [PATCH v8 00/38] target/mips: Limited support for the R5900
>
Hi, Fredrik.
The series looks good.
I added ASE_MMI flag along with INSN_R5900, I think this fits better in the
overall MIPS for QEMU design.
I made a couple of other minor changes.
I experienced
The primary purpose of these changes is to support programs compiled
by GCC for the R5900 target and thereby run R5900 Linux distributions,
for example Gentoo.
GCC in version 7.3, by itself, by inspection of the GCC source code
and inspection of the generated machine code, for the R5900 target,
on
21 matches
Mail list logo
