This is more consistent with the way we handle C #includes and
it simplifies the build system.

This is necessary to allow refactoring some x86util macros with cpuflags.

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

This fix a bunch of "assignment from incompatible pointer type" warnings
with GCC.

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

This separates code relying on inline from that relying on external
assembly and fixes instances where the coalesced check was incorrect.

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Signed-off-by: Diego Biurrun <diego@biurrun.de>

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

To access data at multiple fixed offsets from a base address, this
code uses a single "m" operand and code of the form "32%0", relying on
the memory operand instantiation having no displacement, giving a final
result of the form "32(%rax)".  If the compiler uses a register and
displacement, e.g. "64(%rax)", the end result becomes "3264(%rax)",
which obviously does not work.

Replacing the "m" operands with "r" operands allows safe addition of a
displacement.  In theory, multiple memory operands could use a shared
base register with different index registers, "(%rax,%rbx)", potentially
making more efficient use of registers.  In the cases at hand, no such
sharing is possible since the addresses involved are entirely unrelated.

After this change, the code somewhat rudely accesses memory without
using a corresponding memory operand, which in some cases can lead to
unwanted "optimisations" of surrounding code.  However, the original
code also accesses memory not covered by a memory operand, so this is
not adding any defect not already present.  It is also hightly unlikely
that any such optimisations could be performed here since the memory
locations in questions are not accessed elsewhere in the same functions.

This fixes crashes with suncc.
Signed-off-by: Mans Rullgard <mans@mansr.com>

This code has been disabled since 2003.  Nobody will ever look at
it again.
Signed-off-by: Mans Rullgard <mans@mansr.com>

This puts x86-specific things in the x86/ subdirectory where they
belong.
Signed-off-by: Mans Rullgard <mans@mansr.com>

Refactoring mmx2/mmxext YASM code with cpuflags will force renames.
So switching to a consistent naming scheme beforehand is sensible.
The name "mmxext" is more official and widespread and also the name
of the CPU flag, as reported e.g. by the Linux kernel.

The files do not contain only MMX code.

Fixes compilation for compilers that do not support gcc inline assembly.
Signed-off-by: Diego Biurrun <diego@biurrun.de>

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>

register starvation caused gcc4.2 to fail building 32 bit shared libs
on 64 bit OS X
Signed-off-by: Michael Bradshaw <mbradshaw@sorensonmedia.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Add support for all x86-64 registers
Prefer caller-saved register over callee-saved on WIN64
Support up to 15 function arguments

Also (by Ronald S. Bultje)
Fix up our asm to work with new x86inc.asm.
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
Signed-off-by: Justin Ruggles <justin.ruggles@gmail.com>

Fixes overflows for large image sizes.

Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org

Fixes pre-processing with latest versions of nasm.