hi Erland,<br><br><div class="gmail_quote">On Tue, Jun 17, 2008 at 2:04 AM, Erland Lewin <<a href="mailto:erland@lewin.nu">erland@lewin.nu</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hello Saurabh,<br><br>2008/6/16 saurabh gupta <<a href="mailto:saurabhgupta1403@gmail.com" target="_blank">saurabhgupta1403@gmail.com</a>>:<br><div class="gmail_quote"><div class="Ih2E3d"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
So, I have written fixed point codes in which all calculations are handled through fixed point. I have used the 16:16 notation for fixed point and used 32 bit integer to represent a fixed point.</blockquote></div><div><br>
FWIW, when I wrote an embedded speech recognition engine, I used 16 bits for most of the data in the models etc. If you could manage to store values in 16 bits rather than 32, then I your memory requirements could be halved, and probably performance increase significantly, since the cpu to memory bandwidth would be lower, and I think that might be a performance bottleneck. However, it required careful tracking of what range of values were actually required in various stages of the algorithm.</div>
</div></blockquote><div><br>This was the point where I thought this way. Please correct me if I am wrong. Since the word length of ARM processor of FR is 32bit, I chose 32 bit size for the fixed point notation. In using 32 bit fixed point notation, my range of both integer and fraction part also increases.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="gmail_quote"><div><br>
<br></div><div class="Ih2E3d"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Multiplication and division procedures for fixed point are implemented through macros. As the project progresses, the stress will be given to optimize the codes <br>
more.</blockquote></div><div><br>I hope you won't have to do much if any division because division is quite slow. If there are variables you need to divide by, try storing 1/x instead of x, and then doing multiplication instead of division if you can manage that.</div>
</div></blockquote><div><br>I did do that whenever I had to divide by the constant numbers. But at some points, the situation happens to perform the division by run time variables and so, I had to implement the fixed point division too. <br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="gmail_quote"><div><br>
<br>Good luck,<br><br>Erland<br><br></div></div><br>
<br>_______________________________________________<br>
Openmoko community mailing list<br>
<a href="mailto:community@lists.openmoko.org">community@lists.openmoko.org</a><br>
<a href="http://lists.openmoko.org/mailman/listinfo/community" target="_blank">http://lists.openmoko.org/mailman/listinfo/community</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br>Saurabh Gupta<br>Electronics and Communication Engg.<br>NSIT,New Delhi<br><br>