AVR Freaks

Ok,

Now i am convinced that the GCC optimiser for Cortex-M0 is not only very bad, it is buggy.  And if you don’t want to read all this, skip to the end for a potential work around....

I have a test which just writes consecutive locations in memory, using an array (actually a pointer and offset but its the same thing).  It looks like this:

/* Write 8 bit values to known register locations - using an array */
void test6(void)
{
    volatile uint8_t* const r = (uint8_t*)(0x40002800U); // Register Array

    r[0]   = 0xFF;
    r[1]   = 0xFE;
    r[2]   = 0xFD;
    r[3]   = 0xFC;
    r[4]   = 0xEE;
    r[8]   = 0xDD;
    r[12]  = 0xCC;
}

Now, the compiler should, in my opinion, generate an address for r[0] and then if it can use indexed addressing to access the elements in the array.  Instead the compiler generates a unique entry in the literal table for each array access like this:

000000ec <test6>:
  ec:	22ff      	movs	r2, #255	; 0xff
  ee:	4b0a      	ldr	r3, [pc, #40]	; (118 <test6+0x2c>)
  f0:	701a      	strb	r2, [r3, #0]
  f2:	4b0a      	ldr	r3, [pc, #40]	; (11c <test6+0x30>)
  f4:	3a01      	subs	r2, #1
  f6:	701a      	strb	r2, [r3, #0]
  f8:	4b09      	ldr	r3, [pc, #36]	; (120 <test6+0x34>)
  fa:	3a01      	subs	r2, #1
  fc:	701a      	strb	r2, [r3, #0]
  fe:	4b09      	ldr	r3, [pc, #36]	; (124 <test6+0x38>)
 100:	3a01      	subs	r2, #1
 102:	701a      	strb	r2, [r3, #0]
 104:	4b08      	ldr	r3, [pc, #32]	; (128 <test6+0x3c>)
 106:	3a0e      	subs	r2, #14
 108:	701a      	strb	r2, [r3, #0]
 10a:	4b08      	ldr	r3, [pc, #32]	; (12c <test6+0x40>)
 10c:	3a11      	subs	r2, #17
 10e:	701a      	strb	r2, [r3, #0]
 110:	4b07      	ldr	r3, [pc, #28]	; (130 <test6+0x44>)
 112:	3a11      	subs	r2, #17
 114:	701a      	strb	r2, [r3, #0]
 116:	4770      	bx	lr
 118:	40002800 	.word	0x40002800
 11c:	40002801 	.word	0x40002801
 120:	40002802 	.word	0x40002802
 124:	40002803 	.word	0x40002803
 128:	40002804 	.word	0x40002804
 12c:	40002808 	.word	0x40002808
 130:	4000280c 	.word	0x4000280c

Which is just massively wasteful of code space.  Now in this example, GCC knows EVERYTHING there is to know about the array, it knows its address, and it knows we are accessing it with offsets, but it still decides to generate unique address entries for each array access.

So I made another test and I moved the array to low memory address 0x10 in this instance, and forget that we cant actually write to those locations because they are in FLASH, GCC doesn’t know this and it doesn’t care.  I didn't change anything except the base address of the array (to make it 8 bit) and this is what GCC generates:

00000134 <test7>:
 134:	2310      	movs	r3, #16
 136:	22ff      	movs	r2, #255	; 0xff
 138:	701a      	strb	r2, [r3, #0]
 13a:	3a01      	subs	r2, #1
 13c:	705a      	strb	r2, [r3, #1]
 13e:	3a01      	subs	r2, #1
 140:	709a      	strb	r2, [r3, #2]
 142:	3a01      	subs	r2, #1
 144:	70da      	strb	r2, [r3, #3]
 146:	3a0e      	subs	r2, #14
 148:	711a      	strb	r2, [r3, #4]
 14a:	3a11      	subs	r2, #17
 14c:	721a      	strb	r2, [r3, #8]
 14e:	3a11      	subs	r2, #17
 150:	731a      	strb	r2, [r3, #12]
 152:	4770      	bx	lr

In this case, the compiler actually generated optimal code.  But the only change was the start address of the array, so why GCC decided to now use indexed addressing when before it refused to is a mystery.

But it gets stranger.  I then tried to set the base address so it isnt so low (not 8 bits) but still quite low.  So i set it to 0x200 and this is what we get:

00000154 <test8>:
 154:	2380      	movs	r3, #128	; 0x80
 156:	22ff      	movs	r2, #255	; 0xff
 158:	009b      	lsls	r3, r3, #2
 15a:	701a      	strb	r2, [r3, #0]
 15c:	4b07      	ldr	r3, [pc, #28]	; (17c <test8+0x28>)
 15e:	3a01      	subs	r2, #1
 160:	701a      	strb	r2, [r3, #0]
 162:	4b07      	ldr	r3, [pc, #28]	; (180 <test8+0x2c>)
 164:	3a01      	subs	r2, #1
 166:	701a      	strb	r2, [r3, #0]
 168:	4b06      	ldr	r3, [pc, #24]	; (184 <test8+0x30>)
 16a:	3a01      	subs	r2, #1
 16c:	701a      	strb	r2, [r3, #0]
 16e:	3a0e      	subs	r2, #14
 170:	705a      	strb	r2, [r3, #1]
 172:	3a11      	subs	r2, #17
 174:	715a      	strb	r2, [r3, #5]
 176:	3a11      	subs	r2, #17
 178:	725a      	strb	r2, [r3, #9]
 17a:	4770      	bx	lr
 17c:	00000201 	.word	0x00000201
 180:	00000202 	.word	0x00000202
 184:	00000203 	.word	0x00000203

So in this case, GCC CAN generate some of the addresses using indexed addressing but not others, for no apparent logical reason.  I am always fearful when code is generating illogical results.

Albert Einstein is quoted as saying "the definition of insanity is doing something over and over again and expecting a different result."  Well in this case we are doing the same thing over and over again, and we can not only expect to get differnt results, we are guaranteed to get different results.  Insanity???

So i tried one last test, this time i declared the array as extern, so the compiler doesn’t know its base address, it could be low, it could be high, it could be anywhere.  And what does the compiler generate:

00000188 <test9>:
 188:	22ff      	movs	r2, #255	; 0xff
 18a:	4b08      	ldr	r3, [pc, #32]	; (1ac <test9+0x24>)
 18c:	681b      	ldr	r3, [r3, #0]
 18e:	701a      	strb	r2, [r3, #0]
 190:	3a01      	subs	r2, #1
 192:	705a      	strb	r2, [r3, #1]
 194:	3a01      	subs	r2, #1
 196:	709a      	strb	r2, [r3, #2]
 198:	3a01      	subs	r2, #1
 19a:	70da      	strb	r2, [r3, #3]
 19c:	3a0e      	subs	r2, #14
 19e:	711a      	strb	r2, [r3, #4]
 1a0:	3a11      	subs	r2, #17
 1a2:	721a      	strb	r2, [r3, #8]
 1a4:	3a11      	subs	r2, #17
 1a6:	731a      	strb	r2, [r3, #12]
 1a8:	4770      	bx	lr
 1aa:	46c0      	nop			; (mov r8, r8)
 1ac:	00000000 	.word	0x00000000
			1ac: R_ARM_ABS32	rx

The code it should have generated for each and every one of these test cases, that is what.  This is a bug, it isn't just poor optimisation, its buggy and its bad.  Cortex M0 code is being needlessly and excessively bloated by this buggy code generation and every developer is paying the price in terms of reduced performance, and larger applications.  I actually suspect part of the reason ASF seems so bloated on M0 is precisely because of this code generation.  The reason...

ASF declares ALL its registers as constants at known addresses.  The presumption of the programmer, i assume, is that its better that way, the compiler can optimise the code.  That's a reasonable assumption if the compiler was actually behaving properly (sanely?).  When the reality is, as i have demonstrated, it is significantly worse.  Every access to the memory mapped registers is going to be slower, and is going to consume more code space than if the registers were defined in the linker.  It would be better to define the registers as an external base address (not know at compile time) and a known offset from that address for the individual registers.  But that would require a re-write of ASF.

Now that I know this, for my own low level driver library i will be declaring registers exactly like that.  I don’t think it will always work, i suspect the buggy optimiser will still play havoc with the code generation, but its the only work around i can find.

The ARM GCC maintainers are looking into the bug now, which is good.  But there is definitely something weird going on.  And it does seem like it has something to do with a base of 0x00 or at least 8 bit values. 

Example, its more efficient to generate a constant that is close to another constant by just adding or subtracting an 8 bit value from a pre-existing constant.  And GCC will do this on Cortex-M0 but only if its a very low number (like 8 bits). 

If you have a constant 0x10 and the code needs a constant 0x2C, it will just add 0x1C to the 0x10 constant and its got the new constant using two bytes of code space, and 1 cycle of cpu time.

But if you have a constant in a register 0x80000010 and need 0x8000002C it wont add 0x1c to it, it instead will create a literal table entry for it, and load it, which needs 6 bytes of code space, plus the memory load time to execute (2 cycles plus memory wait states). (three times the code memory, and at least twice the processing time)

Hopefully the bug report sees this sort of thing addressed, because i believe it will yield big decreases in code size for M0 programs, and also speed improvements.

Fingers Crossed.

Yes, I have seen that optimisation as well with Cortex-M3, but with M0 it is not consistently applied when it can be.  M3 code generation is much better at applying these optimisations consistently.

Realistically, M0 code generation should be identical to M3, except when the 32 bit thumb2 instructions are required that the M0+ doesn't have.  That should be the only difference between the two.

I actually said. 

M0 IS a strict subset of M3:

from http://community.arm.com/docs/DOC-7034 :

The test case I produced clearly showed that GCC "CAN" generate much better code for M0, M0+ than it currently does.  I compiled for M3, changed the cpu type in the generated assembler to M0 and then assembled the result, the assembler does not complain.  This proves that the generated code is ONLY using the M0 subset for M3.  Accordingly there is no reason why when i compile that code for M0 i shouldn't get the same result.  If I change my tests, i can make that assembly verification test fail because the compiler will emit M3 specific instructions when its necessary to generate better code.  But for each of my tests the code generated is ONLY using the strict M0 subset.  My contention is that GCC shouldn’t generate WORSE code for M0 than M3, UNLESS it is required to use the M3 superset to be optimal.

Specific Example, M0 AND M3 can load an 8 bit constant with a 16 bit instruction like this :

MOVS <Rd>,#<imm8>

M3 can also load a 8 bit constant using

MOVW<c> <Rd>,#<imm16>

That is a 32 bit instruction.  I suspect that people would be screaming blue murder if GCC emitted this instruction to load 8 bits on the M3.  Its a 32bit instruction when the 16 bit instruction can do the same thing.  Well the situation on M0 is MUCH MUCH worse, as my test case demonstrates.

There is even a nice picture showing the strict Subsets of the Cortex M family: