David Heffernan 2352 Posted July 8, 2020 Rethinking Delphi Floating Point Control Register Management.pdf 2 7 Share this post Link to post
Lars Fosdal 1792 Posted July 8, 2020 @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. Share this post Link to post
David Heffernan 2352 Posted July 8, 2020 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. 1 Share this post Link to post
santiago 37 Posted July 10, 2020 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
Lars Fosdal 1792 Posted July 10, 2020 @David Heffernan - At this point in time, would it make sense to ask EMBT to focus primarily on the 64-bit part of this? Share this post Link to post
David Heffernan 2352 Posted July 10, 2020 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. 4 Share this post Link to post
Lars Fosdal 1792 Posted July 10, 2020 But isn't everything moving towards 64-bit? Share this post Link to post
David Heffernan 2352 Posted July 10, 2020 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. 5 Share this post Link to post
Arnaud Bouchez 407 Posted July 10, 2020 (edited) 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 1 Share this post Link to post
David Heffernan 2352 Posted July 10, 2020 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
Arnaud Bouchez 407 Posted July 10, 2020 (edited) 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 Share this post Link to post
Leif Uneus 43 Posted July 10, 2020 Is it not enough to declare DefaultCW8087 et al. as threadvar? Share this post Link to post
David Heffernan 2352 Posted July 10, 2020 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
David Heffernan 2352 Posted July 10, 2020 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
Arnaud Bouchez 407 Posted July 13, 2020 (edited) 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 1 Share this post Link to post