No-op sequences inserted by MASM for alignment

[MazeGen]

BTW ;)

From the Intel Optimization Reference manual P4 (248966-011)

The one byte NOP, xchg EAX,EAX, has special hardware support.
Although it still consumes a µop and its accompanying resources, the
dependence upon the old value of EAX is removed. Therefore, this µop
can be executed at the earliest possible opportunity, reducing the
number of outstanding instructions. This is the lowest cost NOP
possible.

[nasm64developer]

> The interesting one is "add eax, 0", of all
> the "NOP" instructions it's the only one which
> has an effect on the flags...

Actually, MASM's ALIGN directive is broken even
worse than that. For example, try this with good
old ml.exe version 6.15:

s segment para use16

mov ax,1

align 16
nop
align 1
hlt

align 16
nop
align 2
hlt

align 16
nop
align 4
hlt

align 16
nop
align 8
hlt

.386

mov eax,1

align 16
nop
align 1
hlt

align 16
nop
align 2
hlt

align 16
nop
align 4
hlt

align 16
nop
align 8
hlt

s ends

end

Before the .386 directive, MASM uses NOPs and
MOV AX,AX to pad, prefixed with CS: as needed.
Perfectly reasonable.

After the .386 directive, it silently decides
to emit 32-bit code, despite the fact that you
are still in a 16-bit segment. Execute any of
that code, and boom, you're dead.

The fact of the matter is that relying on the
ALIGN directive is not a good idea. Only the
programmer knows what padding bytes should be
emitted and why, period.

On top of that, MASM's ALIGN doesn't accept an
arbitrary alignment. By contrast, programmers
can easily write a macro that does.

[hutch--]

 :bg

It may hae something to do with the programmer knowing the use of alignment for the particular platform involved. Under 16 bit DOS, align by 2 bytes was the maximum required and was enabled with,

Code Select Expand


ALIGN EVEN


The basic distinction is if you are going to use a later version of ML that is a PE file (post 6.11d) align on the basis of the platform requirement. The only real problem for 32 bit code that I see is the 5 byte padding (add eax, 0) that sets a flag which could break some code if there was a flag test pending.

The following code demonstrates that alignment in 32 bit code is hardly a problem. It has been built with both ML 6.14 and 7.00.

Code Select Expand


; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««
    include \masm32\include\masm32rt.inc
; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««

comment * -----------------------------------------------------
                        Build this  template with
                       "CONSOLE ASSEMBLE AND LINK"
        ----------------------------------------------------- *

    main PROTO :DWORD,:DWORD,:DWORD

    .code

start:
   
; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««

    .data
      psrc db "This is a test of different alignments in MASM",0
      pdst db "                                                "
    .code

    invoke main,ADDR psrc,ADDR pdst,LENGTHOF psrc

    print ADDR pdst

    exit

; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««

main proc src:DWORD,dst:DWORD,cnt:DWORD

  align 1
    cld
  align 2
    mov esi, src
  align 4
    mov edi, dst
  align 8
    mov ecx, cnt
  align 16
    rep movsb
  align 8
    ret

main endp

; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««

end start


[nasm64developer]

> Under 16 bit DOS, align by 2 bytes was the maximum required

Are you confusing the 16-bit 8086/8088 with USE16?

While 16-bit DOS requires segments to be aligned
on 16-byte boundaries -- due to x86 real mode, of
course -- the contents of such segments may very
well desire/require alignments of 2, 4, 8, or 16.

For example, ALIGN EVEN won't do you any good if
you're trying to use 16-byte SSE data under DOS...

Nah... once you know that MASM's ALIGN is riddled
with problems, you just get over it and start to
use your own macro to do a better job.  ;-)

[hutch--]

 :bg

I guess with so many variations, x86 REAL mode using SSE under DOS you could end up with anything you like. Microsoft/IBM DOS was a 16 bit real mode non-reentrant monotasking OS that snreaked some access into extended memory for data apart from the A20 line just above 1 meg.

If you are crafting/running such a hybrid OS, I guess you could get the appropriate assembler from the vendor that would suit your requirements.  :green