Code macro and performance

For Flowcode users to discuss projects, flowcharts, and any other issues related to Flowcode 2 and 3.

Moderators: Benj, Mods

Chet
Posts: 61
Joined: Thu Oct 13, 2005 5:05 am
Location: USA
Has thanked: 2 times
Contact:

Code macro and performance

Postby Chet » Thu Dec 21, 2006 11:02 pm

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

User avatar
Steve
Matrix Staff
Posts: 3073
Joined: Tue Jan 03, 2006 3:59 pm
Has thanked: 87 times
Been thanked: 387 times
Contact:

Postby Steve » Fri Dec 22, 2006 9:26 am

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
Posts: 209
Joined: Thu Oct 19, 2006 11:46 am
Location: Bakewell, UK
Has thanked: 20 times
Been thanked: 16 times
Contact:

Stack overflow

Postby Mark » Sat Dec 23, 2006 12:36 am

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
Go with the Flow.

Dave
Posts: 2
Joined: Mon Nov 13, 2006 4:09 pm
Contact:

Re: Stack overflow

Postby Dave » Sat Dec 23, 2006 5:12 pm

Mark wrote: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

User avatar
Benj
Matrix Staff
Posts: 14223
Joined: Mon Oct 16, 2006 10:48 am
Location: Matrix TS Ltd
Has thanked: 4363 times
Been thanked: 4096 times
Contact:

Postby Benj » Tue Jan 02, 2007 12:36 pm

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.