On 16/05/2012 23:40, Guido Muesch wrote: > 2012/5/16 Peter Bigot<big...@acm.org>: > >> The biggest low-hanging fruit I've found is to avoid printf(3c), which >> adds about 2 kB. If you can't avoid it, you can get a few hundred >> bytes back by building an msp430-libc that doesn't support printing >> 64-bit integers. Look at the README at the top level of msp430-libc >> and invoke configure appropriately. > > Therefore I would suggest to compare the code size on a module by > module basis (e.g. msp430-size -t *.o) and compare it with the output > of the linker map file from IAR (Don't know exactly anymore, but IAR > could generate a file with all the linker information and the size of > the individual modules). That should give you an idea if the code size > difference is mainly in your code, or contributed by the libc. > > Other stupid suggestions: Check for use of inline functions. I am > currently using a fixpoint library, which originally defined all basic > operations as inline functions in its header file. Well, something > like "return (fixedpt_t)(((acc_t)a * (acc_t)b)>>FIXEDPT_SHIFT);" > looked quite innocent but with acc_t being "long long" and > FIXEDPT_SHIFT=20 there was quite some code generated for each > multiplication. Turning that into a function saved a lot. > > Guido
Checking inlines is not a "stupid" suggestion - it's quite a relevant one. But also don't forget that sometimes inlining /saves/ code space - if your code makes heavy use of silly little "getter" and "setter" functions, then making these inline will save the compiler from generating function calls and give it far more freedom to optimise register usage and ultimately save a lot of code space. ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
