Hi Thom,

Thom Johansen <thomj@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 Thu Oct 27 18:14:13 2005