On Wednesday, 27 April 2005, at 18:33:29 (-0400), Mike Frysinger wrote: > uhh, no, but most people would never notice :P > > build = machine the package is *building on* > host = machine the package will *run on* > target = machine the package will *generate code for*
Okay, I had host and target mixed up then. Thanks for fixing it. :) On Saturday, 30 April 2005, at 11:53:10 (-0600), Tres Melton wrote: > I have completed the x86_64 mmx port of the 32bpp shader. I have > included it for you to review. I have cut and pasted it into > Eterm's pixmap.c and used it and it seems to work well. I'm not > asking you to add it yet, just give me your thoughts. First I have > to add some hooks to pixmap.c, adjust the Makefile.in, add the > HAVE_MMX_64 macro, and a few other things before we can smash it in > there. The code looks clean and nicely documented. Works for me. :) > How goes the configure.in modifications? Does it properly sense the > correct processor like we were discussing last week? Mike (a.k.a. vapier/SpanKY) took care of it. I cannot test myself, but I assume it's working. On Tuesday, 03 May 2005, at 18:22:36 (-0600), Tres Melton wrote: > I've read an enormous amount in the last two weeks about assembly code, > mmx extensions, and GNU/Linux and the GCC tools that make it all work. > I now feel comfortable stating that I know what is going on. The inline > assembly code was a necessary intermediate step for me to understand > exactly what was going on inside the processor during the shading > routines. The code that I'm using now uses the exact same mmx > operations as the 32 bit stuff. The difference is pointers and > registers are now 64bits but integers and data remained 32 bits. That > complicated moving the data into and out of the processor's registers. > There are two ways to load a 32bit number into a 64bit register: with > zero padding or sign extension. This is usually handled by the compiler > but we are in assembly code here and not C. The function prototype: > > shade_ximage_16(void *data, int bpl, int w, int h, int rm, int gm, int bm) > > uses integers. But the routines that handle the data treat it as if > they were unsigned (zero padded). Obviously bpl, w, and h cannot ever > be negative but can the color modifiers ever be? The way that I read > the documentation they cannot and that is how I've coded the routines. > If I'm wrong then please let me know before I finalize the patches. No, color modifiers are always >= 0. "unsigned short" would probably be the best data type for them from a strictly bounds-based point of view. > The real question that I have for you is, in what form would you like > the patches? 1) Inline assembly code. 2) A separate asm file for the > MMX_64 stuff. 3) Combining the 32 bit and 64 bit assembly stuff in a > single file in A) a single #if #else #end placing two almost identical > copies of the code in each w/ needed modifications. B) With a bunch of > #if #else #endif sprinkled throughout the code or C) with a number of > #defines that get defined to handle either 32 or 64 bit code? > > The 3 ways to put it all in the mmx_cmod.S file: > A) > #if HAVE_MMX > /* All of the 32 bit code */ > #else if HAVE_MMX_64 > /* All of the 64 bit code */ > #endif > > B) > #if HAVE_MMX > leal (%esi, %ebx, 4), %esi > #else if HAVE_MMX_64 > leaq (%rsi, %rbx, 4), %rsi > #endif > > C) > #if HAVE_MMX > # define SI esi > # define BX ebx > # define LEA leal > #else if HAVE_MMX_64 > # define SI rsi > # define BX rbx > # define LEA leaq > #endif > LEA (%SI, %BX, 4), %SI If you used choice C, is that all the macros you'd need? If so, I like that one. Otherwise, I like B. Why? Because duplicate code gets nasty quickly, and I think it's helpful for those of us who lack your understanding of MMX ASM (like me!) to see side-by-side exactly where the differences are. Cheers, Michael -- Michael Jennings (a.k.a. KainX) http://www.kainx.org/ <[EMAIL PROTECTED]> n + 1, Inc., http://www.nplus1.net/ Author, Eterm (www.eterm.org) ----------------------------------------------------------------------- "Morality cannot be legislated, but behaviour can be regulated. Judicial decrees may not change the heart, but they can restrain the heartless." -- Dr. Martin Luther King, Jr. ------------------------------------------------------- This SF.Net email is sponsored by: NEC IT Guy Games. Get your fingers limbered up and give it your best shot. 4 great events, 4 opportunities to win big! Highest score wins.NEC IT Guy Games. Play to win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20 _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
