Let me start off with a little warning......This topic is going to use C code rather than assembly language code as I am currently working a firmware project that uses both (and besides, the firmware is in H8 and not x86).

With that said, I have a little question that I was hoping to get some help on.......

What if any is the real benefit of using a macro instead of a function call??

As an example if we define a function:

//
// No reason behind this function, its just an example
//
int func_ex(int val1, int val2) {
  int a;
  int b;

  a = val1;
  b = val2;

  return(a+b);
}

and then within our code we call said function 25 times.

vs the use of a macro (called the same exact amount of times as it replaces the line of code that made the function call):

#define mac_func_ex(val1, val2) ( (val1) + (val2) )

?????

Now I know that right off the bat we remove the overhead associated with the call function (push/pop,etc); however; we replace that overhead with the macro code increasing the size of our code block by X-1 amount of times * size of macro code (in our example if we use the macro 25 times in our code then we get an increase of code size by (24 * sizeof(mac_func_ex)).

Thanks and sorry for the C code.

Posted on 2008-07-08 12:22:52 by madprgmr
Any decent compiler will inline functions that are trivial enough - or that you choose to force-inline. Embedded world might be a bit different, I have no experience with compilers for embedded systems.

But generally, I'd use functions instead of macros. It can be easier to diagnose problems in debug builds - if you only have a crash location it might lead you to a non-inlined function (look up address in .map file and go "aha! It's froob_my_knots() that's failing!"), whereas a macro is *always* going to be expanded.

Also, macros have problems with side effects from the expressions you pass them - this can lead to very subtle bugs.

Perhaps not very applicable to embedded systems I guess, debugging - I don't think any of the debuggers I've used handled macro-"functions" very well, whereas with a regular function call, you can step through the individual statements.

And lastly, functions are imho a bit easier to read and maintain. And get properly syntax colored :)
Posted on 2008-07-08 12:34:52 by f0dder
It really depends on the code you're about to put in a macro/func and how your compiler handles it. I always look at the .asm output and benchmark different versions of a func when I wonder which method to use. (benchmark is done on two things - which func is faster by itself, and which one actually makes the whole app faster). You've got code-cache to look-out for, after all :)
With GCC4 for embedded systems, the difference between using macros and (auto-)inline funcs is minimal, but if you are stuck with GCC3.4, the difference is huge (in my experience).

VS2k5 nicely shows macros in a way similar to funcs. It's a real productivity booster (as long as you have 1GB+ ram and maybe dualcore) with its intellisense. You can even trick it to provide full intellisense on things like GPU shaders :D.

I've never had access to crash-info: on embedded devices I've worked on, once something crashes, it reboots or locks-up.... no info. So, VKDebug-style stuff (via a port) or into a file or screen - was what I could debug with. Thus, macro-expansion was never a problem for debugging.
Posted on 2008-07-08 14:00:46 by Ultrano

I have no experience with compilers for embedded systems.


What????  I thought that you were all knowing and all experience :)  I am so shocked at this statement that I am now going to have to pull my vote on making you dictator of the universe.  I hope you have a backup plan for total domination as without embedded systems experience how are you going to reprogram and control the members of your domain?


But generally, I'd use functions instead of macros. It can be easier to diagnose problems in debug builds - if you only have a crash location it might lead you to a non-inlined function (look up address in .map file and go "aha! It's froob_my_knots() that's failing!"), whereas a macro is *always* going to be expanded.

Also, macros have problems with side effects from the expressions you pass them - this can lead to very subtle bugs.


Excellent points.


Perhaps not very applicable to embedded systems I guess, debugging - I don't think any of the debuggers I've used handled macro-"functions" very well, whereas with a regular function call, you can step through the individual statements.


Now that I think about it, all the embedded debuggers that I have use handle macro-functions worth a spit.


And lastly, functions are imho a bit easier to read and maintain. And get properly syntax colored :)


Color??? how do you get edlin to display in color  ;)


It really depends on the code you're about to put in a macro/func and how your compiler handles it. I always look at the .asm output and benchmark different versions of a func when I wonder which method to use. (benchmark is done on two things - which func is faster by itself, and which one actually makes the whole app faster). You've got code-cache to look-out for, after all :)


I have been doing a little .asm output compare but have truly failed in performing an benchmarks on the different code (right now I still have enough code that is being kept in H8 assembly that any code that I feel is time sensitive I will leave in asm).


With GCC4 for embedded systems, the difference between using macros and (auto-)inline funcs is minimal, but if you are stuck with GCC3.4, the difference is huge (in my experience).


I am sorry to say that I am not using GCC, but rather the tools specific to Hitachi (could not convince my company to switch even though there is a gnu toolkit available for the H8)


VS2k5 nicely shows macros in a way similar to funcs. It's a real productivity booster (as long as you have 1GB+ ram and maybe dualcore) with its intellisense. You can even trick it to provide full intellisense on things like GPU shaders :D.


I guess I have spent too long looking at Programmer Porn (you know that dirty code snippet or two that we all love to hate but just have to have) so mind is mush....what is intellisense?


Posted on 2008-07-08 18:27:53 by madprgmr
Intellisense is a feature of more advanced code-editors to auto-suggest and auto-complete text. You can name your variables and funcs with long nice descriptive names, with an actual increase of statements/minute productivity and you having overall easier to maintain (and keep bug-free) source-code. The only drawback of intellisense is that it requires a good dualcore with lots of RAM.

I had missed to look at H8... didn't even see it's a microcontroller :(. I can't get access to whitepapers, so I'll assume it's just like most other microcontrollers. So, no code-cache, no branch-prediction - thus it's really better to inline code as much as possible. Might save you a bit of the stack at some places, too. And also the decision between inline-funcs and macros will be answered with just one disassembly, no benchmarking necessary. I expect since it is just Hitachi's compiler (and isn't GCC4), macros to be more easily handled and to produce smaller an faster code (compared to inlines).
But I haven't found and read easily-available whitepapers on H8 yet, so I'm just speculating
Posted on 2008-07-09 14:11:32 by Ultrano