cremes.devlist@mac.com wrote:
[cross-posted to transcode-dev]
On Apr 23, 2007, at 8:15 PM, David Liontooth wrote:
The latest stable release of transcode, 1.0.3, configures without problems using the current macports packages, but it doesn't build:
gcc -DHAVE_CONFIG_H -I. -I. -I.. -D_REENTRANT -DLINUX -I.. -Wall -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -g -O2 -no-cpp-precomp -D_INTL_REDIRECT_MACROS -MT tcmemcpy.lo -MD -MP -MF .deps/tcmemcpy.Tpo -c tcmemcpy.c -fno-common -DPIC -o .libs/tcmemcpy.o /var/tmp//ccMwDlN6.s:43:missing or invalid immediate expression `0b111' taken as 0 /var/tmp//ccMwDlN6.s:43:suffix or operands invalid for `and' /var/tmp//ccMwDlN6.s:117:missing or invalid immediate expression `0b11' taken as 0 /var/tmp//ccMwDlN6.s:117:suffix or operands invalid for `and' /var/tmp//ccMwDlN6.s:176:missing or invalid immediate expression `0b111' taken as 0 /var/tmp//ccMwDlN6.s:176:suffix or operands invalid for `and' /var/tmp//ccMwDlN6.s:199:missing or invalid immediate expression `0b11' taken as 0 /var/tmp//ccMwDlN6.s:199:suffix or operands invalid for `and' /var/tmp//ccMwDlN6.s:206:Alignment too large: 15. assumed. /var/tmp//ccMwDlN6.s:263:missing or invalid immediate expression `0b11' taken as 0 /var/tmp//ccMwDlN6.s:263:suffix or operands invalid for `and' make[2]: *** [tcmemcpy.lo] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2
I've looked into this a bit. It's choking on some inline assembly in the file ~/aclib/tcmemcpy.c. This file contains functions optimized for memcopy on x86 processors. The surrounding lines look like:
# First align destination address to a multiple of 8 bytes \n\ mov $8, %%eax # EAX <- (8-dest) & 7 \n\ sub %%edi, %%eax \n\ and $0b111, %%eax # ... which is the number of bytes to copy\n\ lea 0f, %%edx # Use a computed jump--faster than a loop\n\ sub %%eax, %%edx \n\ jmp *%%edx # Execute 0-7 MOVSB's \n\
I don't know x86 assembly at all, so I'm hoping someone on the list can chime in here. It (gcc or gas) bitches about this line:
and $0b111, %%eax # ... which is the number of bytes to copy\n\
Is this valid assembly for gcc-4.0.1?
Maybe we are running into a bug or feature disparity with the version of gcc we are using (4.0.1). Any suggestions on how to repair this error? Since I can successfully compile on PowerPC there must be "straight C" implementations of these functions. Any way to selectively choose to use them when compiling transcode instead of the optimized versions? There's a previous discussion on what looks like the same code on 26 January 2005, when Andrew Church submitted the aclib patch -- see http://osdir.com/ml/video.transcode.devel/2005-01/msg00080.html for the final version. A few days later he added x86-64 assembly for aclib (which works great).
The configure script outputs, checking for build architecture... Intel Pentium architecture (IA32) checking if $CC groks MMX inline assembly... yes checking for support of 3DNow in assembly code... yes checking if $CC groks SSE inline assembly... yes checking if $CC can handle SSE2 inline asm... yes checking if $CC groks AltiVec inline assembly... no checking if $CC groks AltiVec C extensions... no I installed yasm and nasm, both available in macports, and I tried the suggested workaround "ac_cv_path_NASM=no", but compilation of aclib still fails on the assembly code: Making all in aclib if /bin/sh ../libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I.. -D_REENTRANT -DLINUX -I.. -Wall -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -g -O2 -no-cpp-precomp -D_INTL_REDIRECT_MACROS -MT tcmemcpy.lo -MD -MP -MF ".deps/tcmemcpy.Tpo" -c -o tcmemcpy.lo tcmemcpy.c; \ then mv -f ".deps/tcmemcpy.Tpo" ".deps/tcmemcpy.Plo"; else rm -f ".deps/tcmemcpy.Tpo"; exit 1; fi mkdir .libs gcc -DHAVE_CONFIG_H -I. -I. -I.. -D_REENTRANT -DLINUX -I.. -Wall -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -g -O2 -no-cpp-precomp -D_INTL_REDIRECT_MACROS -MT tcmemcpy.lo -MD -MP -MF .deps/tcmemcpy.Tpo -c tcmemcpy.c -fno-common -DPIC -o .libs/tcmemcpy.o /var/tmp//ccMAYFCQ.s:43:missing or invalid immediate expression `0b111' taken as 0 Looks like the assembly code needs some tweaking for MacIntel x86. Andrew, contact me if you need a test machine. Dave