Hi Matt,
[...]
| > Intel EM64 30083502.pdf (on page 82) says:
| >
| > 0f b7 ... MOVZX r32,r/m16 (same as AMD)
| > 48 0f b7 ... MOVZX r64,r/m32 (but isn't shown in the AMD manual)
|
| It isn't shown because it's wrong. Adding the REX.W prefix makes that "movzx
| r64, r/m16". The closest you can get to an official movzxd is 8B /rm with
| the ModR/M byte being >= 0xC0 (that is, 2 registers). AMD did not create a
| movzxd because it isn't needed. When 32-bit registers are the target of
| computation, the upper 32-bits is automatically zeroed.
|
| Refer to page 83 of volume 1, section 3.4.5.
|
| I have not tested any of this, but it doesn't make any sense at all to
| change the size of the second operand, and AMD's manual says nothing about
| it. I am more inclined to believe that Intel's manual is just plain buggy
| here.
|
| > My AMD-64 24594.pdf volume3 doesn't show this option,
| > but it got MOVSXD which can be modified to become MOVZXD by
| > deleting the REXW override.
|
| Not exactly. Without the REX.W prefix, movsxd becomes a mov with the same
| implicit zero-extension behavior. Without the REX.W prefix, it essentially
| becomes "movzxd". Check page 203 of volume 3, the entry for "movsxd". It
| explicitly states what I have said here.
| > So my disassembler will produce this syntax:
| > 48 0f b7(64,32) MOVZXD ... (MOVXZ 64,32 in Intel docs only)
I'll immediately correct this one and add one more entry to the
Intel-doc bugs list.
| > 63 r64/rm32 MOVZXD ... (syntax not mentioned in the AMD manuals)
| > 48 63 r64/rm32 MOVSXD ... (here AMD explains the behaviour w/o 48h)
| >
| > Intel says on the latter:
| > The use of MOVSXD without REX.W in 64-bit mode is discouraged,
| > Regular MOV should be used instead of using MOVSXD without REX.W.
| >
| > Perhaps a buggy Intel statement by not knowing the undefined ?
| > (when looking to Intel-manuals this sounds very familiar to me)
| They are right, but it is silly to call this opcode movzxd. Again, all
| instructions will implicitly zero-extend 32-bit results to 64-bits, so it's
| really pointless to have a movzxd instruction. That's why AMD didn't. There
| really isn't any difference between this hypothetical "movzxd" instruction
| and a regular "mov" instruction.
Oh Yes I forgot, this is one of the points why I don't like these 64's,
but to show this hidden behaviour I'll add some 'MOVZXD'-equivalent
mnemonics also for the 64' mov group for my current disassemblers
output options:
8b c1 RAX = Zq ECX Terse-styled
RQ0 = Zq RD1 KESYS hexwork
MOVZXD rax,ecx Intel/AMD explaining
MOV eax,ecx Intel/AMD (as is)
| > Can't tell if there is really a difference in the two CPUs
| > or if just the manuals interpret it apart.
| > .. and your compiler seems to be confused also :)
| >
| > I don't know about your tool, but I'd try "MOVZXD rbx,eax"
| > or try a 48h prefix on a MOVZX ebx,ax.
| > Just a thought from the distance...
|
| The latter would not be the same as the former. Adding REX.W would cause it
| to zero-extend ax -> rbx, not eax -> rbx.
Thanks for correction, now I know where confusion come from:
one more time from the good Intel books.
__
wolfgang