No more list file?

[Don_Kirby]

I've noticed that after compiling with the native mode compiler, the list file, although generated, is empty. Is this intentional, or perhaps it's a byproduct of the native mode build process?

Also, the map file is not created in native mode.

-Don

[mikep]

I've noticed that after compiling with the native mode compiler, the list file, although generated, is empty. Is this intentional, or perhaps it's a byproduct of the native mode build process?

Also, the map file is not created in native mode.

If you use the --keep-files option you get the C source code which is the output from the ZBasic compiler. This is the equivalent of todays list file which shows the generated VM instructions in ZVM mode.

You also get the "incredibly useful and readable" SYM file from GCC which contains the symbol map of flash, EEPROM and RAM. If you look at it carefully you may find a few entries like this

Code: Select all

0000010e T zf_Hello
00000176 T zf_Main

It might be possible to do some post-processing on the SYM file and relate it back to the original source files although I don't know how helpful that is going to be.

[dkinzer]

It might be possible to do some post-processing on the SYM file and relate it back to the original source files.

I've been thinking about some ideas along those lines. However, the code generated by the GNU C compiler keeps some variables in registers and other local variables on the stack so they won't appear in the .sym file.

The information about code and data size that is shown at the conclusion of a compile operation is extracted from the .sym file. I might be useful or informative to study the .sym file to see what elements are contributing the the code and data sizes.

When looking at the .sym file, you'll notice some oddly large address values. The GNU compiler was originally designed for von Neumann (aka Princeton) architecture machines with a single linear address space. The AVR is a Harvard architecture machine with several disjoint address spaces (Flash, RAM, EEPROM). The GNU designers deal with this by treating these individual address spaces as part of a large unified address space with Flash beginning at 0, RAM beginning at 0x00800000 and EEPROM beginning at 0x008100000.