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

[Alex Converse]

On Thu, Aug 26, 2010 at 3:02 PM, M?ns Rullg?rd <mans at mansr.com> 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.
>

generalize it into machine_reg?