The 68HC11 and 68HC12 micro-controllers support a direct addressing mode that gives access to the lower 256 bytes of the address space. This addressing mode is sometimes called page0 addressing mode. It is optimized to produce short instructions in most cases: it only requires one byte to represent the address instead of two bytes for the extended address mode. The page0 addressing mode as well as the extended addressing mode are used in general to access global variables. The discussion explains how you can tune your applications to use this direct addressing mode.

Let's suppose you have some global variable and a function that uses it. For example:

short counter;

void increment()
{
counter++;
}


the compiler will generate instructions that use the extended addressing mode (2 bytes). After a final link, if we put the counter variable at address 0x3000, the program will look like this (8 bytes):

68HC11
increment:
f000: fe 30 00 ldx counter
f003: 08 inx
f004: ff 30 00 stx counter
f007: 39 rts


Now if we put the counter variable in page0, it would be good that a direct addressing mode be used. The compiler and linker can handle this case. We just have to tell it! For this, it is possible to specify a section in which the compiler must put the global variables. The section will be mapped in memory by the linker. A special section called .page0 exists to represent the first 256 bytes (page 0). You may define your own sections and map them in memory as you wish (but this is another story!). You will specify that a variable goes in a particular section with a GCC __attribute__ on the variable:

short counter __attribute__((section(".page0")));


In the generated assembly file, your variable will have the following definition:

.section .page0,"aw",@progbits
.type counter, @object
.size counter, 2
counter:
.zero 2


This assembly definition defines a global variable counter which occupies 2 bytes and which is located somewhere in the .page0 section. We don't know the variable address: it will be defined by the linker during the final link. If you re-compile your program you will also notice that nothing else has changed. The compiler seems to still generate the extended addressing mode. This is right!

So, does the __attribute__ section really helps?

If you are using the 68HC11, yes it does!!! You are in fact lucky that the linker implements something called linker relaxation. At the link time, the linker will notice that the counter variable is in page0. It will then change the ldx and stx instructions to use the direct addressing mode, thus reducing you program by one byte for each instructions.

If you are using the 68HC12, it will not help. Sad but true. The linker relaxation is just not implemented. We must find and need something else!!!

So, we have not solved our problem or at least partially. Could we do better? Let's see.

The GCC compiler implements a specific attribute that tells it to put the variable in the good .page0 section but also that it can use the direct addressing mode to access the variable. You will declare your variable as follows:

short counter __attribute__((page0));


This time the generated code will be different and it will use the direct addressing mode. This is so for 68HC11 as well as 68HC12 (and of course the 68HCS12 derivatives). The final code for 68HC11 will not change but 68HC12 it will be optimized into:

68HC11
00008031 :
8031: dd 00 ldy *counter
8033: 1a 41 leax 1,Y
8035: 5e 00 stx *counter
8037: 3d rts

So, now it works and we could optimize our global variable addressing modes.

Guess what, the compiler can generate other optimized instructions when direct address mode is available. It can optimize the generation of bset and bclr instructions as well. Lets consider the following piece of code:

unsigned char mask __attribute__((page0));

void flag_it()
{
mask |= 0x10;
}

Because this is a global variable that is only one byte wide, the compiler can use the bset instruction to set the flag. Otherwise, the compiler is forced to load the value in a register, perform the bitwise or, and save back the value in memory.

68HC12
00008038 :
8038: 4c 02 10 bset *mask
803b: 3d rts

For 68HC12, putting some global variables in page0 has however one caveat. You have to map the IO registers somewhere else. By default they are mapped at address 0 and they would conflict with your global variables.

For 68HC11, we are lucky because we can manage so that both IO registers and some global variables can be accessed from page 0. For this, you must just be careful when you define the memory layout of your board. Basically, you must define the page0 memory bank in such a way that it does not overlap the IO registers. For example:

MEMORY
{
page0 (rwx) : ORIGIN = 0x040, LENGTH = 0x100 - 0x40
}

Now we know how to optimize. Fine. But which global variable should I put in page0 you are asking? Let's see how to do it.

Before, let's have a look at ELF files. The ELF file is the binary format in which the assembler stores the result of the assembled program: the code, data, symbols, debugging information, and,... relocations! What is a relocation you are asking! The relocation is a kind of marker that tells the linker to adjust (fix) the code so that it uses the final address for symbols. If you take an object file produced by the assembler and dump the relocation section, you will see lines that looks like:

m6811-elf-objdump -r file.o
...
00001043 R_M68HC11_8 _.frame
...
00001de1 R_M68HC11_16 _io_ports
...
00002b31 R_M68HC11_16 time_usec
...

The above relocation extract tells us that the symbol _.frame requires a 1-byte wide relocation in the code section at offset 0x1043. The R_M68HC11_8 represents the relocation type. This one corresponds to a page0 relocation. If the _.frame variable is put at address 0x10, the linker will adjust the code at relative position 0x1043 and add 0x10 there. The instruction that uses this variable will use the good address. The extract also shows us two relocations for global variable time_usec and _io_ports. The relocation is a R_M68HC11_16 which indicates that a 16-bit address is required and must be adjusted.

How can this relocation information help us?

Well, its easy. The relocation tells us exactly what we want: how often is a variable used. If we can count the R_M68HC11_16 relocation for each symbol, sort them by use count, we know which variable we can optimize. Let's do it.

The perl program attached to this article parses the output produced by m68hc11-elf-objdump -r, identify the symbols, count them and sort them.

When you run this script as follows:

m6811-elf-objdump -r file.o | perl page0-guess.pl

it produces an output similar to:

_.frame 1040
_.d1 377
_.d2 279
_.xy 147
_.d3 139
_.z 121
_.d4 114
_.tmp 102
_io_ports 94
time_usec 28
value 25
current 22
__assert 19
total_adjtime 18
panel_putchar 16
timer_create 16
time_sec 15
put_str 15
put_char 12
fast_timers 12
_timer_current_overflow 11


Of course, this list includes some global variables but also some functions
(__assert, panel_putchar, ...). But the following are variables that can be put in the page0:

_.frame _.d1 _.d2 _.xy _.d3 _.z _.d4 _.tmp _io_ports
time_usec value current time_sec fast_timers _timer_current_overflow


By knowing the usage of your global variables you can optimize their access by turning them to direct address modes if you wish. You can analyze whether mapping your IO registers in page0 is good for you or not. You may also use the attach script to identify the functions which are most often used and organize them in memory (put them in non-banked memory if you can) and so on.

Well, the ball is yours now!!!

Stephane