<div dir="ltr"><div><div><div><div><div><div><div><div>Hi,<br></div>one potential problem with 64 bits is for example the (usqInt) cast when shifting &gt;&gt;<br><br></div>Example:<br><br>    (((usqInt) sourceWord) &gt;&gt; 24)<br><br></div><div>will correctly extract the 8 high bit is sourceWord is an unsigned int.<br></div><div>if source word is an declared as int, then we will get a sign extension<br><br></div><div>(usqInt) 0xF7654321 -&gt; 0xFFFFFFFFF7654321UL<br><br></div></div>If with don&#39;t bitAnd: 0xFF the result, it ain&#39;t gonna meet our expectations.<br><br></div><div>That rarely happen that we declare int, by default it&#39;s rather sqInt.<br></div>But things like <br></div>   sqInt foo = long32At( oop , index );<br></div>will also perform a sign extension...<br></div><div>Even if (((usqInt) foo) &gt;&gt;24) doesn&#39;t perform the sign extension by itself, we get the same behaviour at the end.<br></div><div><div><div><div><br></div><div>If we carefully place a &#39;unsigned int&#39; type hint in a method, it is thus vital that this type be preserved with inlining.<br><br></div><div>When I analyze the code, most long32At could in fact be replaced with unsignedLong32At. If tthat didn&#39;t make much difference in 32 bits, it seems more vital to me with 64 bits sqInt...<br></div><div><br></div></div></div></div></div>