On Fri, 8 Oct 2021, Segher Boessenkool wrote: > But many CPUs do not have hardware floating point in any variant, and > their ABIs / calling conventions do not mention floating point at all. > Still, this works with GCC just fine: it passes floats and doubles the > same as 32-bit resp. 64-bit integers. > > binary16 and bfloat16 would be easy to support the same way, but it is a > bit harder for binary128, because we do not have a 128-bit integer type
Supporting passing arguments (and return values) the same as an integer type of the same size is a *choice* (which comes with other choices - in particular, whether to say some or all the higher bits in the register or stack slot are sign-extended, zero-extended or undefined). It's a choice that should be made explicitly, and documented (in the relevant ABI if one is maintained), and coordinated between implementations when there's more than one implementation for the architecture trying to be compatible. We've had plenty of problems in the past with ABIs that were just what happened to fall out of the implementation (e.g. ABIs that depended on the details of what machine mode was assigned to a structure type...). On a related note, I'd encourage architecture maintainers to start thinking now about what exactly their ABIs should be for _BitInt (<http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2763.pdf>, accepted as a required feature for C23 up to at least the width of unsigned long long), and documenting it and coordinating with other implementations where appropriate. There's a concrete proposal for x86_64 (see origin/usr/hjl/bitint branch at https://gitlab.com/x86-psABIs/x86-64-ABI.git) that may at least help as an indication of the sort of issues to address in such an ABI. -- Joseph S. Myers jos...@codesourcery.com
