[comp.os.msdos.programmer] MASM generating extra nops in second pass

ted@polyof.poly.edu (Theodore S. Kapela, Staff) (11/29/90)

I am having a little problem with Microsoft Macro Assembler v4.00.
I have an instruction such as the following:

	mov	dl,(80-lentr)/2

where lentr is a constant (eg: lentr equ 8).  

After the first pass, the assembler generates the hex bytes B2 xx,
(where xx is dependant on the value of lentr).  On the second pass, 
it generates the hex bytes B2 xx 90.  This causes a phase error.  I don't
need the extra nop instruction, nor do I want it.  I know MASM 4.00 
does this a lot.  I have found "fixes" for some of the instances.  It
seems that, in general, when MASM calculates an immediate value using
a constant in some sort of simple equation, it does this.

I was wondering if anyone knows of some way to keep MASM from inserting the
nop instruction.  I didn't put it in the assembler source, so I don't want
it in the resulting executable.  Note that I don't want the solution
of putting in another equ statement.  This works, but it is not
what I am looking for.

Thanx in Advantz

-- 
..............................................................................
    Theodore S. Kapela                  (516) 755-4299 [Voice, Days]
    ted@polyof.poly.edu	                (516) 473-7746 [FAX]
           "Another brilliant mind corrupted by education"

shurr@cbnews.att.com (Larry A. Shurr) (12/01/90)

In article <1990Nov28.220900.5921@polyof.poly.edu>, ted@polyof.poly.edu (Theodore S. Kapela, Staff) writes:
} I am having a little problem with Microsoft Macro Assembler v4.00.
} I have an instruction such as the following:

} 	mov	dl,(80-lentr)/2

} where lentr is a constant (eg: lentr equ 8).  

} After the first pass, the assembler generates the hex bytes B2 xx,
} (where xx is dependant on the value of lentr).  On the second pass, 
} it generates the hex bytes B2 xx 90.  This causes a phase error.  I don't
} need the extra nop instruction, nor do I want it.  I know MASM 4.00...

This may not apply to your situation, but MASM is very ungraceful about
forward references (i.e., references to symbols defined later in the file).
'Course I can't tell if this is a forward reference to "lentr" and, to my
knowledge, the problem I'm referring to has only manifested itself in 
instances where an instruction maay have either an eight or sixteen bit 
operands.  Since your problem involves a "mov dl," instruction no such 
ambiguity should exist- though MASM may act as though the operand can be
8 or 16 bits and not look at the instruction until later, who knows?

You mentioned MASM 4.0.  Are you using 4.0 or a later version?  I have 5.1
which is less buggy and faster, though I know use TASM.

} I was wondering if anyone knows of some way to keep MASM from inserting the
} nop instruction.  I didn't put it in the assembler source, so I don't want
} it in the resulting executable.

I know that you should avoid forward references whenever possible, but, like
I said, I don't know if that applies to you.

Larry
-- 
Larry A. Shurr (cbnmva!las@att.ATT.COM or att!cbnmva!las)
The end of the world has been delayed due to a shortage of trumpet players.
(The above reflects my opinions, not those of AGS or AT&T, but you knew that.)

everett@hpcvra.cv.hp.com.CV.HP.COM (Everett Kaser) (12/04/90)

 shurr@cbnews.att.com (Larry A. Shurr) writes...
> ted@polyof.poly.edu (Theodore S. Kapela, Staff) writes:
>} I am having a little problem with Microsoft Macro Assembler v4.00.
>} 	mov	dl,(80-lentr)/2
>} where lentr is a constant (eg: lentr equ 8).  
>} After the first pass, the assembler generates the hex bytes B2 xx,
>} (where xx is dependant on the value of lentr).  On the second pass, 
>} it generates the hex bytes B2 xx 90.  This causes a phase error.  I don't

>This may not apply to your situation, but MASM is very ungraceful about
>forward references (i.e., references to symbols defined later in the file).
>'Course I can't tell if this is a forward reference to "lentr" and, to my
>knowledge, the problem I'm referring to has only manifested itself in 
>instances where an instruction maay have either an eight or sixteen bit 
>operands.  Since your problem involves a "mov dl," instruction no such 
>ambiguity should exist- though MASM may act as though the operand can be
>8 or 16 bits and not look at the instruction until later, who knows?
>   Larry A. Shurr (cbnmva!las@att.ATT.COM or att!cbnmva!las)

My hunch is that it IS a forward reference, and hence MASM doesn't know *WHAT*
kind of reference 'lentr' is, a constant, a memory reference, a structure
offset, etc.  If a constant of some sort, it would require one byte.  If a
memory reference (yeah, I know, you'd be crazy to use an address in an express-
ion like that, but MASM doesn't assume that you're crazy) it would require
two bytes (for the address).  Always put your equates at the beginning of the
file.

Everett Kaser                   Hewlett-Packard Company
...hplabs!hp-pcd!everett        work: (503) 750-3569   Corvallis, Oregon
everett%hpcvra@hplabs.hp.com    home: (503) 928-5259   Albany, Oregon