Hi! On Mon, Oct 11, 2021 at 08:11:50PM +0000, Joseph Myers wrote: > 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.
I don't disagree at all. But: GCC makes that choice for you, if you do not. Many (embedded and/or older) targets do not. They get the defaults, those just work, and /de facto/ become the standard. In practice most such architectures are purely 32-bit, so there is no sign/zero extension problem. > 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...). Yes. And we still have problems on older ABIs with e.g. new C++ requirements that did not exist >25 years ago when the ABIs were written. Not all of this can be helped at all. > 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. This should really go on gcc@, in a thread of its own, and a wiki page might help as well? Segher
