I hate FP math...

9 views
Skip to first unread message

Michal Necasek

unread,
Nov 15, 2003, 9:14:13 PM11/15/03
to

Since the release of Open Watcom 1.2 is looming ahead, I've
been running a bunch of regression tests, fixing what I can.
Sadly, when running math library tests, I've run into severe
problems that I probably cannot fix.

I have a very strong suspicion that "recent" OS/2 kernels are
seriously broken WRT floating point math. Some OS/2 API calls
have a tendency to trash the FP control word. This was also
observed by the Mozilla folks.

Here's a little test proggy:

----------------------------------------------------
#include <stdio.h>
#include <math.h>
#include <float.h>

void main( void )
{
int cw;
double d;
char buf[512];

cw = _control87( PC_24, MCW_PC ); /* Set FPU CW to atypical
value */
cw = _control87( 0, 0 ); /* Read back the FPU CW */
sprintf( buf, "cw = %#X", cw );
cw = _control87( 0, 0 ); /* Read/print again to ensure */
puts( buf ); /* sprintf() didn't mess
with it */
sprintf( buf, "cw = %#X", cw );
puts( buf );

cw = _control87( 0, 0 ); /* See what FPU CW looks like */
printf( "cw = %#X\n", cw ); /* after we printed it */
d = atan2( 1.0, DBL_MAX ); /* This may cause underflow
xcpt */
cw = _control87( 0, 0 ); /* Let's see what FPU CW is
now */
printf( "cw = %#X\n", cw );
printf( "%g\n", d ); /* Print the atan2 result */
}
----------------------------------------------------

When I ran this program on my machine, I observed the following
behaviour:

- In PM sessions, the FP CW gets trashed (set to 0x37F)

- In FS sessions, the FP CW gets trashed too (but set to 0x362)

- Under debugger control, everything works just fine (I hate that!)

- IBM VAC++ 3.08, Open Watcom and BCOS2 2.0 all exhibit this
behaviour (their default FP CW is different, but all get trashed,
and their respective debuggers mask this problem)

- Borland and Watcom produced executables crash in FS because of
this (because they expect FP underflow exceptions to be masked,
which is not the case after the FP CW gets messed up)

- VAC++ produced executables "only" print different results for
the atan2() call in FS/PM sessions.

- Problem did not exist in Warp Connect

- Problem _did_ exist in WSeB GA

Could be interesting if someone tested this on Warp 4 GA and/or
various Warp 4 FP levels.


Michal

dinkmeister

unread,
Nov 15, 2003, 9:20:37 PM11/15/03
to
suggestion: also try posting to comp.os.os2.bugs to get Scott's attention?

On Sun, 16 Nov 2003 02:14:13 GMT, Michal Necasek wrote:

:
: Since the release of Open Watcom 1.2 is looming ahead, I've

:

Ilya Zakharevich

unread,
Nov 15, 2003, 9:41:54 PM11/15/03
to
[A complimentary Cc of this posting was NOT [per weedlist] sent to
Michal Necasek
<mic...@prodigy.net>], who wrote in article <V3Btb.21079$R92....@newssvr33.news.prodigy.com>:

>
> Since the release of Open Watcom 1.2 is looming ahead, I've
> been running a bunch of regression tests, fixing what I can.
> Sadly, when running math library tests, I've run into severe
> problems that I probably cannot fix.
>
> I have a very strong suspicion that "recent" OS/2 kernels are
> seriously broken WRT floating point math. Some OS/2 API calls
> have a tendency to trash the FP control word. This was also
> observed by the Mozilla folks.

I found (and put workaround into Perl, otherwise overflow exceptions
are frequent) the following scenarios of FP flags changing:

a) Some not-fully understood situations related to PM APIs
(dependent on a video driver and/or PM hooks?);

b) Running INIT/TERM code of certain DLLs; in particular:

b1) depending on used DLLs, FP flags at the start of the
application can be not what is expected; Note that presence
of HOOK DLLs changes the list of DLLs loaded at start time;

b2) DosLoadModule() can change flags;

b3) Creation/destruction of a message queue (un)loads some other
set of HOOK DLLs, thus also may affect the flags.

c) (No workaround possible/easy): some HOOKs are run during a screen
write in a VIO session; they also have a chance [;-)] to modify
the flags; E.g., at least one of the versions of GAMESRVR.DLL (of
Dive) is known to do this.

Hope this helps,
Ilya

Michal Necasek

unread,
Nov 15, 2003, 10:04:45 PM11/15/03
to
Ilya Zakharevich wrote:

> a) Some not-fully understood situations related to PM APIs
> (dependent on a video driver and/or PM hooks?);
>

This is the real issue.

It just occurred to me that I should test a command line boot... my
WSeB machine does NOT trash the FP CW in command line boot.

Replacing SDD with GENGRADD I can see that the problem still exists
in PM sessions but not in FS - I have a hunch that the latest SNAP
might maybe "fix" this too... just maybe.

So anyway the kernel itself is apparently not the culprit, although
I'd still like to know why running under a debugger should affect
things. This makes it somewhat difficult for me to pinpoint the
problem.

> b) Running INIT/TERM code of certain DLLs; in particular:
>

This is somewhat unavoidable but not likely a show stopper. DLLs
that don't use FP math should not need to touch the FP CW ever.
For those that do it might be trickier, but still the INIT/TERM
code does not get run exactly often. I hate FP math even more now.


Michal

William L. Hartzell

unread,
Nov 15, 2003, 10:42:09 PM11/15/03
to
Sir: Michal Necasek wrote: > Ilya Zakharevich wrote: >> a) Some not-fully understood situations related to PM APIs >> (dependent on a video driver and/or PM hooks?); > This is the real issue. > It just occurred to me that I should test a command line boot... my > WSeB machine does NOT trash the FP CW in command line boot. > Replacing SDD with GENGRADD I can see that the problem still exists > in PM sessions but not in FS - I have a hunch that the latest SNAP > might maybe "fix" this too... just maybe. > So anyway the kernel itself is apparently not the culprit, although > I'd still like to know why running under a debugger should affect > things. This makes it somewhat difficult for me to pinpoint the > problem. >> b) Running INIT/TERM code of certain DLLs; in particular: > This is somewhat unavoidable but not likely a show stopper. DLLs > that don't use FP math should not need to touch the FP CW ever. > For those that do it might be trickier, but still the INIT/TERM > code does not get run exactly often. I hate FP math even more now. Would or could this be related to the use of the floating point registers to do matrix intger math, ie. 3Dnow? Bill Thanks a Million!

Marty

unread,
Nov 15, 2003, 10:41:45 PM11/15/03
to
Michal Necasek wrote:
> Ilya Zakharevich wrote:
>
>> a) Some not-fully understood situations related to PM APIs
>> (dependent on a video driver and/or PM hooks?);
>>
> This is the real issue.
>
> It just occurred to me that I should test a command line boot... my
> WSeB machine does NOT trash the FP CW in command line boot.
>
> Replacing SDD with GENGRADD I can see that the problem still exists
> in PM sessions but not in FS - I have a hunch that the latest SNAP
> might maybe "fix" this too... just maybe.
>
> So anyway the kernel itself is apparently not the culprit,

Shouldn't the kernel be protecting your application and even driver code
from this? Isn't that part of maintaining the proper ring/context?

You can probably work around it in your code, but should you have to??

Ilya Zakharevich

unread,
Nov 16, 2003, 2:39:13 AM11/16/03
to
[A complimentary Cc of this posting was NOT [per weedlist] sent to
Michal Necasek
<mic...@prodigy.net>], who wrote in article <hPBtb.21084$K82....@newssvr33.news.prodigy.com>:

> > a) Some not-fully understood situations related to PM APIs
> > (dependent on a video driver and/or PM hooks?);

> This is the real issue.

Well, until proven otherwise, I expect that it is a corollary of "b"
and hook DLLs. Try it under BOOTOS2-created PM session.

> So anyway the kernel itself is apparently not the culprit, although
> I'd still like to know why running under a debugger should affect
> things. This makes it somewhat difficult for me to pinpoint the
> problem.

Could the debugger somehow "hijacks" PM initialization, so the HOOK
DLLs are run in the context of the debugger?

> > b) Running INIT/TERM code of certain DLLs; in particular:

> This is somewhat unavoidable but not likely a show stopper.

My experience is otherwise. *All* things I *could* trace lead to that.

> DLLs that don't use FP math should not need to touch the FP CW ever.

Michal, you are writing compilers, how can you be so naive? Of course
it is not the application code which trashes FP; I think it is CRTL
initialization code of these DLLs.

> For those that do it might be trickier, but still the INIT/TERM
> code does not get run exactly often.

True. It looks like some broken CRTL trash FP flags in *every* entry
point (or those exported from the DLL?).

Hope this helps,
Ilya

Michal Necasek

unread,
Nov 16, 2003, 5:24:08 AM11/16/03
to
Ilya Zakharevich wrote:

>> This is the real issue.
>
> Well, until proven otherwise, I expect that it is a corollary of "b"
> and hook DLLs. Try it under BOOTOS2-created PM session.
>

The WSeB system I was testing on is a pretty clean install... and
I've made sure that the FP CW corruption is there even with plain
old VGA driver. I suspect it's some part of PM itself that's
doing it.

> Could the debugger somehow "hijacks" PM initialization, so the HOOK
> DLLs are run in the context of the debugger?
>

Then the hooks couldn't work, could they? I think this might well
be some obscure bug in the DosDebug API...

> My experience is otherwise. *All* things I *could* trace lead to that.
>

In this case, it's a call to printf() that does it. I really don't
think that loads any DLLs, not even very indirectly. It'll end up
doing a DosWrite to stdout, which in turn will do who knows what
to display the output in a VIO window...

>>DLLs that don't use FP math should not need to touch the FP CW ever.
>
> Michal, you are writing compilers, how can you be so naive?
>

I'm not writing compilers, just maintaining one ;-) Speaking for
(Open) Watcom, it will never touch the FPU if you aren't using any
FP math. This holds true for DLLs as well, AFAICT. There's just
no math code linked in.

If you do use FP math in a DLL however... all bets are off. The
runtime _will_ set the CW to a default value; moreover if any math
exceptions are triggered, the handler is likely to mess with the
control word too.

I think I've just convinced myself that using FP math in a DLL
that's intended to be called by "any" client is probably more
trouble than it's worth.


Michal

Michal Necasek

unread,
Nov 16, 2003, 5:25:35 AM11/16/03
to
William L. Hartzell wrote:

> Would or could this be related to the use of the floating point
> registers to do matrix intger math, ie. 3Dnow?
>

No. One of the CPUs I was testing on is an ol' PPro, no MMX
or 3DNow in sight. That's not to say MMX apps can't be affected
by this problem.


Michal

Michal Necasek

unread,
Nov 16, 2003, 5:27:11 AM11/16/03
to
Marty wrote:

> Shouldn't the kernel be protecting your application and even driver code
> from this?
>

Maybe the kernel does! I would expect that the problem is entirely
with Ring 3 code. There's an awful lot of stuff that runs in R3 ;-)

> You can probably work around it in your code, but should you have to??
>

Certainly not.


Michal

Meinolf Sondermann

unread,
Nov 16, 2003, 6:33:08 AM11/16/03
to
Michal Necasek wrote:
> Ilya Zakharevich wrote:
>
>> a) Some not-fully understood situations related to PM APIs
>> (dependent on a video driver and/or PM hooks?);
>>
> This is the real issue.
>
> It just occurred to me that I should test a command line boot... my
> WSeB machine does NOT trash the FP CW in command line boot.

You should test if it is the PM or the WPS. Run your tests with
RUNWORKPLACE set to some other exec.

>
> Replacing SDD with GENGRADD I can see that the problem still exists
> in PM sessions but not in FS - I have a hunch that the latest SNAP
> might maybe "fix" this too... just maybe.

Does the problem exist with a non-GRADD video driver?

[...]

--
Bye/2
Meinolf

Scott

unread,
Nov 16, 2003, 10:37:24 AM11/16/03
to
1. The kernel does do a save and restore of FP regs on every context switch
2. I don't know about the debugger, per se -- that would take some effort.
3. The problem you are having is a variation of a typical library (in this
case PM) usage
issue. The code that's changing your FP state is, in fact, running as
part of your thread. I
agree that that it is a really crummy situation, but, in fact, FP on x86
has always been
poorly done, and was made worse by some interesting decisions back in
the DOS days.
There is little or nothing we can do at this point.

I think that fairly recent PMMERGEs might have a SET GRENOFLOAT=TRUE feature
that
reduces FP usage in the graphics engine. Otherwise, you're pretty much SOL.
-Scott


eric w

unread,
Nov 16, 2003, 12:29:25 PM11/16/03
to
On Sun, 16 Nov 2003 15:37:24 UTC, "Scott" <sgarf...@sbcglobal.bogus.net>
wrote:

> 1. The kernel does do a save and restore of FP regs on every context switch

they suspect this is a GCC compiler bug according to bugzilla.

the problem arose when MOZILLA switched from VAC++ to GCC .

http://bugzilla.mozilla.org/show_bug.cgi?id=224487

...eric

Al Savage

unread,
Nov 16, 2003, 12:46:45 PM11/16/03
to
On Sun, 16 Nov 2003 17:29:25 UTC, "eric w" <er...@nospam.net> wrote:

> On Sun, 16 Nov 2003 15:37:24 UTC, "Scott" <sgarf...@sbcglobal.bogus.net>
> wrote:
>
> > 1. The kernel does do a save and restore of FP regs on every context switch
>
> they suspect this is a GCC compiler bug according to bugzilla.
>
> the problem arose when MOZILLA switched from VAC++ to GCC .

So, by implication, there is a similar FP Control Word-trashing bug in
the Open Watcom project's compiler (which is what Michal is working
with)?

--
Regards,
Al S.

eric w

unread,
Nov 16, 2003, 1:45:22 PM11/16/03
to

perhaps something on his system has been compiled with the gcc compiler.

Ilya Zakharevich

unread,
Nov 16, 2003, 1:57:39 PM11/16/03
to
[A complimentary Cc of this posting was NOT [per weedlist] sent to
Michal Necasek
<mic...@prodigy.net>], who wrote in article <cfItb.30132$Jg5....@newssvr31.news.prodigy.com>:

> > My experience is otherwise. *All* things I *could* trace lead to that.
> >
> In this case, it's a call to printf() that does it. I really don't
> think that loads any DLLs, not even very indirectly. It'll end up
> doing a DosWrite to stdout, which in turn will do who knows what
> to display the output in a VIO window...

This was exactly the situation I debugged FP flag corruption first.
Read my initial reply: VIO window writes trigger some HOOK DLLs (when
I debugged it, it was GAMESRVR in UserIni[PM_ED_HOOKS]).

[It probably (?) is not INIT/TERM, but still an operation of a HOOK DLL.]

> > Michal, you are writing compilers, how can you be so naive?

> I'm not writing compilers, just maintaining one ;-)

Then you must know how many unobvious things can go wrong...

> Speaking for (Open) Watcom, it will never touch the FPU if you
> aren't using any FP math. This holds true for DLLs as well,
> AFAICT. There's just no math code linked in.

Good to hear. Apparently, IBM uses some *other* compiler. ;-)

> If you do use FP math in a DLL however... all bets are off. The
> runtime _will_ set the CW to a default value; moreover if any math
> exceptions are triggered, the handler is likely to mess with the
> control word too.

AFAIK, EMX will never mess with FP flags (only an explicit
_control87() from the application can do it).

> I think I've just convinced myself that using FP math in a DLL
> that's intended to be called by "any" client is probably more
> trouble than it's worth.

Only if the compiler is broken. (But the DLL should document the
expected values of FP flags.)

Hope this helps,
Ilya

Michal Necasek

unread,
Nov 16, 2003, 2:17:31 PM11/16/03
to
eric w wrote:

> they suspect this is a GCC compiler bug according to bugzilla.
>

No, they do not. There is a bug in gcc that prevents the
suggested workaround from functioning properly, but it's not gcc
code that's trashing the FP CW.

> the problem arose when MOZILLA switched from VAC++ to GCC .
>

I can easily demonstrate that VAC++ compiled programs have the
exact same problem.


Michal

eric w

unread,
Nov 16, 2003, 2:23:21 PM11/16/03
to

ok.

ain't debugging compilers fun!

takes me back many years...

...eric

Michal Necasek

unread,
Nov 16, 2003, 2:32:17 PM11/16/03
to
Ilya Zakharevich wrote:

> [It probably (?) is not INIT/TERM, but still an operation of a HOOK DLL.]
>

Aha! ;-)

>> I'm not writing compilers, just maintaining one ;-)
>
> Then you must know how many unobvious things can go wrong...
>

Oh yes. Writing DLLs is tricky at the best of times. So's FP
math. Combine the two and it's a serious headache.

> Good to hear. Apparently, IBM uses some *other* compiler. ;-)
>

Most likely! ;-)

> AFAIK, EMX will never mess with FP flags (only an explicit
> _control87() from the application can do it).
>

Are you sure? How can that work? I don't see how EMX could ever
deliver consistent math results without setting the FP CW to a known
value.

>> I think I've just convinced myself that using FP math in a DLL
>>that's intended to be called by "any" client is probably more
>>trouble than it's worth.
>
> Only if the compiler is broken.
>

I think your definition of "broken" is "it's not EMX" :-P


Michal

Michal Necasek

unread,
Nov 16, 2003, 2:48:12 PM11/16/03
to
Scott wrote:

> 2. I don't know about the debugger, per se -- that would take some effort.
>

Do you have any idea why it might happen? This issue really bothers me
(in a way more than the actual corruption). I just have no idea how the
debugger could do it.

> 3. The problem you are having is a variation of a typical library (in this
> case PM) usage issue. The code that's changing your FP state is, in fact,
> running as part of your thread.
>

That's certainly what it looks like.

> There is little or nothing we can do at this point.
>

There might be if I could track down what exactly is causing the
corruption...

But I concur that FP math is pretty screwed up on x86.

> I think that fairly recent PMMERGEs might have a SET GRENOFLOAT=TRUE feature
> that reduces FP usage in the graphics engine.
>

Thanks, I think I'll try that. What does "fairly recent" mean BTW?


Michal

Al Savage

unread,
Nov 16, 2003, 3:21:55 PM11/16/03
to
On Sun, 16 Nov 2003 18:45:22 UTC, "eric w" <er...@nospam.net> wrote:

> > So, by implication, there is a similar FP Control Word-trashing bug in
> > the Open Watcom project's compiler (which is what Michal is working
> > with)?
>
> perhaps something on his system has been compiled with the gcc compiler.

???
Michal's testcase code is what he's using to generate the failure, and
he's not using GCC to compile it, he's using Open Watcom (I think).

Or, do you mean that there is some other, running app (compiled by GCC),
that is causing his testcase to present FPCW corruption?

--
Regards,
Al S.

eric w

unread,
Nov 16, 2003, 3:40:02 PM11/16/03
to

my 1st thoughts were he was using gcc to generate the watcom compiler
(horrors);

OR perhaps SNAP used GCC to generate the versions we are running;

but it sounds like we have some VERY talented people all looking into this bug
& I aver it will be solved by the end of the week!

cheers...
...eric

Michal Necasek

unread,
Nov 16, 2003, 4:22:50 PM11/16/03
to
eric w wrote:

> my 1st thoughts were he was using gcc to generate the watcom compiler
> (horrors);
>

It should be possible (OW can be built with gcc on Linux), but what'd
be the point?

Anyway I repeat, apps built with VAC++ have the same problem. The
trick is that:

- VAC++ apps appear to have a default math exception handler that
masks the problem; Watcom, Borland and gcc apps do not handle FP
exceptions when they aren't expecting them. NB: VAC++ apps will still
deliver inconsistent math results.

- The code trashing the FP CW was likely built with VAC++, hence the
trashed FP CW is a lot like what VAC++ apps would normally use anyway.

> OR perhaps SNAP used GCC to generate the versions we are running;
>

It didn't, because gcc is not very suitable for low level OS/2
development (SNAP for OS/2 is built almost completely with VAC++ 3.08,
except for all the actual driver code which is built with Watcom).

At any rate the corruption was occurring even when SNAP wasn't being
used at all, with plain VGA driver.


Michal

Paul Ratcliffe

unread,
Nov 16, 2003, 5:43:08 PM11/16/03
to
On Sun, 16 Nov 2003 02:14:13 GMT, Michal Necasek <mic...@prodigy.net> wrote:

> I have a very strong suspicion that "recent" OS/2 kernels are
> seriously broken WRT floating point math. Some OS/2 API calls
> have a tendency to trash the FP control word. This was also
> observed by the Mozilla folks.

FWIW, here are my results with the .EXE built using VAC++ 3.08:

On Warp 4 FP15, Matrox 2.21.063 drivers, 14.096e kernel, Full screen:
cw = 0X62
cw = 0X62
cw = 0X62
cw = 0X62
0

On Warp 4 FP15, Matrox 2.21.063 drivers, 14.096e kernel, windowed and
on eCS 1.1 no fixes, SDD, 14.093 kernel, windowed:
cw = 0X62
cw = 0X62
cw = 0X37F
cw = 0X37F
5.56268e-309

On eCS 1.1 no fixes, SDD, 14.093 kernel, Full screen:
cw = 0X62
cw = 0X62
cw = 0X362
cw = 0X362
0

Michal Necasek

unread,
Nov 16, 2003, 10:07:41 PM11/16/03
to
Paul Ratcliffe wrote:

> FWIW, here are my results with the .EXE built using VAC++ 3.08:
>
> On Warp 4 FP15, Matrox 2.21.063 drivers, 14.096e kernel, Full screen:
> cw = 0X62
> cw = 0X62
> cw = 0X62
> cw = 0X62
> 0
>

> On eCS 1.1 no fixes, SDD, 14.093 kernel, Full screen:
> cw = 0X62
> cw = 0X62
> cw = 0X362
> cw = 0X362
> 0
>

I think this is A Clue. I just don't know what it means yet.

What happens is that SDD drags in a bunch of PM DLLs into FS processes.
This was never really intended, it just happened to work. Until recently,
when it started causing deadlocks after VIDEOPMI got updated... to cut
the story short, the latest version of SNAP does not do this anymore, and
I suspect (and hope) that the FP CW corruption won't be there in FS. Need
to check this.

I think I'll play with KDB for a bit tomorrow - that is, if I figure
out how the heck I can examine FP registers in KDB! Maybe ICAT can do
it, hmm...


Michal

Ilya Zakharevich

unread,
Nov 16, 2003, 10:25:53 PM11/16/03
to
[A complimentary Cc of this posting was NOT [per weedlist] sent to
Michal Necasek
<mic...@prodigy.net>], who wrote in article <5hQtb.21258$Da7....@newssvr33.news.prodigy.com>:

> > AFAIK, EMX will never mess with FP flags (only an explicit
> > _control87() from the application can do it).

> Are you sure? How can that work? I don't see how EMX could ever
> deliver consistent math results without setting the FP CW to a known
> value.

It is set to a known value by a startup code. Then it is the
responsibility of the application. If *the application* does not
change flags, the flag stays the same.

Personally, I do not see any "trickyness" related to DLLs and/or FP
math. DLLs are just executables using somebody else's stack; since
the structure of the stack does not matter 99.999% of the time, this
is irrelevant for most purposes.

Unless you do *very deep* FP stuff (e.g., you need to run your
calculation twice with different FP flags - to check the stability of
the algorithm), you just do not muck with FP flags, period.

And no function should have FP flag different on return() (comparing
to the entry) - with the obvious exception of the function the purpose
of which is to change FP flags.

> >> I think I've just convinced myself that using FP math in a DLL
> >>that's intended to be called by "any" client is probably more
> >>trouble than it's worth.

> > Only if the compiler is broken.

> I think your definition of "broken" is "it's not EMX" :-P

EMX is unsupported. While this continues, it is as broken as the rest
(or more). This may be easily changed - but apparently we do not have
enough interested people...

Hope this helps,
Ilya

Ilya Zakharevich

unread,
Nov 16, 2003, 10:31:56 PM11/16/03
to
[A complimentary Cc of this posting was NOT [per weedlist] sent to
Michal Necasek
<mic...@prodigy.net>], who wrote in article <f3Qtb.21251$u47....@newssvr33.news.prodigy.com>:

> > they suspect this is a GCC compiler bug according to bugzilla.

> No, they do not. There is a bug in gcc that prevents the
> suggested workaround from functioning properly

Could you provide a pointer, please? I mostly use infinite-precision
calculators, for which FP does not matter much, but I would like to
analyse this anyway...

> > the problem arose when MOZILLA switched from VAC++ to GCC .

> I can easily demonstrate that VAC++ compiled programs have the
> exact same problem.

I would suspect that VAC++ may have its own trashing of FP flags -
which might have masked the trashing from other components (e.g., OS/2
"CORE"). Since GCC is (AFAIK) FP-flags transparent, any change done
by the other components is *immediately* visible.

Ilya

Ilya Zakharevich

unread,
Nov 16, 2003, 10:34:47 PM11/16/03
to
[A complimentary Cc of this posting was NOT [per weedlist] sent to
Michal Necasek
<mic...@prodigy.net>], who wrote in article <0wQtb.21259$gg7....@newssvr33.news.prodigy.com>:

> But I concur that FP math is pretty screwed up on x86.

Again, could you be more detailed here? AFAIK, x86 (can be made)/is
sufficiently close to IEEE for most purposes...

Thanks,
Ilya

eric w

unread,
Nov 16, 2003, 10:51:28 PM11/16/03
to
On Mon, 17 Nov 2003 03:34:47 UTC, Ilya Zakharevich <nospam...@ilyaz.org>
wrote:

i think he refers to Intel's implementation at the hardware level & how the
machine instructions interact.

eric w

unread,
Nov 16, 2003, 10:53:16 PM11/16/03
to
On Mon, 17 Nov 2003 03:31:56 UTC, Ilya Zakharevich <nospam...@ilyaz.org>
wrote:

> > > they suspect this is a GCC compiler bug according to bugzilla.


>
> > No, they do not. There is a bug in gcc that prevents the
> > suggested workaround from functioning properly
>
> Could you provide a pointer, please? I mostly use infinite-precision
> calculators, for which FP does not matter much, but I would like to
> analyse this anyway...

http://bugzilla.mozilla.org/show_bug.cgi?id=224487

Michal Necasek

unread,
Nov 17, 2003, 12:56:39 AM11/17/03
to
Ilya Zakharevich wrote:

> Again, could you be more detailed here? AFAIK, x86 (can be made)/is
> sufficiently close to IEEE for most purposes...
>

I'm not talking about the FPU itself - more like the practical
implementation in a complex multitasking environment. This is probably
for the most part a throwback to the fact that the FPU was initially
a separate chip. It shows.


Michal

Michal Necasek

unread,
Nov 17, 2003, 1:07:36 AM11/17/03
to
Ilya Zakharevich wrote:

> It is set to a known value by a startup code. Then it is the
> responsibility of the application. If *the application* does not
> change flags, the flag stays the same.
>

Oh, OK, so EMX _does_ "mess" with the FP CW. Just like the other
compilers do - set it to a known default during program startup. The
problem is that different compilers have different defaults, and
this naturally also explains why running init code of foreign DLLs
tends to trash the FP CW.

> Personally, I do not see any "trickyness" related to DLLs and/or FP
> math. DLLs are just executables using somebody else's stack; since
> the structure of the stack does not matter 99.999% of the time, this
> is irrelevant for most purposes.
>

That is very seriously untrue. DLLs do not just use someone else's
stack; they also use someone else's memory, file handles and just about
every other resource. Including the FPU state.

> Unless you do *very deep* FP stuff (e.g., you need to run your
> calculation twice with different FP flags - to check the stability of
> the algorithm), you just do not muck with FP flags, period.
>

Yes, that's certainly true. That's why we're having this discussion
in the first place - apps don't expect to have the FP CW changed on them
behind their back, because they're not resetting it all the time!

> And no function should have FP flag different on return() (comparing
> to the entry) - with the obvious exception of the function the purpose
> of which is to change FP flags.
>

I completely agree. Obviously this is not true for some (as yet unknown)
function(s)/API(s).

Practical question: is there some trace utility that would allow me to
track the FPU state across OS/2 API calls? Seeing as debuggers (normally
my favourite tool) are useless in this particular instance...

> EMX is unsupported. While this continues, it is as broken as the rest
> (or more). This may be easily changed - but apparently we do not have
> enough interested people...
>

Heh, don't tell me about it :-)


Michal

Michal Necasek

unread,
Nov 17, 2003, 2:21:39 AM11/17/03
to
Michal Necasek wrote:

> I think this is A Clue. I just don't know what it means yet.
>

I think I have Another Clue. In desperation, I tried to run
OS2TRACE on my test proggy. Only I don't think OS2TRACE can capture
the FPU state, so it doesn't help me much in this case.

Except... the OS2TRACE-instrumented executable suddenly doesn't get
its FP CW trashed! What's up with that?!?

Even stranger, it doesn't matter that the APIs that I suspect
of trashing the FP CW (DosWrite) aren't traced at all. What the
heck could OS2TRACE be doing to affect this?

Curiouser and curiouser...

eric w

unread,
Nov 17, 2003, 2:47:00 AM11/17/03
to

almost sounds like interrupt timing dependencies.

has anyone tried running on different chips; like athlon vs. pentium???

...eric

Ilya Zakharevich

unread,
Nov 17, 2003, 5:38:13 AM11/17/03
to
[A complimentary Cc of this posting was NOT [per weedlist] sent to
Michal Necasek
<mic...@prodigy.net>], who wrote in article <IAZtb.21613$lr1....@newssvr33.news.prodigy.com>:

> > It is set to a known value by a startup code. Then it is the
> > responsibility of the application. If *the application* does not
> > change flags, the flag stays the same.

> Oh, OK, so EMX _does_ "mess" with the FP CW.

Nope.

> Just like the other
> compilers do - set it to a known default during program startup. The
> problem is that different compilers have different defaults, and
> this naturally also explains why running init code of foreign DLLs
> tends to trash the FP CW.

AFAIK, EMX DLL startup code is not doing anything with the FP flags.
So it is not "messing" with flags at all: only the startup code of EMX
*executables* changes anything. Checking... Actually, right now I
cannot find any code which *calls* _control87()... I'm pretty sure I
saw some when I was debugging these problems (last time 3 years ago,
when TCPIP32.DLL turned out to trash the flags on load), but today I
can't...

> That is very seriously untrue. DLLs do not just use someone else's
> stack; they also use someone else's memory, file handles and just about
> every other resource. Including the FPU state.

This is not different from having the code statically loaded; so what
is your point? I singled out the stack since it is mapped
"essentially differently" with different compilers...

> > And no function should have FP flag different on return() (comparing
> > to the entry) - with the obvious exception of the function the purpose
> > of which is to change FP flags.

> I completely agree. Obviously this is not true for some (as yet unknown)
> function(s)/API(s).

I think the only thing we may hope to is to get the list of these
functions, and put wrappers in c.lib. Or maybe Watcom with it smart
calling-convention handlers can autogenerate wrappers for "calling
convention which trashes FP flags" automatically?

However, even in this best scenario I have no idea which entity can
generate such a list. :-(

> Practical question: is there some trace utility that would allow me to
> track the FPU state across OS/2 API calls? Seeing as debuggers (normally
> my favourite tool) are useless in this particular instance...

I do not remember any problem debugging this with sd386.

BTW, can't you modify the calling-convention part of Watcom to
checkpoint FP flags on entry and return, and complain on a discrepancy?

> > EMX is unsupported. While this continues, it is as broken as the rest
> > (or more). This may be easily changed - but apparently we do not have
> > enough interested people...

> Heh, don't tell me about it :-)

This was not directed to you, you have enough problems in your pocket
anyway ;-). But I still hope that if I make remainders each couple of
months, enough people will realize that it is going to be time-saver
for them too to fix problems globally, and not per-application...

[And *several* people is required to get peer-review for QA purposes.]

Yours,
Ilya

Ilya Zakharevich

unread,
Nov 17, 2003, 5:45:46 AM11/17/03
to
[A complimentary Cc of this posting was sent to
eric w
<er...@nospam.net>], who wrote in article <vSrfmdoFuNkL-p...@nospam.nospam.net>:

> > > No, they do not. There is a bug in gcc that prevents the
> > > suggested workaround from functioning properly

> http://bugzilla.mozilla.org/show_bug.cgi?id=224487

- Does not optimize jsnum.c. Due to an optimizer bug in GCC, the _control87()
call was getting reordered after the floating point calls, resulting in a
crash.

Is this actually a bug? I do not remember which function calls may be
reordered; the common sense says that 'none' - but I think that it
were the floating point calls which were reordered before
_control87(), not _control87() after them ;-).

Do I need to change

unsigned fpflag = _control87(0,0);

to

volatile unsigned fpflag = _control87(0,0);

in all of my code??? Should this help?

Ilya

Marc L. Cohen

unread,
Nov 17, 2003, 11:41:53 AM11/17/03