On Thu, 13 Mar 2025 14:09:24 -0700 Jacob Keller <jacob.e.keller@xxxxxxxxx> wrote: > On 3/13/2025 9:36 AM, H. Peter Anvin wrote: > > On March 13, 2025 9:24:38 AM PDT, Yury Norov <yury.norov@xxxxxxxxx> wrote: > >> On Wed, Mar 12, 2025 at 05:09:16PM -0700, H. Peter Anvin wrote: > >>> On March 12, 2025 4:56:31 PM PDT, Jacob Keller <jacob.e.keller@xxxxxxxxx> wrote: > >> > >> [...] > >> > >>>> This is really a question of whether you expect odd or even parity as > >>>> the "true" value. I think that would depend on context, and we may not > >>>> reach a good consensus. > >>>> > >>>> I do agree that my brain would jump to "true is even, false is odd". > >>>> However, I also agree returning the value as 0 for even and 1 for odd > >>>> kind of made sense before, and updating this to be a bool and then > >>>> requiring to switch all the callers is a bit obnoxious... > >>> > >>> Odd = 1 = true is the only same definition. It is a bitwise XOR, or sum mod 1. > >> > >> The x86 implementation will be "popcnt(val) & 1", right? So if we > >> choose to go with odd == false, we'll have to add an extra negation. > >> So because it's a purely conventional thing, let's just pick a simpler > >> one? > >> > >> Compiler's builtin parity() returns 1 for odd. > >> > >> Thanks, > >> Yury > > > > The x86 implementation, no, but there will be plenty of others having that exact definition. > > Makes sense to stick with that existing convention then. Enough to > convince me. There is the possibility that the compiler will treat the builtin as having an 'int' result without the constraint of it being zero or one. In which case the conversion to bool will be a compare. This doesn't happen on x86-64 (gcc or clang) - but who knows elsewhere. For x86 popcnt(val) & 1 is best (except for parity8) but requires a non-archaic cpu. (Probably Nehelem or K10 or later - includes Sandy bridge and all the 'earth movers'.) Since performance isn't critical the generic C code is actually ok. (The 'parity' flag bit is only set on the low 8 bits.) David
