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

Måns Rullgård mans
Thu Aug 26 22:58:14 CEST 2010

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

More information about the ffmpeg-cvslog mailing list