Yes, in fact the whole point of uniarch is to eliminate MCU-specific
information from binutils and gcc. That's gone quite well, and it is an
external specs-file approach that allows the relevant information to be
propagated to the different toolchain phases. This introduces a new package,
msp430mcu, which combines the specs file translations for known chips, the
headers from Texas Instruments, and the linker scripts. Updating to new
devices can be done in emergency cases by editing those files, and more
generally by simply installing a new msp430mcu release without touching
binutils or gcc.
(That space issue you noted that is avoided by using a spec function to do
the translation from the mcu token provided into a preprocessor symbol, so
we can maintain compatibility with the TI headers.)
And I was successful in supporting the legacy genericized MCU names by
associating each one with a specific MCU to which it is considered
equivalent. So things like -mmcu=msp430x1611 will still end up supporting
the MSP430F1611.
I will be making a valiant effort over the next week to rebase the uniarch
work on gcc 4.5.2 and push the relevant updates to the git repositories now
hosted on the mspgcc project.
Peter
On Sat, Feb 5, 2011 at 4:55 AM, Peter Jansen <[email protected]> wrote:
> Hi Peter,
>
> When doing this, could we try and remove some of the occurrences of all
> these
> part numbers from gcc/binutils/libc?
>
> One thing I look at some time ago was to make some changes
> gcc/config/msp430/msp430.h with the SPECS to make it more generic, like
> change
> LINK_SPEC to
>
> #define LINK_SPEC "\
> %{!mmcu*:-m msp430x110} \
> %{mmcu=msp1:-m msp430x110} \
> %{mmcu=msp2:-m msp430x147} \
> %{mmcu=msp3:-m msp430xG4616} \
> %{mmcu=msp4:-m msp430x4783} \
> %{mmcu=msp5:-m msp430x47166} \
> %{mmcu=msp6:-m msp430x5418} \
> %{mmcu=msp430x*:-m msp430x%* } \
> %{mmcu=cc430x*:-m cc430x%* }"
>
> Being a bit more adventurous, which also need changes to msp430-libc, but
> change
>
> CPP_SPEC to
>
> #define CPP_SPEC "\
> %{!mmcu*|mmcu=msp1:%(cpp_msp1)} \
> %{mmcu=msp2:%(cpp_msp2)} \
> %{mmcu=msp3:%(cpp_msp3)} \
> %{mmcu=msp4:%(cpp_msp4)} \
> %{mmcu=msp5:%(cpp_msp5)} \
> %{mmcu=msp6:%(cpp_msp6)} \
> %{mmcu=msp430*:-D__MSP430%*} \
>
> etc, this means changing the __MSP430F149__ to MSP430F149 (without the __
> on the
>
> end, using %*__ in a spec substitution causes a space to be added :-( )
>
> Another change that could be made which affects msp430-libc also, would be
> to
> only build gcrt0.S for msp1/msp2/.../msp6 and re-arrange how
> CRT_BINUTILS_SPECS
> is built, this would mean a new crtmsp430xxxxxxx would not have to be build
> for
> every device.
>
> This might enable adding new parts to gcc may not require any changes, just
> changes to msp430-libc and binutils for the new linker scripts
>
> I can make some patches for this if you like.
>
> Regards,
>
> Peter Jansen
>
> (Sorry missed sending to the mailing list the first time).
>
>
> ----- Original Message ----
> > From: Peter Bigot <[email protected]>
> > To: GCC for MSP430 - http://mspgcc.sf.net <
> [email protected]>
> > Sent: Wed, 22 December, 2010 10:25:59 AM
> > Subject: [Mspgcc-users] Notice of elimination of genericized mcu names in
> >uniarch
> >
> > Traditionally, mspgcc has accepted genericized MCU part numbers, with an
> "x"
> > substituted for the section of the part that denotes the chip memory
> type.
> > E.g. -mmcu=msp430x1611 for the MSP430F1611. See the breakdown of how
> MSP430
> > part numbers are
> >constructed.<
> http://mspgcc4.git.sourceforge.net/git/gitweb.cgi?p=mspgcc4/msp430-libc;a=blob;f=pn-decode.txt;h=bee4afbd76934f88371971f8d89c55081fea0f9f;hb=ti
> >
> >>
> >
> > Of the 270 distinct MSP430 MCUs in the latest list provided to me, 98
> cannot
> > be genericized in this way because the genericization is ambiguous.
> For
> > example, the MSP430F2131 and MSP430G2131 differ in RAM and ROM size and
> > offsets. The MSP430F423 has hardware multiply support, while the
> > MSP430FE423 and MSP430F423A do not. The MSP430F1111 has information
> > sections, while the MSP430C1111 does not.
> >
> > TI provides 61 legacy header files which can be shared for multiple
> chips.
> > For example, the msp430x16x.h would work for MSP430F1610 MSP430F1611
> > MSP430F1612 MSP430F167 MSP430F168 and MSP430F169--however, those chips
> still
> > have different address maps, so a generic msp430x16x fails to provide
> enough
> > information to allow an application to be linked.
> >
> > Attempting to detect when it is safe to recognize a generic name, and
> what
> > prototypical MCU to map it to, is the road to insanity. TI advises that
> new
> > projects should not use the legacy headers.
> >
> > Here's the point: The uniarch updates to mspgcc will no longer support
> > genericized mcu names.
> >
> > Under the current plan, you will have your choice:
> >
> > - Specify a recognized part, e.g. -mmcu=msp430f1611
> > - Specify one of two special-case generic parts, -mmcu=msp430generic
> or
> > -mmcu=msp430xgeneric, and only build relocatable object files (not
> > applications)
> > - Skip the -mmcu option, get whatever happens by default, and don't
> > attempt to reference device registers or constants
> >
> > Whatever you put as the -mmcu parameter to gcc will automatically be
> defined
> > as a preprocessor macro, after conversion to upper case and
> encapsulation in
> > double-underscores: e.g., using -mmcu=msp430f1611 will cause
> __MSP430F1611__
> > to be defined and available for conditional processing.
> >
> > Consequently, certain defines like __MSP430_1611__ which are really
> > alternative spellings of the genericized name will no longer be
> > automatically provided by the compiler. You can, of course, add them
> > yourself.
> >
> > Sorry, this is going to break some code. It'll probably be possible to
> work
> > around this with a legacy.h header that does some magic, but I won't get
> to
> > that in the initial releases, and will prioritize it below things like
> > integrating 20-bit pointer support and improving other optimizations
> unless
> > I hear a lot of really really loud objections.
> >
> > Peter
> >
>
>
>
>
>
> ------------------------------------------------------------------------------
> The modern datacenter depends on network connectivity to access resources
> and provide services. The best practices for maximizing a physical server's
> connectivity to a physical network are well understood - see how these
> rules translate into the virtual world?
> http://p.sf.net/sfu/oracle-sfdevnlfb
> _______________________________________________
> Mspgcc-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/mspgcc-users
>
------------------------------------------------------------------------------
The modern datacenter depends on network connectivity to access resources
and provide services. The best practices for maximizing a physical server's
connectivity to a physical network are well understood - see how these
rules translate into the virtual world?
http://p.sf.net/sfu/oracle-sfdevnlfb
_______________________________________________
Mspgcc-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
