|
From: Charles 'B. K. <kr...@ac...> - 2001-02-06 23:14:57
|
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 |