Floortje Hanneman & Wouter van Ooijen <PICLIST@MITVMA.MIT.EDU> wrote:

> As for a macro which is not recursive yet might not always be able
> to share it's locals with itself consider this 'inline' macro which,
> when entered once with a value in w, is left twice with in w the two
> nibbles which were originally in w.
>
> ; convert w to two hex values in w, high nibble first
> convert_w_to_hl_hex macro
>  cblock
>   _file_1#v($)
>  endc
>  local temp = _file_1#v($)
>  local do_it
>  movwf temp
>  call do_it
>  swapf temp, f
> do_it
>  swapf temp, w
>  andlw H'0F'
>  endm
>
> This macro can be used like
>
> send_ab
>  movlw H'AB'
>  convert_w_to_hl_hex
>  call send
>  return
>
> But there is no technical objection to
>
> send_0b0b
>  movlw H'BB'
>  convert_w_to_hl_hex
>  convert_w_to_hl_hex
>  call send
>  return

    Wouter:

    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).

    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.

    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.

    -Andy

=== Andrew Warren - fastfwd@ix.netcom.com
=== Fast Forward Engineering - Vista, California
=== http://www.geocities.com/SiliconValley/2499