Code macro and performance

[Chet]

Was wondering if using "code" macros has any effect on final compiled
in chip performance. Are the macro "Shell's" stripped from the assembly code"?

Also is using a loop faster than a decision component?

I'm trying to develop a closed loop stepper motion control system.

Thanks

[Steve]

Was wondering if using "code" macros has any effect on final compiled in chip performance. Are the macro "Shell's" stripped from the assembly code"?

There is a small performance "hit" when using macros, but it's not too great. The benifits of using macros (e.g. modular code that is easier to read) out-weighs any system slowdown.

Also is using a loop faster than a decision component?

I've never done any tests on this, but I doubt that there is much between them - I'm guessing they will end up as quite similar code once it is inside the PICmicro.

[Mark]

On a related topic,

Does each call of a macro use up one level of nesting for a subroutine call?

Since (if I'm right) the 16 series PICs have a maximum of 8 levels of (stack) subroutine calls (plus any interrupt calls?) and in-built macro's like the LCD routines may possibly call more than one level of it soon looks posible to overflow the stack? (and I suspect I have had this on one occasion).

So - does Boost C take care of all this and ensure the stack cannot overflow or do we need to calculate it ourselves?

If so can we always assume that component macro's only use one level and that interrupts use one level?

Thanks,
Mark

[Dave]

So - does Boost C take care of all this and ensure the stack cannot overflow or do we need to calculate it ourselves?

BoostC will warn of possible call stack overflows.

Regards
Dave

[Benj]

BoostC will warn of possible call stack overflows.

This may not be the case when using Interrupts etc when the software can be called to another level on the stack at any one time. One or two levels should always be saved for each interrupt that is being used. This helps to create crash proof and reliable software.