Discussion:
DECstation 2100 floating point
(too old to reply)
George Harvey
2011-03-21 20:40:14 UTC
Permalink
Hi,

I've been giving 5.1 a try on my DECstation 2100 (PMIN, R2000 CPU). I
had a bit of trouble finding a disk that the ROM would boot from but
apart from that, the network install ran smoothly. However, running a
few test programs, I'm seeing a lot of floating point errors. For
example, the 'flops' benchmark from pkgsrc returns mostly 'nan' and
'inf' values (see sample output below). If I run the same tests on my
5000/133 (3MIN, R3000 CPU), then they work normally so I'm wondering
what the difference is between R2000 and R3000 floating point behaviour?

For info, dmesg shows the CPU types as follows:

On the 2100 it incorrectly shows the CPU as a R3000:
cpu0 at mainbus0: MIPS R3000 CPU (0x220) Rev. 2.0 with MIPS R3010 FPC
Rev. 2.0
On the 5000/133 it shows:
cpu0 at mainbus0: MIPS R3000A CPU (0x230) Rev. 3.0 with MIPS R3010 FPC
Rev. 4.0

George

=== 'flops' output on DECstation 2100 ===
FLOPS C Program (Double Precision), V2.0 18 Dec 1992

Module Error RunTime MFLOPS
(usec)
1 nan 76.7969 0.1823
2 -1.4667e+01 0.0000 inf
3 inf -719077252129430822595458597950846748799629
130127667406135614065924966910426536007118954834557502031540308274
024000458672866887843129056069389197470953087699454232971665626483
163798647964987849155232846343667122095319825962132090969358849540
2929750866960090586776981335080164582762972091727297738377789
44.0000 -0.0000
4 inf 0.0000 inf
5 inf 0.0000 inf
6 inf 0.0000 inf
7 nan 0.0000 inf
8 inf 0.0000 inf

Iterations = 0
NullTime (usec) = 8.0000
MFLOPS(1) = -0.0000
MFLOPS(2) = -0.0000
MFLOPS(3) = -0.0000
MFLOPS(4) = -0.0000

=== end ===

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
George Harvey
2011-03-24 20:27:45 UTC
Permalink
On Mon, 21 Mar 2011 20:40:14 +0000
Post by George Harvey
I've been giving 5.1 a try on my DECstation 2100 (PMIN, R2000 CPU). I
had a bit of trouble finding a disk that the ROM would boot from but
apart from that, the network install ran smoothly. However, running a
few test programs, I'm seeing a lot of floating point errors. For
example, the 'flops' benchmark from pkgsrc returns mostly 'nan' and
'inf' values (see sample output below). If I run the same tests on my
5000/133 (3MIN, R3000 CPU), then they work normally so I'm wondering
what the difference is between R2000 and R3000 floating point behaviour?
A few more details...

If I compile 'flops' with no optimisation then it works on my 2100, if
I use -O or -O2 then it produces 'nan' and 'inf' results. However, if I
copy the binaries over to my 5000/133 then both optimised versions work
normally. So it looks as though GCC is generating code that works on a
R3000/R3010 combo but doesn't work on a R2000/R2010. I've had a hunt
round the 'net and the R2000 and R3000 are supposed to be
instruction-set compatible so I don't understand why I'm seeing
different results.

George

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Simon Burge
2011-03-24 22:00:30 UTC
Permalink
Post by George Harvey
On Mon, 21 Mar 2011 20:40:14 +0000
Post by George Harvey
I've been giving 5.1 a try on my DECstation 2100 (PMIN, R2000 CPU). I
had a bit of trouble finding a disk that the ROM would boot from but
apart from that, the network install ran smoothly. However, running a
few test programs, I'm seeing a lot of floating point errors. For
example, the 'flops' benchmark from pkgsrc returns mostly 'nan' and
'inf' values (see sample output below). If I run the same tests on my
5000/133 (3MIN, R3000 CPU), then they work normally so I'm wondering
what the difference is between R2000 and R3000 floating point behaviour?
A few more details...
If I compile 'flops' with no optimisation then it works on my 2100, if
I use -O or -O2 then it produces 'nan' and 'inf' results. However, if I
copy the binaries over to my 5000/133 then both optimised versions work
normally. So it looks as though GCC is generating code that works on a
R3000/R3010 combo but doesn't work on a R2000/R2010. I've had a hunt
round the 'net and the R2000 and R3000 are supposed to be
instruction-set compatible so I don't understand why I'm seeing
different results.
Hopefully you've just proved that the problem isn't inside libc or
the kernel since just changing the compile options of the program
itself gets the right results.

There are some R2000-specific options to gcc. Can you try the
-march=r2000 and/or -mtune=r2000 options and see if that makes any
difference?

Cheers,
Simon.

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
George Harvey
2011-03-25 21:52:09 UTC
Permalink
On Fri, 25 Mar 2011 09:00:30 +1100
Post by Simon Burge
Post by George Harvey
On Mon, 21 Mar 2011 20:40:14 +0000
If I compile 'flops' with no optimisation then it works on my 2100, if
I use -O or -O2 then it produces 'nan' and 'inf' results. However, if I
copy the binaries over to my 5000/133 then both optimised versions work
normally. So it looks as though GCC is generating code that works on a
R3000/R3010 combo but doesn't work on a R2000/R2010.
Hopefully you've just proved that the problem isn't inside libc or
the kernel since just changing the compile options of the program
itself gets the right results.
There are some R2000-specific options to gcc. Can you try the
-march=r2000 and/or -mtune=r2000 options and see if that makes any
difference?
No difference when applied to 'flops.c'. I tried:

-O
-O -march=r2000
-O -mtune=r2000
-O -march=r2000 -mtune=r2000

And all four produced exactly the same binary.

George

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Izumi Tsutsui
2011-03-26 02:53:00 UTC
Permalink
Post by George Harvey
-O
-O -march=r2000
-O -mtune=r2000
-O -march=r2000 -mtune=r2000
And all four produced exactly the same binary.
Per src/gnu/dist/gcc4/gcc/config/mips/mips.c,
-march=r2000 is the same as r3000.
Post by George Harvey
-O turns on the following optimization flags: -fdefer-pop
-fdelayed-branch -fguess-branch-probability -fcprop-registers
-floop-optimize -fif-conversion -fif-conversion2 -ftree-ccp
-ftree-dce -ftree-dominator-opts -ftree-dse -ftree-ter -ftree-lrs
-ftree-sra -ftree-copyrename -ftree-fre -ftree-ch -funit-at-a-time
-fmerge-constants
It might help to disable each options (by -fno-delayed-branch etc)
and which one causes the errors.

Probably we should also check R2000/R2010 errata.
---
Izumi Tsutsui

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
George Harvey
2011-03-29 20:31:50 UTC
Permalink
On Sat, 26 Mar 2011 11:53:00 +0900
Post by Izumi Tsutsui
-O turns on the following optimization flags: -fdefer-pop
-fdelayed-branch -fguess-branch-probability -fcprop-registers
-floop-optimize -fif-conversion -fif-conversion2 -ftree-ccp
-ftree-dce -ftree-dominator-opts -ftree-dse -ftree-ter -ftree-lrs
-ftree-sra -ftree-copyrename -ftree-fre -ftree-ch -funit-at-a-time
-fmerge-constants
It might help to disable each options (by -fno-delayed-branch etc)
and which one causes the errors.
I tried turning off each option individually and still got 'inf'
results. I then tried turning them all off, and still got an 'inf'
result. The GCC man page says "only optimizations that have a flag are
listed" so I guess it's one of the unlisted ones that's causing the
problem.

George

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Izumi Tsutsui
2011-03-31 13:51:35 UTC
Permalink
Post by George Harvey
I tried turning off each option individually and still got 'inf'
results. I then tried turning them all off, and still got an 'inf'
result. The GCC man page says "only optimizations that have a flag are
listed" so I guess it's one of the unlisted ones that's causing the
problem.
I tried pkgsrc/benchmark/flops on NetBSD/cobalt 5.99.44 and
it shows a bit strange result:
---
# ./flops

FLOPS C Program (Double Precision), V2.0 18 Dec 1992

Module Error RunTime MFLOPS
(usec)
1 -2.5193e+01 0.4895 28.5980
2 nan -0.0000 -4226415.0942
3 1.4544e-14 33.3001 0.5105
4 1.6415e+09 31.9524 0.4694
5 1.8627e+17 69.2567 0.4187
6 -1.1475e+87 40.3928 0.7179
7 5.1090e+02 54.9010 0.2186
8 -2.9167e-01 0.0000 33103448.4122

Iterations = -640000
NullTime (usec) = 0.0000
MFLOPS(1) = 1.5616
MFLOPS(2) = 0.3848
MFLOPS(3) = 0.6340
MFLOPS(4) = 0.8614

---

flops.c itself might have some non-C99-compliant statements
and aggressive gcc4 generates unintended code?

---
Izumi Tsutsui

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
George Harvey
2011-03-31 20:47:24 UTC
Permalink
On Thu, 31 Mar 2011 22:51:35 +0900
Post by Izumi Tsutsui
I tried pkgsrc/benchmark/flops on NetBSD/cobalt 5.99.44 and
That's odd, on my RaQ 2, running NetBSD/Cobalt 5.0.2, with flops
installed from pkgsrc, I get normal-looking results:

-bash-2.05b$ which flops
/usr/pkg/bin/flops
-bash-2.05b$ flops

FLOPS C Program (Double Precision), V2.0 18 Dec 1992

Module Error RunTime MFLOPS
(usec)
1 1.3358e-12 0.2935 47.7073
2 2.0517e-13 0.1487 47.0793
3 1.7542e-14 0.2976 57.1277
4 -5.4512e-14 0.2855 52.5427
5 3.3307e-16 0.4783 60.6303
6 -1.9040e-14 0.3537 81.9794
7 2.6034e-11 0.4904 24.4680
8 -5.4068e-14 0.3737 80.2754

Iterations = 64000000
NullTime (usec) = 0.0000
MFLOPS(1) = 49.9517
MFLOPS(2) = 41.4133
MFLOPS(3) = 56.7492
MFLOPS(4) = 69.4380

George
Post by Izumi Tsutsui
---
# ./flops
FLOPS C Program (Double Precision), V2.0 18 Dec 1992
Module Error RunTime MFLOPS
(usec)
1 -2.5193e+01 0.4895 28.5980
2 nan -0.0000 -4226415.0942
3 1.4544e-14 33.3001 0.5105
4 1.6415e+09 31.9524 0.4694
5 1.8627e+17 69.2567 0.4187
6 -1.1475e+87 40.3928 0.7179
7 5.1090e+02 54.9010 0.2186
8 -2.9167e-01 0.0000 33103448.4122
Iterations = -640000
NullTime (usec) = 0.0000
MFLOPS(1) = 1.5616
MFLOPS(2) = 0.3848
MFLOPS(3) = 0.6340
MFLOPS(4) = 0.8614
---
flops.c itself might have some non-C99-compliant statements
and aggressive gcc4 generates unintended code?
---
Izumi Tsutsui
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Izumi Tsutsui
2011-04-04 13:38:10 UTC
Permalink
Post by George Harvey
Post by Izumi Tsutsui
I tried pkgsrc/benchmark/flops on NetBSD/cobalt 5.99.44 and
That's odd, on my RaQ 2, running NetBSD/Cobalt 5.0.2, with flops
:

I tried it again on the same machine and now it shows sane results:
---
# ./flops

FLOPS C Program (Double Precision), V2.0 18 Dec 1992

Module Error RunTime MFLOPS
(usec)
1 -4.6896e-13 0.4897 28.5902
2 2.2160e-13 0.2482 28.2060
3 -6.9944e-15 0.4963 34.2511
4 -9.7256e-14 0.4762 31.4990
5 -1.6542e-14 0.7981 36.3357
6 4.3632e-14 0.5903 49.1282
7 -4.9454e-11 0.8182 14.6667
8 7.2164e-14 0.6235 48.1187

Iterations = 32000000
NullTime (usec) = 0.0000
MFLOPS(1) = 29.9332
MFLOPS(2) = 24.8230
MFLOPS(3) = 34.0147
MFLOPS(4) = 41.6230

#
---

Probably flops might have some bugs (uninitialized variable etc?)
and we should also check other programs...

---
Izumi Tsutsui

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Loading...