On Mon, 9 Oct 2006, David Howells wrote: > 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.
True. So wrap around what is there but do not add gazillion of definitions to all arches. > (2) Not everyone realises that fls() can be used to do log2(). So this is a case for a wrapper. > (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). Ok these are boundary checks that are easily coded around. Some variations on fls even exist that also do various flavors of end case handling. > (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. Good stuff. I have always wanted that. The wrapper could check for a constant. > (5) fls() and fls64() can't be used to initialise a variable at compile time, > ilog2() can. Well that is the same issue as (4). - To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
