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

["Jan Beulich" <jbeulich at novell dot com>]

>>> "H.J. Lu" <hjl.tools@gmail.com> 29.11.08 16:40 >>>
On Tue, Nov 25, 2008 at 4:23 AM, Stefan DÃsinger <stefan@codeweavers.com> wrote:
>> Is this safe? So far I haven't run the gas testsuite yet

You'd have to prove it.

>> The code change seems ugly to me, I don't like the way the code changes the
>> indices. I am not familiar with the structures there, so I don't see any way
>> to make it look nicer

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).

>Many x86 instructions have more than one encodings. like size of displacement
>as well as direction bit. Some instructions don't have direction bit:
>
>movdqu, 2, 0xf30f6f, None, 2, CpuSSE2,
>Modrm|IgnoreSize|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, {
>Xmmword|Unspecified|BaseIndex|Disp8|Disp16|Disp32|Disp32S|RegXMM,
>RegXMM }
>movdqu, 2, 0xf30f7f, None, 2, CpuSSE2,
>Modrm|IgnoreSize|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, {
>RegXMM, Xmmword|Unspecified|BaseIndex|Disp8|Disp16|Disp32|Disp32S|RegXMM
>}

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).
But using the testsuite *and* adding new tests properly covering at least
all questionable cases would certainly show that.

>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).

>2. Add assembler switches if necessary.

There's no alternative to using a switch (as proposed) here.

In any case - in order for a change like this to be acceptable I think it would
need to be proven by the author that it in no way alters current behavior.

Jan