On Fri, 15 Feb 2002 10:24:09 -0500, Herbert Graf wrote:

>I think the biggest reason is code space. With a subroutine there is =
only
>one instance of that subroutine in the code, all calls to it branch to =
that
>address. With a macro you are using something called 'inline code', =
every
>time you "call" the macro a copy of that code gets added, so 20 "calls" =
to
>the macro, 20 copies of that code.=20

Minor nit to pick - Subroutines get called, macros get invoked. Using
the term "call" when talking about macros muddies the distinction
between macros and subroutines.

>Now whether this is a bad thing or not is
>up to you and your circumstance. A macro consisting of 1 or 2 lines of =
code
>is mostly better then a subroutine, a macro 30 lines long is probably =
best
>done as a subroutine, but it's up to you. In timing critical =
applications it
>MAY be better to use a macro since you don't have the overhead of the
>subroutine call (which admitidly on a PIC is only two extra cycles, but =
that
>might be important in certain circumstances, in other micro's calling a
>subroutine can hit you with a relatvily large cycle penalty).

Oops, another nit - Actually it's four cycles minimum overhead for a
subroutine. There's the 2 cycles for the call and another 2 for the
return.

Regards, Nitpicker Bob

--
http://www.piclist.com hint: To leave the PICList
mailto:piclist-unsubscribe-request@mitvma.mit.edu