On 29 Mar 2012, dev stated:
On Sat, 24 Mar 2012 10:24:53 -0500
"David C. Rankin" <drankinatty(a)suddenlinkmail.com> wrote:
> On 03/24/2012 02:35 AM, /dev/ammo42 wrote:
> >> Does this mean I'm missing a library that it needs. I can't
> >> ready
> >> > the assembler code for nothing, so I hope so. What's the
> >> > trick?
> > From
http://www.x86-64.org/documentation/assembly.html :
> > push/pop with 32-bit registers are illegal in amd64. You need
> > to disable compilation of this file as it is x86 only
> > assembly.
>
> You are good. Thank you. So the source needs a rewrite for
> x86_64 to eliminate the push/pop. That will be set in the lower
> priority column.
Actually a --disable--mmx option is documented on configure.
And for the rewrite, replacing e?x by r?x in assembler files
won't be enough, some other code also has to be changed to
accommodate the different calling conventions (function
arguments on linux-x86 are on the stack, but the first ones on
linux-amd64 are in the 64-bit registers). Perhaps using inline
assembly would allow having only one version of the assembly
code.
More generally, if you're rewriting it for x86-64 anyway, keeping
it MMX seems pretty much pointless. Just go all the way to SSE, or
better that SSE2: you'll cut off almost no hardware and be much
more useful in future. (AVX is probably a step too far: a lot of
toolchains don't support it yet, and I don't know anyone with AVX
hardware.)
The amd64 specifications include MMX and SSE2 (with 16 SSE registers
instead of 8 in x86), so every amd64 processor can do SSE2. And
also, composite_line_yuv_mmx.S already has a SSE opcode (pextrw).
But you are right, if operations can be easily parallelized we had
better use SSE2, which allows using MMX opcodes on SSE registers
which are 2 times wider than the MMX ones. And allow the use of
SSE2 on x86 if cpuid detects its presence.
>