[FFmpeg-cvslog] r24926 - trunk/libavcodec/x86/vp56dsp.asm
Måns Rullgård
mans
Thu Aug 26 22:27:55 CEST 2010
Reimar D?ffinger <Reimar.Doeffinger at gmx.de> writes:
> On Thu, Aug 26, 2010 at 08:39:25PM +0100, M?ns Rullg?rd wrote:
>> Reimar D?ffinger <Reimar.Doeffinger at gmx.de> writes:
>> > On Thu, Aug 26, 2010 at 03:25:52PM -0400, Ronald S. Bultje wrote:
>> >> On Thu, Aug 26, 2010 at 3:10 PM, Reimar D?ffinger
>> >> <Reimar.Doeffinger at gmx.de> wrote:
>> >> > I complained about the name back then already, but x86_reg is designed
>> >> > to and can be used just fine on all architectures, there really
>> >> > is no need to reinvent the wheel.
>> >> > If the term "x86" alone makes you run away screaming then the
>> >> > solution is to rename it and move it out of x86_cpu.h, but
>> >> > you certainly don't need to reinvent it!
>> >>
>> >> Got it, the name confused me. I'm OK with it then, if Mans is OK also
>> >> (even though the problem is limited to x86 only, apparently).
>> >
>> > 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.
>
> I'd appreciate it if you could give me the impression
> of at least trying to understand me instead of just
> finding a way to bash x86.
Well, I'm sorry if x86 is more of a botch job than just about any
other architecture around. Do you want me to imagine insane quirks in
the others too just to make it more fair?
> But in case I was unclear, I actually managed to construct
> a case (of course very artificial) that shows the issue
> _in principle_ even with non-broken/ancient compilers.
>
> extern long j;
> extern char *array;
> int test(void)
> {
> int i;
> int s;
> for (i = 0; i < j; i++)
> s += array[i];
> return s;
> }
> int test2(void)
> {
> unsigned i;
> int s;
> for (i = 0; i < j; i++)
> s += array[i];
> return s;
> }
> int test3(void)
> {
> unsigned long i;
> int s;
> for (i = 0; i < j; i++)
> s += array[i];
> return s;
> }
>
> Compiled on PowerPC 64 the three loops are:
> .L3:
> lbzx 0,9,11
> addi 11,11,1
> add 0,0,3
> extsw 3,0
> bdnz .L3
>
> .L9:
> lbzx 9,10,11
> addi 0,11,1
> rldicl 11,0,0,32
> add 9,9,3
> cmpd 7,11,8
> extsw 3,9
> blt 7,.L9
>
> .L14:
> lbzx 0,9,11
> addi 11,11,1
> add 0,0,3
> extsw 3,0
> bdnz .L14
Yes, the compiler did a badly with the 32-bit unsigned counter. What
is that supposed to prove?
--
M?ns Rullg?rd
mans at mansr.com
More information about the ffmpeg-cvslog
mailing list