This is the mail archive of the
mailing list for the binutils project.
Re: [PATCH] Support VU0 on MIPS R5900
- From: JÃrgen Urban <JuergenUrban at gmx dot de>
- To: Richard Sandiford <rdsandiford at googlemail dot com>
- Cc: "binutils at sourceware dot org" <binutils at sourceware dot org>
- Date: Sat, 3 Aug 2013 20:12:55 +0200
- Subject: Re: [PATCH] Support VU0 on MIPS R5900
- References: <20130108234130 dot 27410 at gmx dot net> <87a9rrso6l dot fsf at talisman dot default> <trinity-c3dc44a3-27c5-482b-b113-ca0cae29d590-1375046137093 at 3capp-gmx-bs55> <87mwp39mfo dot fsf at talisman dot default> <76A90B6E-700D-4EE8-9BD4-D7EAB1B0D7D6 at gmx dot de> <87ob9f6mc3 dot fsf at talisman dot default>
Am 03.08.2013 um 13:33 schrieb Richard Sandiford <email@example.com>:
> JÃrgen Urban <JuergenUrban@gmx.de> writes:
>> Am 31.07.2013 um 10:13 schrieb Richard Sandiford <firstname.lastname@example.org>:
>>> "JÃrgen Urban" <JuergenUrban@gmx.de> writes:
>>>> ragnarok2040 is busy and wasn't able to finish the work. So I took over
>>>> the work. The binutils changed in the meantime. So the old patch doesn't
>>>> apply and your questions are no longer applicable (the patch is
>>>> completely changed). I couldn't find a way to work the old stuff in,
>>>> because the new binutils are very different. So I decided to add it
>>>> without special support for suffixes. All suffixes are listed instead in
>>>> the mips opcode table, so the suffixes will work without special suffix
>>>> support. I think this was the intented way that binutils was designed
>>> Well, I'm not sure there's really a precedent either way. These VU0
>>> instructions are pretty idiosyncratic. Things like .ob vs. .qh for MDMX
>>> and .s/.d/.ps for FP are similar, but there are different requirements
>>> for when you can use those (no .qh for VR5400, no .ps until MIPS V, etc.)
>>> In this case the suffix is really just an operand that happens to be part
>>> of the mnemonic, so I preferred your original approach of dealing with the
>>> suffixes programmatically. Certainly....
>>>> The result is that the patch adds 1527 instructions.
>>> ...this seems far too many :-)
>>> The easiest way of dealing with it would be to have a pinfo/pinfo2 bit
>>> to say that the suffix is required. Unfortunately there are none left
>>> that we can use.
>>> I'm close to finishing a series of patches to further rework the opcode
>>> table and free up more bits. Those patches again interfere with yours,
>>> sorry. Rather than ask you to make another wholesale change, I've locally
>>> reworked your patch to apply on top of the other ones and to make it
>>> use the pinfo2 approach.
>> I would appreciate it. I am hoping that it gets finally in.
> Here's the patch I'd like to apply. Does it look OK to you?
The patch is OK and thanks for your work.