Next: 3.6 Parameters & Local Up: 3. Using SDCC Previous: 3.4.3 HC08 Storage Class Contents Index

#
3.5 Absolute Addressing

Data items can be assigned an absolute address with the at <address> keyword, in addition to a storage class, e.g.:

> `xdata at 0x7ffe unsigned int chksum;`

or, better conforming to ISO/IEC 9899 C:

> `__xdata __at (0x7ffe) unsigned int chksum;`

In the above example the variable chksum will be located at 0x7ffe and 0x7fff of the external ram. The compiler does not reserve any space for variables declared in this way (they are implemented with an equate in the assembler). Thus it is left to the programmer to make sure there are no overlaps with other variables that are declared without the absolute address. The assembler listing file (.lst) and the linker output files (.rst) and (.map) are good places to look for such overlaps.

If however you provide an initializer actual memory allocation will take place and overlaps will be detected by the linker. E.g.:

> `__code __at (0x7ff0) char Id[5] = ''SDCC'';`

In the above example the variable Id will be located from 0x7ff0 to 0x7ff4 in code memory.

In case of memory mapped I/O devices the keyword volatile has to be used to tell the compiler that accesses might not be removed:

> `volatile __xdata __at (0x8000) unsigned char PORTA_8255;`

For some architectures (mcs51) array accesses are more efficient if an (xdata/far) array`` starts at a block (256 byte) boundary (section 3.12.1 has an example).
Absolute addresses can be specified for variables in all storage classes, e.g.:

> `__bit __at (0x02) bvar;`

The above example will allocate the variable at offset 0x02 in the bit-addressable space. There is no real advantage to assigning absolute addresses to variables in this manner, unless you want strict control over all the variables allocated. One possible use would be to write hardware portable code. For example, if you have a routine that uses one or more of the microcontroller I/O pins, and such pins are different for two different hardwares, you can declare the I/O pins in your routine using:

> `extern volatile __bit MOSI; /* master out, slave in */`
> `extern volatile __bit MISO; /* master in, slave out */`
> `extern volatile __bit MCLK; /* master clock */`
> `/* Input and Output of a byte on a 3-wire serial bus.`
> `If needed adapt polarity of clock, polarity of data and bit order`
> `*/`
> `unsigned char spi_io(unsigned char out_byte)`
> `{`
> `unsigned char i=8;`
> `do {`
> `MOSI = out_byte & 0x80;`
> `out_byte <<= 1;`
> `MCLK = 1;`
> `/* _asm nop _endasm; */ /* for slow peripherals */`
> `if(MISO)`
> `out_byte += 1;`
> `MCLK = 0;`
> `} while(-i);`
> `return out_byte;`
> `}`

Then, someplace in the code for the first hardware you would use

> `__bit __at (0x80) MOSI; /* I/O port 0, bit 0 */`
> `__bit __at (0x81) MISO; /* I/O port 0, bit 1 */`
> `__bit __at (0x82) MCLK; /* I/O port 0, bit 2 */`

Similarly, for the second hardware you would use

> `__bit __at (0x83) MOSI; /* I/O port 0, bit 3 */`
> `__bit __at (0x91) MISO; /* I/O port 1, bit 1 */`
> `__bit __at (0x92) MCLK; /* I/O port 1, bit 2 */`

and you can use the same hardware dependent routine without changes, as for example in a library. This is somehow similar to sbit, but only one absolute address has to be specified in the whole project.

Next: 3.6 Parameters & Local Up: 3. Using SDCC Previous: 3.4.3 HC08 Storage Class Contents Index