Re: [parisc-linux] uninline in bitops.c as ia64 or sparc64?

["Michael S. Zick" <mszick@goquest.com>]

[-- Attachment #1: Type: text/plain, Size: 3351 bytes --]

On Sat July 31 2004 11:58, James Bottomley wrote:
> On Sat, 2004-07-31 at 10:29, Michael S. Zick wrote:
> > How about a different algorithm?
> > Say:: 3 * Log_2 (Register Size)
> 
> This algorithm is a more complex form of generic_ffz() in linux/bitops.h
> 
> perhaps we should use generic_ffz as the basis for this?
> 
generic_ffz is defined as integer - is 'integer' the same size
cpu32 and cpu64?  If not, that routine needs a size-conditional
test for the other 32 bits on cpu64.

Here is a suggested fix for include/asm-parisc/bitops.h -

NOTE 1: I have no way to test this - some needs to check my
work.

NOTE 2: I did try to do this on (electronic) pencil and paper -
You can get the pictures at: <www.goquest.com/~mszick>
as: hpbitfinder.ps.bz2

NOTE 3: Same diff is attached as in-lined, just in case my
mail agent trashes it.

Mike

Index: include/asm-parisc/bitops.h
===================================================================
RCS file: /opt/lib/cvs/parisc/include/asm-parisc/bitops.h,v
retrieving revision 1.1.1.1
diff -u -3 -p -r1.1.1.1 bitops.h
--- a/include/asm-parisc/bitops.h	13 Jul 2004 05:40:29 -0000	1.1.1.1
+++ b/include/asm-parisc/bitops.h	9 Aug 2004 14:33:03 -0000
@@ -217,11 +217,16 @@ static __inline__ int test_bit(int nr, c
  *
  * This algorithm avoids branches by making use of nullification.
  * One side effect of "extr" instructions is it sets PSW[N] bit.
- * How PSW[N] (nullify next insn) gets set is determined by the
+ * How PSW[N] (nullify next insn) gets set is determined by the
  * "condition" field (eg "<>" or "TR" below) in the extr* insn.
  * Only the 1st and one of either the 2cd or 3rd insn will get executed.
  * Each set of 3 insn will get executed in 2 cycles on PA8x00 vs 16 or so
  * cycles for each mispredicted branch.
+ *
+ * Provide either a u64 or u32 version based on cpu register size.
+ * Note that the hard coded field indexes depend on cpu register size;
+ * and the extract instruction generates a right-justified result.
+ * The index numbers are hp-bit-position not radix 2 numbers. <msz>
  */

 static __inline__ unsigned long __ffs(unsigned long x)
@@ -229,14 +234,27 @@ static __inline__ unsigned long __ffs(un
 	unsigned long ret;

 	__asm__(
-#if BITS_PER_LONG > 32
+#ifdef __LP64__
 		" ldi       63,%1\n"
 		" extrd,u,*<>  %0,63,32,%%r0\n"
 		" extrd,u,*TR  %0,31,32,%0\n"	/* move top 32-bits down */
 		" addi    -32,%1,%1\n"
+		" extrd,u,*<>  %0,63,16,%%r0\n"
+		" extrd,u,*TR  %0,47,16,%0\n"   /* xxxx0000 -> 0000xxxx */
+		" addi    -16,%1,%1\n"
+		" extrd,u,*<>  %0,63,8,%%r0\n"
+		" extrd,u,*TR  %0,55,8,%0\n"    /* 0000xx00 -> 000000xx */
+		" addi    -8,%1,%1\n"
+		" extrd,u,*<>  %0,63,4,%%r0\n"
+		" extrd,u,*TR  %0,59,4,%0\n"    /* 000000x0 -> 0000000x */
+		" addi    -4,%1,%1\n"
+		" extrd,u,*<>  %0,63,2,%%r0\n"
+		" extrd,u,*TR  %0,61,2,%0\n"    /* 0000000y, 1100b -> 0011b */
+		" addi    -2,%1,%1\n"
+		" extrd,u,*=  %0,63,1,%%r0\n"   /* check last bit */
+		" addi    -1,%1,%1\n"
 #else
 		" ldi       31,%1\n"
-#endif
 		" extru,<>  %0,31,16,%%r0\n"
 		" extru,TR  %0,15,16,%0\n"	/* xxxx0000 -> 0000xxxx */
 		" addi    -16,%1,%1\n"
@@ -251,6 +269,7 @@ static __inline__ unsigned long __ffs(un
 		" addi    -2,%1,%1\n"
 		" extru,=  %0,31,1,%%r0\n"	/* check last bit */
 		" addi    -1,%1,%1\n"
+#endif
 			: "+r" (x), "=r" (ret) );
 	return ret;
 }



[-- Attachment #2: bitops.h.diff.bz2 --]
[-- Type: application/x-bzip2, Size: 1171 bytes --]

[-- Attachment #3: Type: text/plain, Size: 169 bytes --]

_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux