LPCXpresso 7.3 Assembler generates increased code size

[lpcware]

Content originally posted in LPCWare by MikeSimmonds on Sun Aug 17 15:07:04 MST 2014
The assembler included in 7.3 generates larger code for the same source file with the same options than that
which was included in 6.02.

The root cause seems to be where a forward branch to a label marked as a thumb function is now generating
a wide branch where it used to generate a narrow branch. But not always!

I have tried to find a changelog on the net to see if this behaviour is documented but I failed.
I tried to see if there is a (new?) assembler switch to correct the problem but again I failed.

As I understand things, the "C" compiler generates assembler code that is passed to the assembler,
so this is a problem that will affect all users, not just those who write assembler directly.

Given that branches are very common, this would apear to be a serious backward step.

Examples:

New Assembler [2.23]

00002466 EnableIRQ:
    2466:f45f 7380 movs.wr3, #256; 0x100
    246a:f000 b804 b.w2476 <EnableDisable>             WIDE Branch

0000246e DisableIRQ:
    246e:f45f 73c0 movs.wr3, #384; 0x180
    2472:f000 b800 b.w2476 <EnableDisable>           WIDE Branch

00002476 EnableDisable:
    2476:282a      cmpr0, #42; 0x2a
    2478:d20a      bcs.n2490 <EnableDisable+0x1a>
    247a:f113 23e0 adds.wr3, r3, #3758153728; 0xe000e000
    247e:2820      cmpr0, #32

But see here

00002220 ClkSet:
    2220:2078      movsr0, #120; 0x78
    2222:e7ff      b.n2224 <ClkSetup>                  NARROW Branch

00002224 ClkSetup:
    2224:4b39      ldrr3, [pc, #228]; (230c <Pool>)
    2226:2220      movsr2, #32
    2228:f8d3 11a0 ldr.wr1, [r3, #416]; 0x1a0
    222c:4311      orrsr1, r2

Old Assembler [2.21]

00002466 EnableIRQ:
    2466:f45f 7380 movs.wr3, #256; 0x100
    246a:e002      b.n2472 <EnableDisable>                NARROW Branch

0000246c DisableIRQ:
    246c:f45f 73c0 movs.wr3, #384; 0x180
    2470:e7ff      b.n2472 <EnableDisable>             NARROW Branch

00002472 EnableDisable:
    2472:282a      cmpr0, #42; 0x2a
    2474:d20a      bcs.n248c <EnableDisable+0x1a>
    2476:f113 23e0 adds.wr3, r3, #3758153728; 0xe000e000
    247a:2820      cmpr0, #32

But Again

00002220 ClkSet:
    2220:2078      movsr0, #120; 0x78
    2222:e7ff      b.n2224 <ClkSetup>                NARROW Branch

00002224 ClkSetup:
    2224:4b39      ldrr3, [pc, #228]; (230c <Pool>)
    2226:2220      movsr2, #32
    2228:f8d3 11a0 ldr.wr1, [r3, #416]; 0x1a0
    222c:4311      orrsr1, r2
    222e:f8c3 11a0 str.wr1, [r3, #416]; 0x1a0

I really need a resolution for this, but if one is not forth comming in the near time,
is it acceptable to copy the entire 'tools' directory structure from 6.02 to 7.3?

Regards, Mike

[lpcware]

Content originally posted in LPCWare by MikeSimmonds on Mon Aug 18 04:44:16 MST 2014
Agreed, one can force a wide/narrow choice, but it has never been necessary until now.

Can you point me to the changelog for the specific version of binutils that 7.3 installs where this difference in
behaviour is identified.

Mike.

[lpcware]

Content originally posted in LPCWare by lpcxpresso-support on Mon Aug 18 04:03:21 MST 2014
Sorry - but if you want to guarantee the use of a wide or narrow form of an instruction when writing in assembly code, then you need to specify the width you want explicitly.

Otherwise the assembler can choose whichever it wishes, and there an no guarantees that the rules and heuristics used will not change between GNU tool releases.

Regards,
LPCXpresso Support.

[lpcware]

Content originally posted in LPCWare by MikeSimmonds on Mon Aug 18 00:56:48 MST 2014
Thanks for responding, but my example are using the assembler directly; "C" and whatever new/changed options are used
do not not factor into my equation.

Mike.

[lpcware]

Content originally posted in LPCWare by OldManVimes on Mon Aug 18 00:33:55 MST 2014
Hi Mike,

It's good to see your attention to detail. I am not in a position to give you real support, but the difference you are seeing is the result of a newer GCC compiler version. On average I find that GCC improves with newer versions, so there might be a benefit that we can't identify here. If code size is a primary driver for you, ensure you select the "-Os" optimization level in your compiler settings. I've been playing with "-flto" as well, but it gets a bit aggressive and strips, what it thinks are, un-referenced symbols from my image causing it to fail.

Tip: Create a dummy project in 7.3 using the wizard from scratch and look at the compiler settings this generates. They contain some interesting settings (although they might not have changed that much since version 6). This might give you some other space saving options. The settings generated by the wizard are good with the exception of a generic Eclipse issue where dependency files are borked since there's no dependency between the object file and the dependencies of the source file (talk about frustration). There's a thread lurking somewhere on this forum describing this issue. It also contains a fix. Basically compiler generated dependency files is beyond the level of competence of the Eclispe CDT community.

Cheers,
Vimes

"And when the Patrician was unhappy, he became very democratic. He found intricate and painful ways of spreading that unhappiness as far as possible."