loody <miloody@xxxxxxxxx> writes:
>> Â Probably because in 2.6.30 you only cast the result of 32-bit multiplies
>> to 64 bits. In the 2.6.33 kernel, the mutliplies are 64-bit as the
>> 0x000010c7ull constant is 64-bit...
>
>>> void __udelay(unsigned long us)
>>> {
>>> Â Â Â Âunsigned int lpj = current_cpu_data.udelay_val;
>>>
>>> Â Â Â Â__delay(((unsigned long long)(us * 0x000010c7 * HZ * lpj)) >> 32);
> so that means (us * 0x000010c7 * HZ * lpj) is calculated at 32-bits and finally
> (unsigned long long) cast it as 64-bits?
> if i remember correctly, "64bit cast to 32-bits" is possible get 0
> value, since high bits cast out.
> But how 34-bits cast to 64-bits will make the value as 0 if original
> low 32-bits value is non-zero?
I don't know the type of HZ. But assuming it is a constant, then the
rules of C are that the expression
us * 0x000010c7 * HZ * lpj
gets evaluated in the type "unsigned long". The fact that you then cast
that "unsigned long" value to "unsigned long long" does not cause the
multiplication to be done in the type "unsigned long long".
You need to write something like
(unsigned long long) us * 0x000010c7 * HZ * (unsigned long long) lpj
to get the multiplication to be done in the "unsigned long long" type.
This questoin has nothing to do with gcc, by the way, it's a C language
question.
Ian
