x86 assembly equ vs =

Question

I am taking a class in x86 assembly language and it's starting to move rather fast. There is one thing that the book keeps doing without mentioning how it works, and that is using the equ and = operators when defining data.

So it seems like equ is used to define constants, but is = the same thing? If I had some code:

.data
   count = 100            ; Is this a constant? Of what data type is this?
   array WORD count DUP(?)
   x_param EQU [EBP + 8]  ; Is this a constant?

I am asking because until now we have defined data by declaring it's type, but how does it work when there is no type declared (like count = 100)

I've been googling and searching forums about these operators for the past few days (Spring break), and I cannot come up with anything, so I figure I should ask myself.

EDIT I am using the x86 MASM assembler

Rox

You forgot to mention which assembler you use. Please add a tag too. Also, don't google or use forums, rather, look in the official manual for your assembler first. – Haploid

See the manual about EQU and =. TL;DR: EQU can define constant numeric or reassignable text, = does reassignable numeric. – Haploid

Alright, so then if I declared a = 1 or b equ 1, would they both be 32-bit data types (DWORD)? – Rox

No, they will have value 1. The data type will depend on where and how you use them. – Haploid

Answer 1

First, the immediate answer to your question...

Equ Sets the number in stone.

= Sets the number until you change it later on.

Beware !!! The definition of "later on" can confuse the living daylights out of you; particularly with multiple source files.

Here is a useful trick that you can use with these two directives to define a bunch of numbers when...

• You want names that represent a unique value (i.e., mathematically "unique", as in, you want to guarantee that none of them are the same)
• You don't really care what they are
• You may want to add or delete these values as your development progresses

• You don't know (when you start out) exactly how many of these you'll want

  The_Counter             =               0
  The_Counter             =               The_Counter + 1
  
  
  Fred                    =               The_Counter
  The_Counter             =               The_Counter + 1
  
  Barney                  =               The_Counter
  The_Counter             =               The_Counter + 1
  
  Dino                    =               The_Counter
  The_Counter             =               The_Counter + 1
  
  Arnold                  =               The_Counter
  The_Counter             =               The_Counter + 1
  
  Mr_Slate                =               The_Counter
  The_Counter             =               The_Counter + 1
  

Now, as you can see, Fred, Barney, Dino, Arnold, Mr_Slate could all change their values with this scheme, and that might be a bad thing; so, if you want to make sure that Fred et.al. don't get changed by somebody else (or yourself, in error) in another part of your source files, then you can combine the = and the Equ in the above scheme like this...

    The_Counter             =               0
    The_Counter             =               The_Counter + 1


    Fred                    Equ             The_Counter
    The_Counter             =               The_Counter + 1

    Barney                  Equ             The_Counter
    The_Counter             =               The_Counter + 1

    Dino                    Equ             The_Counter
    The_Counter             =               The_Counter + 1

    Arnold                  Equ             The_Counter
    The_Counter             =               The_Counter + 1

    Mr_Slate                Equ             The_Counter
    The_Counter             =               The_Counter + 1

In this case, they'll still all be different from each other, but their actual values won't be candidates for change.

While this example uses Flintstone's characters for the name, it can easily be changed to something more useful, like...

• Assigning multiple interrupt handlers and their priority. You could move the position of two lines in that source code, and experiment with a system that allows you to observe the differences when one interrupt handler gets priority over another, and then switch it up.
• Changing which values you choose in a lookup table
• Giving a constant a name that everyone in a group development can use (as a text label, hopefully that is obvious in its name) without ever having to worry about exactly what that specific integer value is

...and about 47 other good reasons that I can't think up right now.

Oh, just a suggestion; if you want to use this sort of scheme, I find it highly beneficial to place these Equ and = directives, etc. into their own include file; generally named SomeFile.Equ or whatever. I have personally found that by segregating these sorts of assembler directives and such stuff from the actual machine language instructions, you'll find that your code is far more legible, as well as way more maintainable; big time way more. (Just my suggestion.)

Good question, and one that gave me weeks of bewilderment myself.

Sundried