Dmitry wrote:
from now I would like to reorganize binutils:
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
...
16xx11: 48K ROM, 10K RAM
while this uses TI's description it isn't very transparent for the user.
who remembers that xx5x means 16k Flash... and it has the drawback that
TI might change the naming scheme for new CPUs.
x1k128
x2k128
...
x60k2048
the name only contains information about Flash/RAM sizes, but there are
also differences in memory layout (e.g. the 16xx devices with RAM where
others have Flash)
i guess the xx1x format is preferable. while it isn't so transparent as
the other, it doesn't sugest that you know enough about the device by
just looking at the filename.
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.
i guess adding one or two linker files in the future should not be a
problem. that will probably be needed if TI releases new devices (they
have a few interesting parts in the roadmap that are likely to have a
different memory layout, more that just flash start address changes)
So, gcc (I hope 4.xx soon) will define _device_ like __MSP430x149__ as it was
before (with -mmcu=... option).
that's good. that measn that for the normal user, nothing changes. only
special projects that work with custom linker scripts or do some other
tricks must be adapted.
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?
sounds reasonable to me.
- it's backwards compatible as long as the user uses the -mmcu=
- it reduces the number of files, less duplicate information
- binutils get more independent, so that in many cases adding a new
device only requires changes to gcc and not binutils.
chris
