From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:58351) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TqrTN-0007ZS-Ez for qemu-devel@nongnu.org; Thu, 03 Jan 2013 15:33:08 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TqrTK-0002Ow-T4 for qemu-devel@nongnu.org; Thu, 03 Jan 2013 15:33:05 -0500 Date: Thu, 3 Jan 2013 14:32:03 -0600 From: Scott Wood References: <1357243641.22404.4@snotra> In-Reply-To: (from agraf@suse.de on Thu Jan 3 14:31:30 2013) Message-ID: <1357245123.22404.9@snotra> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; delsp=Yes; format=Flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH 12/15] openpic: IRQ_check: search the queue a word at a time List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf Cc: "" , "" On 01/03/2013 02:31:30 PM, Alexander Graf wrote: >=20 >=20 > Am 03.01.2013 um 21:07 schrieb Scott Wood : >=20 > > On 01/03/2013 12:53:13 PM, Alexander Graf wrote: > >> On 22.12.2012, at 03:15, Scott Wood wrote: > >> > Search the queue more efficiently by first looking for a =20 > non-zero word, > >> > and then using the common bit-searching function to find the bit =20 > within > >> > the word. It would be even nicer if bitops_ffsl() could be =20 > hooked up > >> > to the compiler intrinsic so that bit-searching instructions =20 > could be > >> > used, but that's another matter. > >> > > >> > Signed-off-by: Scott Wood > >> What we really want is a bitmap wide ffs() bipops helper function =20 > that returns the first set bit in a bitmap and can optimize the hell =20 > out of that operation inside of itself. I don't think this belongs to =20 > the OpenPIC code. > > > > Well, we do have find_next_bit() in bitops.c, but it looks =20 > comparitively complicated in order to be generic and simply return a =20 > value rather than perform an action on each bit set. I suspect that =20 > the code in this patch would be faster, and avoids the need for me to =20 > follow all the twists and turns of find_next_bit() to figure out =20 > whether the undocumented interface is actually exactly what I guess =20 > it to be (e.g. what does it return when no bit is found?). >=20 > I would just call it bit_ffs and follow the same semantics. I'm not sure how that's an answer to what I wrote... -Scott=