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

[Måns Rullgård]

"Ronald S. Bultje" <rsbultje at gmail.com> writes:

> 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).

How would you define this magic type on systems with 64-bit registers,
64-bit long, and 32-bit pointers (common for MIPS64 and PPC64).  These
particular functions should clearly be using a 32-bit parameter in
this case.  Some other uses of the type probably really want the full
native register width.

There is no generic solution.

On x86, something has to do the sign-extension regardless of what type
is used.  Adding the one or two instructions needed to the asm
functions isn't all that bad IMO.

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