GCC 4.1.1 m68k-rtems generating invalid code for -m5307 proce ssor ?
ianc at goanna.iinet.net.au
Wed Jun 27 02:37:50 UTC 2007
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?
It was a needed to meet performance requirements for a large system that
was sold. The V3 core offers quite a bit more than the V2 core which
was the default that we used to use. Only when we failed to meet the
performance requirements with the V2 core did we move to the V3 core.
The main difference between the 2 is that (from memory) the m5200 does
*not* support hardware divide and needs to be done in a library routine.
This is a huge performance impact whenever divides or mods are required.
We performed timing on just one small piece of code, which was a small
loop which someone included a mod instruction in for a ring buffer. The
problem was the mod was not divisible by 2, and hence a divide was
required. With m5200, this loop took over 300us. Using m5307, this
loop took around 30us.
This is a 10 fold improvement.
> 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
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.
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
I hope explanation helps make sense of why we needed to do it.
Goanna Technologies Pty Ltd
+61 8 9221 1860
More information about the users