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
next prev parent 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.