David Liontooth wrote:
> Francesco Romani wrote:
>   
>> On Sat, 21 Apr 2007 12:23:25 -0700
>> David Liontooth <[EMAIL PROTECTED]> wrote:
>>
>>   
>>     
>>>> This is x86; config.h attached.
>>>>       
>>>>         
>> Thanks.
>> Could you please also specify the OS X and gcc versions? 
>>   
>>     
> uname:
> Darwin Kernel Version 8.9.1: Thu Feb 22 20:55:00 PST 2007;
> root:xnu-792.18.15~1/RELEASE_I386 i386 i386
>
> gcc -v:
> Using built-in specs.
> Target: i686-apple-darwin8
> Configured with: /private/var/tmp/gcc/gcc-5367.obj~1/src/configure
> --disable-checking -enable-werror --prefix=/usr --mandir=/share/man
> --enable-languages=c,objc,c++,obj-c++
> --program-transform-name=/^[cg][^.-]*$/s/$/-4.0/
> --with-gxx-include-dir=/include/c++/4.0.0 --with-slibdir=/usr/lib
> --build=powerpc-apple-darwin8 --with-arch=nocona --with-tune=generic
> --program-prefix= --host=i686-apple-darwin8 --target=i686-apple-darwin8
> Thread model: posix
> gcc version 4.0.1 (Apple Computer, Inc. build 5367)
>
> Thanks for looking into this!
>
> Cheers,
> Dave
>
>
>   
[I'd sent this earlier, but didn't see it on gmane

[EMAIL PROTECTED] 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 MacIntel OSX test machine.

Dave




Reply via email to