[Ffmpeg-devel] [PATCH] Partial port of ffmpeg to MS Visual C - and a note on the inttypes.h issue

[Måns Rullgård]

Steve Lhomme said:
> Aurelien Jacobs wrote:
>> On Tue, 30 Jan 2007 09:25:38 +0100
>> Steve Lhomme <steve.lhomme at free.fr> wrote:
>>
>>> Michael Niedermayer wrote:
>>>> Hi
>>>>
>>>> On Mon, Jan 29, 2007 at 10:15:00AM +0100, Steve Lhomme wrote:
>>>>> Alex Beregszaszi wrote:
>>>>>> Hi,
>>>>>>
>>>>>>>> If you really want to be that gnucentric,
>>>>>>> do you know why everyone who uses visual <bluescreen, restarts system) C++
>>>>>>> has a problem with understanding the different between standart and gcc?
>>>>>>> we HATE gcc and we certainly are not, where not and never will be
>>>>>>> gnucentric, ffmpeg code is stanard C, everything else is under #ifdefs
>>>>>>> like asm, always_inline and so on
>>>>>>>
>>>>>>> it must be something like
>>>>>>> * user sees vc++ fail with random program
>>>>>>> * user sees gcc to suceed with same random program
>>>>>>> * user concludes that program is written specifically for gcc as he knows
>>>>>>>  MS always follows all standards very carefully
>>>>>> Thats a great point here.
>>>>> It's like the difference between people who prefer to use C99 and the
>>>>> ones who prefer to use a real-world compiler.
>>>>>
>>>>> Anyway, C99 doesn't cover inline ASM AFAIK so you can't seriously say
>>>>> that FFMPEG is not designed for gcc.
>>>> you know very well that they are under #ifdefs (some of the other people
>>>> who claimed that ffmpeg where written for gcc may or may not have known that
>>>> but you do as you have worked with the code) so could you maybe spare
>>> The ASM code is #ifdef'd by the makefile. If you compile the code with
>>> another compiler it will fail because the ifdefs are not clean. I
>>> actually made some changes recently to DrFFMPEG to have both ppc and
>>> i386 ASM compiled in the same project at the same time (to make
>>> universal binaries in XCode) and I had to add some cleaner #ifdef's.
>>>
>>> Nevertheless, the "full" FFMPEG is only usable with a tuned gcc. That's
>>> my whole point. Portable ASM files (to be processed by nasm and yasm) is
>>> always possible and make the code much more portable. But I understand
>>> it's not the goal of this project.
>>
>> Why would nasm or yasm be more portable than gas for example ?
>> Do nasm or yasm support ppc, arm, alpha, sparc, sh4... ?
>
> WTH are you talking about ? I'm saying that the hardware acceleration
> could be available to more than a tuned gcc, not that ASM code is
> portable across platforms.

I thought your main complaint was that the optimized code can't be built
with msvc.  If it can't be built with msvc, what difference does it make
if gcc or nasm is used instead?

That said, I personally prefer writing assembler code in separate files,
avoiding battles with the gcc register allocator, at least when I'm
writing entire functions in assembler.  For hacks involving one or two
instructions, I'll use inline assembler.

Oh, and don't even think of mentioning inline asm in msvc.

-- 
M?ns Rullg?rd
mru at inprovide.com