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

[Ronald S. Bultje]

Hi,

On Thu, Aug 26, 2010 at 2:53 PM, Reimar D?ffinger
<Reimar.Doeffinger at gmx.de> wrote:
> 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?

These are dsputil function prototypes... I know arm doesn't actually
use C in its SIMD so it couldn't care less, but do you want x86_reg in
libavcodec/dsputil.h?

Ronald