How macros in embedded C affect memory?

Question

I know that macros in C such as:

#define VARNULL (u8)0

doesn't store this VARNULL in RAM, but this of course will increase the code size in the FLASH.

But what if I have a multi-line macro such as:

#define CALL_FUNCS(x) \
do { \
  func1(x); \
  func2(x); \
  func3(x); \
} while (0)

By knowing that func1, func2, and func3 are functions from different .c files. Does this means that these functions will be stored in RAM? And of course in the FLASH (the code).

Kindly correct me if I'm wrong?

Macros do not affect the runtime, they affect the code before compilation. — Iharob Al Asimi, May 13 '16 at 14:47
Unless it is used, `VARNULL` is not stored anywhere. if you use `VARNULL`, the compiler sees the code as if you wrote `(u8)0`, and it will make appropriate use of that zero. With `CALL_FUNCS`, if you don't use it, nothing goes into the program. If you invoke it, then three function calls in sequence are generated at that spot in the code, just as if you'd written them out long-hand. If you have a debuggable image (probably you don't in an embedded system), then a `const` variable appears in the symbol table and can make debugging easier; a macro isn't recorded so it's harder to debug. — Jonathan Leffler, May 13 '16 at 15:01
See [`static const` vs `#define` vs `enum`](https://stackoverflow.com/questions/1674032/static-const-vs-define-vs-enum/1674459#1674459) for a discussion of constants and macros. — Jonathan Leffler, May 13 '16 at 15:03
You have asked two questions here; you would probably do better to have posted them separately. — Clifford, May 14 '16 at 19:52
Thank you guys for your replays. You are right, it would be better to separate these 2 questions. I just separated them. — Sameh NAGI, Nov 24 '16 at 23:18

score 4 · Answer 1 · answered May 13 '16 at 14:59

You keep saying that "of course" the macros will be "stored" in flash memory on your target device, but that is not true.

The macros exist in the source code only; they are replaced with their defined values during compilation. The program in flash memory will not "contain" them in any meaningful way.

score 1 · Accepted Answer · answered May 14 '16 at 20:02

Macros, and any other directive prefixed with a # are processed before C compilation by the pre-processor; they do not generate any code, but rather generate source code that is then processed by the compiler as if you had typed in the code directly. So in your example the code:

int main()
{
    CALL_FUNCS(2) ;
}

Results in the following generated source code:

int main()
{
    do { \
      func1(2);
      func2(2);
      func3(2);
    } while (0) ;
}

Simple as that. If you never invoke the macro, it will generate exactly no code. If you invoke it multiple times, it will generate code multiple times. There is nothing clever going on the macro is merely a textual replacement generated before compilation; what the compiler does with that depends entirely on what the macro expands to and not the fact that it is a macro - the compiler sees only the generated code, not the macro definition.

With respect to const vs #define, a literal constant macro is also jyst a textual replacement and will be placed in the code as a literal constant. A const on the other hand is a variable. The compiler may simply insert a literal constant where that generates less code that fetching the constant from memory, in C++ that is guaranteed for simple types, and it would be unusual for a C compiler not to behave in the same way. However, because it is a variable you can take it's address - if your code does take the address of a const, then the const will necessarily have storage. Whether that storage is in RAM or ROM depends on your compiler and linker configuration - you should consult the toolchain documentation to see how it handles const storage.

One benefit of using a const is that const variables have strong typing and scope unlike macros.

How macros in embedded C affect memory?

2 Answers2