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

[Ian Caddy]

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 
difference here.

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 
specific variant.

I hope explanation helps make sense of why we needed to do it.

regards,

Ian Caddy


-- 
Ian Caddy
Goanna Technologies Pty Ltd
+61 8 9221 1860