MASM: punpckldq mmreg, qword ptr [eax] now gives error - by Avery Lee

Status : 

  Won't Fix<br /><br />
		Due to several factors the product team decided to focus its efforts on other items.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.


1
0
Sign in
to vote
ID 294468 Comments
Status Closed Workarounds
Type Bug Repros 0
Opened 8/21/2007 6:19:09 PM
Access Restriction Public

Description

With MASM 9, using the MMX unpack instructions with a pointer argument explicitly marked with "qword ptr" now results in A2070: invalid instruction operands. This is an undocumented breaking change from MASM 8 (VS2005).

My understanding is that a lack of a pointer prefix means that the memory argument size is supposed to be implied from the register argument, which means that the meaning should be the same with and without qword ptr. This is why movd mm0, [eax] not assembling with MASM 8 was deemed By Design. This means that adding "qword ptr" here shouldn't make a difference, but it does.
Sign in to post a comment.
Posted by Microsoft on 10/16/2007 at 9:33 AM
We are resolving won't fix for this release, but considering for next
Posted by Bill [MSFT] on 8/22/2007 at 5:19 PM
Thanks for responding so soon. Yes, it looks like we have created an inconsistency with the earlier fix we made to PUNPCKLDQ.

Because it is an inconsistency in the expected usage but we correctly emit the opcode for the PUNPCKLDQ mm,m32 intruction, this bug won't meet the bar to make it into the current product cycle. But we will look at it right after version 9.

Thank you
Visual Studio Product Team
Posted by Avery Lee on 8/22/2007 at 2:36 PM
This change now means that MASM's memory operand size checking is inconsistent when the PTR operator is absent.

Chapter 3 of the MASM 6.1 Programmer's Guide (the latest full documentation for MASM I could find), states under Indirect Memory Operands, Specifying Operand Size: "You must give the size of an indirect memory operand in one of three ways: By the variable's declared size, With the PTR operator, Implied by the size of the other operand."

For PUNPCKLDQ mm0, [eax] to assemble given the new checking, MASM 9 must have inferred that [eax] has DWORD size, contrary to the last documented behavior. However, ADDSS has a similar definition (ADDSS xmm1, m32) and yet ADDSS xmm0, [eax] does not assemble. This is also true for MOVD, PMOVZXBW, and MOVSXD. MASM 8 broke code relative to MASM 7 when it began enforcing this, but its behavior was consistent with the existing documentation. This new behavior is not.
Posted by Bill [MSFT] on 8/22/2007 at 1:06 PM
Again, thank you for contacting us.

This is an expected behavior change for MASM version 9. Version 9 of the assembler enforces the size of the memory reference where version 8 would allow other sizes to be specified. This is a bug in version 8. As a check, the memory reference size of the resulting instruction encoding can be seen with a link -dump -disasm of the resulting obj created by a version 8 assembler. Here the disassembler correctly decodes this as a dword memory reference for all four cases in the supplied repro case.

Looking at the Intel documentation, the memory reference in question is a dword (doubleword or m32) reference. A snippet from Intel® 64 and IA-32 Architectures Software Developer's Manual Volume 2B: Instruction Set Reference, N-Z found on http://www.intel.com/products/processor/manuals/index.htm shows:

PUNPCKLDQ mm, mm/m32 -- Interleave low-order doublewords from mm and mm/m32 into mm.

Note that in this case, the memory reference size does not match the register size because this is an unpack instruction. In other words, two dwords, one of which can be memory, are unpacked in to a mm register.

I hope this information was useful to you.

Thank you
Visual Studio Product Team.
Posted by Microsoft on 8/21/2007 at 9:33 PM
Thanks for your feedback. We have reproduced this bug on Visual Studio 2008 Beta 2, and we are sending this bug to the appropriate group within the VisualStudio Product Team for triage and resolution.

Thank you,
Visual Studio Product Team.
Posted by Microsoft on 8/21/2007 at 6:59 PM
Thank you for your feedback. We are currently investigating. If this issue is urgent, please call support directly (see http://support.microsoft.com). Thank you, Visual Studio Product Team.