#870 inc DPTR for consecutive addresses

[Konstantin Kim]

Is it feasible to replace DPTR loading by simple increment in cases like following one:

    static void gpif_init_flowstates(void)
    {
            /* Clear all flowstate registers, we don't use this functionality. */
            FLOWSTATE = 0;
            FLOWLOGIC = 0;
            FLOWEQ0CTL = 0;
            FLOWEQ1CTL = 0;
            FLOWHOLDOFF = 0;
            FLOWSTB = 0;
            FLOWSTBEDGE = 0;
            FLOWSTBHPERIOD = 0;
    }

actually produces:

_gpif_init_flowstates:
    mov dptr,#0xE6C6
    clr a
    movx    @dptr,a
    mov dptr,#0xE6C7
    movx    @dptr,a
    mov dptr,#0xE6C8
...
}

http://sigrok.org/gitweb/?p=sigrok-firmware-fx2lafw.git;a=blob;f=gpif-acquisition.c

[Benedikt Freisen]

This looks like something a peephole optimizer could do, provided that no flags get in the way.

[Konstantin Kim]

Sounds like good candidate for reverse peephole rule applying (starting from last matching case).
The peephole way is still a short term solution.

Long-term is Generalized constant propagation

[Maarten Brock]

This could be handled by the register tracker in src/mcs51/rtrack.c. Unfortunately it currently does not support tracking the DPTR.

[Konstantin Kim]

Are you sure?

little test:

__asm
    mov     dptr,#0xE6C6    //_FLOWSTATE
    clr     a
    movx    @dptr,a
    mov     dptr,#0xE6C7    //_FLOWLOGIC
    movx    @dptr,a
    mov     dptr,#0xE6C8    //_FLOWEQ0CTL
    movx    @dptr,a
__endasm;

shows that it have perfect DPTR tracking with "--fverbose-asm --peep-asm"

000000 90 E6 C6         [24]  122   mov dptr,#0xE6C6
  000003 E4               [12]  123     clr a
  000004 F0               [24]  124     movx    @dptr,a
                                125 ;   genFromRTrack replaced  mov dptr,#0xE6C7
  000005 A3               [24]  126     inc dptr
  000006 F0               [24]  127     movx    @dptr,a
                                128 ;   genFromRTrack replaced  mov dptr,#0xE6C8
  000007 A3               [24]  129     inc dptr
  000008 F0               [24]  130     movx    @dptr,a

Funny that without "--fverbose-asm" it have no effect ;)

[Maarten Brock]

O wow, I was not (no longer) aware.

But that is a mysterious bug, to only track DPTR when --fverbose-asm is used.

[Maarten Brock]

Should be fixed in [r13897].

[Konstantin Kim]

mean time "fverbose-asm" issue seems solved.
at the same time, the original question is still open
rtrack not affects c-code ;(

[Maarten Brock]

rtrack currently cannot track symbols.
It will never be able to track global symbols as these are not placed yet by the linker at this stage.
In this case however it could try to get the absolute address of these symbols.
Also, if the symbols were on stack, it could try to find the relative address of the symbols.

[Konstantin Kim]

I found working workaround. Way is to avoid "__at" keyword itself:

#define XSFR(addr)  *((__xdata char*)(addr))
#define FLOWSTATE  ( XSFR( 0xE6C6 ) )
#define FLOWLOGIC  ( XSFR( 0xE6C7 ) )
#define FLOWEQ0CTL ( XSFR( 0xE6C8 ) )

But it may provoke mess as per it rely on preprocessor. I believe it is better anyway to treat symbols in rtrack (if is possible).

[Jim Granville]

This says open, but also says

status: open --> closed-fixed Should be fixed in [r13897].

Which Win64 SDCC release should this appear in ?

Having INC DPTR for consecutive addresses would be great.
More 8051's are being released with XDATA SFRs.

[Philipp Klaus Krause]

That commit [r13897] happened on the day after the 4.2.0 release. Then the ticket was closed, but it was reopened a few days later. Possibly the implemented solution does not yet apply to all scenarios?

[Maarten Brock]

The reason I reopened this ticket is that rtrack could still do better as pointed out by Konstantin and as I described in

In this case however it could try to get the absolute address of these symbols.
Also, if the symbols were on stack, it could try to find the relative address of the symbols.

It currently only handles literals.

The bug that it only worked when -fverbose-asm was used was fixed.

[Oleg Endo]

rtrack currently cannot track symbols.
It will never be able to track global symbols as these are not placed yet by the linker at this stage.

It doesn't necessarily have to get the absolute addresses.

For example

extern __xdata char some_data[];

int test_00 (void)
{
  return some_data[1] + some_data[2];
}

produces:
    mov dptr,#(_some_data + 0x0001)   (*1)
    movx    a,@dptr
    mov r7,a
    mov r6,#0x00
    mov dptr,#(_some_data + 0x0002)   (*2)
    movx    a,@dptr
    mov r4,#0x00

Here rtrack could replace the dptr load at (*2) with an inc dptr ... if it tracked symbol + offset as well. Of course it would make the tracking code more complex.

https://sourceforge.net/p/sdcc/feature-requests/969/ is basically the same thing as this here.