Re: c4x - TMS320C30-40

[Ralf Corsepius <corsepiu at faw dot uni-ulm dot de>]

Am Mit, 2003-06-04 um 18.40 schrieb Joel Sherrill:
> "Svein E. Seldal" wrote:
> > 
> > I have taken the liberty to continue this discussion in the public forum
> > of the binutils list...
> 
> Fine by me.
> 
> > Joel Sherrill wrote:
> > > Well I can report that is builds.  There is a problem in the top level
> > > config.sub which breaks tic4x-rtems and c4x-rtems.  Neither is in the
> > > master list of CPUs (variable name basic_machine) around line 223.
> > > Worse, later (line 916) c4x* (notice the *) is always mapped to
> > > tic4x-unknown.
> > > I deleted the "*" on line 916 and added c4x and tic4x to the list of
> > > basic
> > > machines and it now recognizes tic4x-rtems and c4x-rtems.  I am not
> > > 100% sure of the fix but know that ./config.sub gives me the answer I
> > > expect for the following cases:
> > >
> > > c4x-coff
> > > c4x-elf
> > > c4x-rtems
> > > tic4x-coff
> > > tic4x-elf
> > > tic4x-rtems
> > >
> > > Before my mods tic4x-* --> tic4x-coff and ditto for c4x.
> > 
> > Well this is a kind of issue. First of all, config.sub should report
> > 'tic4x' when you input 'c4x'.
I do not agree on this. 

Why not keeping them separate? c4x is one thing, tic4x is a different
one. If people want to use your C40 ports, just tell them to use
tic4x-*.

> >  This is a part of the depreciated name
> > thing. It enables people to still use the c4x as a targetname for the
> > tic4x, because the 'c4x' name does not work in the binutils.
IMO, then, binutils (!) should not accept "c4x".

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.

> I should have been more formal about the output of config.sub.  The 
> output is the same with the config.sub shipped with gcc 3.3
> and binutils 2.13.91.

> bash-2.05$ sh -x /tmp/j1
> + ./config.sub tic4x-coff
> tic4x-unknown-coff
> + ./config.sub tic4x-elf
> tic4x-unknown-coff
> + ./config.sub tic4x-rtems
> tic4x-unknown-coff
> + ./config.sub c4x-coff
> tic4x-unknown-coff
> + ./config.sub c4x-elf
> tic4x-unknown-coff
> + ./config.sub c4x-rtems
> tic4x-unknown-coff
> 
> No matter what you provide to config.sub, you end up with tic4x-coff.

You have just discovered, why I introduced a hacked config.sub to RTEMS.

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.

Ralf