$ cat a.c
#define __STDC_WANT_IEC_60559_TYPES_EXT__
#include <math.h>
#include <stdio.h>
#include <string.h>
#include <ffi.h>
_Float16 myexp(_Float16 x)
{
return 1 + x;
}
int main(void)
{
_Float16 f16 = 1.23e3;
void *values[1] = {&f16};
float res;
_Float16 res2;
ffi_type *args[1] = {&ffi_type_float};
ffi_cif cif;
if (ffi_prep_cif(&cif, FFI_DEFAULT_ABI, 1,
&ffi_type_float, args) != FFI_OK)
{
return 1;
}
ffi_call(&cif, FFI_FN(myexp), &res, values);
memcpy(&res2, &res, 2); /* fixup, assuming LE */
printf("%e\n", (double)res2);
return 0;
}
$ gcc a.c -Wall -lm -lffi && ./a.out
1.231000e+03
Feature or enhancement
Proposal:
Both gcc (since v12) and clang (since v14) have support for the _Float16 (i.e. partial support for Annex H of the C23). Complex half-precision type also supported by mentioned compilers. I think, we could utilize that and enable using native half-precision types conditionally in the ctypes module, like we do for complex types. For the rest (struct/array/memoryview) - half-precision types will be enabled unconditionally.
ToDo:
'Ze'type in the struct module'Ze'type in the memoryview'Ze'type in the array module'e'(_Float16) to the ctypes module'Ze'(_Float16 _Complex) to the ctypes moduleLast two tasks looks less trivial, as the libffi has no support for
_Float16type. Does this prevents us from adding such type or we can include workarounds for the libffi to the CPython itself?Details
Following works on x86:
Has this already been discussed elsewhere?
I have already discussed this feature proposal on Discourse
Links to previous discussion of this feature:
https://discuss.python.org/t/106723