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