[lkml]   [2008]   [Mar]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] x86: merge the simple bitops and move them to bitops.h

On Fri, 14 Mar 2008 23:18:45 +0100, "Andi Kleen" <>
> > #else
> > static inline int fls64(__u64 x)
> > {
> > if (x == 0)
> > return 0;
> > return __fls(x) + 1;
> That would require a polymorphic macro __fls that adapts to 32bit and
> 64bit arguments. Not good C style.

Hi Andi,

It's unsigned long __fls(unsigned long)... and this is only compiled
if unsigned long is as long as u64. Seems fine to me. Moreover, it
is _exactly_ how it is done in x86_64 now. I must be missing something.

> > This is the only reason that this define exists. With another
> > name it would be fine. HWEIGHT_USE_MULTIPLIER?
> AFAIK it only exists because some ancient sparc chips had incredibly
> slow multipliers.

Good to know. And I realized that there is also the machines without
a hardware multiply instruction at all. So you are right. i386/x86_64
should just unconditionally set ARCH_HAS_FAST_MULTIPLIER.

> > And my feeling is that this is exactly the reason why this is
> > not a good version for a generic implementation in bitops.h. But
> > I don't care much.
> I bet most different approaches who might be slightly
> faster for larger bit strings would make the one bit
> case slower.

That is true, of course. But then the name of the function should
give a hint that it is optimized for short sequences.

Alexander van Heukelum

-- - Or how I learned to stop worrying and
love email again

 \ /
  Last update: 2008-03-15 18:59    [W:0.045 / U:0.704 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site