Re: [PATCH v2 1/2] eal: provide leading and trailing zero bit count abstraction

[Tyler Retzlaff <roretzla@linux.microsoft.com>]

On Fri, Jan 06, 2023 at 11:48:17AM +0000, Bruce Richardson wrote:
> On Thu, Jan 05, 2023 at 04:32:40PM -0800, Stephen Hemminger wrote:
> > On Thu, 5 Jan 2023 09:21:18 -0800
> > Tyler Retzlaff <roretzla@linux.microsoft.com> wrote:
> > 
> > > On Thu, Jan 05, 2023 at 10:01:31AM +0100, Thomas Monjalon wrote:
> > > > 05/01/2023 08:09, Morten Brørup:  
> > > > > > From: Tyler Retzlaff [mailto:roretzla@linux.microsoft.com]
> > > > > > +/**
> > > > > > + * @warning
> > > > > > + * @b EXPERIMENTAL: this API may change, or be removed, without prior
> > > > > > notice
> > > > > > + *
> > > > > > + * Get the count of leading 0-bits in v.
> > > > > > + *
> > > > > > + * @param v
> > > > > > + *   The value.
> > > > > > + * @return
> > > > > > + *   The count of leading zero bits.
> > > > > > + */
> > > > > > +__rte_experimental
> > > > > > +static inline unsigned int
> > > > > > +rte_clzl(unsigned long v)  
> > > > > 
> > > > > Don't use l (long) and ll (long long) for names (and types), use explicit bit lengths, 32 and 64.
> > > > > 
> > > > > E.g.: rte_clz32(uint32_t v)  
> > > > 
> > > > I agree on using numbers.
> > > >   
> > > 
> > > love the idea, fewer functions too.
> > > 
> > > though it is a shame we cannot adopt C11 standard because we could just
> > > do away with the bit suffixes entirely.
> > 
> > We could but the project needs to support older RHEL releases
> > which have older tool sets. Though probably this is moot point given
> > how much meson seems to change.
> 
> True, though meson tends to be a bit easier to update than GCC on a system
> - no "pip3 install --upgrade gcc", sadly :-)

* on linux. :)

> 
> If we can't go all the way to C11 support, how about at least going to C99
> support? As far as I know DPDK has never updated its minimum C-standard
> version, and it might be a good idea to start the process of doing so, even
> if it is a baby step.

the thing that blurs the line a bit is how the gcc version that is
holding us back does actually allow the use of some C99 optional
features. for example we use the C99 fixed width integer types so
technically some of the code already requires C99.

i also notice at least one driver is explicitly specifying -std=gnu99 so
maybe that driver just isn't being built when the old gcc is detected?

anyway, i think we are stuck pre-c99 so long as we have RHEL 7 to
contend with. the rationale is if we could use a compiler conforming to
the new standard we could just directly use those features, but so long
as we have to support non conforming compiler at a particular level we
have to introduce an abstraction and that is where all the extra work
comes from.

a prominent example is atomics from C11, but for other reasons in our
code base that i won't go into even if we required C11 we would still
need to abstract atomics. fwiw i'm working on this patch series now and
hope to provide a first draft in the next week or two.

finally, i do think it would be good to document a minimum C compiler
conformance level rather than specific gcc versions. though i admit we
also have a hard dependency on gcc right now. my goal is to improve
portability to a level where we could just state "you need a C<N>
compliant compiler" (or as close to it as possible).

ty