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

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