[Cfp-interest] FUNCTIONS - outline updated

Jim Thomas jwthomas at cup.hp.com
Thu May 20 10:55:04 PDT 2010


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.

>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.
>_______________________________________________
>Cfp-interest mailing list
>Cfp-interest at oakapple.net
>http://mailman.oakapple.net/mailman/listinfo/cfp-interest
>
>
>  
>



More information about the Cfp-interest mailing list