next up previous contents index
Next: 3.4.2 Z80/Z180 Storage Class Up: 3.4 Storage Class Language Previous: 3.4 Storage Class Language   Contents   Index

Subsections


3.4.1 MCS51/DS390 Storage Class Language Extensions

In addition to the ANSI storage classes SDCC allows the following MCS51 specific storage classes:


3.4.1.1 data / near

This is the default storage class for the Small Memory model (data and near can be used synonymously). Variables declared with this storage class will be allocated in the directly addressable portion of the internal RAM of a 8051, e.g.:

data unsigned char test_data;
Writing 0x01 to this variable generates the assembly code:

75*00 01   mov  _test_data,#0x01


3.4.1.2 xdata / far

Variables declared with this storage class will be placed in the external RAM. This is the default storage class for the Large Memory model, e.g.:

xdata unsigned char test_xdata;
Writing 0x01 to this variable generates the assembly code:

90s00r00   mov  dptr,#_test_xdata  
74 01      mov  a,#0x01  
F0         movx @dptr,a


3.4.1.3 idata

Variables declared with this storage class will be allocated into the indirectly addressable portion of the internal ram of a 8051, e.g.:

idata unsigned char test_idata;
Writing 0x01 to this variable generates the assembly code:

78r00       mov  r0,#_test_idata 
76 01       mov  @r0,#0x01
Please note, the first 128 byte of idata physically access the same RAM as the data memory. The original 8051 had 128 byte idata memory, nowadays most devices have 256 byte idata memory. The stack is located in idata memory.


3.4.1.4 pdata

Paged xdata access is currently not as straightforward as using the other addressing modes of a 8051. The following example writes 0x01 to the address pointed to. Please note, pdata access physically accesses xdata memory. The high byte of the address is determined by port P2 (or in case of some 8051 variants by a separate Special Function Register, see section 4.1).

pdata unsigned char *test_pdata_ptr; 
 
void main()  
{  
    test_pdata_ptr = (pdata *)0xfe;  
    *test_pdata_ptr = 1;  
}
Generates the assembly code:

75*01 FE   mov  _test_pdata_ptr,#0xFE 
78 FE      mov  r0,#0xFE  
74 01      mov  a,#0x01 
F2         movx @r0,a
Be extremely carefull if you use pdata together with the --xstack option.


3.4.1.5 code

'Variables' declared with this storage class will be placed in the code memory:

code unsigned char test_code;
Read access to this variable generates the assembly code:

90s00r6F   mov dptr,#_test_code 
E4         clr a 
93         movc a,@a+dptr
char indexed arrays of characters in code memory can be accessed efficiently:

code char test_array[] = {'c','h','e','a','p'};
Read access to this array using an 8-bit unsigned index generates the assembly code:

E5*00      mov a,_index

90s00r41   mov dptr,#_test_array

93         movc a,@a+dptr


3.4.1.6 bit

This is a data-type and a storage class specifier. When a variable is declared as a bit, it is allocated into the bit addressable memory of 8051, e.g.:

bit test_bit;
Writing 1 to this variable generates the assembly code:

D2*00       setb _test_bit
The bit addressable memory consists of 128 bits which are located from 0x20 to 0x2f in data memory.

Apart from this 8051 specific storage class most architectures support ANSI-C bitfields 3.1.


3.4.1.7 sfr / sbit

Like the bit keyword, sfr / sbit signifies both a data-type and storage class, they are used to describe the special function registers and special bit variables of a 8051, eg:

sfr at 0x80 P0;  /* special function register P0 at location 0x80 */ 
sbit at 0xd7 CY; /* CY (Carry Flag) */
Special function registers which are located on an address dividable by 8 are bit-addressable, an sbit addresses a specific bit within these sfr.


3.4.1.8 Pointers to MCS51/DS390 specific memory spaces

SDCC allows (via language extensions) pointers to explicitly point to any of the memory spaces of the 8051. In addition to the explicit pointers, the compiler uses (by default) generic pointers which can be used to point to any of the memory spaces.

Pointer declaration examples:

/* pointer physically in internal ram pointing to object in external ram */  
xdata unsigned char * data p; 
 
/* pointer physically in external ram pointing to object in internal ram */  
data unsigned char * xdata p; 
 
/* pointer physically in code rom pointing to data in xdata space */  
xdata unsigned char * code p; 
 
/* pointer physically in code space pointing to data in code space */  
code unsigned char * code p; 
 
/* the following is a generic pointer physically located in xdata space */ 
char * xdata p;
Well you get the idea.

All unqualified pointers are treated as 3-byte (4-byte for the ds390) generic pointers.

The highest order byte of the generic pointers contains the data space information. Assembler support routines are called whenever data is stored or retrieved using generic pointers. These are useful for developing reusable library routines. Explicitly specifying the pointer type will generate the most efficient code.


3.4.1.9 Notes on MCS51 memory layout

The 8051 family of microcontrollers have a minimum of 128 bytes of internal RAM memory which is structured as follows:

- Bytes 00-1F - 32 bytes to hold up to 4 banks of the registers R0 to R7,
- Bytes 20-2F - 16 bytes to hold 128 bit variables and,
- Bytes 30-7F - 80 bytes for general purpose use.

Additionally some members of the MCS51 family may have up to 128 bytes of additional, indirectly addressable, internal RAM memory (idata). Furthermore, some chips may have some built in external memory (xdata) which should not be confused with the internal, directly addressable RAM memory (data). Sometimes this built in xdata memory has to be activated before using it (you can probably find this information on the datasheet of the microcontroller your are using, see also section 3.11 Startup-Code).

Normally SDCC will only use the first bank of registers (register bank 0), but it is possible to specify that other banks of registers should be used in interrupt routines. By default, the compiler will place the stack after the last byte of allocated memory for variables. For example, if the first 2 banks of registers are used, and only four bytes are used for data variables, it will position the base of the internal stack at address 20 (0x14). This implies that as the stack grows, it will use up the remaining register banks, and the 16 bytes used by the 128 bit variables, and 80 bytes for general purpose use. If any bit variables are used, the data variables will be placed after the byte holding the last bit variable. For example, if register banks 0 and 1 are used, and there are 9 bit variables (two bytes used), data variables will be placed starting at address 0x22. You can also use --data-loc to specify the start address of the data and --iram-size to specify the size of the total internal RAM (data+idata).

By default the 8051 linker will place the stack after the last byte of data variables. Option --stack-loc allows you to specify the start of the stack, i.e. you could start it after any data in the general purpose area. If your microcontroller has additional indirectly addressable internal RAM (idata) you can place the stack on it. You may also need to use --xdata-loc to set the start address of the external RAM (xdata) and --xram-size to specify its size. Same goes for the code memory, using --code-loc and --code-size. If in doubt, don't specify any options and see if the resulting memory layout is appropriate, then you can adjust it.

The linker generates two files with memory allocation information. The first, with extension .map shows all the variables and segments. The second with extension .mem shows the final memory layout. The linker will complain either if memory segments overlap, there is not enough memory, or there is not enough space for stack. If you get any linking warnings and/or errors related to stack or segments allocation, take a look at either the .map or .mem files to find out what the problem is. The .mem file may even suggest a solution to the problem.


next up previous contents index
Next: 3.4.2 Z80/Z180 Storage Class Up: 3.4 Storage Class Language Previous: 3.4 Storage Class Language   Contents   Index
Bernhard Held 2004-02-21