From: Frieder Ferlemann <Frieder.Ferlemann_at_web.de>
Date: Thu, 27 Oct 2005 18:13:42 +0200

Hi Thom,

Thom Johansen <thomj_at_pvv.ntnu.no> schrieb am 27.10.2005 17:33:31:
> > b) clears the accumulator before use
> Ìn Rockbox, everyone who uses accumulators are responsible for
> clearing them after use, exactly so we don't have to constantly
> worry about clearing them before use (there's no point in not
> clearing them anyway, since we've got the movclr instruction).

thanks for clarifying:)

> > c) uses the fetched data to calculate the current
> > and the next data. (for .order8 only and assuming an
> > even number of input data)
> How exactly will there be additional benefit if the input
> data is fetched from slow RAM? The instruction will block until
> the load is done anyway.

Yes, it blocks but only half as often (the inner loop iterates only
half the number of rounds and the additional mac.l rx,ry takes
its arguments from registers).

I'm not familiar with the 5249 SDRAM data read access, the
corresponding wait states and the pipelining stuff so I'm rather
guessing now:
I assume at least 3-4 cycles for the consecutive long word (a0)+ reads in the
mac.l %a5, %a3, (%a0)+, %a5, %acc1
instructions (if the data is fetched from 3-1-1-1 SDRAM).
If the data in %a5 is reused with a (one-cycle) mac.l %a5,ry instruction
then you could get almost twice the throughput within 4-5 cycles.
(Maybe this reasoning is wrong)

> Do you know if the input data size assumption is valid?

No I don't. Please excuse me for jumping into the topic without having
any Rockbox context.

> In any case, I'll wait with commiting this change until I can
> actually measure if it's beneficial in any way.

Yes, please:)

> > d) reduce rounding error
> What rounding error? This is FLAC we're talking about, there
> should be no rounding error.

Yes, you're right. This was my boguous reasoning:
If the algorithm calculates f.e. the 1/8 the of the sum x(i)*y(i) (with i=0 to 7)
then I was assuming that Sum/8 is slightly worse than (Sum+4)/8.
(Both results will have the same average rounding but (Sum+4)/8
is more symmetrical around zero)
But I see I'm wrong there (FLAC will have taken this into account
during encoding), so simply forget point d)

Greetings,
Frieder
______________________________________________________________
Verschicken Sie romantische, coole und witzige Bilder per SMS!
Jetzt bei WEB.DE FreeMail: http://f.web.de/?mc=021193
Received on 2005-10-27