[Cfp-interest 1524] Re: request for input

[Jim Thomas]

Thanks, Joseph. Please see below.

> On Mar 2, 2020, at 1:17 PM, Joseph Myers <joseph at codesourcery.com> wrote:
> 
> On Mon, 2 Mar 2020, Jim Thomas wrote:
> 
>> In trying to redo the annex for TS-3 to not require support for any 
>> particular interchange and extended types, I feel more strongly that 
>> this would be the more useful approach. I believe some implementations 
>> need nomenclature and rules for at least one extra floating type (for 
>> _Float16, _Float80, or _Float128 in particular), but would balk at 
>> having to also support _Float32, _Float64, and _Float32x, especially 
>> when they already support equivalent types as float and double.
> 
> There's no such thing as _Float80 (that's not a width corresponding to an 
> IEEE interchange encoding).

Right. The common 80-bit IECC 60559 extended format can be supported as a TS-3 extended type _Float32x or _Float64x (or both).
> 
> If you already support an equivalent type, supporting the extra name, and 
> corresponding function aliases, is easy (whether the type is a distinct 
> type, which is what you want to simplify use of _Generic without needing 
> conditions in the user code for whether the types are distinct or not, or 
> just acts as a typedef name rather than a distinct type).
> 
> (If the type is a distinct type, it's very clear that e.g. the functions 
> for _Float64 can have the same addresses as the functions for double, 
> because little is specified about the results of converting function 
> pointers from one type to another.  If it's a typedef, it's a bit less 
> clear, see what I wrote in reflector message 14590 (25 Jan 2017), though 
> normal library practice does often have e.g. ldexp = scalbn.)
> 
>> One of Jens's ideas was to replace new math functions with type-generic 
>> macros. Though this is problematic for math functions in general (see 
>> Joseph’s (SC22WG14.17170) N2426), these operations (that round result to 
>> specified type) are somewhat special. IEC 60559 describes them as 
>> generic operations, e.g., compare the IEC 60559 description of these 
>> operations:
> 
> I think the same principle still applies to them - if e.g. libffi gets 
> support for these types, then if you have normal functions any language 
> runtime can bind to the functions, just like other C functions, without 
> needing special C code, but if you only have type-generic macros then 
> other-language bindings are more complicated.

Is it significantly more complicated?

T1 T1addT2(T2 x, T2 y) { return T1add(x, y); }
> 
>> Implementations shall provide the following formatOf 
>> general-computational operations, for destinations of all supported 
>> arithmetic formats, and, for each destination format, for operands of 
>> all supported arithmetic formats with the same radix as the destination 
>> format.
>> 
>> ― formatOf-addition(source1, source2)
>> 
>> vs it’s description of other operations such as
>> 
>> Implementations shall provide the following homogeneous general-computational operations for all supported arithmetic formats: 
>> 
>> ― sourceFormat roundToIntegralTiesToEven(source)
> 
> The difference here is that formatOf-addition is one operation per format 
> (with the format name as part of the operation name), generic over the 
> other two formats, while roundToIntegralTiesToEven has a name independent 
> of format and is generic over one format.  I.e. most operations are 
> generic over at least one format in IEEE 754, and language bindings 
> represent that in the most appropriate way for the language in question.  
> I don't think the difference between a format name forming or not forming 
> part of the name of the operation is relevant to type-specific versus 
> type-generic bindings in C.

I see your point. 
> 
>> Also, these operations (that round to narrower type) are correctly 
>> rounded. So, for example, any faddsuffix function invocation would 
>> produce the same result provided it’s arguments weren’t narrowed (with 
>> loss of range and/or precision) to a parameter type, and It seems 
> 
> The tricky thing - the reason why the tgmath.h rules need to specify 
> exactly how the underlying function is determined rather than just saying 
> any function with wide-enough parameters is used - is integer types, which 
> may get narrowed even when floating arguments don't (e.g. an 
> implementation where binary64 is the widest floating-point format can't 
> avoid narrowing long long arguments to these functions).

Do you see a problem if the tgmath rules specify that any wide enough function is used (provided one exists), where integer arguments are regarded (as they are in the TS) as having a certain floating type (double, _Float64, or _Decimal64) depending on the prefix type?

- JIm Thomas

> 
>> What do you think?
> 
> Functions with defined parameter types are well-understood and work well 
> in C and we know the TS specification for the functions can be implemented 
> without problems.
> 
> Type-generic macros have proven much trickier in practice and many more 
> issues have shown up in the past with attempts to specify particular 
> type-generic macros in the standard C library.  I think we ended up with a 
> reasonable specification for the tgmath.h macros after DR#13, but 
> inventing type-generic macros is a high-risk area and I'd be wary of 
> adding anything new there to the standard that doesn't come with 
> implementation experience from the TS.
> 
> -- 
> Joseph S. Myers
> joseph at codesourcery.com