I'm updating a larger project to compile with the RH port of gcc for MSP430 as well as previous mspgcc versions. I've noticed a few problems.
versions used from http://www.ti.com/tool/msp430-gcc-opensource: - GCC_RH_20131206.zip - msp430-130423-272-source.tar.bz2 (resp. the provided windows command line binaries) == 1) iomacros.h includes the following 4 lines in the section that is parsed by "as" and "cc" #define const_sfrb(x,x_) const sfrb_(x,x_) #define const_sfrw(x,x_) const sfrw_(x,x_) #define const_sfra(x,x_) const sfra_(x,x_) #define const_sfrl(x,x_) const sfrl_(x,x_) it is an error for "as" when it sees the "const". solution: move these line in between the #ifdef'd part where only the c compiler sees it and add the following to the section for the assembler. #define const_sfrb(x,x_) x=x_ #define const_sfrw(x,x_) x=x_ #define const_sfra(x,x_) x=x_ #define const_sfrl(x,x_) x=x_ == 2) .noinit segment is not correctly flagged, it is needlessly downloaded to the target and occupies flash for a series of zeros. objdump shows ... 8 .rodata 000009dc 00002100 00002100 00000194 2**2 CONTENTS, ALLOC, LOAD, DATA 9 .text 0000acd2 00002adc 00002adc 00000b70 2**1 CONTENTS, ALLOC, LOAD, READONLY, CODE 10 .data 0000035c 00001100 0000d7ae 0000b844 2**1 CONTENTS, ALLOC, LOAD, DATA 11 .bss 00000808 0000145c 0000db0a 0000bba0 2**1 ALLOC 12 .noinit 000002f1 00001c64 0000db0a 0000bba0 2**1 CONTENTS, ALLOC, LOAD, DATA ... and objcopy seems to include the zeros from .noinit in the .a43 (intel hex). == 3) it looks like COMMON is included in the ".noinit" section, i thought it belongs to the ".bss" section. there are multiple "end" labels defined, one in ".bss" and one in ".noinit" and unfortunately "_end" is placed in .bss instead of the very end of RAM (behind .noinit) as it was in mspgcc. (seen in the ld files for msp430f2410 and others) == 4) and probably not MSP430 specific, with -Os "static inline functions()" are not inlined, i also tried adding __attribute__((always_inline)) but it did not seem to have an effect in a quick test. we are using such one-line functions for pin access. when not inlined the call will probably increase the code size considerably with register moving to prepare a call to one assembler line that does not even touch a register... we used to use -O2 only but the code is a little bit larger with GCC 4.x so we added -Os ... == 5) it was probably a design decision to change the ABI and start with R12 instead of R15 for parameters. this leads to some work with assembler modules interacting with c modules. it would be nice if there where some defines available to detect the ABI. i've passed a -D from the command line depending on which compiler is used (old mspggc/ti gcc). i'm also not getting any source, just assembler, with "objdump -dSt" of the .elf file, which previously worked. ==== positively, after working around these issues (we use custom linker scripts anyway as we reserve space for a bootlaoder, MSP430F2xx) it compiles and runs :-) thanks, chris ------------------------------------------------------------------------------ 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
