MASM Bug, or is this right?

[Randall Hyde]

As some of you may be aware, I've been working on a test program for HLA recently. To that end, I've been preparing HLA source files and equivalent MASM source files, compiling them, and comparing the object code results.  I've come across an interesting difference. Consider the MASM code:

pushw ax
pushw bx
pushw cx
  .
  .
  .
pushw di ;All eight 16-bit registers.

If you disassemble this code, MASM has failed to put the 0x66 size prefix in front of these instructions. IOW, they disassemble as

push eax
push ebx
  .
  .
  .
push edi

Given that pushw with other arguments emits the 0x66 prefix, as I would expect, I suspect this is a defect.
The MASM version under test is v6.14 (i.e., the same one that ships with MASM32).

I wonder if someone out there could try this with MASM 7.x? (I don't have a clue where my copy went).
Cheers,
Randy Hyde
P.S. just use dumpbin /disasm to check out the object file MASM creates.

[GregL]

Randall,

I got the same results with ML 6.15 and ML 7.10. I looked it up in the MASM Reference and it lists PUSHW reg16, PUSHW segreg and PUSHW immed as valid.

Here's the dissassembly:

    15:     pushw ax
00401000 50               push        eax 
    16:     pushw bx
00401001 53               push        ebx 
    17:     pushw cx
00401002 51               push        ecx 

[hutch--]

Randy,

It appears the mnemonic PUSHW is defective where PUSH is not. Here is a quick test piece done with ML 6.14.

Code Select Expand


    nop
    push ax
    nop
    pushw ax
    nop
    push di
    nop
    pushw di
    nop

GENERATES

0040100C 90                     nop
0040100D 6650                   push    ax
0040100F 90                     nop
00401010 50                     push    eax
00401011 90                     nop
00401012 6657                   push    di
00401014 90                     nop
00401015 57                     push    edi
00401016 90                     nop


[zcoder]

Is the PUSHW affected by the model?

Zcoder....

[Wistrik]

What I can recall, and I'm a bit rusty, is that MASM determines when/how to use prefixes based on your target environment as specified by the source code (processor, memory model, etc.), not the environment you're assembling in.