Searching \ for 'CODE formatting....' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/index.htm?key=code+formatting
Search entire site for: 'CODE formatting....'.

Truncated match.
PICList Thread
'CODE formatting....'
1996\12\08@000410 by Giles L. Honeycutt

flavicon
face
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.

1996\12\08@155856 by John Payson

picon face
> 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...]

1996\12\08@195426 by Bob Blick

flavicon
face
>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

1996\12\09@030818 by Giles L. Honeycutt

flavicon
face
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_OUTgilesamiTakeThisOuTspamix.netcom.com


John Payson wrote:
{Quote hidden}

1996\12\09@101528 by Bob Fehrenbach

picon face
Bob Blick <.....bblickKILLspamspam@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     bfehrenbspamKILLspamexecpc.com

1996\12\09@102917 by John Payson

picon face
> >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?

1996\12\09@131920 by sdattalo

face
flavicon
face
Bob Fehrenbach wrote:
{Quote hidden}

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

1996\12\09@150411 by fastfwd

face
flavicon
face
Bob has asked me to forward this to the list.

Bob Fehrenbach <bfehrenbspamspam_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@fastfwdKILLspamspamix.netcom.com                 ===
=== Fast Forward Engineering - Vista, California          ===
===                                                       ===
=== Custodian of the PICLIST Fund -- For more info, see:  ===
=== http://www.geocities.com/SiliconValley/2499/fund.html ===

1996\12\09@182617 by Robert Lunn

flavicon
face
Andy and Bob, et al, 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
>
>The parentheses in the first two lines should not include the "+1"'s.

       Well, the "+1"'s have to be somewhere...

       I just assumed the code was written 'low endian'.

___Bob

1996\12\09@183455 by fastfwd

face
flavicon
face
Robert Lunn <KILLspamPICLISTKILLspamspamMITVMA.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 - RemoveMEfastfwdTakeThisOuTspamix.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 ===

More... (looser matching)
- Last day of these posts
- In 1996 , 1997 only
- Today
- New search...