Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!apple!motcsd!xdos!doug
From: doug@xdos.UUCP (Doug Merritt)
Newsgroups: comp.sys.amiga
Subject: Re: To macro, or not to macro?  (LONG) ... a programming style.
Message-ID: <375@xdos.UUCP>
Date: 4 Jun 89 18:17:36 GMT
References: <2454@van-bc.UUCP>
Reply-To: doug@xdos.UUCP (Doug Merritt)
Organization: Hunter Systems, Mountain View CA (Silicon Valley)
Lines: 27

In article <2454@van-bc.UUCP> lphillips@lpami.wimsey.bc.ca (Larry Phillips) writes:
>The inefficiency comes when my macro is defined as: [...]
>       move.l  \1,a0		[...]
>which will, of course generate:
>       move.l  a0,a0
>       bsr     printit

Although your point is in general quite reasonable, in this example
it is inappropriate because the extra overhead of the move will be
totally swamped by the overhead of the call to printit. There is
no conceivable situation in which the difference would be measurable.

Actually this just confirms your point that macro efficiency is often
not a problem. And in fact many macros in both assem and C will be
*faster* than doing a subroutine call, and this can be a *very* important
programming tool. It's often possible to get a 20% overall improvement
by converting a C call to a macro, and I've gotten far more than that
at times.

But it's important to be careful, when optimizing, not to spend any
time optimizing something that will never have a measurable effect.
This is often one of the earmarks of an expert programmer versus a
hacker-wanna-be (present company excluded, of course).
	Doug
-- 
Doug Merritt		{pyramid,apple}!xdos!doug
Member, Crusaders for a Better Tomorrow		Professional Wildeyed Visionary