[FFmpeg-devel] [PATCH] MMX for Win64

Måns Rullgård mans
Wed May 7 00:38:49 CEST 2008


Michael Niedermayer <michaelni at gmx.at> writes:

> On Tue, May 06, 2008 at 07:56:26AM +0100, Ramiro Polla wrote:
>> matthieu castet wrote:
>>> Reimar D?ffinger wrote:
>>>> On Sun, May 04, 2008 at 05:05:47PM +0100, M?ns Rullg?rd wrote:
>>>>> "Zuxy Meng" <zuxy.meng at gmail.com> writes:
>>>>>> 2008/5/4 M?ns Rullg?rd <mans at mansr.com>:
>>>>>>> It's wrong to use size_t here.  There is no guarantee that size_t
>>>>>>> is at all suitable.  For instance, it could legally be 64 bits on a
>>>>>>> 32-bit system, or 32 bits on a 64-bit system.
>>>>>> What about intptr_t?
>>>>> That's guaranteed to be at least as wide as a pointer.  Since we're
>>>>> not dealing with pointers here, it is incorrect to use it.  It is
>>>>> possible to have 32-bit pointers and 64-bit long.
>>>> What is required here (and what long is "misused" for) is native
>>>> register size. And since all of the modified code is x86 specific,
>>>> pointers and native register contents are not really distinguishable.
>>>> Still, the proposed patch just hacks a few places and is not a proper
>>>> solution.
>>> And since there already conditional code in libavutil/x86_cpu.h for X86_32 
>>> and X86_64, it could be trivial to define here the type we want.
>>
>> Attached patch passes regression tests on mingw32 and mingw64.
>>
>> Ramiro Polla
>
>> Index: libavutil/x86_cpu.h
>> ===================================================================
>> --- libavutil/x86_cpu.h	(revision 13058)
>> +++ libavutil/x86_cpu.h	(working copy)
>> @@ -31,6 +31,7 @@
>>  #    define REG_D "rdi"
>>  #    define REG_S "rsi"
>>  #    define PTR_SIZE "8"
>> +typedef int64_t register_t;
>>  
>>  #    define REG_SP "rsp"
>>  #    define REG_BP "rbp"
>> @@ -50,6 +51,7 @@
>>  #    define REG_D "edi"
>>  #    define REG_S "esi"
>>  #    define PTR_SIZE "4"
>> +typedef int32_t register_t;
>
> Id prefer reg_t as its shorter

*_t is reserved by POSIX.

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




More information about the ffmpeg-devel mailing list