Re: Sunperf library, pure functions?

From: PHinker (hinker_at_comcast.net)
Date: 11/05/04 

Date: 5 Nov 2004 07:33:56 -0800

Richard E Maine <nospam@see.signature> wrote in message news:<m1mzxx8nf5.fsf@MLMCE0000L22801.local>...
> Janne Blomqvist <foo@bar.invalid> writes:
>
> > On 2004-11-04, David Ham <d.a.ham@citg.tudelft.nl> wrote:
>
> >> Except that f90 is very commonly used as a suffix meaning "free form
> >> fortran source" even if the source is actually f95 just as .f is used to
> >> mean "fixed form fortran source" even if the source is f90 or f95.
> >>
> >> It has been pointed out here a number of times that the commonly used
> >> suffixes are not totally logical.
> >
> > Yes, I'm aware of that. But, I don't think there necessarily is a
> > connection between the symbol name and the name of the source
> > file.
>
> True, but... the same kind of "logic" that resulted in ".f90" being
> a common source file name for f95 code turns out to apply to other
> situations. F95 compilers often were typically evolutionary
> developments from f90 compilers, rather than wholy new from scratch.
> As such, if compiler internals included f90 in their names, these
> often didn't change. In some cases, changing them would cause
> pointless incompatibility with code compiled with earlier
> compiler versions.
>
> It is really the same reason. Once you have adopted f90 as part of
> the name, be it a file name or a compiler internal procedure, you
> end up not wanting to introduce needless incompatibilities.
> Perhaps the f90 shouldn't have been adopted as part of the name in the
> first place, but that's hindsight.
>
> Thus you can't conclude much about f95 support just based on
> finding f90 in an internal name. Maybe the product version in
> question doesn't support f95 - I don't know; but I don't think
> you can deduce that solely based on the internal name. The
> observed behavior is perhaps stronger evidence, though not
> conclusive.

As it turns out, the 'mangled name' that the compiler outputs is just
a string used to differentiate the various incarnations of the NRM2
generic interface. We use a common source to provide the
computational functionality for specific routines and automatically
generate a variety of language and legacy interfaces. The routine in
question (snrm2) is a member of the 'family' of routines designated as
NRM2.

interface nrm2
   real function snrm2(n,x,incx)
   ...
   end function
   real*8 function dnrm2(n,x,incx)
   ...
   end function
end interface

However many BLAS routines have parameters which are not frequently
used as demonstrated by Mikael's code. He is calling nrm2 with only
the array parameter (X). To provide that functionality without
writing specific F95 code for all 1700+ routines in the Performance
Library, we expand the family interface as follows:

interface nrm2
   real function snrm2(n,x,incx)
     integer :: n, incx
     real :: x(*)
   end function
   real*8 function dnrm2(n,x,incx)
      integer :: n, incx
      real*8 :: x(*)
   end function
   real function ___pl_snrm2_f90(n,x,incx)
      integer, optional, intent(in) :: n, incx
      real, intent(in), dimension(:):: x
   end function
   real*8 function ___pl_dnrm2_f90(n,x,incx)
      integer, optional, intent(in) :: n, incx
      real*8, intent(in), dimension(:) :: x
   end function
end interface

   We then create F95 wrappers which provide the optional parameter
processing:

subroutine ___pl_snrm2_f90(n,x,incx)
integer, intent(IN), optional :: n, incx
real, dimension(:), intent(IN) :: x
integer :: _n, _incx

if (.not. present(n)) then
   _n = size(x)
else
   _n = n
endif
if (.not. present(incx)) then
   _incx = 1
else
   _incx = incx
endif
___pl_snrm2_f90 = snrm2(_n, x, _incx)
return
end

   This is so we can provide both the F90[F95] OPTIONAL parameter
support as well as not breaking legacy code which uses the old style
F77 interfaces to the BLAS and LAPACK routines.

   I'm typing this all from memory so I probably made some mistakes
but you get the gist of it from this I think. The F95 wrappers are
more complex than what I've shown. For instance, we short-circuit the
compiler's desire do gather/scatter on non-unit-stride vectors and
matrices when calling 'foreign' languages.

Relevant Pages

  • Re: MFC and c++ problems
    ... compiler to generate code that is architecturally nonsensical. ... So a design in which a control has any syntactic knowledge of any container of itself ... GetParent->SendMessage is the interface of choice, ...
    (microsoft.public.vc.mfc)
  • Re: Win32 API and gfortran
    ... write out a module containing only interface blocks and compile the ... that the /iface switches and ATTRIBUTES directives change the compiler ... arguments are passed in the normal Fortran way ...
    (comp.lang.fortran)
  • Re: Using early-bound interface on a late-bound object
    ... > the compiler determines which interfaces to use, ... > supports the declared interface. ... >> help if someone can point me to some authoritative document or reference ... within customer shops when they mirrored this 'division' to keep their ...
    (microsoft.public.vb.general.discussion)
  • Re: object system...
    ... in a statically compiled app, all of the type information is known at ... compiler starts integrating itself with the outside world, ... produces the result, the type or interface. ... optimizations the ...
    (comp.object)
  • Re: Some OO design principles WAS Re: Differences in data description in programming languages
    ... Late binding means it is resolved at run time. ... Conformance is a quality that applies to interfaces. ... * An interface can also be a collection of method prototypes, ... the Compiler provides conformance checking. ...
    (comp.lang.cobol)