On 5/23/16 4:30 PM, Alan Somers wrote:
On Fri, May 6, 2016 at 8:45 AM, Kurt Lidl <l...@pix.net <mailto:l...@pix.net>> wrote:On 5/5/16 12:31 PM, John Baldwin wrote: 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? Just as a note - at my prior job (Pi-Coral, now defunct) we used this API everywhere in the dataplane code of our product. Since the company is gone, that particular use-case doesn't matter anymore. At the very least, this deserves a mention in the release notes, and also UPDATING! -Kurt UPDATING is updated as of r300539. Any objection to merging this to stable/10?
Not to me - as I mentioned, the company went out of business, so catering to its needs is a NOP. Go for it! -Kurt _______________________________________________ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
