mlt - assembler error have_mmx.S: Assembler messages: Error: operand type mismatch for `push'
24 Mar
2012
24 Mar
'12
6:29 a.m.
Guys,
Strange build failure with libraries/mlt. It fails with an assembler error
that I know nothing about:
cc -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector
--param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2 -Wall -fPIC -DPIC -O4 -pipe
-fomit-frame-pointer -ffast-math -DUSE_MMX -g -D_FILE_OFFSET_BITS=64
-D_LARGEFILE_SOURCE -pthread -Wall -fPIC -DPIC -O4 -pipe -fomit-frame-pointer
-ffast-math -DUSE_MMX -g -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -pthread
-Wall -fPIC -DPIC -O4 -pipe -fomit-frame-pointer -ffast-math -DUSE_MMX -g
-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -pthread `pkg-config gtk+-2.0
--cflags` `pkg-config gdk-pixbuf-2.0 --cflags` `pkg-config pangoft2 --cflags`
-I../.. -c -o producer_pango.o producer_pango.c
cc -o have_mmx.o -c have_mmx.S
have_mmx.S: Assembler messages:
have_mmx.S:20: Error: operand type mismatch for `push'
have_mmx.S:24: Error: invalid instruction suffix for `pushf'
have_mmx.S:25: Error: invalid instruction suffix for `pop'
have_mmx.S:28: Error: invalid instruction suffix for `push'
have_mmx.S:29: Error: invalid instruction suffix for `popf'
have_mmx.S:30: Error: invalid instruction suffix for `pushf'
have_mmx.S:31: Error: invalid instruction suffix for `pop'
have_mmx.S:51: Error: invalid instruction suffix for `pop'
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?
--
David C. Rankin, J.D.,P.E.
24 Mar
24 Mar
7:35 a.m.
New subject: [trinity-devel] mlt - assembler error have_mmx.S: Assembler messages: Error: operand type mismatch for `push'
On Sat, 24 Mar 2012 01:29:13 -0500
"David C. Rankin" <drankinatty(a)suddenlinkmail.com> wrote:
Guys,
Strange build failure with libraries/mlt. It fails with an
assembler error that I know nothing about:
cc -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector
--param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2 -Wall -fPIC -DPIC -O4
-pipe -fomit-frame-pointer -ffast-math -DUSE_MMX -g
-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -pthread -Wall -fPIC
-DPIC -O4 -pipe -fomit-frame-pointer -ffast-math -DUSE_MMX -g
-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -pthread -Wall -fPIC
-DPIC -O4 -pipe -fomit-frame-pointer -ffast-math -DUSE_MMX -g
-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -pthread `pkg-config
gtk+-2.0 --cflags` `pkg-config gdk-pixbuf-2.0 --cflags` `pkg-config
pangoft2 --cflags` -I../.. -c -o producer_pango.o producer_pango.c
cc -o have_mmx.o -c have_mmx.S have_mmx.S: Assembler messages:
have_mmx.S:20: Error: operand type mismatch for `push'
have_mmx.S:24: Error: invalid instruction suffix for `pushf'
have_mmx.S:25: Error: invalid instruction suffix for `pop'
have_mmx.S:28: Error: invalid instruction suffix for `push'
have_mmx.S:29: Error: invalid instruction suffix for `popf'
have_mmx.S:30: Error: invalid instruction suffix for `pushf'
have_mmx.S:31: Error: invalid instruction suffix for `pop'
have_mmx.S:51: Error: invalid instruction suffix for `pop'
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.
3:24 p.m.
New subject: [trinity-devel] mlt - assembler error have_mmx.S: Assembler messages: Error: operand type mismatch for `push'
On 03/24/2012 02:35 AM, /dev/ammo42 wrote:
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.
--
David C. Rankin, J.D.,P.E.
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.
> >
29 Mar
29 Mar
8:22 p.m.
New subject: [trinity-devel] mlt - assembler error have_mmx.S: Assembler messages: Error: operand type mismatch for `push'
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:
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.
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.
> > 
30 Mar
30 Mar
2:36 p.m.
New subject: [trinity-devel] mlt - assembler error have_mmx.S: Assembler messages: Error: operand type mismatch for `push'
On 29 Mar 2012, dev stated:
On Sat, 24 Mar 2012 10:24:53 -0500
"David C. Rankin" <drankinatty(a)suddenlinkmail.com> wrote:
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.)
--
NULL && (void)
On 03/24/2012 02:35 AM, /dev/ammo42 wrote:
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. 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.
2:57 p.m.
New subject: [trinity-devel] mlt - assembler error have_mmx.S: Assembler messages: Error: operand type mismatch for `push'
On 03/30/2012 09:36 AM, Nix wrote:
Sheesh :)
You guys are way ahead of me on this one :)
I know what you are talking about, and where to find the sections in my old
c++ book, but that is the extent of my current knowledge of the issue. I'll
capture this information and put it in a bug report, but I can't get to
working on it until after I get the rest of the major packages patched for
libpng15 (koffice, digikam, etc..) (and then there is that week or so before
April 15 (16th this year) that is lost to uncle sam)
I'll post he bug number and if anyone stumbles across any patch information
while poking around on the web, please add it to the bug report for reference.
Thanks :)
--
David C. Rankin, J.D.,P.E.
> 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.)
4:02 p.m.
New subject: [trinity-devel] mlt - assembler error have_mmx.S: Assembler messages: Error: operand type mismatch for `push'
On 03/30/2012 09:57 AM, David C. Rankin wrote:
I'll post he bug number and if anyone stumbles
across any patch information
while poking around on the web, please add it to the bug report for reference.
Thanks :)
http://bugs.pearsoncomputing.net/show_bug.cgi?id=951
Bug includes x86_64 assembler error, broken sox compatibility and broken
qimage compatibility.
I did get it to build on i686 with:
./configure \
--prefix=${TDEDIR} \
--enable-gpl \
--disable-sox \
--disable-qimage
--
David C. Rankin, J.D.,P.E.
7:22 p.m.
New subject: [trinity-devel] mlt - assembler error have_mmx.S: Assembler messages: Error: operand type mismatch for `push'
On Fri, 30 Mar 2012 15:36:34 +0100
Nix <nix(a)esperi.org.uk> wrote:
On 29 Mar 2012, dev stated:
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.
On Sat, 24 Mar 2012 10:24:53 -0500
"David C. Rankin" <drankinatty(a)suddenlinkmail.com> wrote:
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.) On 03/24/2012 02:35 AM, /dev/ammo42 wrote:
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. > 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. 
7:40 p.m.
New subject: [trinity-devel] mlt - assembler error have_mmx.S: Assembler messages: Error: operand type mismatch for `push'
On 30 March 2012 15:22, /dev/ammo42 <mickeytintincolle(a)yahoo.fr> wrote:
On Fri, 30 Mar 2012 15:36:34 +0100
Nix <nix(a)esperi.org.uk> wrote:
Will this impact Trinity on ARM?
Calvin
On 29 Mar 2012, dev stated:
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.
> On Sat, 24 Mar 2012 10:24:53 -0500
"David C. Rankin" <drankinatty(a)suddenlinkmail.com> wrote:
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.) 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.
7:44 p.m.
New subject: [trinity-devel] mlt - assembler error have_mmx.S: Assembler messages: Error: operand type mismatch for `push'
On Fri, 30 Mar 2012 15:40:05 -0400
Calvin Morrison <mutantturkey(a)gmail.com> wrote:
On 30 March 2012 15:22, /dev/ammo42
<mickeytintincolle(a)yahoo.fr>
wrote:
Anyway any MMX/SSE code will have to be disabled.
Apparently on ARM
NEON is a similar instruction set but I don't know if there's a way of
doing run-time detection of NEON (like CPUID on x86/amd64).
On Fri, 30 Mar 2012 15:36:34 +0100
Nix <nix(a)esperi.org.uk> wrote:
Will this impact Trinity on ARM? On 29 Mar 2012, dev stated:
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.
> 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.)
Calvin
---------------------------------------------------------------------
To unsubscribe, e-mail:
trinity-devel-unsubscribe(a)lists.pearsoncomputing.net For additional
commands, e-mail: trinity-devel-help(a)lists.pearsoncomputing.net Read
list messages on the web archive:
http://trinity-devel.pearsoncomputing.net/ Please remember not to
top-post:
http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
4417
days inactive
4423
days old
9 comments
4 participants
participants (4)
-
/dev/ammo42 -
Calvin Morrison -
David C. Rankin -
Nix