This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: c4x - TMS320C30-40
- From: Hans-Peter Nilsson <hp at bitrange dot com>
- To: "Svein E. Seldal" <Svein dot Seldal at solidas dot com>
- Cc: Ralf Corsepius <corsepiu at faw dot uni-ulm dot de>, Joel Sherrill <joel dot sherrill at OARcorp dot com>, Binutils List <binutils at sources dot redhat dot com>
- Date: Wed, 4 Jun 2003 20:30:22 -0400 (EDT)
- Subject: Re: c4x - TMS320C30-40
On Thu, 5 Jun 2003, Svein E. Seldal wrote:
> Ralf Corsepius wrote:
> > IMO, then, binutils (!) should not accept "c4x".
>
> Well this is easier said than done. When Michael Hayes ported the c4x
> port to the gcc, it was named 'c4x'. All files for this port is located
> in the gcc/config/c4x directory.
>
> Later it was decided that the official name for this target should be
> 'tic4x', not 'c4x', mainly because there are other Texas Instruments
> (hence ti) targets that has applied this scheme. 'tic4x' is a more
> descriptive name than 'c4x', and coexists better with other targets.
>
> However, the gcc still uses the 'c4x' name, simply because all the files
> have been checked in under the 'c4x' name. Because you cannot simply
> rename the gcc/config/c4x to gcc/config/tic4x, gcc uses the c4x as its
> native target name. So gcc needs alias 'tic4x' as a 'c4x' target.
I think I spot a misconception: the GCC target directory name
does *not* mandate the actual target name. See xstormy16 which
lives in stormy16/. It had a name-change after the port was
included.
> On the other hand, binutils has the problem the other way around:
> binutils needs to alias 'c4x' is in fact a 'tic4x' target.
No name dependence here either.
> Thus we have the duality of this target name, in which we need to
> support both.
You might need to, but not due to any file name in gcc or
binutils.
(BTW, tic4x-elf *should* expand to tic4x-unknown-elf. There
should be no need to provide a company field; if there is, it's
a bug.)
brgds, H-P