Re: REAL(16) (was Re: [Patch, Fortran] Two minor tweaks for type-bound procedure parsing)

[Steve Kargl <sgk at troutmask dot apl dot washington dot edu>]

On Tue, Aug 26, 2008 at 08:22:41AM +0200, Daniel Kraft wrote:
> Steve Kargl wrote:
> >On Mon, Aug 25, 2008 at 11:50:16PM +0200, Dominique Dhumieres wrote:
> >>>REAL(16) needs to be done in software -- on x86, x86-64 -- as it is not
> >>>supported in hardware; if you want to use more than REAL(8) on x86,
> >>>x86-64 you can use REAL(10).  Or you use a system such as PowerPC which
> >>>supports REAL(16) in silicon.
> >>As far as I can tell, the ifc implementation is a "real" one where the 
> >>full 128 bits are used to code the real number.  So far i did not have 
> >>the time to play with it.
> >>
> >>Now concerning gfortran and since gcc requires gmp and mpfr, how 
> >>difficult (efficient) would it be to use these libraries to implement 
> >>REAL(xxx)?
> >>
> >
> >Getting +, -, *, and / working is almost trivial.  The hard part is 
> >getting REAL(16) working in all the fun corners of the standard 
> >as well as getting IO working.  Here's a start where one may need
> >to distinguish between hardware FP and software emulation.
> 
> Whilst we are at it, what about an INTEGER-KIND for unlimited range 
> using mpz?  And of course, a REAL-KIND for rationals using mpq, not 
> supporting all the trancendental intrinsics, of course...

Personally, I think people should use David Bailey's multi-precision
library

http://www.netlib.org/mpfun/index.html

There is also the possiblity of using mpfr directly via Fortran's
C binding feature.

> And we could do a whole set of KIND's for floating-point numbers for the 
> required precision:
> 
> 10000-19999: mpfr-type with 0000-9999 bits of precision

You only need one.  -freal-bit=XYZ can be used to define a 
XYZ-bit precision real where the exponent range is unlimited
(well, limited by mpfr to something like 2**32-1).

> I thought yesterday a bit about using gmp/mpfr for this kind of problem, 
> too, and am not quite sure whether it will be easy to manage the memory 
> in all cases without leaks; at least until finalization is 
> implemented...  Or do you think this can be done?

There is always the possibility of memory leaks.  OTOH, on the mpfr
mailing list someone has been using valgrind to look for leaks, and
has only found the leaking of cached constants when his program 
exited.  The leaks would come from the Fortran side.

> But in general, this stuff sounds interesting!  Maybe I'll find some 
> time to play with it after the F2003 OOP things that should go in for 
> stage1.

By the time F2003 OOP is completely implemented in gfortran, I suspect
we'll have F2008 to worry about. :-)

-- 
Steve