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.


The ORG-equivalent or absolute approach

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];

The specification file


System Memory Map

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.


Looks like an error but isn't

It may look like the ram memory section has an address (0x1000) that overlaps with the const section since these two sections appear to have the same value. In fact these addresses are relative to the starts of the RAM and ROM memory locations respectively. Thus the ram section starts at location 0x4000 + 0x1000 or 0x5000 and not at location 0x1000.


The "Leave-it-to SDS approach

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".


Ready to generate the executable file

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 01, 1996 05:29 PM by M. Smith.
Copyright -- M. R. Smith