GCC 4.1.1 m68k-rtems generating invalid code for -m5307 proce ssor ?
ralf.corsepius at rtems.org
Wed Jun 27 03:25:06 UTC 2007
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
> 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.
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.
More information about the users