[libdv-dev] Re: Trouble compiling...

[Charles 'B. K. <kr...@ac...>]

Hi Scott,

I've been out of town for the last week.

"Scott F. Johnston" <sc...@wb...> writes:

> I'm trying to recompile libdv on an SGI, as I've got some files I
> want to convert to frames.

> So much time has gone into optimizing libdv for intel architecture
> that I'm having all sorts of trouble with it under IRIX. Some things
> I can patch, but others I'm at a loss for. There are two basic
> categories of problems:

>   * Compiler restrictions

Yes, I have been liberal in spots of code, assuming that we are using
gcc.  I used a number of gcc specific language extensions.   

>   * ARCH_X86 mmx and asm restrictions.

> For example, I have no knowledge of the syntax used for table
> initialization in vlc.c. This certainly isn't ANSI-C, and puts a
> severe restriction on the compilers that can be used for libdv.
> I don't even know what to do to convert this syntax to "C".
> (This is the show-stopper for me, as I don't know how to proceed.)

I guess you figured this out, but it's a gcc specific extension.  

> Hints like: __attribute__ ((aligned (8))) only apply to specific
> compilers. I've begun to wrap these with:
>   #if HAVE_GCC
>   #define ALIGN8 __attribute__ ((aligned (8)))
>   #define ALIGN32 __attribute__ ((aligned (32)))
>   #else
>   #define ALIGN8
>   #define ALIGN32
>   #endif // HAVE_GCC
> This makes the alignment hints invisible under non-gcc.

> There are lots of places where mmx and asm code is being used
> with no alternative. For example,
>   idct_248.c:  the "fixed_multiply"
>   should be in a #if ARCH_X86 block with an alternative.
>   I can guess that the solution is (a * b) >> 16, but that
>   assumes that you're doing 16.16 fixed. There's no comment to that fact
>   at the head of the routine, and I don't know x86 asm.

Whoops.  You're right.  That needs comments, and should have a C version.

The opcode in question, imull, is multiplying two 32 bit values.  The
upper 32 bits of the 64 bit product are the result.  

>   dct.c:  mmx code should be similarly blocked off.

> I'm going to try to get the code a little less gcc/x86 centric at home
> tonight. If I've any patches, I'll send them in. If you could help
> explain
> vlc.c tables, I'd appreciate it.

Sorry I couldn't be much help as I was away.  

I see you've submitted a patch, and I'll take a look at it now.

> Thanks,

> Scott

-- Buck