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: PATCH: Properly handle x86 crc32 in Intel mode


>> >crc32 is a very special instruction and doesn't follow the normal
>> >rule.
>> 
>> I don't think it's that special - it's very close to movzx/movsx. And hence it
>> should be implemented similarly.
>
>They are close, but different when treating data size prefix. Also
>I want to use the same opcode entries for both AT&T and Intel modes.

Sure, I can't see why this shouldn't be possible (though one of my long term
plans is to add functionality to allow a clean split between Intel and AT&T
syntax, so that in either mode insns/suffixes valid only in the other mode
cannot be used without at least a warning). And this I continue to believe
without suffix use in Intel mode.

And unfortunately once again I have to complain that you committed the
patch too quickly (despite saying you'd wait for a day or two you really
didn't seem to). As the Intel mode maintainer, I think I should be allowed
to request change like I did, but if you commit things before I even have a
chance to look at the patch, this is not really appropriate I'm afraid.

>I can change the disassembler not to generate the suffix for Intel
>syntax. Should -Msuffix generate the suffix for Intel syntax?

In my opinion it shouldn't, but this is inconsistent at present anyway I
believe; the meaning of -Msuffix in Intel mode should really be that
with/without it default sizing suffixes are/aren't displayed (and regardless
of it suffixes on unambiguous instructions are never used) and operand
sizes on memory operands are/aren't displayed (even) when unambiguous
through a register operand.

>> >> Also, while at this - could you have your doc people clarify the meaning of
>> >> an operand size prefix used with this instruction? Since all other 3-byte SSE4
>> >> insns use this prefix (I really wonder why), explicitly stating its meaning on
>> >> crc32 would disambiguate things.
>> >
>> >I don't believe the gas manual need to cover those kinds of things
>> >in ISA spec.
>> 
>> I thought you were still working for Intel - it's the IA-32 SDM-s that I asked
>> to get a respective clarification added.
>
>Oops. I have double checked this before. 0x66 is treated as data size
>prefix on source, not destination, which is the difference between
>crc32 and movsx/movzx.

And this is what I asked to be written in the SDM explicitly, in the hope that
you can get the responsible people to do so.

Jan


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