GCC 4.1.1 m68k-rtems generating invalid code for -m5307 proce ssor ?

[Ralf Corsepius]

On Wed, 2007-06-27 at 10:37 +0800, Ian Caddy wrote:
> 
> Ralf Corsepius wrote:
> > On Tue, 2007-06-26 at 20:54 +0800, Mick Davis wrote:
> >> In a previous email, you listed only the rtems-supplied patch 
> >> gcc-core-4.1.1-rtems4.7-20070102.diff for the gcc source; have you made 
> >> other changes?
> >>
> >> As far as I remember, GCC doesn't build the 5307 libraries unless you 
> >> modify some options for your target.  I made the attached patch for 
> >> building our 5307 gcc.
> > 
> > What do you gain with this new multilib variant add?

> > Which showstopper problem does it solve which prevents you to use one
> > the other multilibs?
> > 
> > What is the percentage in performance gain you get (Figures please).
> 
> On our whole system idle time in a heavily loaded system we were able to 
> obtain about a 6% increase in our idle time, which put us into safe 
> territory, and meet the specification.  It was an easy fix without 
> having to go back and hand optimise large areas of code.
> 
> Normally I would agree with you about adding a variant for every 
> different processor that is, but we are talking a core version 
> difference here.
Don't get me wrong, but I've seen so many "silly please add a new
multilib variant" requests, not to question such requests.

In most cases they boil down to: "I need cpu XXX supports instruction
xyz, but I am seeing the compiler emits instruction yyz, which costs one
cpu cycle more".

> I definitely think there is a case for adding a Coldfire V3 core 
> variant, it is like having a 68000 and a 68020 variant, when everything 
> could run on 68000, but we use our own custom BSP anyway, and roll our 
> own RTEMS tools and so were able to make the change.
So you are saying a fundamental multilib variant is missing from the
rtems-m68k multilibs? 

> It really does depend on peoples requirements.  If you can get away with 
> simple, then that is fine, but we couldn't and so made the move to the 
> specific variant.
Well, it's a pity you do so, but it's your liberty to do so.

> I hope explanation helps make sense of why we needed to do it.
Yes, thanks.

While we're at it: The m68k port in upstream GCC is a shape, it is not
unlikely RTEMS can't avoid stop supporting the m68k.
 I hope, such an escalation can be avoided, but ATM I can't exclude
anything. I can only encourage anybody being interested future m68k
support in GCC/rtems to actively contribute to upstream FSF-GCC.

Ralf