Ard Biesheuvel wrote:
On 18 July 2013 16:54, Tejas Belagod <tbela...@arm.com> wrote:
I'd like to follow up this thread to move towards removing arm_neon.h's
dependence on stdint.h. My comments inline below.
As far as I can tell, the only dependency arm_neon.h has on the
contents of that header are the [u]int[8|16|32|64]_t typedefs. The
kernel does define those, only in a different header.
Hello Tejas,
What I did not realize at the time is that those types are part of the
visible interface of the NEON intrinsics. Just as an example, there is
a function in arm_neon.h:
uint8x8_t vset_lane_u8 (uint8_t __a, uint8x8_t __b, const int __c);
which clearly needs a type definition for uint8_t. Changing the
published and documented interface is unlikely to be a realistic
option, I'm afraid, and simply dropping the #include will cause
breakage for some existing users, which is also not very appealing.
I was thinking more on the lines of
#ifdef __INT8_TYPE__
typedef __INT8_TYPE__ int8_t;
#endif
and
#ifdef __UINT64_C
#define UINT64_C(c) __UINT64_C (c)
#endif
In other words this is perhaps reproducing a part of stdint-gcc.h. I don't know
if there can be a situation when these are predefines are not defined ( eg. some
-m option that turns them off?)
Conditionally including stdint.h in case those types have not been
defined (yet) would be the only remaining option, I think, but I am
not sure if that is feasible.
Are you proposing something like:
/* arm_neon.h */
#ifndef __intxx_t_defined ...
#define __STDC_CONSTANT_MACROS
#include <stdint.h>
#endif
...
/* Prevent __STDC_CONSTANT_MACROS from polluting the environment. */
#ifdef __STDC_CONSTANT_MACROS
#undef __STDC_CONSTANT_MACROS
#endif
/* End of arm_neon.h */
Including all of stdint.h for only a few basic types/macros that we need seems
to suggest to me that its too heavy a hammer, is it not?
Thanks,
Tejas.
In the kernel case, I have worked around it by having a separate
compilation unit containing the wrapped NEON intrinsics code, and
using plain old C types to interface with the wrapper functions.
[...]
Regards,
Ard.