This sounds like a perfectly good arrangement - if it makes your life easier for maintaining the binutils, then fine. The majority of users do not call the assembler or linker directly, and therefore only see the compiler's -mcpu flag. Since you are leaving that unchanged, I think most people will view changes to binutils as something that happens behind the scenes. Those relatively few users who have stand-alone assembly files will not have a problem as there is no difference to the assembler, and the few who call the linker directly should have no problems beyond changing a few lines in their makefiles - a minor change when compared to a major compiler version change.
Regards, David > Fellows, > > I got some problems with mail, so my answers may be slow. > > from now I would like to reorganize binutils: > - there are a huge number of devices of msp430 family and adding all of them > seems to be a problem cause some people complain that makefiles getting > huge. > - form assembler's point of view there is no difference between devices. > - from linker's point of view there is no difference between, say, 2101 and > 1101 ones. they both have 1k of rom and 128 bytes of ram. > > Therefore, I just want to create msp430x[RAM]x[ROM] devices > > For example: > > xx0x: 1K ROM, 128 RAM > xx1x: 2K ROM, 128 RAM > xx2x: 4K ROM, 256 RAM > xx3x: 8K ROM, 256 RAM > xx4x: 12K ROM, 512 RAM > xx5x: 16K ROM, 512 RAM > xx6x: 24K ROM, 1024 RAM > xx7x: 32K ROM, 1024 RAM > xx8x: 48K ROM, 2048 RAM > xx9x: 60K ROM, 2048 RAM > 16xx10: 32K ROM, 5K RAM > 16xx11: 48K ROM, 10K RAM > > _OR_ > x1k128 > x2k128 > x4k256 > x8k256 > x12k512 > x16k512 > x24k1024 > x32k1024 > x48k2048 > x60k2048 > x32k5k > x48k10k > > I hope this will cover all possible devices. > If start address of some area of new device will be changed in the future, > this can be handled with -Tadta, -Ttext of -Tbss options to linker. > > So, gcc (I hope 4.xx soon) will define _device_ like __MSP430x149__ as it was > before (with -mmcu=... option). > Then pass no device number to assembler (cause they are all equal). > Then pass rom/ram configuration to linker like '-m xx7x'. > GCC will not distinguish crt support functions (gcrt0.S defines default IRS > routines. Vectors are defined in header files.) > GCC will select an appropriate library (with or without hardware multiplier > support) according to device specified. > > What do you think? > > Cheers, > ~d > > > > > ------------------------------------------------------- > SF.Net email is Sponsored by the Better Software Conference & EXPO > September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices > Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA > Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf > _______________________________________________ > Mspgcc-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/mspgcc-users > > >
