CC loop assignment oddity

The DDE compiler, v5.82 is the one that’s currently installed here.

Here’s a snippet of some code:

    // 2, clear the relevant bitmap
    // for ( int offset = 0; offset < ( 64 * 64 ); offset++ )
    // {
    //    texture[0][offset] = 0; // black
    // }
    // The above translates to:
    //      MOV      a1,#0                   ; offset
    //      MOV      a3,#0                   ; colour zero
    //   |L000d44.J124.main|
    //      LDR      a2,[sp]                 ; load address of bitmap
    //      STRB     a3,[a2,a1]              ; write colour to address + offset
    //      ADD      a1,a1,#1                ; increment offset
    //      CMP      a1,#&1000               ; done? (&1000 = 4096 = 64 * 64)
    //      BLT      |L000d44.J124.main|     ; loop if not
    // Not sure why we load the base address all the time, but still, it's
    // 4096 byte writes (and word loads!). We can do better.
    __asm
    {
       // Better being 1024 word writes, but since we're writing eight words
       // at a time, we only need to loop through this 128 times.
       MOV   R0, texture[0]     // start
       ADD   R1, R0, #4096      // end
       MOV   R2, 0              // set up all of the registers
       MOV   R3, 0
       MOV   R4, 0
       MOV   R5, 0
       MOV   R6, 0
       MOV   R7, 0
       MOV   R8, 0
       MOV   R9, 0
     loop:
       STMIA R0!, {R2-R9}
       CMP   R0, R1
       BLT   loop
    }

The assembler in the comments is a translation of the code that has been commented out.

Why has the compiler decided to put LDR a2,[sp] within the loop? It isn’t written to or corrupted, so it could have been placed outside of the loop to save reloading it four thousand times unnecessarily.

Assuming texture is something like char *texture[4], it’ll probably be reloading texture[0] all the time because the compiler isn’t certain that the STRB’s aren’t modifying the 4 bytes of RAM that texture[0] occupies.

Manually caching the pointer in a local variable outside of the loop is one common way of avoiding the compiler constantly reloading it:

char *p = texture[0];
for(int offset=0;offset<64*64;offset++) { p[offset] = 0; }

Making the local pointer const can also help, e.g. char * const p = texture[0];

You can also use the C99 restrict qualifier, which AIUI basically means “the memory accessed via this pointer is completely independent of all other memory”. I.e. writing to memory via the restricted pointer won’t alter any value that could be read via any other pointer/variable, and writing to memory via any other pointer won’t alter any value that you can read via the restricted pointer. But whether restrict actually works or not seems to be very hit-or-miss; with CC 5.89, the following still reloads texture[0] for every loop iteration:

void test(char * restrict * restrict texture)
{
  for(int offset=0;offset<64*64;offset++)
    texture[0][offset] = 0;
}

the compiler isn’t certain that the STRB’s aren’t modifying the 4 bytes of RAM that texture⁰ occupies.

Can it not see texture[0][offset], that the base address (texture⁰) doesn’t change at all?
It compiles to literally five instructions, which is why it seemed odd to me to keep on reloading.

Manually caching the pointer in a local variable outside of the loop

That makes sense.
But since it’s a contiguous array of bytes all with the same value, the STM code that I created is much more direct. ;)

Or memset()…