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

[Måns Rullgård]

Reimar D?ffinger <Reimar.Doeffinger at gmx.de> writes:

> 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!

Other architectures don't need such a type since they don't have the
problem it solves in the first place.

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