msp430-elf size optimizations - some notes and a patch

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

msp430-elf size optimizations - some notes and a patch

DJ Delorie

I'm writing this document to collect some of the current/new knowledge
on how to minimize the flash/rom size needed for MSP430 applications,
using the new msp430-elf (FSF/Red Hat) tools. I'll keep a copy at
http://people.redhat.com/~dj/msp430/size-optimizations.html

This document has two purposes: to collect this information in one
public place, and to ask others to test it out and provide feedback.

    Linker Section Optimization
    __int20 Patch for Large Model
    Building Newlib for Reduced Size

Obvious: Please do all size testing with -Os, which optimizes for
size, and not -O3, which optimizes for speed.

** Linker Section Optimizations

The msp430-elf assembler has a new directive ".refsym" that adds a
reference to the named symbol into the generated object. In the past,
to do this, you'd use a ".word" directive instead, but that takes up
space in the final image. This new directive takes up no space in the
image.

The startup code provided in the upstream newlib/libgloss (crt0 et al)
uses ".refsym" to tell the linker about dependencies between the
various snippets of startup code and things in the whole image which
require them. This dependency information is partly manual in crt0.S
itself, and partly automatic in code generated by gcc and gas.

For example, gcc has code to check if main() ever returns. In most
embedded programs, it won't. If it *does* return, gcc adds a ".refsym"
that causes a snippet in crt0.S to be included which adds a call to
exit() after the call to main(). If main() doesn't return, there won't
be any special code after the call to main().

The assembler has code to detect if either the data or bss sections
are used, and if they are, it will use .refsym to tell crt0 to pull in
snippets of code to initialize the RAM correctly. However, this means
that most objects will now have extra "undefined" symbols that aren't
part of your application:

        U __crt0_movedata

This new functionality means that there's a new library that must be
linked in: "-lcrt". This is built by libgloss (part of newlib) by
splitting up crt0.s, and contains all the snippets. To link this
library correctly, you need a special new section in your linker
script, which looks like this:

.text           :
  {
    . = ALIGN(2);
    PROVIDE (_start = .);
    KEEP (*(SORT(.crt_*)))
    *(.lowtext .text .stub .text.* .gnu.linkonce.t.* .text:*)

The keep/sort line places all the snippets from crt0 at that point
(after _start but before the rest of your program) in asciibetical
order. Conveniently, the sections in libcrt.a are all named like
".crt_0013something" so the four-digit number causes them to all be
inserted in the right order.

What's the net result of all this? A simple "blink an led" program
that has no global variables can take as few as 24 bytes of flash
depending on how you blink the led!

** __int20 Patch for Large Model

The second big change is some ongoing work to add true "__intN"
support to the GCC internals. Before now, gcc had one __int128 type
built-in and any target that wanted something else had to hack it in
somehow, without support from gcc's core. I've put a huge unofficial
patch online at:

http://people.redhat.com/~dj/msp430/int20-patch.txt

This patch may not apply cleanly if the upstream sources have changed
too much since the patch was generated.

There are two parts to this patch: The first part is the core __intN
support, and the second part is changes to the msp430 backend to
enable __int20 and support it as a regular integer type. Note that
this patch mostly affects "large model" programs (-mlarge) as it
changes pointer math to use __int20 for size_t instead of "unsigned
long".

To explicitly use the __int20 type, replace "int" with "__int20" like
this:

unsigned __int20 x[10];
extern __int20 a, b, c;
void foo (__int20 a, void *b);

Note that __int20 won't work (and you'll get a helpful compile-time
error) unless you are building for an MSP430X-class cpu. You are
allowed to use an explicit __int20 type with small model, though.

** Building Newlib for Reduced Size

In some cases, applications may want to use the stock newlib runtime
but want to reduce the amount of flash newlib routines use. If you're
willing to rebuild newlib yourself, there are some config options you
can provide that remove features you may not need. For an up-to-date
list of these options, run "./configure --help" in the newlib/
subdirectory. Any --enable-foo option can be given as --disable-foo to
disable a feature. For example:

../newlib-trunk/configure --disable-newlib-io-float

There is also an alternate tiny malloc() implementation that can be
enabled:

../newlib-trunk/configure --enable-newlib-nano-malloc

Note that you can specify multiple --enable/--disable options on one
configure command.


------------------------------------------------------------------------------
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
_______________________________________________
Mspgcc-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Reply | Threaded
Open this post in threaded view
|

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

David Brown-4
On 05/03/14 23:25, DJ Delorie wrote:

>
> I'm writing this document to collect some of the current/new knowledge
> on how to minimize the flash/rom size needed for MSP430 applications,
> using the new msp430-elf (FSF/Red Hat) tools. I'll keep a copy at
> http://people.redhat.com/~dj/msp430/size-optimizations.html
>
> This document has two purposes: to collect this information in one
> public place, and to ask others to test it out and provide feedback.
>
>     Linker Section Optimization
>     __int20 Patch for Large Model
>     Building Newlib for Reduced Size
>
> Obvious: Please do all size testing with -Os, which optimizes for
> size, and not -O3, which optimizes for speed.
>
> ** Linker Section Optimizations
>
> The msp430-elf assembler has a new directive ".refsym" that adds a
> reference to the named symbol into the generated object. In the past,
> to do this, you'd use a ".word" directive instead, but that takes up
> space in the final image. This new directive takes up no space in the
> image.
>
> The startup code provided in the upstream newlib/libgloss (crt0 et al)
> uses ".refsym" to tell the linker about dependencies between the
> various snippets of startup code and things in the whole image which
> require them. This dependency information is partly manual in crt0.S
> itself, and partly automatic in code generated by gcc and gas.
>
> For example, gcc has code to check if main() ever returns. In most
> embedded programs, it won't. If it *does* return, gcc adds a ".refsym"
> that causes a snippet in crt0.S to be included which adds a call to
> exit() after the call to main(). If main() doesn't return, there won't
> be any special code after the call to main().
>
> The assembler has code to detect if either the data or bss sections
> are used, and if they are, it will use .refsym to tell crt0 to pull in
> snippets of code to initialize the RAM correctly. However, this means
> that most objects will now have extra "undefined" symbols that aren't
> part of your application:
>
> U __crt0_movedata
>
> This new functionality means that there's a new library that must be
> linked in: "-lcrt". This is built by libgloss (part of newlib) by
> splitting up crt0.s, and contains all the snippets. To link this
> library correctly, you need a special new section in your linker
> script, which looks like this:
>
> .text           :
>   {
>     . = ALIGN(2);
>     PROVIDE (_start = .);
>     KEEP (*(SORT(.crt_*)))
>     *(.lowtext .text .stub .text.* .gnu.linkonce.t.* .text:*)
>
> The keep/sort line places all the snippets from crt0 at that point
> (after _start but before the rest of your program) in asciibetical
> order. Conveniently, the sections in libcrt.a are all named like
> ".crt_0013something" so the four-digit number causes them to all be
> inserted in the right order.
>
> What's the net result of all this? A simple "blink an led" program
> that has no global variables can take as few as 24 bytes of flash
> depending on how you blink the led!
>
> ** __int20 Patch for Large Model
>
> The second big change is some ongoing work to add true "__intN"
> support to the GCC internals. Before now, gcc had one __int128 type
> built-in and any target that wanted something else had to hack it in
> somehow, without support from gcc's core. I've put a huge unofficial
> patch online at:
>
> http://people.redhat.com/~dj/msp430/int20-patch.txt
>
> This patch may not apply cleanly if the upstream sources have changed
> too much since the patch was generated.
>
> There are two parts to this patch: The first part is the core __intN
> support, and the second part is changes to the msp430 backend to
> enable __int20 and support it as a regular integer type. Note that
> this patch mostly affects "large model" programs (-mlarge) as it
> changes pointer math to use __int20 for size_t instead of "unsigned
> long".
>
> To explicitly use the __int20 type, replace "int" with "__int20" like
> this:
>
> unsigned __int20 x[10];
> extern __int20 a, b, c;
> void foo (__int20 a, void *b);
>
> Note that __int20 won't work (and you'll get a helpful compile-time
> error) unless you are building for an MSP430X-class cpu. You are
> allowed to use an explicit __int20 type with small model, though.
>
> ** Building Newlib for Reduced Size
>
> In some cases, applications may want to use the stock newlib runtime
> but want to reduce the amount of flash newlib routines use. If you're
> willing to rebuild newlib yourself, there are some config options you
> can provide that remove features you may not need. For an up-to-date
> list of these options, run "./configure --help" in the newlib/
> subdirectory. Any --enable-foo option can be given as --disable-foo to
> disable a feature. For example:
>
> ../newlib-trunk/configure --disable-newlib-io-float
>
> There is also an alternate tiny malloc() implementation that can be
> enabled:
>
> ../newlib-trunk/configure --enable-newlib-nano-malloc
>
> Note that you can specify multiple --enable/--disable options on one
> configure command.
>

Hi,

While it is usually good to generate small code, it is worth remembering
that there is a limit to how important it is to get the smallest
possible code.  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.  So there is little
point in saving a few bytes on startup code that is almost always used,
even on small programs - any program that comes close to at least 512
bytes is going to have global (or at least statically allocated) data.

If there are no costs involved, then the sort of micro-optimisations you
mention are fine - after all, there are some programs that don't use
initialised data (preferring to initialise explicitly in code), and some
that don't use uninitialised data (due to the idiotic non-standard
behaviour of TI's compilers/libraries that don't clear the bss at
startup).  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.

Reducing library size (especially for things like printf and friends) is
always useful, however.  And since most embedded programs do not return
from main(), then size optimisations based on that are worthwhile.

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 :-)


Will the __intN stuff ever make it into mainline?  The msp430 port may
be the only chip that needs __int20, but there are other chips that
could benefit from different integer sizes - perhaps __int24 on the
8-bit AVR, or __int40 on some devices with DSP-style accumulators.


mvh.,

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
_______________________________________________
Mspgcc-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Reply | Threaded
Open this post in threaded view
|

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

Peter Bigot-4
On Thu, Mar 6, 2014 at 6:05 AM, David Brown <[hidden email]> wrote:
> Will the __intN stuff ever make it into mainline?  The msp430 port may
> be the only chip that needs __int20, but there are other chips that
> could benefit from different integer sizes - perhaps __int24 on the
> 8-bit AVR, or __int40 on some devices with DSP-style accumulators.

I'd hope that it's done in a way that allows that, though I haven't
looked at what DJ did.  Speaking as somebody who did all this in gcc
almost two years ago, part of what's needed was already there, but it
had some bugs (which I reported, and one of which Nick later
rediscovered in the RH port).  There are a lot of other issues for
full msp430 20-bit support too (mostly to do with address/non-address
value differences), many of which were solved in mspgcc.

Hopefully the new clean-room implementation, done by folks who know
more about gcc, will address the flaws in mspgcc's approach and be
acceptable upstream.

Peter

------------------------------------------------------------------------------
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
_______________________________________________
Mspgcc-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Reply | Threaded
Open this post in threaded view
|

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

DJ Delorie
In reply to this post by David Brown-4

> 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.

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

> 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.

> 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.

> 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.

> 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.

------------------------------------------------------------------------------
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
_______________________________________________
Mspgcc-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Reply | Threaded
Open this post in threaded view
|

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

DJ Delorie

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

I added this:


Lastly, there's a GCC option -minrt that tells gcc to use a "minimum
runtime" for programs that do not need static initializers or
constructors (popular in C++ and Java). Note that this is different
than initialized data (like "int j = 5;"), this is for functions that
need to be called before main() is. You can also forcibly remove the
extra language support in your linker script by discarding anything
from crtbegin/crtend:

  /DISCARD/ : { *crtbegin*.o(*) *crtend*.o(*) }

Don't forget to take out the KEEP's for crtbegin/end too, though ;-)


------------------------------------------------------------------------------
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
_______________________________________________
Mspgcc-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Reply | Threaded
Open this post in threaded view
|

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

Peter Bigot-4
Is it the intent to fully support C++ in this port, inclusive of
static initializers and exceptions?   (Exclusive of features that
require host support like threads, though it'd be good if <chrono>
could be used with various MSP430 clocks providing the underlying
timers.)

Proper support for C++11 in msp430-elf-gcc sometime soon would be one
of the things that will slow my move to ARM-based microcontrollers.  I
can respect flags that disable its support; I don't want to have to
add flags to put support back, or find language-mandated features do
not work.  (The move to ARM is inevitable, though; MSP430 just doesn't
stack up so well anymore, even for ultra-low-power applications).

Peter

On Thu, Mar 6, 2014 at 12:07 PM, DJ Delorie <[hidden email]> wrote:

>
>> Er, that reminds me, I missed some stuff in the doc about removing
>> Java support... sigh.
>
> I added this:
>
>
> Lastly, there's a GCC option -minrt that tells gcc to use a "minimum
> runtime" for programs that do not need static initializers or
> constructors (popular in C++ and Java). Note that this is different
> than initialized data (like "int j = 5;"), this is for functions that
> need to be called before main() is. You can also forcibly remove the
> extra language support in your linker script by discarding anything
> from crtbegin/crtend:
>
>   /DISCARD/ : { *crtbegin*.o(*) *crtend*.o(*) }
>
> Don't forget to take out the KEEP's for crtbegin/end too, though ;-)
>
>
> ------------------------------------------------------------------------------
> 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
> _______________________________________________
> Mspgcc-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/mspgcc-users

------------------------------------------------------------------------------
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
_______________________________________________
Mspgcc-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Reply | Threaded
Open this post in threaded view
|

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

DJ Delorie

> Is it the intent to fully support C++ in this port, inclusive of
> static initializers and exceptions?

If you have enough flash/ram, yes.  We fully test C++ in our
simulators, so if gcc/newlib support it in general, it should work for
msp430 also.

> (Exclusive of features that require host support like threads,
> though it'd be good if <chrono> could be used with various MSP430
> clocks providing the underlying timers.)

Well, if you want *peripheral* support in the runtime libraries,
that's a different story ;-)

------------------------------------------------------------------------------
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
_______________________________________________
Mspgcc-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Reply | Threaded
Open this post in threaded view
|

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

Peter Bigot-4
On Thu, Mar 6, 2014 at 12:47 PM, DJ Delorie <[hidden email]> wrote:
> If you have enough flash/ram, yes.  We fully test C++ in our
> simulators, so if gcc/newlib support it in general, it should work for
> msp430 also.

Great.  I'll try that out once it looks like all the TI patches are
applied to the 4.9 development branch.

>> (Exclusive of features that require host support like threads,
>> though it'd be good if <chrono> could be used with various MSP430
>> clocks providing the underlying timers.)
>
> Well, if you want *peripheral* support in the runtime libraries,
> that's a different story ;-)

No, I (very much) don't want gcc or newlib to do the peripheral
interface.  I am hopeful, though, that I can use the standard
templates by providing my own underlying implementation for (for
example) std::system_clock and std::high_resolution_clock.  Haven't
looked into the details yet, though.

Peter

------------------------------------------------------------------------------
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
_______________________________________________
Mspgcc-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Reply | Threaded
Open this post in threaded view
|

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

Nader
In reply to this post by DJ Delorie
Hi DJ,

    Great news and thank you for the update, is it possible to throw
somewhere the Windows binaries? I think it is time for fresh windows
binaries, the last one was back in December. Is it possible to have Windows
binaries every 3-4 months?Someplace on TI web site or some other site, or
simply if you can guide me where to find them, that will include all new
additions and fixes etc... The alternative is to have really a detailed
build for windows native binaries, like the one already released, using
cygwim, or some nice documentation on how I can build the msp-elf RH tools
myself.

Cheers.
Nader




On Wed, Mar 5, 2014 at 2:25 PM, DJ Delorie <[hidden email]> wrote:

>
> I'm writing this document to collect some of the current/new knowledge
> on how to minimize the flash/rom size needed for MSP430 applications,
> using the new msp430-elf (FSF/Red Hat) tools. I'll keep a copy at
> http://people.redhat.com/~dj/msp430/size-optimizations.html
>
> This document has two purposes: to collect this information in one
> public place, and to ask others to test it out and provide feedback.
>
>     Linker Section Optimization
>     __int20 Patch for Large Model
>     Building Newlib for Reduced Size
>
> Obvious: Please do all size testing with -Os, which optimizes for
> size, and not -O3, which optimizes for speed.
>
> ** Linker Section Optimizations
>
> The msp430-elf assembler has a new directive ".refsym" that adds a
> reference to the named symbol into the generated object. In the past,
> to do this, you'd use a ".word" directive instead, but that takes up
> space in the final image. This new directive takes up no space in the
> image.
>
> The startup code provided in the upstream newlib/libgloss (crt0 et al)
> uses ".refsym" to tell the linker about dependencies between the
> various snippets of startup code and things in the whole image which
> require them. This dependency information is partly manual in crt0.S
> itself, and partly automatic in code generated by gcc and gas.
>
> For example, gcc has code to check if main() ever returns. In most
> embedded programs, it won't. If it *does* return, gcc adds a ".refsym"
> that causes a snippet in crt0.S to be included which adds a call to
> exit() after the call to main(). If main() doesn't return, there won't
> be any special code after the call to main().
> The assembler has code to detect if either the data or bss sections
> are used, and if they are, it will use .refsym to tell crt0 to pull in
> snippets of code to initialize the RAM correctly. However, this means
> that most objects will now have extra "undefined" symbols that aren't
> part of your application:
>
>         U __crt0_movedata
>
> This new functionality means that there's a new library that must be
> linked in: "-lcrt". This is built by libgloss (part of newlib) by
> splitting up crt0.s, and contains all the snippets. To link this
> library correctly, you need a special new section in your linker
> script, which looks like this:
>
> .text           :
>   {
>     . = ALIGN(2);
>     PROVIDE (_start = .);
>     KEEP (*(SORT(.crt_*)))
>     *(.lowtext .text .stub .text.* .gnu.linkonce.t.* .text:*)
>
> The keep/sort line places all the snippets from crt0 at that point
> (after _start but before the rest of your program) in asciibetical
> order. Conveniently, the sections in libcrt.a are all named like
> ".crt_0013something" so the four-digit number causes them to all be
> inserted in the right order.
>
> What's the net result of all this? A simple "blink an led" program
> that has no global variables can take as few as 24 bytes of flash
> depending on how you blink the led!
>
> ** __int20 Patch for Large Model
>
> The second big change is some ongoing work to add true "__intN"
> support to the GCC internals. Before now, gcc had one __int128 type
> built-in and any target that wanted something else had to hack it in
> somehow, without support from gcc's core. I've put a huge unofficial
> patch online at:
>
> http://people.redhat.com/~dj/msp430/int20-patch.txt
>
> This patch may not apply cleanly if the upstream sources have changed
> too much since the patch was generated.
>
> There are two parts to this patch: The first part is the core __intN
> support, and the second part is changes to the msp430 backend to
> enable __int20 and support it as a regular integer type. Note that
> this patch mostly affects "large model" programs (-mlarge) as it
> changes pointer math to use __int20 for size_t instead of "unsigned
> long".
>
> To explicitly use the __int20 type, replace "int" with "__int20" like
> this:
>
> unsigned __int20 x[10];
> extern __int20 a, b, c;
> void foo (__int20 a, void *b);
>
> Note that __int20 won't work (and you'll get a helpful compile-time
> error) unless you are building for an MSP430X-class cpu. You are
> allowed to use an explicit __int20 type with small model, though.
>
> ** Building Newlib for Reduced Size
>
> In some cases, applications may want to use the stock newlib runtime
> but want to reduce the amount of flash newlib routines use. If you're
> willing to rebuild newlib yourself, there are some config options you
> can provide that remove features you may not need. For an up-to-date
> list of these options, run "./configure --help" in the newlib/
> subdirectory. Any --enable-foo option can be given as --disable-foo to
> disable a feature. For example:
>
> ../newlib-trunk/configure --disable-newlib-io-float
>
> There is also an alternate tiny malloc() implementation that can be
> enabled:
>
> ../newlib-trunk/configure --enable-newlib-nano-malloc
>
> Note that you can specify multiple --enable/--disable options on one
> configure command.
>
>
>
> ------------------------------------------------------------------------------
> 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
> _______________________________________________
> Mspgcc-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/mspgcc-users
>

------------------------------------------------------------------------------
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
_______________________________________________
Mspgcc-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Reply | Threaded
Open this post in threaded view
|

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

DJ Delorie

>     Great news and thank you for the update, is it possible to throw
> somewhere the Windows binaries? I think it is time for fresh windows
> binaries, the last one was back in December.

Sorry, I don't work for TI, so I can't make them do a release or say
anything about their schedule or intentions.  All I do is maintain the
port in the FSF source tree.

Also, please keep in mind that this is a patch that's still a
work-in-progress, subject to change, etc.  Certainly not a supported
or official thing yet.

> or some nice documentation on how I can build the msp-elf RH tools
> myself.

Note: msp430-elf, not msp-elf

The answer here is "the same way you build any other cross toolchain."
There's nothing magic about he msp430-elf tools, assuming you know how
to build a cross toolchain at all.  If not, you're probably going to
be frustrated, but in case you want to try anyway...

Basically (and substituate your real paths as desired):

P="--prefix=/usr/local"
T="--target=msp430-elf"

export PATH=/usr/local/bin:$PATH

cd $binutilsworkdir
$somewhere/binutils-sources/configure $P $T
make
make install

cd $gccworkdir
$somewhere/gcc-sources/configure $P $T --with-newlib --enable-languages=c,c++
make all-host
make install-host

cd $newlibworkdir
$somewhere/newlib-sources/configure $P $T
make
make install

cd $gccworkdir
make all-target
make install-target

------------------------------------------------------------------------------
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
_______________________________________________
Mspgcc-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Reply | Threaded
Open this post in threaded view
|

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

David Brown-4
In reply to this post by DJ Delorie
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
_______________________________________________
Mspgcc-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Reply | Threaded
Open this post in threaded view
|

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

DJ Delorie

> 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.

Worst case startup is around 400 bytes, but once you start optimizing,
you might as well handle all the cases as best you can.

> 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.

Basic C++ should be there, I think including exceptions.

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

Sorry, Ada isn't on my to-do list ;-)

> 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.

Me too.

------------------------------------------------------------------------------
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
_______________________________________________
Mspgcc-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Reply | Threaded
Open this post in threaded view
|

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

Nader
In reply to this post by DJ Delorie
Hi DJ,

    Thank you for your prompt reply, I understand, it is just always
frustrating for Windows users to deal with this, i will try your
configuration and do some research.

On a  different note, i was wondering if anybody on the list have the same
problem as me, using the TI pre-compiled binaries for the MSP430 (the RH
port, downloaded from TI web site), the msp430-elf-gdb.exe , works Ok with
430 and 430X but using only small memory model for a 430X. If you switch to
large memory and have code above 64K, it will build ok the .elf file or
.hex file (all addresses are OK), but msp430-elf-gdb.exe does not load code
or debug any address above the 64K. In fact address like 0x10000 wraps
around to 0x0000. If you step into a function that supposed to be in high
memory, the GDB simply report as invalid address, and try to step into
0x0000 instead of 0x10000. Anybody experienced this behavior?

Cheers.















On Thu, Mar 6, 2014 at 9:53 PM, DJ Delorie <[hidden email]> wrote:

>
> >     Great news and thank you for the update, is it possible to throw
> > somewhere the Windows binaries? I think it is time for fresh windows
> > binaries, the last one was back in December.
>
> Sorry, I don't work for TI, so I can't make them do a release or say
> anything about their schedule or intentions.  All I do is maintain the
> port in the FSF source tree.
>
> Also, please keep in mind that this is a patch that's still a
> work-in-progress, subject to change, etc.  Certainly not a supported
> or official thing yet.
>
> > or some nice documentation on how I can build the msp-elf RH tools
> > myself.
>
> Note: msp430-elf, not msp-elf
>
> The answer here is "the same way you build any other cross toolchain."
> There's nothing magic about he msp430-elf tools, assuming you know how
> to build a cross toolchain at all.  If not, you're probably going to
> be frustrated, but in case you want to try anyway...
>
> Basically (and substituate your real paths as desired):
>
> P="--prefix=/usr/local"
> T="--target=msp430-elf"
>
> export PATH=/usr/local/bin:$PATH
>
> cd $binutilsworkdir
> $somewhere/binutils-sources/configure $P $T
> make
> make install
>
> cd $gccworkdir
> $somewhere/gcc-sources/configure $P $T --with-newlib
> --enable-languages=c,c++
> make all-host
> make install-host
>
> cd $newlibworkdir
> $somewhere/newlib-sources/configure $P $T
> make
> make install
>
> cd $gccworkdir
> make all-target
> make install-target
>


--
Nader Shehayed

------------------------------------------------------------------------------
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
_______________________________________________
Mspgcc-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Reply | Threaded
Open this post in threaded view
|

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

DJ Delorie

> On a  different note, i was wondering if anybody on the list have the same
> problem as me, using the TI pre-compiled binaries for the MSP430 (the RH
> port, downloaded from TI web site), the msp430-elf-gdb.exe , works Ok with
> 430 and 430X but using only small memory model for a 430X. If you switch to
> large memory and have code above 64K, it will build ok the .elf file or
> .hex file (all addresses are OK), but msp430-elf-gdb.exe does not load code
> or debug any address above the 64K. In fact address like 0x10000 wraps
> around to 0x0000. If you step into a function that supposed to be in high
> memory, the GDB simply report as invalid address, and try to step into
> 0x0000 instead of 0x10000. Anybody experienced this behavior?

Cc'ing Kevin, our gdb expert...

Could you come up with a small test case we can use to debug this?
Perhaps including the ELF file and a sample gdb session, so we use all
the same command line parameters etc?

------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech
_______________________________________________
Mspgcc-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users