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>
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.
Many functions have such a prefix, but do not actually use any
instructions or features from that set, thus giving the false
impression that swscale is highly optimized for a particular
system, whereas in reality it is not.
Keep only the plain C code in the main rgb2rgb.c and move the x86
specific optimizations to x86/rgb2rgb.c
Change the initialization pattern a little so some of it can be
factorized to behave more like dsputils.
being able to compile it and deduplicate the code at the same time.
Originally committed as revision 30978 to svn://svn.mplayerhq.hu/mplayer/trunk/libswscale
This is of course done with permissions from the authors. The only GPL
component left are MMX optimizations for YUV to RGB conversion.
Originally committed as revision 30965 to svn://svn.mplayerhq.hu/mplayer/trunk/libswscale
- Place curly brackets in the same line as while/for/if/switch/else/do;
- Place curly brackets at column 0 in the next line starting a function.
Originally committed as revision 29523 to svn://svn.mplayerhq.hu/mplayer/trunk/libswscale
- Use 4 spaces throughout for indentation;
- Fix inconsistent indentation;
- Indent function calls and declarations aligning arguments on multiple lines
to the column after the opening parentheses;
- Align asm code to the column 4 spaces after the call to __asm__();
- Align cases in switch statements to the same column as "switch".
Originally committed as revision 29522 to svn://svn.mplayerhq.hu/mplayer/trunk/libswscale
Date: Wed Mar 18 23:11:50 2009
New Revision: 28996
Log:
Fix libswscale compilation on non-x86, hopefully without breaking MinGW64 again.
This change was non optimal, correct would have been to revert the offending commits
if no time was available to find a clean fix.
Originally committed as revision 29003 to svn://svn.mplayerhq.hu/mplayer/trunk/libswscale
It seems that binutils >= 2.18 just treat eax as rax but older versions fail.
Originally committed as revision 28136 to svn://svn.mplayerhq.hu/mplayer/trunk/libswscale
Neither the asm() nor the __asm__() keyword is not part of the C99
standard, but while GCC accepts the former in C89 syntax, it is not
accepted in C99 unless GNU extensions are turned on (with -fasm). The
latter form is accepted in any syntax as an extension (without
requiring further command-line options).
Sun Studio C99 compiler also does not accept asm() while accepting
__asm__(), albeit reporting warnings that it's not valid C99 synta.
Originally committed as revision 27778 to svn://svn.mplayerhq.hu/mplayer/trunk/libswscale
These functions are never called by themselves, the alias
interleaveBytes is used instead.
Originally committed as revision 27735 to svn://svn.mplayerhq.hu/mplayer/trunk/libswscale