This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Feature request: Set the direction flag on x86/x64 register->register operations


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]