Proposal: fixing the 'pure' floating point problem.

[Sergey Gromov]

Tue, 17 Mar 2009 03:38:23 -0700, Walter Bright wrote:

> Don wrote:
>> Walter Bright wrote:
>>> Don wrote:
>>>> A has called a function in B. B is not a floatingpoint module, so b() 
>>>> can only be called when the mode is set back to the default. a() 
>>>> violates this contract, so a() is incorrect. There's nothing wrong 
>>>> with b() or c(). If a() wants to call b(), it needs to restore the 
>>>> mode first; or else change b() into another floatingpoint module.
>>>
>>> Ok, this was the missing piece in my understanding of the proposal.
>>>
>>> But this requires that std.math either be floatingpoint, or two 
>>> versions of it must exist if you want to do change the rounding modes 
>>> on it.
>> 
>> I'm proposing that std.math would be floatingpoint. The docs contain 
>> references to the sticky flags; I just went to a lot of trouble to make 
>> sure that exp() sets the sticky flags correctly.
> 
> If std.math was floatingpoint, then its functions could not be pure.

Let's see.

int foo(int x)
{
  return x * x;
}

This function receives its argument in a thread-local register EAX and
returns its result in a thread-local register EAX.  You say this
function *can* be pure.

Now this function:

module(floatingpoint)
double bar(double x)
{
  return x * x;
}

This function receives its arguments on a thread-local FPU stack, in a
thread-local FPU mode register, and in a thread-local FPU flags
register.  It returns its result on a thread-local FPU stack, in a
thread-local FPU mode register, and in a thread-local FPU flags
register.  You say this function *can not* be pure.  Why?