Date: Thu, 05 May 2016 09:31:44 -0700 From: John Baldwin <jhb@freebsd.org> To: Alan Somers <asomers@freebsd.org> Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r299090 - in head: etc/mtree include lib/libbluetooth sbin/hastd share/man/man3 sys/dev/xen/blkback sys/kern sys/net sys/sys tests/sys tests/sys/sys usr.sbin/bluetooth/hccontrol Message-ID: <2368543.Vvp613SNcD@ralph.baldwin.cx> In-Reply-To: <201605042234.u44MYBMX054443@repo.freebsd.org> References: <201605042234.u44MYBMX054443@repo.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wednesday, May 04, 2016 10:34:11 PM Alan Somers wrote: > Author: asomers > Date: Wed May 4 22:34:11 2016 > New Revision: 299090 > URL: https://svnweb.freebsd.org/changeset/base/299090 > > Log: > Improve performance and functionality of the bitstring(3) api > > Two new functions are provided, bit_ffs_at() and bit_ffc_at(), which allow > for efficient searching of set or cleared bits starting from any bit offset > within the bit string. > > Performance is improved by operating on longs instead of bytes and using > ffsl() for searches within a long. ffsl() is a compiler builtin in both > clang and gcc for most architectures, converting what was a brute force > while loop search into a couple of instructions. > > All of the bitstring(3) API continues to be contained in the header file. > Some of the functions are large enough that perhaps they should be uninlined > and moved to a library, but that is beyond the scope of this commit. Doesn't switching from bytes to longs break the ABI? That is, setting bit 9 now has a different representation on big-endian systems (0x00 0x01 before, now 0x00 0x00 0x01 0x00 on 32-bit BE, and 4 more leading 0 bytes on 64-bit). This means you can't have an object file compiled against the old header pass a bitstring to an object file compiled against the new header on big-endian systems. Even on little-endian systems if an old object file allocates storage for a bitstring the new code might read off the end of it and fault (or return garbage if bits are set in the extra bytes it reads off the end)? Is the API is so little used we don't care? -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2368543.Vvp613SNcD>