What do assemblers translate macros into during assembling? [closed]

I have dug in simple binaries, such as though like x86 bootloaders, sega video game binaries, etc. I know that these files tend to use assembler macros to define data, etc. What I am having trouble figuring out is what assemblers tend to translate macros into exactly (are they instructions, custom formatted data entries used statically, addressing mode/special opcodes, etc.).

I do not know if this is the wrong place to ask. If so, I am saving time by double-posting on reverse engineering 's SE.

• Please do not cross-post to multiple Stack Exchanges. It saves you time but it wastes everybody else's because anyone who thinks they have an answer to your question needs to find your other post on the other SE to check whether somebody has already answered. It also wastes the time of anyone who wants this answer after you because the answers are fragmented, making it harder for them to find the material they want. – David Richerby Feb 6 '14 at 8:52

From a semantic point of view, macros are expanded into assembly code. How macros are actually implemented probably depends on the assembler. One option would be to expand them in a preprocessing step, like in C compilers; another would be to expand them on the go. The end result is the same — it is as if the macros were expanded textually in a preprocessing step.

There are other mechanisms used in assemblers that you might consider macros but are different. For example, the x86 MASM uses db/dw/dd to define data. These are stored in the resulting executable, the exact way depending on the executable format, particularly how the binary is loaded into memory. Usually there is a specific data segment which is loaded into a specific address, the relevant pages being marked non-executable if the processor supports this.

A macro is (by definition) a text to text translation. So you can define NUMBER to be 100, and use NUMBER each time, and change the definition once if NUMBER ever has to be 99. Some macro processors can handle macros with arguments, and expand to different text depending on them.

In assembly, macros are used to expand to stereotyped stretches of code (on VAX VMS there was a set of I/O routines that were implemented as hairy macros), to "fake" instructions by combining several others, ...

For a (gentle) introduction to macros in general, see the C (or C++) preprocessor. To go overboard, the Unix m4(1) macro processor (the 4 is because it was the fourth complete redesign) is something to behold. For examples specifically in assembler, look at NASM and/or GNU's gas (if on Linux, it's info should be installed).

Do you mean macros or directives? An assembler directive doesn't actually compile/assemble to any code; it just tells the assembler what to do with a single-pass phase before the assembling actually begins.

For example, the x86 db is not a macro, but a directive. It's a directive that gets translated in to the binary equivalent of that textually and stored as cumberless data somewhere in the binary(to which can be specified).

The directive known as times is a directive used to fill the binary file released with 0s and 1s, or one or the other, or any combination thereof, etc. This is done in x86 bootloaders because, on x86, all bootloaders must be 512 bytes or BIOS won't read it. However, the directive doesn't assemble to any "useful" code/data.

Macros are, as mentioned, data that can be referenced by name rather than value. Assemblers can use both, but it sounds to me like you're confusing these two terms.

While the data directives can also be used like macros along the source, the actual directives can not, and are usually "pre-assembler" steps much like C's preprocessor.