[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <7795.1160388696@redhat.com>
Date: Mon, 09 Oct 2006 11:11:36 +0100
From: David Howells <dhowells@...hat.com>
To: Christoph Lameter <clameter@....com>
Cc: Matthew Wilcox <matthew@....cx>, torvalds@...l.org, akpm@...l.org,
sfr@...b.auug.org.au, linux-kernel@...r.kernel.org,
linux-arch@...r.kernel.org
Subject: Re: [PATCH 1/4] LOG2: Implement a general integer log2 facility in the kernel [try #4]
Christoph Lameter <clameter@....com> wrote:
> Why so complicated and why do it at all? We already have fls and ffs
> amoung the bit operations and those map to cpu instructions on arches
> that support these. fls can be used as a log 2 facilities. If you need
> another name and further refine it then just add an inline function.
There are a number of reasons:
(1) There are a bunch of independent log2 implementations lying around in the
code. It'd be nice to just have one set that anyone can use.
(2) Not everyone realises that fls() can be used to do log2().
(3) ilog2(n) != fls(n)
This means that the asm-optimised version for one might be less optimal
for the other (for example, ilog2() produces an undefined result if n <=
1, fls() must return 0).
(4) There are occasions when you might want to take a log2 of a constant.
With the totally inline asm approach, it would always execute some code,
though it should be unnecessary. What I've done permits you to avoid that
as the answer is always going to be the same.
(5) fls() and fls64() can't be used to initialise a variable at compile time,
ilog2() can.
David
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists