mlt - assembler error have_mmx.S: Assembler messages: Error: operand type mismatch for `push'
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?
On Sat, 24 Mar 2012 01:29:13 -0500 "David C. Rankin" drankinatty@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.
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.
On Sat, 24 Mar 2012 10:24:53 -0500 "David C. Rankin" drankinatty@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.
On 29 Mar 2012, dev stated:
On Sat, 24 Mar 2012 10:24:53 -0500 "David C. Rankin" drankinatty@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.)
On 03/30/2012 09:36 AM, Nix 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.
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.)
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 :)
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
On Fri, 30 Mar 2012 15:36:34 +0100 Nix nix@esperi.org.uk wrote:
On 29 Mar 2012, dev stated:
On Sat, 24 Mar 2012 10:24:53 -0500 "David C. Rankin" drankinatty@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.
On 30 March 2012 15:22, /dev/ammo42 mickeytintincolle@yahoo.fr wrote:
On Fri, 30 Mar 2012 15:36:34 +0100 Nix nix@esperi.org.uk wrote:
On 29 Mar 2012, dev stated:
On Sat, 24 Mar 2012 10:24:53 -0500 "David C. Rankin" drankinatty@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.
Will this impact Trinity on ARM?
Calvin
On Fri, 30 Mar 2012 15:40:05 -0400 Calvin Morrison mutantturkey@gmail.com wrote:
On 30 March 2012 15:22, /dev/ammo42 mickeytintincolle@yahoo.fr wrote:
On Fri, 30 Mar 2012 15:36:34 +0100 Nix nix@esperi.org.uk wrote:
On 29 Mar 2012, dev stated:
On Sat, 24 Mar 2012 10:24:53 -0500 "David C. Rankin" drankinatty@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.
Will this impact Trinity on ARM?
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).
Calvin
To unsubscribe, e-mail: trinity-devel-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@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
-
/dev/ammo42 -
Calvin Morrison -
David C. Rankin -
Nix