[XviD-devel] Inlined ASM code again

[Michael Militzer]

Quoting Edouard Gomez <ed.gomez at free.fr>:

[...]

> @skal: sorry but i don't see any advantage from using nasm over a cpp+cc
>        couple. You have macros in both cases, you have a lot more
>        control over variables declaration with a cc (and that count on unix
> where
>        namespace pollution is a pain), and the more important one is
>        that you can hopefully use complex types (structures) directly in
>        the code... doing  so in nasm is far from easy  because of the cc
>        structure packing rules.
>        Now i must admit i  used intrinsics to test gcc capabilities, but
>        it  could be done  with simple  macros that  would just  wrap mmx
>        opcodes and nothing  more (mmx.h in ffmpeg or  mplayer or ...) so
>        you would still have the same flexibility than nowadays with nasm. 

Well, as I said if inline asm makes things faster (and fps is what counts)
then we can discuss what to do about it. However I still believe that
little is more evil when trying to (properly) port a software to a
different c compiler than the existence of inline assembler. Even if there
is a mmx.h: every compiler has different intrinsics, some don't support
all instructions and in this case the port couldn't make use of all asm 
optimizations. Also adopting such a mmx.h for a new compiler is quite a
lot of work. Simply using NASM (and keeping c and asm seperate) is much
more convenient.

Also such mmx.h wrappers often have different macros for the same asm
command (to cope with different op count or addressing modes). This is
pretty annoying - at least I don't like it ;-)

Also, as you already noticed yourself: different compilers don't produce
the same code. gcc 3.2 is fast, gcc 3.3 is slow and gcc 3.4 is fast - so
what? With NASM we can be sure that the same code is produced on every
platform regardless which c compiler (or version) is used.

bye,
Michael