LSS Vs LST Files

Go To Last Post
10 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Could someone explain to me what the difference is between the *.LSS files and the *.LST files generated by the compiler? I see that the *.LSS file has a lot more comments from the original C code retained than the *.LST... I was just wondering what other differences there were & what purpose these files serve.

Also, as I was looking through the *.LSS file out of curiousity... noticing the pattern of C code line followed by assembly code... noticed that there were places every now & then where the assembly code was missing for some reason... Why would this be? It's valid code with a valid path, but for some reason corresponding assembly code seems to be missing.

Here's an example:

				if (Gov.StickEnabled && Rx.Valid[THR])
    3ccc:	80 91 b8 0c 	lds	r24, 0x0CB8
    3cd0:	88 23       	and	r24, r24
    3cd2:	51 f1       	breq	.+84     	; 0x3d28 
    3cd4:	80 91 5f 07 	lds	r24, 0x075F
    3cd8:	22 c0       	rjmp	.+68     	; 0x3d1e 
					{
						RunGovernor = TRUE;
					}
				}

Why is there no corresponding assembly code for "RunGovernor = TRUE"? Everywhere else in this file has one C code line followed by as many assembly lines as it takes to execute the line... except for a few places such as the one in the above example? Am I doing something wrong? Or am I just misinterpreting this file?

Thanks in advance for any help....

James

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Try your code with -O0
and then with -Os

The optimiser has probably removed some redundant code.

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

FWIF: *none* of them are generated by the compiler.

One is the assembly listing, and the other one is a disassembly listing
interspersed with source code snippets based on the debugging (line number)
information found in the final ELF file. The more sophisticated the
optimization process gets, the less useful the latter method will be,
because the basic assumption of the developer "one line of my C code somehow
matches N lines of assembly" will no longer apply.

Personally, I've found both of them not to be very useful. When I want to
get a picture of what assembly code the compiler generated, I tell the compiler
to just produce an assembly code file (suffix .s). This is done by replacing
the option -c by -S. For debugging, I just look at the C source and plain
disassembly for a particular function or part of a function, and try to follow
the code flow.

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If you use an Mfile generated Makefile then for fred.c the command "make fred.s" will generate the intermediate avr-as file that is passed from C compiler to assembler. I don't believe there's any easy way to achieve this within Studio's Makefile system

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Okay, thanks for the info on how to build the *.s file. I just wanted to look at the difference in code generated for a few slight variations in C code (i.e. to see which used less lines of code), but was overwhelmed by the diff file as hundreds (thousands?) of lines show up as changed due to slight line number shifts, etc... I finally gave up trying to find the actual difference after spending 15 minutes stepping thru each unrelated line diff. I've read many threads where people suggest viewing the assembly listing to get a better idea of what's going on... I guess I just haven't been able to find the usefulness in this yet... Thanks for the help though...

James

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well the .s are perfect for this kind of analysis. Just make the change and a decent diff tool will just spot a few lines of changed code

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

that's exactly what I did... but there were thousands of changed lines because of some slight numbering change that cascaded across the whole file...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I get it now..... after spending a long time staring at the *.s file & matching it against the *.c file..

If for some reason you wanted to modify the *.s file is there any way to have that version loaded into the AVR? I'm not needing to do this... just a curiosity.

Thanks,
James

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
If for some reason you wanted to modify the *.s file is there any way to have that version loaded into the AVR? I'm not needing to do this... just a curiosity.

Sure you can get the C compiler to generate a .s and then use that as the basis of an Asm source you build into the project after "hand optimising" it. Just don't forget to rename it from .s to .S though!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

okay, thanks!