Re: PATCH: Properly handle x86 crc32 in Intel mode

["H. J. Lu" <hjl at lucon dot org>]

On Wed, May 02, 2007 at 02:10:57PM +0100, Jan Beulich wrote:
> >>> "H. J. Lu" <hjl@lucon.org> 02.05.07 14:56 >>>
> >On Wed, May 02, 2007 at 10:12:23AM +0100, Jan Beulich wrote:
> >> >>> "H. J. Lu" <hjl@lucon.org> 30.04.07 19:40 >>>
> >> >This patch fixes crc32 in Intel mode. I will check it in if there
> >> >are no objections in a day or 2.
> >> 
> >> I completely disagree here. No suffixes should be used in Intel mode unless
> >> there's no other way to distinguish multiple possible operand sizes. Hence the
> >> crc32-intel test is entirely wrong. The second operand's size of crc32 should
> >> be deduced from register size or memory operand size specifier, and if there's
> >> a memory operand without specifier it should be warned about just like in all
> >> other ambiguous cases.
> >
> >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.

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

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


H.J.