how to interpret the list file

[energetic007]

How to interpret the list file .............
Guys i am guessing what use the list file could be put to and how it can be helpful in debugging. I know its something like the compiler produces the asm codes for the useful codes only in which some computation is done but i am curious to use it for debugging....

[C Turner]

The things for which I find the list file to be most useful are:

- Optimizing code produced by the compiler.
- Divining the nature of compiler bugs.

On the first one, consider the following two operations on an unsigned 32 bit integer ("a") on a PIC16 processor in which one may want to align some bits with a piece of hardware or divide the value by two:

a >>= 1;

shift_right(&a, 4, 0);

They both accomplish (more or less) the same thing in that "a" gets shifted to the right one bit and divided-by-two, but if you take a look at the code listing you'll see that they produce slightly different code. In some cases - such as those where space and/or timing is at a premium - knowing what sort of C code produces the smallest, most compact assembly is crucial. (The CCS manual gives some nice examples where some "clever" C code results in very ugly, inefficient assembly.)

Another example would be for a function like "write_eeprom()" - at least in the PIC16F series. If one is writing to the EEPROM in several places throughout the code, it may go unnoticed that the entire function for doing this is repeated every time it is called, taking up quite a bit of space. Knowing that - by having looked at the list file - one could place it in its own, separate function and prevent that from happening!


When I started writing more code PIC code in C than assembly, I looked at the resulting ASM file quite often and experimented to see how the C code affected the efficiency of the resulting code - the result of this is that my PIC C code often looks a bit different from code that I would write on a system from which I was more separated from the hardware.

Another good reason to at least take a look at the list file now and then is that is refreshes the understanding of the PIC's opcodes and hardware structure: Maintaining touch with this aspect of the hardware is very important when writing code for an embedded processor as you really cannot (and should not!) stray too far if you want to write reasonably efficient code on a processor with (usually!) very limited resources.


* * *

The other point - divining compiler bugs. Most of the time, they are really *my* bugs, but on occasion, once the problem has been distilled to its essence (that is, you have written code with the fewest-possible number of lines that clearly demonstrates the issue) being able to step through code of minimal complexity better allows an understanding of the problem.

The most recent example for me was when, in some early versions of the 5.x compiler, simply using "sprintf" caused the interrupts to be turned off. The problem, isolated in a simple example, was passed to the CCS folks and fixed in the very next release.

* * *

Another thing that is not always appreciated is demonstrated in your example: Even code that might seem to do nothing on the first examination (e.g. compiler directives) can cause surprising amount of code to be generated - say, to zero at the RAM, set up hardware, etc. and if space is at a premium, a close examination of the list file might well reveal unnecessary "goings on" that, in a specific case, could be safely omitted.

I'm sure that there are many more instances/examples, but the above two are those that come to mind first.

CT

[PCM programmer]

The first thing to look at is your fuses. Instantaneous recognition of a bug: