[Cfp-interest] FUNCTIONS - outline updated

[Stephen Canon]

On May 20, 2010, at 10:55 AM, Jim Thomas wrote:

> Stephen Canon wrote:
> 
>> On May 18, 2010, at 2:12 PM, Fred J. Tydeman wrote:
>> 
>>> On Mon, 17 May 2010 17:27:49 -0700 Jim Thomas wrote:
>>> 
>>>> I posted an update (dated May 17) of our working outline for Functions 
>>>> to the CFP twiki under Topics/Formats/Attachments.
>>>> 
>>>> 
>>> I see a 18 May 2010 dated functions.pdf on the wiki.
>>> But, when I try to look at it, Adobe reader starts,
>>> and then gives a status of Stopped (so I am unable
>>> to view the file).
>>> 
>>> As I recall, the issignalling() function takes a
>>> floating-point type.  That implies to me that the
>>> normal function calling sequence will be used.  My
>>> understanding is some implementations would trigger
>>> the SNaN doing the function call.  I think this
>>> function needs a pointer to floating-point type.
>>> 
>>> 
>> 
>> By this line of reasoning, wouldn't all of the clause 5.7.2 operations require a pointer-to-floating argument?  
>> 
>>   "They are never exceptional, even for signaling NaNs."
>> 
>> 
> Good point.
> 
>> Since x87 signals denormal and invalid on single- and double-precision loads[1], one could run into this problem for all of the 5.7.2 functions.
>> 
>> However, I don't think that we need to do anything.  I know of no 32-bit x86 platform that passes floating-point arguments in register under the default calling conventions.  If such a platform exists, and the maintainers care about conformance, they could presumably declare these functions to use an alternative ABI that passed floating-point arguments on the stack.
>> 
>> That leaves the problem of moving the data to the stack; our hypothetical platform maintainers would need to teach the compiler to do memory-memory copies of single- and double-precision floating-point data through either general-purpose, MMX, or SSE registers instead of through x87.
>> 
> Are you saying this is a problem for 5.7.2 functions? I don't see why a 
> compiler (with the usual x86 or i386 calling conventions) would be 
> tempted to go through x87 for these functions.

I'm saying that an implementation on 32 bit intel would need to do the following in order to conform to the requirements of 5.7.2:

* Use a calling convention for these functions that passes single- and double- precision arguments either in memory, in general-purpose registers, or on MMX/SSE.  The usual calling conventions pass such arguments in memory, so there is generally no problem.

* If the argument needs to be copied in memory in order to be passed as an argument, that copy needs to happen through the general-purpose or MMX/SSE registers.  Again, many compilers already do this for speed, but it's conceivable that some compilers may current copy floating-point data through x87.

What I'm *really* saying is that we don't need to (and shouldn't) define pointer-to-float forms for the 5.7.2 operations, because it's an extra layer of complexity that is not necessary.  Platform vendors can work around the architecture/ABI limitations on their platform if necessary.

- Steve