#969 Initialization of global __xdata string needs optimization

[Dmitry Kharitonov]

Bad [or missing] optimization during initialization.

    char __xdata str[]="12334TEST";

translate to

;   main.c:3: char __xdata str[]="12334TEST";
    mov dptr,#_main_str_10000_2
    mov a,#0x31
    movx    @dptr,a
    mov dptr,#(_main_str_10000_2 + 0x0001)
    inc a
    movx    @dptr,a
    mov dptr,#(_main_str_10000_2 + 0x0002)
    inc a
    movx    @dptr,a
    mov dptr,#(_main_str_10000_2 + 0x0003)
    movx    @dptr,a
    mov dptr,#(_main_str_10000_2 + 0x0004)
    inc a
    movx    @dptr,a
    mov dptr,#(_main_str_10000_2 + 0x0005)
    mov a,#0x54
    movx    @dptr,a
    mov dptr,#(_main_str_10000_2 + 0x0006)
    swap    a
    movx    @dptr,a
    mov dptr,#(_main_str_10000_2 + 0x0007)
    mov a,#0x53
    movx    @dptr,a
    mov dptr,#(_main_str_10000_2 + 0x0008)
    inc a
    movx    @dptr,a
    mov dptr,#(_main_str_10000_2 + 0x0009)
    clr a
    movx    @dptr,a

It's strange why the "inc DPTR" is not used?
ACC is very well optimized.
It was also possible to place the line in the code segment, and copy it with something like strcpy.

[Dmitry Kharitonov]

SDCC : mcs51/z80/z180/r2k/r2ka/r3ka/sm83/tlcs90/ez80_z80/z80n/r800/ds390/pic16/pic14/TININative/ds400/hc08/s08/stm8/pdk13/pdk14/pdk15/mos6502/mos65c02 TD- 4.4.0 #14620 (MINGW64)

[Benedikt Freisen]

This sounds more like a feature request to me, because nothing here looks broken.
I have changed the title to reflect that.

[Maarten Brock]

Ticket moved from /p/sdcc/bugs/3754/

Can't be converted:

• _category: other

[Oleg Endo]

It's strange why the "inc DPTR" is not used?

Because it's emitting code to access individual memory locations at dptr + offset. And at each instruction it "forgets" the previous value of the address pointer.

Similar thing happens when initializing/accessing an array on the stack (using --stack-auto)

void main_01(void) 
{
  char str[]="1233";
}

produces:

_main_01:
    mov a,sp
    add a,#0x05
;   bug.c:61: char str[]="1233";
    mov sp,a
    add a,#0xfc
    mov r1,a
    mov @r1,#0x31
    mov a,r1
    inc a
    mov r0,a
    mov @r0,#0x32
    mov a,#0x02
    add a, r1
    mov r0,a
    mov @r0,#0x33
    mov a,#0x03
    add a, r1
    mov r0,a
    mov @r0,#0x33
    mov a,#0x04
    add a, r1
    mov r0,a
    mov @r0,#0x00
;   bug.c:62: }
    mov a,sp
    add a,#0xfb
    mov sp,a
    ret


should be ideally:
    mov a,sp
    add a,#0x05
    mov sp,a

    mov r1,a
    mov @r1,#0x31
    inc r1
    mov @r1,#0x32
    inc r1
    mov @r1,#0x33
    inc r1
    mov @r1,#0x34
   ...

I think this kind of case could be handled by the register value tracking, if it was extended to be a bit more sophisticated.