
Rockbox mail archiveSubject: Re: coldfire EMAC routinesRe: coldfire EMAC routines
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 34 cycles for the consecutive long word (a0)+ reads in the mac.l %a5, %a3, (%a0)+, %a5, %acc1 instructions (if the data is fetched from 3111 SDRAM). If the data in %a5 is reused with a (onecycle) mac.l %a5,ry instruction then you could get almost twice the throughput within 45 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 20051027 Page template was last modified "Tue Sep 7 00:00:02 2021" The Rockbox Crew  Privacy Policy 