f5mul - does it change the code size?

Iurii Vlasenko

I use Code::Blocks and TI/Redhat gcc compiler.

I've got a problem with code size during the project building. When I compare the MAP file of the build with the one from one of the old projects, I see a difference in library object files source/ The old project uses f5mul directory, the new one takes lib files from an upper directory (/ti/gcc/msp430-elf/lib).

An example from the MAP file:

Old (good) project:

LOAD /home/drvlas/ti/gcc/bin/../lib/gcc/msp430-elf/4.9.1/f5mul/libgcc.a

New (bad) project:

LOAD /home/drvlas/ti/gcc/bin/../lib/gcc/msp430-elf/5.3.0/../../../../msp430-elf/lib/libc.a

I cannot find in my IDE setup what causes the difference. Still, I think that the growth of the code size is linked to it.

UDDATED. The version of the compiler has changed from 4.9.1 to 5.3.0. I try to build the old project - the linker shows lack of memory too. So, the problem may be redefined so: the project that was OK with 4.1.9 version of compiler cannot be built with 5.3.0.

over 7 years ago

0 George Mock over 7 years ago

TI__Guru**** 232700 points

It appears this problem is introduced in the March release version 5.3.0.105 by Red Hat. And it is also present in the June release version 5.3.0.219 by Somnium. I'll file an issue with Somnium.

Thanks and regards,

-George

0 Iurii Vlasenko over 7 years ago

Expert 1050 points

Thanks!
I've found 2 ways to deal with a problem so far. First, I switched to a CCSv6 - and it gives a shorter code. And second, I edited my project to eliminate a float operation - it reduced the code size substantially.
Still, it would be good to be in a full control of a code generation :)
Regards,
Yury

0 Joe Seymour over 7 years ago

Prodigy 90 points

Without more details of the differences between your "good" and "bad" projects it's difficult to say for sure what's caused the change in size. Are you able to provide complete good and bad elf files, or map files, or both?

> The old project uses f5mul directory

The set of multilibs changed between the "good" and "bad" compilers: gcc.gnu.org/.../msg00600.html

It's possible that this change is responsible for the size difference you're seeing. Unfortunately there's no way for you to switch back to the old set of multilibs without rebuilding the toolchain. It's also possible that the size change is caused by something else entirely.

0 Iurii Vlasenko over 7 years ago in reply to Joe Seymour

Expert 1050 points

"Good" and "bad" are exactly the same.

Well, I have not understood all the details with the reduced number of multilibs, but my current vision of the problem is such:

Some time ago I inserted the float operation in my project - erroneously. But the size of the project allowed me not to notice this fact. Then (in some time) the project approached 16K. And a tiny change in Compiler caused over-float.

After transition to CCS native Compiler I could compile the project. Then I've found my fault and now I can build the project with both CCS and GCC.

BTW that error of mine looked so:

  uint32_t volatile ulBlink;
...
  ulBlink = (uint32_t)Period_ms * (229*7.3728/16);

I decided that 229*7.... calculation will be performed during the compilation. But it had to be cast to uint23_t - and that was not made.

So I changed that part to:

ulBlink = Period_ms * (7372800UL>>16);

Thanks to all! I have not the problem now.

Regards,

Yury

Code Composer Studio™︎

Code Composer Studio forum

f5mul - does it change the code size?