AVR microcontrollers, who initilizes assembly `data` segment and what is the purpose to have this directive?

Question

I am new to assembly and microcontrollers and am trying to figure out how they work.

Now, I have read a lot how in assembly text and data segments are for storing program code and initial data for it. Everywhere people say[1,2,3] (if they say something) data segment stores values preinitialized for the program.

But in AVR, as I understand, data means SRAM. And to have it initialized you need to instruct your microcontroller to put some actual values there. Only having instructions under .dseg somewhere in your code does not magically put values into SRAM. The microcontroller has to reach the initializing instructions by its pace, following the program as usual: starts at 0x0 of the program segment, which is flash in AVR, and follows the instructions.

For instance, in this question the guy examines the code, produced by avr-gcc from C, and finds the routines initializing SRAM from flash, i.e. the program segment of the code.

If it is so, then what is the purpose of having .dseg?

Maybe it is for different assemlers or other tools (like avr-gcc in the referenced question, or avrstudio in the link 1), which would add necessary initialization instructions when processing the code with .dseg?

But if you work with "bare bones" the microcontroller starts from 0x0 (or somewhere else, according to the datasheet), this is where your program starts and there is nothing more to it, is there? (Of course, you put a vector table there for the interupts, if you want to handle them. And 0x0 is the address where RESET brings the microcontroller to. But it is not essential.)

PS

I thought .dseg/cseg could imply different address spaces: when you write an address in .dseg it is for SRAM, in .cseg -- for flash. But it seams addressing depends solely on instruction definition: ADD a1, a2 -- a# are registers, RJMP a -- a is flash (i.e. program), the SRAM is accessed indirectly via registers -- LDS R1, 0x0060.

Here again, can it be so, that the code under .dseg label like in 1:

 .DSEG                        ; Start data segment
 var1:  .BYTE 1               ; reserve 1 byte to var1

substitutes the indirect access to SRAM via registers? Probably this information should be searched within the documentation for the particular assembler at hand? Again, "bare bone" AVR instruction set doesn't provide any of such?

Answer 1

These segments are merely metadata - they have no meaning to the AVR CPU or to your code. They are instructions for the linker.

When you compile a C program with avr-gcc, it adds what is called a 'stub'. This code contains the interrupt vectors and reset vector. When the CPU starts up, it does not immediately execute your main method, instead it starts executing in the reset vector. The reset vector points to the startup code in the assember stub. This code initializes the stack pointer and the data segments. After this is finished, it jumps into your main method. If you write in pure assembly on bare metal, none of this is done for you unless you do it yourself.

The different segments are used primarily by the compiler, assembler, and linker to put the pieces of your program together intelligently and make sure each static variable has its own piece of address space. When the pieces are put together, address pointers and offsets are substituted into the program code in appropriate locations. After the program is compiled and linked, the segments no longer really exist in the output bin/hex file. Actually, none of the data segments end up in the hex file at all, only a copy of the initialization data for the initialized segment in a location that has been substituted into the startup code. For example, there is no difference from the microcontroller's standpoint between initialized and uninitialized data. However, the startup code would like all of the initialized data to be in one contiguous block so it can loop over it in one loop. Also, the startup code needs to know where the segment is located and how big it is. The linker combines the segments from the individual object files into one big segment, then it substitutes the addresses into the startup code after it has figured out where to put everything.

Also, there is a rather important difference between an AVR microcontroller and a standard PC: in the AVR, instructions and data have completely separate address spaces. This means that you need to know which address space you're referring to when you perform a memory access. The assembler may be able to help you with this if it is intelligent enough.

Answer 2

It doesn't matter what instructions are going to be used, the processor can get at all parts of SRAM and Flash memory. So ignore registers and instructions for now.

Initialised variables must be placed in SRAM, or they can't be used as variables, i.e. the program can't update their value.

Their initial values must be stored in flash, otherwise the initial values would be lost when power is removed.

The processor copies values from Flash to SRAM to initialise the values of all the initialised variables (they are normally stored next to each other in SRAM, and before the uninitialised variables in SRAM). The processor executes a loop which copies an area of Flash to SRAM. That loop is an early part of the program that initialises the program's state. In C, all that initialisation is run before main() is called.

The variables are stored in SRAM when the program is running, and the space is reserved by the assembler reading the program's .dseg directives containing .BYTE to reserve the space. Their initial values are stored in Flash, in a .CSEG, and the literal values are stored within the .CSEG using .DB or .DW.

If all of the initialised variables are next to each other, then the program needs to know the start address of the SRAM variables to initialise, and the start address of the Flash that contains their initial values. It also needs the length of the initialised variables area.

In almost-C it would be:

unsigned char* flash_values = flash_address_of_initial_values_of_initialised_variables;
unsigned char* SRAM_initialised_vars = SRAM_address_of_initialised_variables;
for (int i=0; i<length_of_initialised_variables; ++i) {
    SRAM_initialised_vars[i] = PROGRAM_MEMORY(flash_values[i]);
}

Edit: PROGRAM_MEMORY(...) retrieves the value from Flash memory.