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

[Ronald S. Bultje]

Hi,

On Thu, Aug 26, 2010 at 3:10 PM, Reimar D?ffinger
<Reimar.Doeffinger at gmx.de> wrote:
> On Thu, Aug 26, 2010 at 08:02:55PM +0100, M?ns Rullg?rd wrote:
>> Reimar D?ffinger <Reimar.Doeffinger at gmx.de> writes:
>> > On Thu, Aug 26, 2010 at 05:05:26PM +0200, Dominik 'Rathann' Mierzejewski wrote:
>> >> On Thursday, 26 August 2010 at 16:34, Ronald S. Bultje wrote:
>> >> > 2010/8/26 M?ns Rullg?rd <mans at mansr.com>:
>> >> > > "Ronald S. Bultje" <rsbultje at gmail.com> writes:
>> >> [...]
>> >> > >> This "problem" is biting me in other places too, and I don't like this
>> >> > >> at all. Does anyone have opinions on best way forward from here?
>> >> > >>
>> >> > >> <crazy>
>> >> > >> How about making all SIMD-related int->long?
>> >> > >> </crazy>
>> >> > >
>> >> > > Isn't long 32-bit on win64 or something like that?
>> >> >
>> >> > Is there a type that's 32-bit on all x86-32 (or all 32-bit systems in
>> >> > existence) and 64-bit on all x86-64 (or all 64-bit systems in
>> >> > existence)?
>> >>
>> >> intptr_t?
>> >> It's supposed to be used only for pointer arithmetic, though, and I don't
>> >> like abusing it.
>> >>
>> >> Wouldn't a simple #define depending on 32/64-bitness be acceptable?
>> >
>> > Uh.. did you all forgot about x86_reg or what am I missing?
>>
>> We can't use that in generic C code. ?These interfaces are used by all
>> architectures.
>
> 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).

Ronald