Harry H. Arends wrote:
>     xorlw   (0x08 ^ 0x1C)      ; CV541
>     btfsc   STATUS,Z
>     retlw   CVAR_29
>     xorlw   (0x1C ^ 0x02)     ; CV515
>     btfsc   STATUS,Z
>     retlw   MAX_BRIGHT

What's happening here is that he is testing the original value in W against
a succession of constants.  He checks for a particular constant by XORing it
into W, then checking for the result being 0.  That works, but corrupts the
value in W.  He therefore XORs the test value again into W, which restores W
to its original value, then he XORs the new test value into W to be able to
check for zero again.

The optimization is to note that XORing with two successive values is the
same as XORing with the XOR of the two values.  Therefore XORing with the
previous test value to restore W then XORing with the new test value is done
in one step.  He wrote out the two values separately and let the assembler
find the XOR of them to make it easier to see what's going on.

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


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist