Rethinking Delphi’s management of floating point control registers

[David Heffernan 2345]

Rethinking Delphi Floating Point Control Register Management.pdf

[Lars Fosdal 1792]

@David Heffernan - I took the liberty of splitting this off into a new thread.
I think @Marco Cantu and @David Millington should look closer at this.

[David Heffernan 2345]

1 minute ago, Lars Fosdal said:

@David Heffernan - I took the liberty of splitting this off into a new thread.
I think @Marco Cantu and @David Millington should look closer at this.

They both have seen the document already.

[santiago 36]

On 7/8/2020 at 3:45 AM, David Heffernan said:

They both have seen the document already.

Did you get any feedback?

[Lars Fosdal 1792]

@David Heffernan - At this point in time, would it make sense to ask EMBT to focus primarily on the 64-bit part of this?

 

[David Heffernan 2345]

12 minutes ago, Lars Fosdal said:

@David Heffernan - At this point in time, would it make sense to ask EMBT to focus primarily on the 64-bit part of this?

 

I don't think so. It's very important that code behaves the same way for both 32 and 64 bit compilers and indeed for the non Windows platforms too. 

[Lars Fosdal 1792]

But isn't everything moving towards 64-bit?  

[David Heffernan 2345]

5 minutes ago, Lars Fosdal said:

But isn't everything moving towards 64-bit?  

32 bit processes on Windows aren't going away anytime soon.

 

It's actually not hard to change the runtime to address these issues, which can effectively be summarised as isolating threads from each other's execution contexts.

 

I would imagine that Emba don't do it because they perceive that the benefit is too small in comparison with other candidate developments. And remember that I'm proposing a breaking change in behaviour which always raises the bar. 

 

Personally I feel that it's important to build on solid foundations. We've just had a huge breaking change by the killing of ARC. So breaking changes can happen.  And by the token that a minority of users care about floating point, breaking changes in this area won't affect many people. And surely those that are affected would by and large appreciate the change. 

[Arnaud Bouchez 407]

I agree with you.

IMHO it is less a breaking change than a bugfix.
The behavior you propose seems more stable, in terms of thread-safety.

 

Note that FPC RTL mimics the same behavior, and is affected by the same bug.

 

Is just calling Set8087CW() at thread start enough as a workaround in user-code?

Edited July 10, 2020 by Arnaud Bouchez

[David Heffernan 2345]

14 minutes ago, Arnaud Bouchez said:

Is just calling Set8087CW() at thread start enough as a workaround in user-code?

No. That can result in a change to the floating point control state in a different thread, due to the data race on the global var.

[Arnaud Bouchez 407]

Fair enough.

😞

 

But FPC doesn't suffer from this race condition AFAIK:

    procedure Set8087CW(cw:word);
      begin
         default8087cw:=cw;
         asm
           fnclex
           fldcw cw
         end;
      end;

 

Edited July 10, 2020 by Arnaud Bouchez

[Leif Uneus 43]

Is it not enough to declare DefaultCW8087 et al. as threadvar?

[David Heffernan 2345]

2 hours ago, Arnaud Bouchez said:

Fair enough.

😞

 

But FPC doesn't suffer from this race condition AFAIK:

    procedure Set8087CW(cw:word);
      begin
         default8087cw:=cw;
         asm
           fnclex
           fldcw cw
         end;
      end;

 

That's a different race though. At least when you call Set8087CW then you know what happens in your thread. But you can still end up modifying things in other threads I guess.

[David Heffernan 2345]

1 hour ago, Leif Uneus said:

Is it not enough to declare DefaultCW8087 et al. as threadvar?

I don't think so. You want to be able to define a default FPCR for new threads, so just making those vars threadvars doesn't achieve that.

 

But in any case, why have threadvars for something that is already part of the thread context? That makes no sense to me.

[Arnaud Bouchez 407]

I guess this bug may be some inheritance from DOS/TurboPascal years... when the 8087 was already there and no thread was involved.

 

Edited July 13, 2020 by Arnaud Bouchez