Hi Any, you're a fast responder.
I'm on-line only in the evening (and only occasionally), so my responses
might take some time.

>    If you rewrite your macro so that it doesn't reserve a new
>    register each time it's invoked, there is STILL "no technical
>    objection" to your second example... It'll work just fine if you
>    rewrite it so each invocation uses the SAME "temp" register
>    (although in either case, you'll have to fix the macro so it
>    doesn't do a "call do_it"; that won't work, since there's no
>    "RETURN" at the end of the macro).

I think you missed the purpose of the macro: the macro does not have a return
inside it because it relies on a return lateron (which is used twice!).
In C it would be written like
   void call_for_both_nibbles( int x; void f(int) ){
      f( x >> 4 ); f( x & 0xFF ); }
but in assembler the explicit passing of f can be avoided by requiring that
the code
of f follows the macro 'call'. The temp is equivalent to the x parameter of
the function.

Two simple examples of this technique:

beep_twice
 call beep
beep
 <the actual code of beep>
 return

delay_8
 call delay_4
delay_4
 return

>    Again, I may be missing something, but I still don't see any
>    reason (other than the rather arbitrary "I don't want my macro's
>    variables to appear in the symbol list") for forcing the macro
>    to reserve unique registers each time.

It's not so much the fact that they'll appear in the symbol list (although I
don't like that),
but the fact that the symbol is accessible elsewhere, which is a very bad
idea (when I use X
inside such a macro, and another X elsewhere, which I forget to allocate,
the 'elsewhere'
happyly uses the X in the macro, without any error message from the
assembler). And when I do
allocate the new X I'll get a double defined symbol! Ok, I could use long
names which include
the module, but that doesn't make the code very readable.

>    Wait... This just occurred to me:  Maybe you're misunderstanding
>    the operation of the CBLOCK directive.  Are you aware that each
>    invocation of your example macro will reserve an additional
>    register?  For example, if first invocation assigns "temp" to
>    register 20, the second invocation will assign "temp" to
>    register 21.

Yes, I'm aware that cblock is rather primitive. One day I'll write MPASM
macro's for automatic
- unused code elimination
- inlining of routines which are called only once
- static-stack wise file allocation (I've seen that one on the piclist some
time ago).
But up till then I'll simply use CBLOCK (I'm not out of file registers yet...).

regards,
Wouter.