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
