Discussion:
Floating point mystery
(too old to reply)
Ivan Levashew
2009-05-05 05:34:46 UTC
Permalink
Hello!

I can't get floating point operations working. Try running this in your
version of Turbo (Borland) Pascal:

{$N+}
uses CRT;
type Float = Real;

var X, Y, Z : Float;

function TestOK : Boolean;
var R : String;
begin
X := 2.0;
Y := 5.0;
Z := X / Y;
Str(Z : 0 : 3, R);
TestOK := R = '0.400';
end;

var i : Integer;

begin
i := 0;
while TestOK do
begin
i := i + 1;
if i >= 1000 then begin Write('.'); i := 0; end;
if KeyPressed then Break;
end;
WriteLn('Iterations: ', i);
end.

The problem might appear after you have run this program from IDE
several times. It doesn't appear when program is being launched from
command line. It doesn't appear on the first launch.

During the first several runs everything is OK: 2.0 / 5.0 = 0.400

But then floating point goes wild. 2.0 / 5.0 = 5.00, then NaNs, then
another stupid values. I have to keep {$N-,$E+} mode because of this. I
tried various versions of BP, the problem seems to be everywhere.

But I can't remember ever having such a problem on a real DOS
environment. So I guess this is DOSBox specific problem.

Do you know a cure against it? {$N-,E+} doesn't count. Neither FPC.
--
If you want to get to the top, you have to start at the bottom
Marco van de Voort
2009-05-05 07:39:40 UTC
Permalink
Post by Ivan Levashew
But I can't remember ever having such a problem on a real DOS
environment. So I guess this is DOSBox specific problem.
Do you know a cure against it? {$N-,E+} doesn't count. Neither FPC.
Trying to get a fixed DosBox seems the most logical. I doubt you'll find a
"support broken DOSBox floating emulation" switch in a Turbo product from
the early nineties :-)
Ivan Levashew
2009-05-05 08:02:56 UTC
Permalink
Post by Marco van de Voort
Trying to get a fixed DosBox seems the most logical. I doubt you'll find a
"support broken DOSBox floating emulation" switch in a Turbo product from
the early nineties :-)
I'm not sure about the exact nature of this problem. All the 3D games
are full of floating point calculations yet they are indeed working in
DOSBox.
--
If you want to get to the top, you have to start at the bottom
Marco van de Voort
2009-05-05 08:52:03 UTC
Permalink
Post by Ivan Levashew
Post by Marco van de Voort
Trying to get a fixed DosBox seems the most logical. I doubt you'll find a
"support broken DOSBox floating emulation" switch in a Turbo product from
the early nineties :-)
I'm not sure about the exact nature of this problem. All the 3D games
are full of floating point calculations yet they are indeed working in
DOSBox.
It sounds to me like related to missing floating point error handling. I
would expect BP to runtime error on FPU errors, not show "nan".

And 3D games usually don't do any.
Marco van de Voort
2009-05-05 08:52:55 UTC
Permalink
Post by Marco van de Voort
And 3D games usually don't do any.
And they probably stress the 386/387, not the 8086/80286/287 emulation.
Ivan Levashew
2009-05-05 10:57:37 UTC
Permalink
Post by Marco van de Voort
It sounds to me like related to missing floating point error handling. I
would expect BP to runtime error on FPU errors, not show "nan".
Yes, it sometimes show 205 runtime error.

It depends on whether "go wild" happened in "*" or Str.
--
If you want to get to the top, you have to start at the bottom
Bart
2009-05-05 11:04:41 UTC
Permalink
Op Tue, 05 May 2009 12:34:46 +0700 schreef Ivan Levashew
Post by Ivan Levashew
Hello!
I can't get floating point operations working. Try running this in your
I cannot reproduce this with TP 6 on my Win9x system.

Bart
--
Bart Broersma
***@tiscali.nl
(ff _ANTISPAM_ wegpoetsen uit dit adres natuurlijk)
Ivan Levashew
2009-05-05 12:26:59 UTC
Permalink
Post by Bart
Op Tue, 05 May 2009 12:34:46 +0700 schreef Ivan Levashew
Post by Ivan Levashew
Hello!
I can't get floating point operations working. Try running this in your
I cannot reproduce this with TP 6 on my Win9x system.
Bart
Is everything also fine in DOSBox?
--
If you want to get to the top, you have to start at the bottom
Zaphod Beeblebrox
2009-05-05 14:39:08 UTC
Permalink
Post by Ivan Levashew
Hello!
I can't get floating point operations working. Try running this in
<snip>
Post by Ivan Levashew
The problem might appear after you have run this program from IDE
several times. It doesn't appear when program is being launched from
command line. It doesn't appear on the first launch.
During the first several runs everything is OK: 2.0 / 5.0 = 0.400
But then floating point goes wild. 2.0 / 5.0 = 5.00, then NaNs, then
another stupid values. I have to keep {$N-,$E+} mode because of
this. I tried various versions of BP, the problem seems to be
everywhere.
But I can't remember ever having such a problem on a real DOS
environment. So I guess this is DOSBox specific problem.
Do you know a cure against it? {$N-,E+} doesn't count. Neither FPC.
I cannot duplicate it running the TP 7 IDE (w/RT 200 patch) in CMD.EXE
under XP SP3, but it does happen in DOSBox 0.72 under XP SP3 exaclty
as you describe it. Other symptoms include that it visibly slows down
on the run before the problem occurrs, and if you run keep running it,
it will eventually start running properly again and seems to run
properly from then on (well, for at least a couple dozen attempts any
way).

Seems like DOSBox is at fault here. Is there any particular reason
you need to use DOSBox? Also, have you reported this to the DOSBox
developers?
--
Zaphod

Arthur: All my life I've had this strange feeling that there's
something big and sinister going on in the world.
Slartibartfast: No, that's perfectly normal paranoia. Everyone in the
universe gets that.
Ivan Levashew
2009-05-05 15:07:44 UTC
Permalink
Post by Zaphod Beeblebrox
Seems like DOSBox is at fault here. Is there any particular reason
you need to use DOSBox?
NTVDM is in many ways worse and its glitches are less predictable.
Post by Zaphod Beeblebrox
Also, have you reported this to the DOSBox
developers?
No.

I first tried to search for this problem on their forums, but didn't
found anything yet.
--
If you want to get to the top, you have to start at the bottom
Zaphod Beeblebrox
2009-05-05 15:24:57 UTC
Permalink
Post by Ivan Levashew
Post by Zaphod Beeblebrox
Seems like DOSBox is at fault here. Is there any particular reason
you need to use DOSBox?
NTVDM is in many ways worse and its glitches are less predictable.
I can't argue with you there, although I've generally had good luck.
Post by Ivan Levashew
Post by Zaphod Beeblebrox
Also, have you reported this to the DOSBox developers?
No.
I first tried to search for this problem on their forums, but didn't
found anything yet.
If the DOSBox angle doesn't work out, you might consider VMWare. It
shouldn't be too difficult to get a DOS environment up and running
under one of the free VMWare offerings. It may be that it will be
more stable than the current state of DOSBox.
--
Zaphod

Voted "Worst Dressed Sentient Being in the Known Universe" for seven
years in a row.
Ivan Levashew
2009-05-06 09:40:16 UTC
Permalink
Confirmed. It is a DOSBox issue.

http://vogons.zetafleet.com/viewtopic.php?t=21548
--
If you want to get to the top, you have to start at the bottom
Loading...