This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: V6 [PATCH] x86: Add <sys/platform/x86.h>
- From: "H.J. Lu" <hjl dot tools at gmail dot com>
- To: Florian Weimer <fweimer at redhat dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Tue, 30 Oct 2018 10:42:08 -0700
- Subject: Re: V6 [PATCH] x86: Add <sys/platform/x86.h>
- References: <CAMe9rOqcfBAsSQQme3VJyMKsbAvKO_YdaG=1ZJqrm+T8aPztag@mail.gmail.com> <87ftwti8xk.fsf@oldenburg.str.redhat.com> <CAMe9rOrV3aQa_TZTcUTkhL2y7HOGPj_ynFu1Jb7UmM=xg4KziQ@mail.gmail.com>
On Thu, Oct 25, 2018 at 11:11 PM H.J. Lu <hjl.tools@gmail.com> wrote:
>
> On 10/25/18, Florian Weimer <fweimer@redhat.com> wrote:
> > * H. J. Lu:
> >
> >> /* CPU_FEATURE_USABLE evaluates to true if the feature is usable. */
> >> #define CPU_FEATURE_USABLE(name) \
> >> ((need_arch_feature_##name \
> >> && (x86_get_arch_feature (index_arch_##name##_Usable) \
> >> & (bit_arch_##name##_Usable)) != 0) \
> >> || (!need_arch_feature_##name \
> >> && (x86_get_cpuid_registers (index_cpu_##name)->reg_##name \
> >> & (bit_cpu_##name)) != 0))
> >
> > I still think this is wrong. This should be a const function, with a
> > single argument, returning bool, so that we do not expose the internal
>
> The only things exposed are
>
> enum
> {
> /* The integer bit array index for the first set of internal feature
> bits. */
> FEATURE_INDEX_1 = 0,
> FEATURE_INDEX_2,
> /* The current maximum size of the feature integer bit array. */
> FEATURE_INDEX_MAX
> };
>
> enum
> {
> COMMON_CPUID_INDEX_1 = 0,
> COMMON_CPUID_INDEX_7,
> COMMON_CPUID_INDEX_80000001,
> /* Keep the following line at the end. */
> COMMON_CPUID_INDEX_MAX
> };
>
> struct cpuid_registers
> {
> unsigned int eax;
> unsigned int ebx;
> unsigned int ecx;
> unsigned int edx;
> };
>
> following the conventions of C/C++.
>
> > implementation. It will also be possible to use this function from Ada,
> > Fortran, and so on. This is not possible with a preprocessor macro.
>
> This is designed for C/C++. This is never intended for Fortran nor
> Ada. If there are requests for Fortran or Ada, we can investigate different
> approaches for them.
>
> Any other comments?
I'd like to add this C/C++ feature to glibc. If there is no objection, I will
check it in tomorrow.
--
H.J.