#2132 [MCS51] Certain variables overlap in the XRAM

closed-wont-fix
Maarten Brock
None
MCS51
5
2014-08-16
2013-02-13
Molnár Károly
No

Example:

__xdata __at (0x0000) unsigned char bf0[256];
__xdata unsigned char var0;
__xdata unsigned char var1;
__xdata unsigned char var2;
__xdata unsigned char var3;

void main(void)
{
bf0[0] = '0';
var0 = '1';
var1 = '2';
var2 = '3';
var3 = '4';
}

Excerpt from the disassembled list (mcs51-disasm.pl):

_main:

0x0064: 90 00 00 mov DPTR, #0x0000 ; DPTR = 0x0000
0x0067: 74 30 mov A, #0x30 ; ACC = 0x30 {'0'}
0x0069: F0 movx @DPTR, A ; XRAM[DPTR] = ACC
0x006A: 90 00 00 mov DPTR, #0x0000 ; DPTR = 0x0000
0x006D: 74 31 mov A, #0x31 ; ACC = 0x31 {'1'}
0x006F: F0 movx @DPTR, A ; XRAM[DPTR] = ACC
0x0070: 90 00 01 mov DPTR, #0x0001 ; DPTR = 0x0001
0x0073: 74 32 mov A, #0x32 ; ACC = 0x32 {'2'}
0x0075: F0 movx @DPTR, A ; XRAM[DPTR] = ACC
0x0076: 90 00 02 mov DPTR, #0x0002 ; DPTR = 0x0002
0x0079: 74 33 mov A, #0x33 ; ACC = 0x33 {'3'}
0x007B: F0 movx @DPTR, A ; XRAM[DPTR] = ACC
0x007C: 90 00 03 mov DPTR, #0x0003 ; DPTR = 0x0003
0x007F: 74 34 mov A, #0x34 ; ACC = 0x34 {'4'}
0x0081: F0 movx @DPTR, A ; XRAM[DPTR] = ACC
0x0082: 22 ret ; PCH = [SP--], PCL = [SP--]

I have included a simple example program.

SDCC : mcs51/gbz80/z80/z180/r2k/r3ka/ds390/pic16/pic14/TININative/ds400/hc08/s08 3.2.1 #8384 (Jan 13 2013) (Linux)

Károly

Discussion

    • Category: --> MCS51
    • Group: --> fixed
     
  • Maarten Brock
    Maarten Brock
    2013-12-25

    I don't know why Philipp set the group to fixed. It's not. But without feature request and discussion this won't be fixed either. It is documented behavior.

    Historically variables declared with __at() were not allocated but just got an EQU in the assembly. This also meant they could not be initialized. This way they could be used to overlay with other variables. This behavior was kept for backward compatibility.

    Later I added that when an absolute variable does have an initializer it is allocated and thus should not overlap other variables.

    This is documented in the manual 3.7 Absolute Addressing.

    Maarten

     
    Last edit: Maarten Brock 2013-12-25
  • Maarten Brock
    Maarten Brock
    2013-12-25

    • status: open --> closed-wont-fix
    • assigned_to: Maarten Brock
     
  • I guess the group was just some colletaral damage from getting the category information from the old into the new bug tracker. AFAIK, we don't use the group field, and anything in there is just side-effects from the Sourceforge tracker transition.

    AFAIR, during the early days of the new tracker, setting the category had the side-effect of setting the group to the default value, which was "fixed".

    Philipp

     
  •