Linux PARISC architecture development
 help / color / mirror / Atom feed
From: Joel Soete <joel.soete@tiscali.be>
To: Grant Grundler <grundler@parisc-linux.org>
Cc: parisc-linux@lists.parisc-linux.org
Subject: Re: [parisc-linux] a fast fls also for 2.6?
Date: Fri, 05 Sep 2003 19:26:13 +0000	[thread overview]
Message-ID: <3F58E355.30009@tiscali.be> (raw)
In-Reply-To: <20030905182621.GC10216@dsl2.external.hp.com>

Grant Grundler wrote:

>On Fri, Sep 05, 2003 at 01:00:35PM +0000, Joel Soete wrote:
>  
>
>>remember me that I also suggest a __fls() in: 
>><http://lists.parisc-linux.org/pipermail/parisc-linux/2003-August/020628.html>
>>    
>>
>
>sorry - I missed that.
> 
>  
>
>>Without any remark, I don't know if you could also be interested to 
>>include it in 2.6.
>>    
>>
>
>no - becuase fls() and ffs() return the same values for given input.
>(I see comments in include/asm-ppc/bitops.h to that effect).
>
>parisc __ffs costs the same number of cycles regardless of input.
>(2 cycles per 3 instructions about on PA 2.0 machines).
>ie there is no advantage to "searching from the top" vs "searching
>from the bottom" which is what I think the intent of fls() vs ffs().
>For generic implementations, this intent is important.
>
>What we could do is redefine fls() to also use ffs() and add
>my comment above. Patch appended. Please test/review and tell me
>if that should be committed. I haven't tested it yet and the comments
>in PPC bitops.h could be wrong.
>
>thanks,
>grant
>
>
>Index: include/asm-parisc/bitops.h
>===================================================================
>RCS file: /var/cvs/linux-2.6/include/asm-parisc/bitops.h,v
>retrieving revision 1.2
>diff -u -p -r1.2 bitops.h
>--- include/asm-parisc/bitops.h	1 Sep 2003 00:30:42 -0000	1.2
>+++ include/asm-parisc/bitops.h	5 Sep 2003 18:11:21 -0000
>@@ -281,9 +281,14 @@ static __inline__ int ffs(int x)
> 
> /*
>  * fls: find last bit set.
>+ *
>+ * parisc __ffs costs the same number of cycles regardless of input.
>+ * A similar implementation for __fls() would have no advantage.
>+ * ie there is no advantage to "searching from the top" vs "searching 
>+ * from the bottom" which is the intent of fls() vs ffs().
>  */
> 
>-#define fls(x) generic_fls(x)
>+#define fls(x) ffs(x)
> 
> /*
>  * hweightN: returns the hamming weight (i.e. the number
>
>  
>
My bad, I undurstand that ffs return the index of the first bit set otc 
fls returning the the index of the last bit set
(ie for 1010: ffs would return 2 and fls would return 4)?

Sorry for confusion. It was never the less a good exercice ;)

Thanks,
    Joel

  reply	other threads:[~2003-09-05 19:26 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <3F58838A.9010203@tiscali.be>
     [not found] ` <3F5888F3.5060609@tiscali.be>
2003-09-05 18:26   ` [parisc-linux] a fast fls also for 2.6? Grant Grundler
2003-09-05 19:26     ` Joel Soete [this message]
2003-09-05 19:29     ` Grant Grundler
2003-09-05 19:54       ` Joel Soete
2003-08-07 15:37 Joel Soete

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3F58E355.30009@tiscali.be \
    --to=joel.soete@tiscali.be \
    --cc=grundler@parisc-linux.org \
    --cc=parisc-linux@lists.parisc-linux.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox