Post by thread:CODE formatting....

Has anyone got a standard for Pic code formatting?? As my projects have started getting large and multiple, I have adopted my own, and willing to change to another or share mine. How I do it.. ALL_CAPS is used for defines, EQU, macros, and constants First_cap is used for function names, something with a return at the end all_lower is for simple labels for close by GOTOs in side of functions. Underscore_at_end_ is for any function in PAGE1 rather than PAGE0. I have not had to use a larger chip, so I don't have anything for PAGE2 or PAGE3. underscore_at_end as above, but not a function call, just for GOTOs. ;label_comment I do this when a branch falls through and a labels clarifies the code, but it does not ever have a GOTO using it. This keeps me from looking for nonexistent GOTO statements. Please make comments and share your point of view.

> ALL_CAPS is used for defines, EQU, macros, and constants > First_cap is used for function names, something with a return at the > end > all_lower is for simple labels for close by GOTOs in side of > functions. > Underscore_at_end_ is for any function in PAGE1 rather than PAGE0. I > have not had to use a larger chip, so I don't have > anything for PAGE2 or PAGE3. > underscore_at_end as above, but not a function call, just for GOTOs. > ;label_comment I do this when a branch falls through and a labels I personally prefer caps for code labels and MChip-defined I/O designators (e.g. PORTA); FirstCase for most data labels, _LEADING_UNDERSCORE for code branch tables, and for other bizarre constructs, whatever I come up with... I've not decided whether I prefer my first tab stop at column 9 or 17, and my code unfortunately reflects this (if I import a piece of code from another app I've written, I'll often have to adjust it); the opcode field begins 8 columns later, and the comments go in column 41 or 49. One other thing I do, which I find helps code readability a LOT, is to indent by one space the opcode for any instruction which may be conditionally skipped: movf Foo,w btfss Z clrf Bar iorwf Bar,f etc. When using double-conditionals [e.g. if I want Bar to be clear if bit Foo,0 or Foo,1 is set]: btfss Foo,0 btfsc Foo,1 clrf Bar the indent is a little less than clear, but note that I do not add a second level of indent; if I did, it would appear that skipping the first instruct- ion would imply skipping the second when in fact the reverse is true. Of course, some might argue against such constructs altogether, but I know of no other good way to, e.g., perform an add-with-carry that produces a meaningful carry out: movf Source,w btfsc C incfsz Source,w addwf Dest,f [does anyone know who invented that ingenious piece of code? They should win an award or something...]

>I know of no >other good way to, e.g., perform an add-with-carry that produces a meaningful >carry out: > > movf Source,w > btfsc C > incfsz Source,w > addwf Dest,f > >[does anyone know who invented that ingenious piece of code? They should >win an award or something...] John, Please continue with the explanation of this one, I'm not quick enough to figure out what you're doing. Thanks, Bob

Well John, I have been having a bit of trouble just from switching between C and ASM, as I don't use tabs at all in my C programming and I keep tying to comment with a ; or a // in the wrong places. I like the indenting for the "conditionals" I will try and incorperate it in my own style. I guess from the lack of response on the topic of ASM code formatring, that thier is no standard or rule of thumb, just so long as your code works! Giles L. Honeycutt spam_OUTgilesamiTakeThisOuTix.netcom.com John Payson wrote: {Quote hidden}> I've not decided whether I prefer my first tab stop at column 9 or 17, and > my code unfortunately reflects this (if I import a piece of code from another > app I've written, I'll often have to adjust it); the opcode field begins 8 > columns later, and the comments go in column 41 or 49. One other thing I > do, which I find helps code readability a LOT, is to indent by one space the > opcode for any instruction which may be conditionally skipped: > > movf Foo,w > btfss Z > clrf Bar > iorwf Bar,f > etc. > > When using double-conditionals [e.g. if I want Bar to be clear if bit Foo,0 > or Foo,1 is set]: > > btfss Foo,0 > btfsc Foo,1 > clrf Bar > > the indent is a little less than clear, but note that I do not add a second > level of indent; if I did, it would appear that skipping the first instruct- > ion would imply skipping the second when in fact the reverse is true. Of > course, some might argue against such constructs altogether, but I know of no > other good way to, e.g., perform an add-with-carry that produces a meaningful > carry out:

Bob Blick <.....bblickKILLspam@spam@TELIS.ORG> wrote: >> movf Source,w >> btfsc C >> incfsz Source,w >> addwf Dest,f >Please continue with the explanation of this one, I'm not quick enough to >figure out what you're doing. Bob, Perhaps a whole macro would illustrate: ;Two byte add. Standard PIC instruction set does not have an add ;with carry instruction. ;At exit, if C = 1, result is greater than 2 bytes. ;Usage example: add_word buff, new_data add_word: macro aaa, bbb movf (bbb+1), w addwf (aaa+1), f movf (bbb), w skpnc incfsz (bbb), w addwf (aaa), f endm Bob -- Bob Fehrenbach Wauwatosa, WI bfehrenbKILLspamexecpc.com

> >I know of no > >other good way to, e.g., perform an add-with-carry that produces a meaningful > >carry out: > > > > movf Source,w > > btfsc C > > incfsz Source,w > > addwf Dest,f > > > >[does anyone know who invented that ingenious piece of code? They should > >win an award or something...] > > John, > > Please continue with the explanation of this one, I'm not quick enough to > figure out what you're doing. I don't know of any good explanation for the code, except to describe it as follows: If the carry was set, then... If the source operand was 255... We'd be adding 256, which means the destination should have zero added and the carry should be set. Since adding zero to the destination would leave it unchanged, and since the carry is already set, we can simply do nothing. Otherwise... Add the source, plus one, to the destination; the carry will do what it will. Otherwise... Add the source to the destination; the carry will do what it will. I have no idea who invented that ingenious piece of code, but it really is quite remarkable. Unfortunately, I know of no good way to do such an add for the case of dest=source1+source2, other than coding it as dest=source1; dest+=source2. By the way, when adding a constant, it's possible to shave off an instruction if a "known-zero" location exists. Assuming a 16C84 [address $7F will always read zero], the following are I think the best approaches. Note that unlike the 'add a variable' routine above, these lend themselves readily to the case 'dest=source+const'. ; If constant is zero: rlf KZ,w ; KZ=known-zero @ $7F addwf Dest,f ; Or addwf Source,w // movwf Dest ; If constant is 1-254: rlf KZ,w addlw Const addwf Dest,f ; If constant is 255: [dest+=255] movlw 255 btfss C addwf Dest,f ; If constant is 255: [dest=source+255] movf Source,w btfss C addlw 255 movwf Dest,f I think these approaches are the best possible. Anyone know of anything shorter?

Bob Fehrenbach wrote: {Quote hidden}> > Bob Blick <.....bblickKILLspam.....TELIS.ORG> wrote: > > >> movf Source,w > >> btfsc C > >> incfsz Source,w > >> addwf Dest,f > > >Please continue with the explanation of this one, I'm not quick enough to > >figure out what you're doing. > > Bob, > > Perhaps a whole macro would illustrate: > > ;Two byte add. Standard PIC instruction set does not have an add > ;with carry instruction. > ;At exit, if C = 1, result is greater than 2 bytes. > ;Usage example: add_word buff, new_data > > add_word: macro aaa, bbb > movf (bbb+1), w > addwf (aaa+1), f > movf (bbb), w > skpnc > incfsz (bbb), w > addwf (aaa), f > endm > > Bob > > -- > Bob Fehrenbach Wauwatosa, WI EraseMEbfehrenbspam_OUTTakeThisOuTexecpc.com And as Bob F. and I were recently discussing, this comes from Microchip's AN617. The author is Frank Testa. Someone correct me if I wrong, but I believe Frank has a PhD in physics. Scott

Bob has asked me to forward this to the list. Bob Fehrenbach <bfehrenbspam_OUTexecpc.com> wrote: > add_word: macro aaa, bbb > movf (bbb+1), w > addwf (aaa+1), f > movf (bbb), w > skpnc > incfsz (bbb), w > addwf (aaa), f > endm Bob: The parentheses in the first two lines should not include the "+1"'s. -Andy === Andrew Warren - @spam@fastfwdKILLspamix.netcom.com === === Fast Forward Engineering - Vista, California === === === === Custodian of the PICLIST Fund -- For more info, see: === === http://www.geocities.com/SiliconValley/2499/fund.html ===

Robert Lunn <KILLspamPICLISTKILLspamMITVMA.MIT.EDU> wrote: > >> movf (bbb+1), w > >> addwf (aaa+1), f > >> .... > > > > The parentheses in the first two lines should not include the > > "+1"'s. > > Well, the "+1"'s have to be somewhere... Bob: Yes, but my point was that every macro paremeter must be enclosed in its own set of parentheses, like this: movf (bbb)+1,w addwf (aaa)+1,f -Andy === Andrew Warren - RemoveMEfastfwdTakeThisOuTix.netcom.com === === Fast Forward Engineering - Vista, California === === === === Did the information in this post help you? Consider === === contributing to the PICLIST Fund. Details are at: === === http://www.geocities.com/SiliconValley/2499/fund.html ===