Olin Lathrop wrote:
> Harry H. Arends wrote:
>>     xorlw   (0x08 ^ 0x1C)      ; CV541
>>     btfsc   STATUS,Z
>>     retlw   CVAR_29
>>     xorlw   (0x1C ^ 0x02)     ; CV515
>>     btfsc   STATUS,Z
>>     retlw   MAX_BRIGHT
> 
> ...
> ...
> 
> This is not very good programming because each test value is now in two
> places, leaving open the possibility of making a mistake and getting them
> out of sync.  If I were to use this successive XOR technique, I would make a
> macro you pass the test value and the associated return value to.  The macro
> would use a assembly time variable to track the previous test value and
> compute the new combined XOR value.  The result would be easier to read and
> more maintainable, and you know that the previous value is always XORed out
> correctly.  The equivalent code to the snippet above would look something
> like:
> 
>      check_val h'1C', cvar_29     ;CV541
>      check_val h'02', max_bright  ;CV515
> 
>

Or one could EQU some constants to the actual values and
use them instead :

CV111  equ  h'08'             ; or whatever it was...
CV541  equ  h'1C'
CV515  equ  h'02'

   xorlw   (CV111 ^ CV541)     ; CV541
   btfsc   STATUS,Z
   retlw   CVAR_29
   xorlw   (CV541 ^ CV515)     ; CV515
   btfsc   STATUS,Z
   retlw   MAX_BRIGHT


Then each value is in only one place and can be reused
in other places in the code easily, if needed.

Jan-Erik.
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist