I just want to make a quick comment about this assembler / C debate.
I think I saw an article in Circuit Cellar that solves the problem of using
C as
opposed to Assembler for writting easily readable and maintainable code. The
technique involves writing the code in assembler and then placing the C code
that
equates to the assembler in the comments to the right of the assembler code.
This gives some(!) of the benefits of both languages at the same time. Many
times
I see comments embedded in assembler code that look like this:
movlw 8
movwf Cnt ; Loop 8 times
loop movf Reg1, w ; Move value to w
movwf Reg2 ; Move w to Reg2
decfsz Cnt, f ; Decrement Counter
goto loop ; Is it zero yet?
.
.
.
Now you have the speed and compactness of assembler AND the readability of C.
Neat huh? Just my two cents worth. If you agree, use it - if not trash it.
ps - I love this list!! I learn something most every day.
>I just want to make a quick comment about this assembler / C debate.
>
>I think I saw an article in Circuit Cellar that solves the problem of using
>C as
>opposed to Assembler for writting easily readable and maintainable code.
>
>I much prefer to see this:
>
> movlw 8 ; for (Cnt=8; Cnt>0; Cnt--)
> movwf Cnt ; {
>loop movf Reg1, w ; Reg2 = Reg1;
> movwf Reg2
> decfsz Cnt, f
> goto loop ; }
> .
> .
> .
>
>Now you have the speed and compactness of assembler AND the readability of C.
>Neat huh? Just my two cents worth. If you agree, use it - if not trash it.
I recall that article. Just think about it though....
Now you have two undocumented algo. to maintain. If you saw that C code in
a program by itself you'd say what a dork. No comments on why he is doing
it. Now you have C code that may not say the same thing as the assembler.
Which algo. is correct? Is the assembler different because a bug was fixed
and the maintenance programmer forgot to change the C code comments or did
the programmer hand compile the C the wrong way around. That was never
addressed in the article.
Instead...
> movlw 8 ; Use a loop to read our 8 byte
> movwf Cnt ; message from FIFO port 1 and
>loop movf Reg1, w ; send it out FIFO port 2 so
> movwf Reg2 ; that network stays busy.
> decfsz Cnt, f
> goto loop ; }
> .
Ultimately what which would you like to maintain in a year?
Regards,
John
Pioneers are the ones, face down in the mud,
with arrows in their backs.
Automation Artisans Inc. Ph. 1-250-544-4950
PO Box 20002 Fax 1-250-544-4954
Sidney, BC CANADA V8L 5C9
>I much prefer to see this:
>
> movlw 8 ; for (Cnt=8; Cnt>0; Cnt--)
> movwf Cnt ; {
>loop movf Reg1, w ; Reg2 = Reg1;
> movwf Reg2
> decfsz Cnt, f
> goto loop ; }
> .
> .
> .
>
>Now you have the speed and compactness of assembler AND the readability of C.
>Neat huh? Just my two cents worth. If you agree, use it - if not trash it.
Yep, we do that regularly, except we use psuedo code or pascal equivalent, that
way its a bit more precise and a bit more readable than C (well for real
new programmers that is AND ensures a bit more type checking constructs than
C is (in)famous for...)
Rgds
Mike
Some say there is no magic but, all things begin with thought then it becomes
academic, then some poor slob works out a practical way to implement all that
theory, this is called Engineering - for most people another form of magic.
One of the biggest problems with commenting assembly code (speaking as
one who did it for many years on IBM mainframes) where on each line you
try to describe what the instruction does,is that there is a tendency
when reading the program later (either you or someone else) to read the
comments, and not the code. And if the comments are at all incorrect,
bugs galore can creep in when you modify stuff later.
The approach we always took here was to comment WHAT THE CODE DID, as
opposed to what the instructions did. One can assume that an assembler
programmer knows the assembler inside out (or else he shouldn't be
trying to modify the code!). But clearly explaining what the section of
code is supposed to do is far more useful.
Documenting code is an art, and is much harder than writing it in the
first place. After all, you KNOW what you are doing, so the tendency is
to explain things from your point of view, rather than that of some poor
slob (and it could be you!) trying to change it three years later.
This applies to code written in any language, not just cryptic languages
like assembler and C. Even "self-documenting" languages like (shudder)
COBOL are not really self-documenting. The individual statements are
easy to understand (but then to an assembler expert, so are assembler
instructions). It's the overall logic of the code fragment that needs to
be explained.
Ideally, the comments in your code should be the same, no matter what
language you are progamming in. If you wrote a program in "C", and then
decided to redo it in assembler for speed, the comments from your C
program should be able to be copied directly to your assembler program
and still be meaningful. Someone reading your program should be able to
figure out what the code fragments do, even if they don't know the
language.
At 05:52 PM 18/02/1997 -0500, you wrote:
>One of the biggest problems with commenting assembly code
...
[snip]
>Ideally, the comments in your code should be the same, no matter what
>language you are progamming in. If you wrote a program in "C", and then
>decided to redo it in assembler for speed, the comments from your C
>program should be able to be copied directly to your assembler program
>and still be meaningful. Someone reading your program should be able to
>figure out what the code fragments do, even if they don't know the
>language.
>
>My $.02 worth
>
Larry,
More like $2,000,000.00 worth. Hear hear! Well said.
John
Pioneers are the ones, face down in the mud,
with arrows in their backs.
Automation Artisans Inc. Ph. 1-250-544-4950
PO Box 20002 Fax 1-250-544-4954
Sidney, BC CANADA V8L 5C9
>Ideally, the comments in your code should be the same, no matter what
>language you are progamming in. If you wrote a program in "C", and then
>decided to redo it in assembler for speed, the comments from your C
>program should be able to be copied directly to your assembler program
>and still be meaningful. Someone reading your program should be able to
>figure out what the code fragments do, even if they don't know the
>language.
Larry,
That's probably a good point. I tend to document my assembler with C code
to provide the logic to me later.
And C code doesn't need a whole lot of comments, because I avoid like the
plague those keystroke-saving shortenings.
The biggest thing, in my book, is to document the inputs, outputs, and uses
(globals, other resources) of every routine, and a basic concept of what it
does. THen I can come back later and figure out what it takes to translate
from one to another language.
Also, it's far easier to keep these items maintained than it is to document
the code alongside the code.
Andy
==================================================================
Andy Kunz - Montana Design - 409 S 6th St - Phillipsburg, NJ 08865
Hardware & Software for Industry & R/C Hobbies
"Go fast, turn right, and keep the wet side down!"
==================================================================
I definitely agree that comment lines are for explaining the concept.
I have some 8086 code that I wrote 8 years ago that I have to revisit from
time to time. I would like to say that my verbose comments make it easy
for me or anybody else to look at it and jump right in to fix or modify.
The trouble is my nose just grew another inch and I need to trim it back
before it pushes the monitor off the back of the desk.
I could just kick myself when I see that all I did was paraphrase
the mnemonic. I can look at mnemonics any time I like so there is no need to
repeat them. I am, however, thrilled when I remembered to comment a problem
such as why it is necessary to set a loop up a certain way in order to
prevent an off-by-one error or some other problem that was resolved via
the school of hard knocks. This is the kind of stuff that melts away quickly
and becomes confused. Take my word. You won't remember it later. A simple
sentence or phrase will make all the difference in the world. This idea
seems to be true no matter whether the language is assembly or some
higher-level language. The source code is like a circuit board in which
most of the components are instantly recognizable, but one needs the schematic
or a good functional text to know the purpose of the components.
>The source code is like a circuit board in which
>most of the components are instantly recognizable, but one needs the schematic
>or a good functional text to know the purpose of the components.
>
Excellent analogy.
>
> I definitely agree that comment lines are for explaining the concept.
> I have some 8086 code that I wrote 8 years ago that I have to revisit from
> time to time. I would like to say that my verbose comments make it easy
> for me or anybody else to look at it and jump right in to fix or modify.
> The trouble is my nose just grew another inch and I need to trim it back
> before it pushes the monitor off the back of the desk.
>
> I could just kick myself when I see that all I did was paraphrase
> the mnemonic. I can look at mnemonics any time I like so there is no need to
> repeat them. I am, however, thrilled when I remembered to comment a problem
> such as why it is necessary to set a loop up a certain way in order to
> prevent an off-by-one error or some other problem that was resolved via
> the school of hard knocks. This is the kind of stuff that melts away quickly
> and becomes confused. Take my word. You won't remember it later. A simple
> sentence or phrase will make all the difference in the world. This idea
> seems to be true no matter whether the language is assembly or some
> higher-level language. The source code is like a circuit board in which
> most of the components are instantly recognizable, but one needs the schematic
> or a good functional text to know the purpose of the components.
>
> Martin McCormick
I am making the transition from assembly to C. I find myself writing my
comments in C like format. I think it is a great concept. There is lot
of value to that.
Now I am looking for help in writing PIC applications in C. I am
looking for some simple C code used for the MPLAB, to begin my
familiarization with the concept of using the C compiler.
