Linker (Stage 1) -- Specifying CODE and DATA memory locations |
If Shakespeare had been an assembly language programmer, he would have probably entitled this page
Variable, Variable -- where fore art thou, Variable
The original HVZ source file e1v0.s specified the memory location of its variables using the assembly language directive ORG. This directive we know is not SDS compatible. Instead we have to make use of the directive section.
A SDS linker uses the assembler directive section in the source file e1v2.s and an external specification file memorymap.spc to determine the memory location of its variables or "its memory map".
The same specification file can be used in all the experiments given in the "Companion", which makes life a lot easier. It is possible to generate a specification file to exactly locate the variables in the same memory positions as suggested by HVZ. However, the SDS software tools offers simpler ways to do the equivalent that it is not worth the effort!
There are two methods for memory specification.
File absmap.spc shows how to specify that the SDS linker place the various memory sections specified in e1v2.s at absolute locations in the memory of either the SDS simulator or of a real evaluation board.
/****************************************************************************** Use this spec file (absmap.spc) to link your own target programs. 0x1000 bytes each are reserved for "malloc" space and stack space; you can modify this if you wish. ******************************************************************************/ partition { overlay { region {} reset[addr=0]; /* reset vector */ region {} vects[addr=8]; /* other vectors */ region {} code[addr=0x1000,roundsize=4]; /* executable code */ region {} init; /* C++ init thunks */ region {} exit; /* C++ exit thunks */ region {} const[addr=0x2000,roundsize=4]; /* constant data */ region {} string[addr=0x2800,roundsize=4]; /* constant strings */ DATA = $; /* "data" download addr */ /* Copy of RAM 'data section' in ROM */ /* Used during processor initialization */ region {} datasection_inROM[addr=0x3000,roundsize=4]; region {} sds_startup[addr=0x3800]; /* Real Life Solution */ } romexample; } ROM; partition { overlay { region {} data[roundsize=4]; /* initialized on reset */ region {} ram[roundsize=4]; /* zeroed on reset */ region {} malloc[size=0x1000]; /* malloc space */ region {} stack[size=0x800]; /* stack */ STKTOP = $; /* SP reset value */ } example; } RAM[addr=0x4000];
Additional information about this specification file can be found in the "Full Companion".
The specification file essentially decides the memory map for the program. You should download the file absmap.spc into your working directory.
The first part of this specification file provides information about the ROM (fixed) code/constants location.
The second part of the specification file describes the position of the RAM (changeable) data locations in memory. The section stack and the defined constant STKTOP play an important role in the handling of subroutines, parameter passing and what are called in the "C" language -- automatic variables. All the memory locations associated with the RAM sections have unknown values. This is equivalent to what would happen in these memory locations if you had a real processor and "switched it on".
If you are interested in a discussion of the topic If the program code lives in unchangeable ROM how can I run different programs on my machine then follow this link.
IMPORTANT CHANGE TO THE SOURCE CODE |
As can be seen from the specification file above, the RAM memory that can be used to store changeable data values (such as the memory location pointed to by the label C in our code) is limited to the following range
Valid RAM memory locations from 0x4000 to 0x7FFF
The value we are using for the label C is set to 0x202200, far outside this range of available RAM memory. We must adjust the definition of C
C EQU 0x202200
to
C EQU 0x7200
With this modification we get file e1v3.s. This new source file must be assembled to give the object file e1v3.o.
With the "full SDS" kit, we could change the specification files to include RAM locations at 0x202200. However with the demo kit we are limited. For further explanation on the limitations imposed by the demo kit itself, and the requirements to support Laboratory 2 on the demo kit, follow this link.
The Leave-it-to SDS approach is the one to use once you are familiar with the SDS toolkit. It is discussed in the "Full Companion".
With the memory specification file in place, we are ready to move onto the final preparation phase of activating the SDS linker and downloading the code into simulator and running it.
![]() |
Last modified: July 17, 1996 01:16 PM by M. Smith.
Copyright -- M. R. Smith