On Tue, Jan 14, 2014 at 02:08:53PM +0100, Emil Renner Berthing wrote: > Right, so the workaround is something like > $ msp430-elf-gcc -mmcu=msp430g2231 -Os -static -nostdlib -Wall -Wextra > simple.c -o simple.elf `msp430-elf-gcc gcc -print-libgcc-file-name` > ..and then add my own assembly to clear .bss etc. and jump to main(). > > I guess I had just hoped there would be a standard way of doing this, so > everyone doesn't have to implement that bit again.
An objdump of the newlib .o could tell where the bss is eaten up, then selective surgery on newlib/libgloss can be done (do the MSP *really* need stdio?). Other cruft (the C++ and java one) can be ifdeffed out in crtstuff.c (in libgcc). And that printf is pure evil :D (not that I often use printf on MCUs...) Compiling the target app with LTO (verify that ISR are actually emitted! attribute used helps) or better yet do a single compilation unit with the world declared static (essentially what Byte Craft does from forever) gain *huge* code space with -Os. Yes, I'm aggressively spacing optimizing the code :D Also unsigned int is obviously easier to process than an unsigned char, most of the time: the MSP is almost pure 16 bit (except for load/store), the stack is slotted on even addresses and registers needs to be anded with FFh to ensure 8-bit semantic. At 4 bytes (IIRC) for each unsigned char parameter used, the gain is significant. -- Lorenzo Marcantonio Logos Srl ------------------------------------------------------------------------------ CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments & Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk _______________________________________________ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
