This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: New target for Coldfire v4e?


>>>Would there now be separate m68k and coldfire targets?  Said another
>>>way, would m68k-XYZ be able to include Coldfire support?
>> 
>> 
>> The suggestion as I put it forth would be no.  You have sepperate
>> tools, one --target=m68k-xyz for the m68k family, and
>> --target=coldfire-xyz for the ColdFire family.
>
>Obviously this has impact beyond gcc and would have to be
>coordinated.  Targets would have to be added to at least
>binutils, gdb, and newlib.
>
>If a decision is made to move on this, I would suggest
>that a push is made to get the targets into the other
>tools soon so official releases with coldfire-xyz
>have a chance to show up before they are requred by gcc.

Yet another part I hand't thought of yet...

I agree that we would have to make patches to binutils and newlib to
support the coldfire-xyz targets and have those go through at least
one release cycle *before* splitting ColdFire off from the m68k backend.


>I would also suggest that we consider being generous
>with multilibs on both targets.  It looks like
>m68k-rtems would only be able to go down 1 multilib
>(m5200 based upon 3.3.5) while coldfire could be
>expanded to have omre optimal libraries for some
>variants.
>
>Personally I don't have a problem with coldfire targets
>not defining m68k although it will take a while to get
>all the software fixed.  As someone said earlier,
>embedded developers are cautious and the gcc adoption
>timeframe is longer than with Linux distributions.
>I would be surprised if it didn't take years to see
>all the impacts of not defining m68k.  How many
>embedded developers are still using gcc 2.95?

We could leave the current m68k definitions in place for
--target=coldfire-xyz for a few revs with the indication that it will
be removed.


I don't expect this to be in gcc within the next *year*, butunless the
issue is rasied now, decided on, and put on the development plan for
the m68k target, it will never get addressed and we end up with even
more software keying off of m68k definitions for ColdFire support.

-- 
Peter Barada
peter@the-baradas.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]