Assembly 8086 EQU directive

Question

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?

Jesher

Depends on the actual assembler you use. Is it emu8086? Then I don't know. But most of the x86 assemblers don't have preprocessor. So the EQU in such case is evaluated upon definition, not replaced. And I'm like 99% sure it's your case as well. For preprocessor feel free to run some C compiler preprocessor (or even something standalone, but I have gcc always around, so I would go for the C one). – Mucoviscidosis

Uhm, I got it. Is there anything like preprocessor in assembly, I would actually need it? – Jesher

Just edited my answer to demonstrate that EQUs are global (EQU declared inside procedure). – Unbalance

Answer 1

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.

Pavior

The produced garbage from using varA EQU [bp+2] and varB EQU [bp+2] clearly demonstrates that EMU8086 should not even have accepted those equates in the first place. Another flaw in the emulator discovered! +1 Nice to see you took the time to find out about EQU. – Leverrier

Answer 2

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.

Leucocytosis

Answer 3

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... :)

Mucoviscidosis

I bet you were the chap who wrote those Apple ][ expansion card ROMs which had only 256 bytes. They were so tight for memory I saw some code that branched to the middle of another instruction to get a side-effect. It was the offset 0x38 of another branch instruction followd by RTS. That 0x38 happens to be the instruction SEC and the cheeky chap branched there to get a RTS with the carry set. – Direct

@WeatherVane I must humbly admit I never got that far...self modifying code? Check. Using code itself also as data for processing? Check. But partially reused opcode... can't recall doing that one. It's entertaining anecdote, ty. :) (and I never did Apple ][, only ZX Spectrum) – Mucoviscidosis