J3/06-222 To: J3 From: Bill Long Subject: C13 - UTI 60, 62, 65: KIND arguments Date: 28-jul-2006 --------------------- Three Unresolved Technical Issues in Clause 13 regard optional KIND arguments for the intrinsics BIT_SIZE (UTI 62, page 359), BITS_KIND (UTI 60, page 361), and LEADZ (UTI 65, page 395). The basic argument in each case is that the kind type parameter for the BITS type is of type default integer and, therefore, the result values of these functions should also be of type default integer. Result values larger than huge(0) would never occur. Reply: ----- There are two distinct cases. 1) For BIT_SIZE and BITS_KIND the result values are known at compile time and the function references are likely replaced by the compiler with the appropriate constant. Including a KIND argument effectively allows the user to specify a kind type for that constant. The length type parameter for CHARACTER is also of type default integer and the LEN and LEN_TRIM intrinsics have optional KIND arguments. Having optional KIND arguments for similar intrinsic functions makes the standard more consistent. 2) LEADZ, TRAILZ, POPCNT, and POPPAR actually involve computation. It could be important for performance to have a non-default KIND for the result. For example, the computation might be more efficient if done with 64-bit hardware instructions, producing a 64-bit result, even if the default integer is 32 bits. Avoiding the final conversion of the result to a 32-bit value aids performance. For code portability the supplied KIND argument could be a named constant that is defined as appropriate for ports of the program to specific hardware platforms. To write optimal code it is important for users to have this capability. Therefore, it is preferred to leave the optional KIND arguments as currently specified.