luka032
luka032

Reputation: 955

Assembly 8086 EQU directive

I'm having trouble just making clear EQU directive in assembler (8086).

abc EQU xyz

Does EQU literally swaps abc when found in code with xyz, whatever xyz represents, value etc?

i.e. Can i write?

varA EQU [bp+4]

mov ax, varA

And one more question is EQU globally accessed, i.e. can I define EQU out of procedure, and in procedure to use it?

Upvotes: 7

Views: 13662

Answers (3)

EQU items are not variables, they don't take any memory space :

  • When EQU referes to a constant value, it becomes a synonym for that value. This value can't be overwritten, even if you try it won't change.
  • When EQU referes to another variable, it becomes a synonym for that variable, so everything that happens to the synonym will happen to the variable.

Copy-paste next code in EMU8086 and run :

.model small
.stack 100h
.data

xyz DW  2016    ;◄■■■ ABC IS NOT A VARIABLE, IT IS
abc EQU xyz     ;     JUST A SYNONYM FOR XYZ.

pqr EQU 10      ;◄■■■ PQR IS NOT A VARIABLE, IT IS
                ;     JUST A SNYNONYM FOR NUMBER 10.

varA EQU [bp+2] ;◄■■■ BP POINTS TO GARBAGE.

.code

mov  ax, @data
mov  ds, ax

mov  abc, 25    ;◄■■■ XYZ BECOMES 25!!!!

mov  pqr, 999   ;◄■■■ NO ERROR, BUT THE VALUE WILL NOT CHANGE.
mov  ax, pqr    ;◄■■■ AX IS NOT 999, AX=10.

mov  si, varA   ;◄■■■ GARBAGE.
mov  bp, sp
mov  si, varA   ;◄■■■ DIFFERENT GARBAGE.
push ax         ;◄■■■ PUSH 10.
call my_proc

mov  ax, NUMBER ;◄■■■ YES, EQUS ARE GLOBAL!!! (AX=0B9H).

mov  ax, 4c00h
int  21h

;-----------------------------------------

my_proc proc  
mov  bp, sp
mov  si, varA    ;◄■■■ WRONG VALUE (ANOTHER GARBAGE). 
mov  si, [bp+2]  ;◄■■■ PROPER VALUE (10).

varB EQU [bp+2]
mov  si, varB    ;◄■■■ WRONG AGAIN.

NUMBER EQU 0b9h  ;◄■■■ DEFINE EQU INSIDE PROCEDURE.

ret
my_proc endp          

In the case of [bp+2] it just doesn't seem to work, probably because the compiler can't get a fixed value.

Upvotes: 11

Shift_Left
Shift_Left

Reputation: 1243

EQU simply denotes equality, therefore abc EQU xyz, xyz must have been defined previously.

In your second example, it would need to be like

%define varA [bp+4]

mov   ax, varA

Then after your code is assembled, an object dump would yield

mov ax, [bp+4]

then you could do something like

Bubble equ varA

mov  bx, Bubble

and you'd get

mov bx, [bp+4]

Generally, all assemblers work the same way, although syntactically there are subtle nuances such as NASM requires %, others may not.

Upvotes: 4

Ped7g
Ped7g

Reputation: 16596

Some assemblers have reasonable macro support, that usually works internally as preprocessor, or very close to it.

Otherwise as I already wrote in comment, why don't you use C preprocessor? (it's standalone tool, you can preprocess any text file with it, just using #define and other to extend your asm source, the rest of the content doesn't have to look like C source, preprocessor doesn't care, it's processing the file as [any] text file).

Would you need it? I wouldn't. I did huge code in ASM only due to my lack of experience and macros/preprocessor wouldn't save me from that huge mistake (they would probably just make it less obvious and somewhat more bearable for longer period of time).

While you do in ASM only small pieces of code for educational reasons, or performance/low-level things, macros/preprocessor would IMHO add layer of abstraction shadowing the produced instructions, so during debugging you may then find yourself asking "where did this one come from?". I prefer to write every ASM instruction rather by hand, knowing why I put it there, I don't want any surprises in ASM code, it's already quite tough to write bug free code in ASM.

Then again most of my late work in ASM were 256B intros, so I really had to know about each byte produced... :)

Upvotes: 3

Related Questions