Post by thread:[PIC] xorlw question

Part of code: =============================================== FindCV: bcf NOCV bcf RDONLY xorlw 0x00 ; CV513 btfsc STATUS,Z retlw PRIM_ADDR0 xorlw (0x00 ^ 0x08) ; CV521 btfsc STATUS,Z retlw PRIM_ADDR1 xorlw (0x08 ^ 0x1C) ; CV541 btfsc STATUS,Z retlw CVAR_29 xorlw (0x1C ^ 0x02) ; CV515 btfsc STATUS,Z retlw MAX_BRIGHT xorlw (0x02 ^ 0x03) ; CV516 btfsc STATUS,Z retlw E_CV516 xorlw (0x03 ^ 0x04) ; CV517 btfsc STATUS,Z retlw E_CV517 xorlw (0x04 ^ 0x05) ; CV518 btfsc STATUS,Z retlw E_CV518 xorlw (0x05 ^ 0x20) ; CV545 btfsc STATUS,Z retlw E_CV545 xorlw (0x20 ^ 0x21) ; CV546 btfsc STATUS,Z retlw E_CV546 bsf RDONLY xorlw (0x21 ^ 0x06) ; CV519 btfsc STATUS,Z retlw MFG_VR_CODE =================================================== This routine is called with the actual CV value in w eg CV513=0x00 and CV519=0x06 {Quote hidden}> -----Oorspronkelijk bericht----- > Van: .....piclist-bouncesKILLspam@spam@mit.edu [piclist-bouncesKILLspammit.edu] > Namens Olin Lathrop > Verzonden: dinsdag 6 januari 2009 22:07 > Aan: Microcontroller discussion list - Public. > Onderwerp: Re: [PIC] xorlw question > > Harry H. Arends wrote: > > Could someone explain this construction to me. > > I looked in the MPASM help file but cant find a description. > > > > xorlw (0x05 ^ 0x20) ; CV545 > > The "^" is documented in the manual, so I guess you're asking > why someone would do this? To answer that, we need to see a > few more lines around this one. > > > ******************************************************************** > Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products > (978) 742-9014. Gold level PIC consultants since 2000. > -

Redwood Shores, 6 januari 2009. Dear Harry, They are using the ^-XOR to undo the modification they made to the source variable in the previous xorlw. So the value in W is modified by the check, and by adding the previous value to the next check using ^, it undoes this damage while doing the next check at the same time. I can imagine writing code like this, although with this amount of values I'd probably opt for a jump table instead (if the memory was available). I certainly would've added more comments about what was happening especially in the beginning. Greetings, Maarten Hofman. 2009/1/6 Harry H. Arends <.....h.arendsKILLspam.....home.nl> {Quote hidden}> Part of code: > =============================================== > FindCV: > bcf NOCV > bcf RDONLY > xorlw 0x00 ; CV513 > btfsc STATUS,Z > retlw PRIM_ADDR0 > xorlw (0x00 ^ 0x08) ; CV521 > btfsc STATUS,Z > retlw PRIM_ADDR1 > xorlw (0x08 ^ 0x1C) ; CV541 > btfsc STATUS,Z > retlw CVAR_29 > xorlw (0x1C ^ 0x02) ; CV515 > btfsc STATUS,Z > retlw MAX_BRIGHT > xorlw (0x02 ^ 0x03) ; CV516 > btfsc STATUS,Z > retlw E_CV516 > xorlw (0x03 ^ 0x04) ; CV517 > btfsc STATUS,Z > retlw E_CV517 > xorlw (0x04 ^ 0x05) ; CV518 > btfsc STATUS,Z > retlw E_CV518 > xorlw (0x05 ^ 0x20) ; CV545 > btfsc STATUS,Z > retlw E_CV545 > xorlw (0x20 ^ 0x21) ; CV546 > btfsc STATUS,Z > retlw E_CV546 > bsf RDONLY > xorlw (0x21 ^ 0x06) ; CV519 > btfsc STATUS,Z > retlw MFG_VR_CODE > =================================================== > This routine is called with the actual CV value in w eg CV513=0x00 and > CV519=0x06 > > > -----Oorspronkelijk bericht----- > > Van: EraseMEpiclist-bouncesspam_OUTTakeThisOuTmit.edu [piclist-bouncesspam_OUTmit.edu] > > Namens Olin Lathrop > > Verzonden: dinsdag 6 januari 2009 22:07 > > Aan: Microcontroller discussion list - Public. > > Onderwerp: Re: [PIC] xorlw question > > > > Harry H. Arends wrote: > > > Could someone explain this construction to me. > > > I looked in the MPASM help file but cant find a description. > > > > > > xorlw (0x05 ^ 0x20) ; CV545 > > > > The "^" is documented in the manual, so I guess you're asking > > why someone would do this? To answer that, we need to see a > > few more lines around this one. > > > > > > ******************************************************************** > > Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products > > (978) 742-9014. Gold level PIC consultants since 2000. > > --

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.

> xorlw (0x05 ^ 0x20) ; CV545 Harry, as Maarten said, the 5 restores W, and 20 is the next test. Here's one I use for checking a character in a serial string. The commented XORLW values are what are executed (ie what's in Program Memory). movfw indf0 chk_n xorlw "N" ;XORLW 0x4e bnz chk_f ;if not "N" bsf off_on ;else set to "device on" bra ss chk_f xorlw "N"^"F" ;XORLW 0x08 bnz chk_st ;if not "F" bra ss ;else leave as "device off" chk_st xorlw "F"^"S" ;XORLW 0x15 bz st_req ;status request bra ss If you follow the bit patterns in binary you'll see how it works, for example W ^ 0x4e W ^ 0x4e then W ^ 0x46 4e 01001110 ^ 46 01000110 -------------- 08 00001000 Here's another one goes_hi movfw dev_no ;set test bit, goes high xorlw .1 bnz h2 movlw .1 iorwf instath bra in_rdy h2 xorlw .1^.2 ;restore, test new value bnz h3 movlw .2 iorwf instath bra in_rdy h3 xorlw .2^.3 bnz h4

Olin Lathrop wrote: {Quote hidden}> 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.

A jump table isent a possibilty becourse not all CV's are used. Harry {Quote hidden}> -----Oorspronkelijk bericht----- > Van: @spam@piclist-bouncesKILLspammit.edu [KILLspampiclist-bouncesKILLspammit.edu] > Namens Maarten Hofman > Verzonden: dinsdag 6 januari 2009 22:53 > Aan: Microcontroller discussion list - Public. > Onderwerp: Re: [PIC] xorlw question > > Redwood Shores, 6 januari 2009. > > Dear Harry, > > They are using the ^-XOR to undo the modification they made > to the source variable in the previous xorlw. So the value in > W is modified by the check, and by adding the previous value > to the next check using ^, it undoes this damage while doing > the next check at the same time. > > I can imagine writing code like this, although with this > amount of values I'd probably opt for a jump table instead > (if the memory was available). I certainly would've added > more comments about what was happening especially in the beginning. > > Greetings, > Maarten Hofman. > > 2009/1/6 Harry H. Arends <RemoveMEh.arendsTakeThisOuThome.nl> > > > Part of code: > > =============================================== > > FindCV: > > bcf NOCV > > bcf RDONLY > > xorlw 0x00 ; CV513 > > btfsc STATUS,Z > > retlw PRIM_ADDR0 > > xorlw (0x00 ^ 0x08) ; CV521 > > btfsc STATUS,Z > > retlw PRIM_ADDR1 > > xorlw (0x08 ^ 0x1C) ; CV541 > > btfsc STATUS,Z > > retlw CVAR_29 > > xorlw (0x1C ^ 0x02) ; CV515 > > btfsc STATUS,Z > > retlw MAX_BRIGHT > > xorlw (0x02 ^ 0x03) ; CV516 > > btfsc STATUS,Z > > retlw E_CV516 > > xorlw (0x03 ^ 0x04) ; CV517 > > btfsc STATUS,Z > > retlw E_CV517 > > xorlw (0x04 ^ 0x05) ; CV518 > > btfsc STATUS,Z > > retlw E_CV518 > > xorlw (0x05 ^ 0x20) ; CV545 > > btfsc STATUS,Z > > retlw E_CV545 > > xorlw (0x20 ^ 0x21) ; CV546 > > btfsc STATUS,Z > > retlw E_CV546 > > bsf RDONLY > > xorlw (0x21 ^ 0x06) ; CV519 > > btfsc STATUS,Z > > retlw MFG_VR_CODE > > =================================================== > > This routine is called with the actual CV value in w eg > CV513=0x00 and > > CV519=0x06 > > > > > -----Oorspronkelijk bericht----- > > > Van: spamBeGonepiclist-bouncesspamBeGonemit.edu > [TakeThisOuTpiclist-bouncesEraseMEspam_OUTmit.edu] Namens > > > Olin Lathrop > > > Verzonden: dinsdag 6 januari 2009 22:07 > > > Aan: Microcontroller discussion list - Public. > > > Onderwerp: Re: [PIC] xorlw question > > > > > > Harry H. Arends wrote: > > > > Could someone explain this construction to me. > > > > I looked in the MPASM help file but cant find a description. > > > > > > > > xorlw (0x05 ^ 0x20) ; CV545 > > > > > > The "^" is documented in the manual, so I guess you're asking why > > > someone would do this? To answer that, we need to see a few more > > > lines around this one. > > > > > > > > > > ******************************************************************** > > > Embed Inc, Littleton Massachusetts, > http://www.embedinc.com/products > > > (978) 742-9014. Gold level PIC consultants since 2000. > > > -- >

I wil give it a try with youre solution. Thanks Harry {Quote hidden}> -----Oorspronkelijk bericht----- > Van: RemoveMEpiclist-bouncesTakeThisOuTmit.edu [piclist-bouncesEraseME.....mit.edu] > Namens Olin Lathrop > Verzonden: woensdag 7 januari 2009 0:08 > Aan: Microcontroller discussion list - Public. > Onderwerp: Re: [PIC] xorlw question > > 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. > -

Harry H. Arends wrote: > I wil give it a try with youre solution. Thanks > Why ? Doesn't the original code work ? {Quote hidden}> Harry > >> -----Oorspronkelijk bericht----- >> Van: EraseMEpiclist-bouncesmit.edu [RemoveMEpiclist-bouncesEraseMEEraseMEmit.edu] >> Namens Olin Lathrop >> Verzonden: woensdag 7 januari 2009 0:08 >> Aan: Microcontroller discussion list - Public. >> Onderwerp: Re: [PIC] xorlw question >> >> 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. >> --

Hi Harry, Once I did something like this (It is not perfect as it does not care of page boundaries but might help): switch macro file variable swtch = 0 movf file,W endm case macro l, addr xorlw l ^ swtch btfsc STATUS,Z goto addr swtch = l endm ;---- testing ---- switch TEST case b'11110000', FIRST-CASE case b'11111000', SECOND-CASE case b'11111110', THIRD-CASE goto NON-OF-THEM You can replace the "goto addr" with returns easily. Tamas On Wed, Jan 7, 2009 at 9:49 AM, Harry H. Arends <RemoveMEh.arendsspam_OUTKILLspamhome.nl> wrote: {Quote hidden}> I wil give it a try with youre solution. Thanks > > Harry > > > -----Oorspronkelijk bericht----- > > Van: RemoveMEpiclist-bouncesTakeThisOuTspammit.edu [EraseMEpiclist-bouncesspamspamBeGonemit.edu] > > Namens Olin Lathrop > > Verzonden: woensdag 7 januari 2009 0:08 > > Aan: Microcontroller discussion list - Public. > > Onderwerp: Re: [PIC] xorlw question > > > > 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. > > --

It does but it may be reducing the amount memory used. And using more CV's easier. {Quote hidden}> -----Oorspronkelijk bericht----- > Van: RemoveMEpiclist-bouncesKILLspammit.edu [piclist-bouncesSTOPspamspam_OUTmit.edu] > Namens Jan-Erik Soderholm > Verzonden: woensdag 7 januari 2009 11:17 > Aan: Microcontroller discussion list - Public. > Onderwerp: Re: [PIC] xorlw question > > Harry H. Arends wrote: > > I wil give it a try with youre solution. Thanks > > > > Why ? Doesn't the original code work ? > > > > > Harry > > > >> -----Oorspronkelijk bericht----- > >> Van: spamBeGonepiclist-bouncesSTOPspamEraseMEmit.edu > [KILLspampiclist-bouncesspamBeGonemit.edu] Namens > >> Olin Lathrop > >> Verzonden: woensdag 7 januari 2009 0:08 > >> Aan: Microcontroller discussion list - Public. > >> Onderwerp: Re: [PIC] xorlw question > >> > >> 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 {Quote hidden}> >> 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. > >> --

Harry H. Arends wrote: > It does but it may be reducing the amount memory used. > And using more CV's easier. I'm not sure that the macro solution sugested by Olin would save any code space, it mainly makes the code a bit more readable, but as I understand it, the expanded macro would take more or less the same code space as before. Jan-Erik. {Quote hidden}> >> -----Oorspronkelijk bericht----- >> Van: EraseMEpiclist-bouncesEraseMEmit.edu [@spam@piclist-bounces@spam@spam_OUTmit.edu] >> Namens Jan-Erik Soderholm >> Verzonden: woensdag 7 januari 2009 11:17 >> Aan: Microcontroller discussion list - Public. >> Onderwerp: Re: [PIC] xorlw question >> >> Harry H. Arends wrote: >>> I wil give it a try with youre solution. Thanks >>> >> Why ? Doesn't the original code work ? >> >> >> >>> Harry >>> >>>> -----Oorspronkelijk bericht----- >>>> Van: spamBeGonepiclist-bouncesKILLspammit.edu >> [.....piclist-bouncesspam_OUTmit.edu] Namens >>>> Olin Lathrop >>>> Verzonden: woensdag 7 januari 2009 0:08 >>>> Aan: Microcontroller discussion list - Public. >>>> Onderwerp: Re: [PIC] xorlw question >>>> >>>> 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. >>>> --

> I'm not sure that the macro solution sugested by > Olin would save any code space, Only if the macro is 'clever enough' to recognise sequential elements and replaces the xorlw/btfss/retlw code pattern to decfsz/retlw. Or even more if it recognises larger sequences and replaces the code to jump table. Not sure if that is possible with the original MPLAB macros or with Olin's macro preprocessor. A HLL compiler is a better candidate for doing such optimisations in my opinion. Tamas On Wed, Jan 7, 2009 at 12:18 PM, Jan-Erik Soderholm < TakeThisOuTjan-erik.soderholm.....TakeThisOuTtelia.com> wrote: {Quote hidden}> Harry H. Arends wrote: > > It does but it may be reducing the amount memory used. > > And using more CV's easier. > > I'm not sure that the macro solution sugested by > Olin would save any code space, it mainly makes > the code a bit more readable, but as I understand > it, the expanded macro would take more or less > the same code space as before. > > Jan-Erik. > > > > > > >> -----Oorspronkelijk bericht----- > >> Van: TakeThisOuTpiclist-bouncesKILLspamspammit.edu [.....piclist-bouncesRemoveMEmit.edu] > >> Namens Jan-Erik Soderholm > >> Verzonden: woensdag 7 januari 2009 11:17 > >> Aan: Microcontroller discussion list - Public. > >> Onderwerp: Re: [PIC] xorlw question > >> > >> Harry H. Arends wrote: > >>> I wil give it a try with youre solution. Thanks > >>> > >> Why ? Doesn't the original code work ? > >> > >> > >> > >>> Harry > >>> > >>>> -----Oorspronkelijk bericht----- > >>>> Van: RemoveMEpiclist-bouncesspamBeGonemit.edu > >> [spamBeGonepiclist-bounces@spam@spam_OUTmit.edu] Namens > >>>> Olin Lathrop > >>>> Verzonden: woensdag 7 januari 2009 0:08 > >>>> Aan: Microcontroller discussion list - Public. > >>>> Onderwerp: Re: [PIC] xorlw question > >>>> > >>>> 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. > >>>> -- >

> -----Original Message----- > From: TakeThisOuTpiclist-bouncesspammit.edu [piclist-bouncesEraseMEmit.edu] On Behalf > Of Harry H. Arends > Sent: 07 January 2009 09:46 > To: 'Microcontroller discussion list - Public.' > Subject: RE: [PIC] xorlw question > > A jump table isent a possibilty becourse not all CV's are used. > # That doesn't prevent you using a jump table though? Regards Mike ======================================================================= This e-mail is intended for the person it is addressed to only. The information contained in it may be confidential and/or protected by law. If you are not the intended recipient of this message, you must not make any use of this information, or copy or show it to any person. Please contact us immediately to tell us that you have received this e-mail, and return the original to us. Any use, forwarding, printing or copying of this message is strictly prohibited. No part of this message can be considered a request for goods or services. =======================================================================

I may use it to make the code more readable when documenting the code afterwards. Harry {Quote hidden}> -----Oorspronkelijk bericht----- > Van: RemoveMEpiclist-bouncesEraseMEspam_OUTmit.edu [@spam@piclist-bouncesRemoveMEEraseMEmit.edu] > Namens Olin Lathrop > Verzonden: woensdag 7 januari 2009 14:16 > Aan: Microcontroller discussion list - Public. > Onderwerp: Re: [PIC] xorlw question > > Harry H. Arends wrote: > > I wil give it a try with youre solution. > > Why do you need to touch it at all? I wasn't advocating a > particular solution, just pointing out that what was there > was poorly written. That doesn't mean it needs to be "fixed" > if it's working. While the existing code is messy and hard > to maintain, the logic appears to be correct. > > > ******************************************************************** > Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products > (978) 742-9014. Gold level PIC consultants since 2000. > -