# How is data allocated in an assembly language using the instruction set?

Consider the following excerpt of assembly code written for the Nios II embedded processor architecture:

    .section .data
.align 2
va:   .long 0x0
vb:   .long 0x11223344
vc:   .long 0x55667788


The following needs to be done:

• Allocate enough memory for all three variables
• Ensure the memory allocated is contiguous
• Translate instructions that use a variable's name into instructions that use the variable's address

I don't see how this can be done through the instruction set and was hoping for some insight on how the translation of the code above to the instruction set occurs.

• The linker does not do the first two items. – Ignacio Vazquez-Abrams Jan 21 '15 at 3:23
• @IgnacioVazquez-Abrams Would that be the assembler's job? – Phidias Jan 21 '15 at 3:23
• No. It's nobody's job. Assembler directives do not allocate memory, and there is no need for the memory to be contiguous regardless. – Ignacio Vazquez-Abrams Jan 21 '15 at 3:25
• @IgnacioVazquez-Abrams What do you mean by "assembler directives do not allocate memory"? I though the entire point of the code above was to allocate memory. Secondly, I was taught that memory is allocated contiguously. – Phidias Jan 21 '15 at 3:27
• That's not quite accurate. Those directives state that arbitrary bytes are to be placed at the current and following memory locations; the "allocation" happens because more bytes have been added to the assembly, not because those directives are being used. – Ignacio Vazquez-Abrams Jan 21 '15 at 3:35

This IS allocating the memory, and it has nothing to do with the instruction set. Assemblers are incredibly simple - the lines in the assembly file correspond almost exactly to the output binary, very little rearranging is done. The line ".long 0x0" just means 'give me four bytes right here and load them with the value 0x0'. The data is 'allocated' the same way as instructions. A line 'MOV R12, R11' just means 'give me four bytes right here and load them with the binary encoding for MOV R12, R11'. The data is contiguous for the same reason that your instructions are contiguous - you typed them on contiguous lines in the assembly file. The "va:" just means 'call the location of these four bytes "va"'. This is only used inside the assembler. Wherever you reference 'va' in the code, the assembler will insert the address of the four data bytes that 'va' refers to, which is just a number. Note that this may not be done by the assembler, this may be done by the linker. However, the string 'va' will never appear in the output binary.

Basically, assembly is almost a direct representation of the memory contents. Successive lines of assembly will end up in successive addresses. The only exception is when you change sections (.section). Any data explicitly located in the code will be contiguous if it is contiguous in the assembly file. Now, sections do screw around with this a little bit. It's possible that everything .data ends up in one part of memory and everything .text ends up in another part. However, the blocks will not be broken up - if they are contiguous in the assembly file, then they will be contiguous in the output.

Data like this is not "allocated" in quite the same way.

What happens is that, when you run a program, that program is loaded into memory. If that program contains 0x000000001122334455667788 somewhere, then those memory locations (12 in all unless I miscounted) will contain those values. When you compile your code, all NAMES are translated into memory addresses. From then on, no instructions are actually executed to make this happen - the memory is there, it is "allocated" (enough memory is allocated to hold the entire program, static variables like this and all), and because the entire program is placed in that memory, the variables are initialized.

Then, when you say "load variable va into register 'X'", the compiled code (which says "load address 0x84573412 into register 'X'") will get the right bit of data.

The names of the variables are only there for your convenience - otherwise you would have to allocate specific addresses yourself.