Re: Updating binutils for new MSP430 chips

[Peter Bigot <pab at peoplepowerco dot com>]

If somebody could spare a few moments for the questions below and any
relevant advice, I'd appreciate it, and it'd make reviewing the
resulting changes easier once they're submitted.

As it stands, I plan to keep EM_MSP430 at its current value, reduce
the number of subarchitectures to two (16-bit address vs 20-bit
address, using new integral values), have one emulation that will
require the MEMORY block to be provided in separate chip-specific
linker scripts, and distribute those linker scripts outside of
binutils (paired with the chip-specific include files that define the
peripherals).

I'm still going to have to encode tables of chip names in some
binutils source files, but they'll be used only to set default values
for chip properties and to control the application of errata
workarounds.

I currently intend to continue to use elf output and the bfd linker;
if I should be considering gold instead, please let me know.

Thanks.

Peter

On Fri, Aug 13, 2010 at 9:53 AM, Peter Bigot <pab@peoplepowerco.com> wrote:
> Support for TI's MSP430 line of microcontrollers was added to binutils in
> the mid 2000s, and is most frequently used with the mspgcc project's patches
> to GCC 3.2.3. ?I've been maintaining the forked versions used in mspgcc4 for
> the last six months, and have been working with Texas Instruments to extend
> GNU toolchain support to several chip lines that have been added since then.
> I'm now working to bring the mspgcc and mspgcc4 back together and unify the
> toolchain.
>
> I've been unable to contact the listed binutils MSP430 maintainer (Dmitry
> Diky) at any of the email addresses I've found, and he doesn't appear to be
> active in the community. ?So I'm planning to proceed with updates. ?I'd like
> to do this in a way that they can be integrated into the main distribution,
> but that's secondary to developing a solution that's maintainable. ?What's
> there right now doesn't meet that goal.
>
> Currently binutils has two architectures defined for MSP430: EM_MSP430 and
> EM_MSP430_OLD.
>
> Mainline binutils has 14 sub-architectures (bfd_mach_msp*/E_MSP430_MACH_*)
> and 59 emulations. ?The forked binutils has 25 sub-architectures with 100
> emulations.
>
> The sub-architectures seem to have no purpose. ?Only two are actually used
> for something that can't be represented in an emulation (whether a hardware
> multiply capability is available), and I think that should be a compiler
> multilib feature just as with SIMD instruction support. ?I suspect the rest
> were intended to avoid problems when linking object files built for two
> different chips with different register addresses that were resolved at
> assembly time, but in fact there's not even a warning if you actually do
> this.
>
> What I would like to do is eliminate all the distinct architectures.
> There's one architectural extension that added a few instructions, but I'm
> not convinced it warrants a distinct machine type.
>
> Questions:
>
> (a) In what way is the specific machine number used that would cause
> problems if I did this?
>
> (b) Should I be concerned about existing object files and libraries that
> have the current numbers embedded in them? ?(If the machine number is never
> used, I think the answer is it won't matter.)
>
> (c) Would eliminating all these machine numbers be an acceptable patch for
> mainline binutils?
>
> Next question deals with emulations. ?There are currently over 270 chips in
> the MSP430 line. ?Most of them differ in terms of flash and RAM memory
> addresses and sizes, as well as whether certain peripherals are available
> (which isn't a concern to binutils). ?Historically, the approach has been to
> define an emulation for each one of them.
>
> What I'd really like to do is have a file for each chip that defines its
> MEMORY section, and possible the physical addresses of the hardware
> registers it supports. ?Everything else, such as the SECTIONS blocks, should
> be close to the same.
>
> I would really like to have a way where, if TI releases a new chip that
> requires a different MEMORY command block, a user can add that to a build
> command and use the chip without requiring an update to binutils. ?From the
> linker script perspective it seems like this should be possible with -T, and
> possibly other ways.
>
> The killer is the need to list each emulation in ld/Makefile.am. ?It's just
> unworkable, and clutters binutils.
>
> I'm wondering whether I can get away with a single emulation for
> elf32msp430, and require that any invocation of ld include as an input a
> script with the appropriate MEMORY command, something like the way elfm64hc*
> does for the GENERIC_BOARD variants.
>
> Question:
>
> (a) What linker configuration architecture you would recommend to solve this
> problem?
>
> Thanks.
>
> Peter
>