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

[Reimar Döffinger]

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!