[Cfp-interest] FUNCTIONS - outline updated

[Stephen Canon]

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."

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.

Admittedly, this is a lot of work to get conformance, but it is not impossible; furthermore, as far as I am aware, none of the platforms that seem to care about conformance would have such a high bar set in front of them (please correct me if I'm forgetting something here) -- most already pass arguments on the stack in the default calling conventions, and many avoid copying singles and doubles through x87.

The benefit of the pointer forms does not seem to justify the implementation burden to me.

- Steve

[1] native (80 bit) x87 loads do not suffer from this.