AVR Freaks

Well, actually, since CV only compiles (with current version) from within the IDE, it is right there in front of you after each build:

The .HEX file for the above is reported as 43KB, and the .ROM (another output representation) is 99KB.

I don't entirely get the point, or the question. First 12kbyte; then 26KB. Are these different .HEX files, and the size on disk of each? As roundly discussed above, in general from the same tool (CV in this case) the larger the program the larger the file on disk. And yes, you could create an app with pieces located all over flash.

What does the build summary tell you?

What are "AVR code density techniques"? CV, as with other compilers, will have different options. In short, you build for "Size" or Speed". The savings in space with "Size" will depend almost entirely on the app and how you write >>your<< code.

The same thing really applies in general: >>You<< need to become familiar with the AVR, and the code generation model of your compiler brand, and write the C code so that the compiler can generate efficient sequences. I can write a 10-line program doing a few float computations and output the results using the biggest printf() and virtually fill up a Mega88. Or I can write a quite detailed app and have it fit quite nicely, thank you.

What I do with CV is to scan the composite .LST file during development and look for obviously bloated sequences--many, many machine language instructions for a single C line. Often you can help the compiler with a well-placed cast, or re-do the sequence so that you do not force the compiler to go through all the shenanigans.

Have you looked at the results panes, and the .LST file?

In the case of CV clearly the .map file is not of much use in determining this (Lee already told you that the report at the end of the build in the IDE is where you'll actually find all you are looking for). In other compilers that are linking compilers the .map file is a more powerful tool as each .c file is compiled in complete isolation and then another tool (the linker) "glues" all the bits together and one of it's outputs is a .map file that tells you what went where and how big it was. But CV doesn't work like this and its .map file is for a different purpose.

Bottom line: ignore then .map file comment

The big picture is that the guys that invent these computers also invent the instructions and opcodes... and they are all different... in a few cases, one could burn the program designed and written for an avr mega16 into a mega32 or 128 perhaps, but it still might not run if something very simple was different and not accounted for... location of stack, location of certain registers in the memory map... I met a few computer science guys that grasped the concept of 'hi level language: readable by humans. Compiler converts to machine language: readable by computer' Then he assumed that the output of the 68000 compiler would just run on the VAX. Here's an analogy... computer instructions are to the computer they run on as human languages are to the country in which they are spoken. So Atmel procesors speak 'AVR instructions' and Microchip cpus speak 'PIC instructions' and Intel cpus speak 'Pentium instructions'. That stretching it too much? And as to the 'code density' concept, that has to do with the 'cleverness' and 'elegance' of the instruction set. Certain classic computers have been respected because they were easy to program... had just the right mix of instructions and registers and memory addressing modes.... PDP11, 68000, 6809... other cpus are regarded as hard to program because of no instruction to do certain common operations, not enough registers with certain often used modes. That chart is Atmel bragging that the AVR takes fewer instructions to express some algorithm than all those other cpus.

In properly written code the .h files will not generate ANY code so there #include'sion will have no effect on the final binary size - they are just a way of an author of some "lib" function providing you with the documentation of how the interface to their function works. It's when you include the lib itself during the linking phase that the code that the .h file refers to gets "pulled in" (if properly written only the used parts of a lib will be pulled in). Some of the code you pull in isn't as the result of an explicit function invocation but is an implicit side effect of using some operator (like +,-,*,/ with float variables)

Of course CV is not a linking compiler in this sense but it does have a clever mechanism whereby it only builds in selected parts of some .c code that effectively constitutes its "run time library" (aka "libc" and "libm")