This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: Feature request: Set the direction flag on x86/x64 register->register operations
- From: "H.J. Lu" <hjl dot tools at gmail dot com>
- To: "Stefan Dösinger" <stefan at codeweavers dot com>
- Cc: "Jan Beulich" <jbeulich at novell dot com>, "Joey Ye" <joey dot ye at intel dot com>, "Weiliang Lin" <weiliang dot lin at intel dot com>, "Xuepeng Guo" <xuepeng dot guo at intel dot com>, binutils at sourceware dot org
- Date: Mon, 1 Dec 2008 13:42:41 -0800
- Subject: Re: Feature request: Set the direction flag on x86/x64 register->register operations
- References: <00b801c94ef8$abe5f480$03b1dd80$@com> <6dc9ffc80811290740p2098e230y7b4b05ad1b57e013@mail.gmail.com> <4933AD98.76E4.0078.0@novell.com> <006301c953fb$f2035090$d609f1b0$@com>
On Mon, Dec 1, 2008 at 1:29 PM, Stefan Dösinger <stefan@codeweavers.com> wrote:
> First of all, thanks for your replies.
>
>> >> Is this safe? So far I haven't run the gas testsuite yet
>>
>> You'd have to prove it.
> I ran the testsuite in the meantime and found a few bugs: I have an updated, but still imperfect patch attached(the modification of the tests and 16 bit movs).
>
>> First of all you'd need to complete what you started: Your patch
>> apparently
>> only cares about 32- and 64-bit register operands at present, but
>> should
>> in particular also deal with 16-bit ones (i.e. it should be generalized,
>> since
>> if the command line option you propose is passed, the user ought to be
>> allowed to expect that *all* code gets handled the alternative way).
> I have to double check what I actually want in that case, and see how msvc handles these cases, and then think how to keep the behavior consistent. (Microsoft software doesn't always show consistent behavior unfortunately)
>
>> Indeed, and it would seem to me the patch as is doesn't correctly deal
>> with
>> all cases (specifically, the early setting of found_reverse_match
>> doesn't
>> seem right if none of the opcodes matching the current insn have a D
>> bit).
> The testsuite agreed with you, and I've changed that.
>
>> But using the testsuite *and* adding new tests properly covering at
>> least
>> all questionable cases would certainly show that.
> The testsuite now seems to pass if I force the change on, of course if the opcodes that the patch intentionally changes are "fixed" in the testsuite. I'll add a new test instead of modifying the existing ones.
>
>> >As you stated here, one may want one particular encoding. I'd like to
>> see:
>> >
>> >1. Allow a suffix in mnemonic, like mov.dn, mov.db, mov.dd. mov.dw
>>
>> I don't think this would help the author, as it would then need a
>> compiler
>> change, too (whereas in the current shape I don't think such would be
>> needed).
> Correct
>
Your new patch still doesn't handle movdqu and other instructions,
like instructions with more than 1 source operands. I think you should
first implement a suffix, saying, n, to select the next match instead of
the first match. You can mark those instructions with a bit. A new
switch can make the next match the default.
--
H.J.