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.
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
Randy,
It appears the mnemonic PUSHW is defective where PUSH is not. Here is a quick test piece done with ML 6.14.
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
Is the PUSHW affected by the model?
Zcoder....
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.