Jump to content
David Heffernan

Rethinking Delphi’s management of floating point control registers

Recommended Posts

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

They both have seen the document already.

Did you get any feedback?

Share this post


Link to post
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. 

  • Like 5

Share this post


Link to post
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. 

  • Like 6

Share this post


Link to post

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 by Arnaud Bouchez
  • Like 1

Share this post


Link to post
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.

Share this post


Link to post

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 by Arnaud Bouchez

Share this post


Link to post
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.

Share this post


Link to post
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.

Share this post


Link to post

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

 

Edited by Arnaud Bouchez
  • Like 1

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×