[FFmpeg-cvslog] r24926 - trunk/libavcodec/x86/vp56dsp.asm

[Måns Rullgård]

Loren Merritt <lorenm at u.washington.edu> writes:

> On Thu, 26 Aug 2010, M?ns Rullg?rd wrote:
>> Reimar D?ffinger <Reimar.Doeffinger at gmx.de> writes:
>>>
>>> This specific problem? Yes.
>>> The problem in general? Not so sure.
>>> Nowadays compilers tend to be brighter, but one of the issues tended to be that
>>> something like
>>> int i;
>>> for (i = 0; i < j; i++)
>>>    array[i];
>>> ended up with a sign-extension inside the loop.
>>> I'd think that is not that unlikely to apply to other 64 bit
>>> architectures as well and would make a "register-size" type
>>> useful for them as well.
>>
>> That problem is also specific to x86.  I know of no other architecture
>> where the declared type of the counter would make a difference in a
>> construct like that.
>
> Just to be clear: You're saying that there are no archs other than x86
> where int is 32bit and pointer is 64bit?

No, and stop being obtuse.  I'm saying that all other 64-bit archs I
know of simply sign-extend 32-bit values when they are loaded from
memory, if their type is signed, and operate on the full 64-bit
registers.  In some cases a 32-bit result of an instruction is
automatically sign-extended when placed in a 64-bit register.  In
either case, the declared type of an array index has no effect on the
generated code beyond what is implied by the integer promotion rules
of C.

-- 
M?ns Rullg?rd
mans at mansr.com