c4x - TMS320C30-40

[Svein E. Seldal]

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.

On the other hand, binutils has the problem the other way around: 
binutils needs to alias 'c4x' is in fact a 'tic4x' target.

Thus we have the duality of this target name, in which we need to 
support both.

BTW! All other ti targets have done it in this way.

> config.sub is much more general than binutils/gcc and therefore must
> accept any target-triple anybody thinks is useful somewhere. 
> People (Admitted, probably very few) have been and are using c4x* for
> their proprietary purposes (eg. RTEMS does still support the "c4x"
> targets), therefore you (rsp. binutils) is not in a position to change
> this.

There was a discusstion about this when I filed the request for approval 
for the top-level config (nearly one year ago). I explained it to the 
top-config maintainer, and he approved. This is the first time I've run 
across issues with this method.

> My proposal: Keep tic4x and c4x separate in config.sub.
> 
> Applications (binutils, gcc, newlib, RTEMS) then can deal with these
> target_cpu's at their will.

I dont see why we shouldn't split them into two. It will require some 
changes in the configure-files in the binutils subdirs, but apart for 
that there should not be any problem implementing this.

However, for one this configuration that exists today works. And the 
fact that other targets use the same scheme, may indicate that this is a 
real way to do it.

Secondly, splitting the c4x and the tic4x does not solve Joel's problems 
entirely. We still need to set the default os of the triplet to "coff" 
for BFD to understand.


Regards,
Svein