Re: New target for Coldfire v4e?

[Peter Barada <peter at the-baradas dot com>]

>>>uClinux required that FLAT file format and -mid-shared-library
>>>mess to support shared libraries with UNIX semantics without
>>>an MMU.
>> 
>> Then the answer to your first question is no.  The changes are to
>> m68k.h/m68k.c,m68k.md, as well as the t-linux file and I'd have to go
>> back and look, but I think maybe one or two others(pretty small
>> stuff), all in gcc/config/m68k.
>
>Are these changes disruptive for other m68k targets?

Hopefully not, but they do affect commen code generation macros and
functions.

>> gerg@snapgear.com already has a 547x/548x uClinux version(its in the
>> uclinux CVS tree), using the FLAT file format.  I'm assuming it uses
>> the current m68k-uclinux target.
>
>Last time I checked uClinux's CVS repository and web site, there
>were no clues about upcoming v4e support.
>
>It seems this whole development is happening behind a curtain.
>NDAs or what?

I beleive that I"ve checked out the uclinux tree with support for the
547x target in it, Greg and verify that.  This work hasn't been done
under NDAs, just that it isn't worth exposing it until it is known to
work. I haven't signed any NDA to see the work thus far, and you've
seen that Freescale is trying to get it integrated back into the
mainline tree.

>>>Without seeing what changes he made, I'm not really sure what
>>>would be the best option...
>> 
>> The more I work in this area, the more I think ColdFire should split
>> off into its own config directory.
>
>I tend to agree, perhaps sharing some common code.  Targets such
>as RTEMS and uClinux may want to support both architectures while
>retaining consistency in target macros such as TARGET_OS_CPP_BUILTINS.

I'm looking at splitting off the gcc/config/m68k directory into
gcc/config/coldfire for some of this and future work and adding
configs or coldfire-elf and coldfire-linux...

>>>Besides, adding a new target *can* be approved in stage 3, unless
>>>of course the new code affects other targets.  My guess is that
>>>adding v4e support impacts m68k.md and m68k.c *much* more than
>>>the t-linux parts we're discussing, so it won't qualify for 4.0.
>> 
>> I'm sure it won't make it into 4.0.
>
>Perhaps it'd better if it lives as an external patchset for a while,
>like many new targets do in their infancy.

Your probably right, but the quicker that they are seen teh quicker
they can be revamped into something acceptable to the mainline.

>> I see from the development plan that 4.0 is not going to split off
>> until early '05, so getting bite-sized patches that reviewers can
>> understand and approve(but not commit) will make it easier for other
>> people who want to develop in this area.
>
>The long-term goal may be full-merge, but in the meanwhile you
>could get to merge trivial preparatory patches to setup the ground.
>
>Besides, have you already submitted patches for config.sub and
>config.guess to the configury project?  And what about as/ld changes?

Any prepatory patched have to wait until mainline gets out of stage 3
unless the release manager doesn't care about changes to gcc that
affect a non primary or secondary port.  as/ld already support
-mcfv4e.

I don't think any patches have been submitted for config.sub.

-- 
Peter Barada
peter@the-baradas.com