Re: [PATCH] more problems with newlib/libc/machine/m68k/memcpy.S

["Aaron J. Grier" <agrier at poofygoof dot com>]

On Wed, Feb 10, 2010 at 11:21:15AM +0100, Josef Wolf wrote:

> On Tue, Feb 09, 2010 at 05:10:38PM -0800, Aaron J. Grier wrote:
> > On Tue, Feb 09, 2010 at 03:15:11PM +0100, Josef Wolf wrote:
> > > 3. -mcpu32 seems to imply -mc68020.
> >
> > it's been this way for years and is arguably incorrect, as neither
> > instruction set is a superset of the other.
>
> I don't think there is a proper way to fix this, since it depends not
> only on the CPU, but also on how memory is connected.

I was commenting on -mcpu32 implying -mc68020.  the two share a subset
of instructions, but optimizations for one do not necessarily imply
benefit for the other.

> IMHO, the best option is to be conservative. It's better to have
> suboptimal code on some CPU than get address errors on some other CPU.

yes, absolutely.  working code is always preferred to non-working code.
:)  unaligned transfers not handled by hardware must be handled by
software, even if it's non-optimal.

> > I have also noticed that there is a point of diminishing returns for
> > jumping through alignment hoops.  depending on the CPU speed, it may
> > be faster to do a zero-overhead byte copy for small transfers rather
> > than go through alignment setups.
> 
> Does this really depend on CPU speed? I think CPU-type and existence of
> caches is the distinguishing factor here.

thinking about this, you are correct, it's not affected by CPU speed.
the overhead is a fixed percentage.

I don't believe any CPU32 pas has cache to speak of (unless you count
instruction fetch buffer) but 68020 does.  (I think 68010 has a loop
mode but no cache?)

-- 
  Aaron J. Grier | "Not your ordinary poofy goof." | agrier@poofygoof.com