Support for GCC8

[travisgoodspeed]

Currently, the project builds with msp430-gcc 4.6.3 as distributed by Debian, but it would be nice to also support msp430-elf-gcc-7.3.2 as distributed by Texas Instruments. Requested by @docprofsky.

• [x] Dialect differences are fixed, so that all modules compile.
• [x] Linking scripts ported, so that a binary links.
• [x] The firmware works!
• [x] Linking technique is documented.
• [x] The firmware size is reasonable.
• [x] ABI is matched in the CC430F6137 RTC errata fix assembly.

And finally,

• [x] Documentation is updated to reference GCC8.
• [x] @travisgoodspeed wears a GCC8 watch for at least a week.
• [x] GCC8 becomes the default.
• [x] GCC4 support is removed.

[travisgoodspeed]

A few notes on the linking situation:

The CC430F6137 and CC430F6147 are pretty much the same chip from a software perspective, except for a few fixes of errata and the complete replacement of the ADC with a different and incompatible implementation. Rather than break break compatibility between them or make a compile-time choice between the two, we simply made a custom linker script with symbols for the I/O devices of both chips, then detect at runtime which ADC driver we ought to be using. This served us well enough in GCC 4.6.3, but in GCC 7 the linking scripts have changed, and we must create a new one.

Additionally, we reserve half of SRAM for the DMESG buffer. This is done statically in the linking script, so that we can still read the DMESG buffer even when all else is corrupted.

The most actively maintained fork of GCC for the MSP430 seems to be the one maintained by Mitto Systems for Texas Instruments. http://www.mittosystems.com/ti-msp430-gcc.html

[desertsagebrush]

I was just encountering this problem and was about to post an issue when I saw this. Is there anything that I can do to give you a hand with this?

[travisgoodspeed]

A pull request that builds on GCC7 without pulling in a dozen floating point and heap functions would be lovely. It should be enough to just pull in another printf and sprintf implementation, and maybe trace dependencies to figure out what else is pulling in so many standard library routines.

[travisgoodspeed]

The new compiler's bloat is largely caused by dropping msp430-libc for newlib, and I've been able to make it fit by installing a new printf() implementation to avoid newlib's. I'll push that up to a branch and merge it if and when I can do so cleanly or reduce the rest of the bloat.

[travisgoodspeed]

Pushed a forgotten replacement for stdio.h that is needed to prevent redefinition warnings. You should be able to build the GCC7 branch now with make -f Makefile.gcc7.

It is still quite a bit larger than with GCC4. If it doesn't fit, disable some modules at the beginning of the Makefile.

[travisgoodspeed]

As one additional headache, the calling convention has changed in GCC7. Now the first parameter and return value are in R12, rather than R15. This will break a lot of the RTC driver, which uses raw assembly, but all the rest of the code ought to be pure C.

http://www.ti.com/lit/an/slaa664/slaa664.pdf

[travisgoodspeed]

I pushed code to the GCC7 branch which enabled the RTC errata fix in both calling conventions. Not yet tested on real hardware.

After testing it and optimizing some code, I hope to merge this into the master branch, making GCC8 the new default compiler.

[travisgoodspeed]

Some sources of bloat in GCC8's build:

• [x] malloc() and sbrk(), when we damned well don't need a heap.
• [x] srand() seems to call malloc(). Replace it in rng.c.

[travisgoodspeed]

GCC8 now works with make -f Makefile.gcc8 clean sbwflash. I'll be cutting out GCC4 support after wearing a GCC8 watch a week or two, to make sure there are no pesky edge cases.