It maybe be worth the trouble to elaborate on Erik's rules a little bit. The reasoning behind them is that at the assembly language level, each of the different address spaces needs a different sequence of code to access it. As an example, consider this simple C fragment:

int i;
i = 520;

If 'i' is in the DATA space, a hypothetical compiler might generate something like this:

MOV   i,#2
MOV   i+1,#8

If 'i' is in the IDATA space, the same compiler might generate this:

MOV   R0,#i
MOV   @R0,#2
INC   R0
MOV   @R0,#8

Finally, if 'i' is in the XDATA space, the compiler needs to do this:

MOV   DPTR,#i
MOV   A,#2
MOVX  @DPTR,A
INC   DPTR
MOV   A,#8
MOVX  @DPTR,A

From these examples, it's easy to see that DATA variables are accessed the fastest, followed by those in the IDATA space, followed by those in the XDATA space. These facts form the basis for Erik's rules.


The large memory model puts all variables in XDATA space by default, which is exactly what you don't want if you're worried about execution speed and/or code size.


DATA variables are the only ones the 8051 can access directly, so it only makes sense to put variables that you plan to access directly there.


Variables in IDATA space are naturally accessed indirectly, so IDATA is the natural place to put variables that you plan to access through pointers. (You could just as well put indirectly accessed variables in the DATA space, except that you will probably want to conserve it for directly addressed variables due to its limited size.)


When all else fails, use XDATA where it will hurt you the least.

One other point, of course, is that larger data structures won't fit in the relatively small DATA and IDATA areas. If you need a 500-byte buffer, it has to go in XDATA.

-- Russ