Path: utzoo!attcan!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!elroy.jpl.nasa.gov!ames!eos!eugene
From: eugene@eos.arc.nasa.gov (Eugene Miya)
Newsgroups: comp.benchmarks
Subject: Re: more bc babble
Message-ID: <7709@eos.arc.nasa.gov>
Date: 18 Dec 90 22:24:25 GMT
References: <1990Dec11.163826.5439@eagle.lerc.nasa.gov> <OLES.90Dec13213301@kelvin.uio.no> <111443@convex.convex.com> <KHB.90Dec17205404@chiba.Eng.Sun.COM>
Reply-To: eugene@eos.UUCP (Eugene Miya)
Organization: NASA Ames Research Center, Calif.
Lines: 22

In article <KHB.90Dec17205404@chiba.Eng.Sun.COM> khb@chiba.Eng.Sun.COM
(Keith Bierman fpgroup) writes:
>There are systems which still don't know about the "ibmism" real*8
>means DOUBLE PRECISION.

Still benchmarking and I don't have a lot of time. BUT..
      REAL*8
works on the Univac/Unisys EXEC*1100 ASCII Fortran compiler, even tho..
'8' has absolutely no meaning on this 36-bit word oriented machine.

Then, you can always tell the REAL perspective of a user when as you them
what single-precision means.  Real(tm) numeric types insist on 64-bit 8^).

Added note on the series benchmark.  I see you use DINT().  Turns out
the CRI CFT[77] lines of compilers fails Fortran compiler validation suite
test T801 (there abouts), subtest (some number) which is the DINT() conversion.
Interesting selection.  Back to the remote login (this one via phone,
have your ever thought about benchmarking phone systems........).

--e.n. miya, NASA Ames Research Center, eugene@eos.arc.nasa.gov
  {uunet,mailrus,most gateways}!ames!eugene
  AMERICA: CHANGE IT OR LOSE IT.