Re: msp430-elf size optimizations - some notes and a patch

On 06/03/14 17:34, DJ Delorie wrote:
> 
>> Even if you have the smallest mps430 with 512 bytes flash, it does
>> not matter if your program is 24 bytes or 511 bytes - all that
>> matters is that it fits in the chip you have.
> 
> If the startup is more than 512 bytes, it matters a lot.  If you only
> have 512 bytees of code space and you discover your project doesn't
> fit because of a couple hundred bytes of Java support, is that OK?
> Probably not.  This is the type of thing we're trying to avoid.  The
> GCC runtime supports *everything* GCC could do, but most project don't
> need everything.

OK, if it is /that/ much space then it's a completely different matter.
 I thought we were just talking about clearing the bss and setting the
initialised data, which should just be a couple of short simple loops.

> 
> Er, that reminds me, I missed some stuff in the doc about removing
> Java support... sigh.

It never occurred to me that there might be java support there - I doubt
if anyone will miss it.

Perhaps more relevantly, what about C++ support?  msp430 developers will
need some basic C++ support, including global constructors - but can
usually do without global destructors, support for unhandled exceptions
(or any exceptions or RTTI), etc., which can otherwise take up a lot of
code space.

And I expect Ada support is on your things-to-do list as well, in case
you get bored!

> 
>> But if there /are/ costs - which can include lots of confusing
>> unnecessary symbols in map files and debugger sessions - then it is
>> not clear that saving a couple of bytes is worth it.
> 
> There are already a lot of confusing symbols in the raw dumps, but
> they won't confuse the debugger or the programmer.  The ones that
> confuse the debugger are definitions of symbols, whereas these are
> references to symbols.

Fair enough.  Sometimes I have occasion to look through map files and
other "raw dumps" in my embedded development, such as to figure out why
lots of library code has been linked in, so I dislike extra symbols if
they are not important.

But if this system saves as much startup code as you say, then the extra
symbols are a very small price to pay.

> 
>> And since most embedded programs do not return from main(), then
>> size optimisations based on that are worthwhile.
> 
> Especially since an ISO-compliant exit() has a lot of work to do.

Indeed.

On some systems (not gcc on the msp430), I have had to resort to making
empty stub functions for exit() and a few other library functions in
order to avoid massive library imports.

> 
>> Ultimately, rather than having compiler flags "optimise for space" or
>> "optimise for speed", what we /really/ want is "give me the fastest
>> possible code that takes no more space than I have on the chip".  Maybe
>> that will come in gcc 5.0 :-)
> 
> Given that the compiler (which does the optimization) and the linker
> (which knows how big the image is) are separate projects, I doubt
> you'll ever see this.

Yes, I know - even if they were combined, the task would be impossible.

> 
>> Will the __intN stuff ever make it into mainline?
> 
> That's the plan.  It's been officially deferred until 4.10's cycle but
> the reviews so far have been positive.

Fantastic.

Thanks for all your work here.  I haven't started using the new port - I
don't like to change toolchains in the middle of a project - but I am
looking forward to it for the future.  The fact that Red Hat and TI are
working together on this has bumped up the msp430 significantly as a
processor choice at my company.

David





------------------------------------------------------------------------------
Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
With Perforce, you get hassle-free workflows. Merge that actually works. 
Faster operations. Version large binaries.  Built-in WAN optimization and the
freedom to use Git, Perforce or both. Make the move to Perforce.
http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk