Structure of large link libraries in f95

glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:

> If I understand the INTRINSIC attribute almost all can now be passed
> as actual arguments.

No. The opposite. Almost none can. Basically, the list of those that can
be passed as actual arguments hasn't changed since days of yore. Might
be that one or two got added somewhere. I'd have to check to make sure
of that, but mostly the list of ones that can be passed has stayed
stagnant, while the list of intrinsics that exist has grown greatly.

Most of the intrinsics don't even have specific names, just generic
names. Having a specific name is a first requirement for being passed,
as there is currently no facility for passing a generic as an actual
argument. You might have overlooked this, as generic names didn't exist
in f66, but it is of major importance to this matter today. I would say
that the specific name business was the major reason, rather than
anything having to do with inline generation. It would have been a royal
pain to define specific names for all the combinations of kinds even
explicitly mentioned in the standard, much less, kinds not required by
the standard, but widely supported. Making zillions of specific names
just isn't a viable approach to this.

--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain

Steven G. Kargl wrote:
>
>>I just tried compiling Olagnon's f90aib and it blew my year-old version
>>of gfortran. Last time I tried it, maybe 5 years ago, it blew the
>>then-current Salford compiler and gave an "unimplemented feature"
>>message with the Lahey compiler. Evidently it is a harsh test for an
>>f90 compiler.
>
>
> Run, do not walk, to the gfortran wiki to get a new copy of
> gfortran. I just compiled f90aib with both the 4.1.1 and trunk
> versions of gfortran.
>
>
The new gfortran no longer crashes on compiling f90aib.f90, and the
executable works ok on the source file f90aib.f90, but it fails on
Metcalf's convert.f90, giving as output only a message specifying usage
syntax.

Richard Maine wrote:

> Gary L. Scott <garyscott@ev1.net> wrote:
>
>
>>Richard Maine wrote:
>
>
>>>Not only doesn't the Fortran standard have file scope, it doesn't even
>>>have the concept of a source file at all. The source code is just a
>>>sequence of lines.
>>>
>>
>>So, they might be internal, they might be external, since it's
>>undefined.
>
>
> No, it is perfectly well defined that the procedures you are talking
> about are external. That has nothing to do with any question about
> source files. They have the syntax of external procedures - they aren't
> after a contains.
>
> Why would you say it is undefined? I don't follow that. Being in the
> same file isn't even a concept of the standard, so it would not affect
> anything.... including it would not make perfectly well-defined things
> suddenly become undefined.
>

It just seems to me that CONTAINS is superfluous in this case. It makes
perfect sense for those procedures in the same source file to be treated
as internal since ALL of the same information is available. They're
certainly not "external" in the literal sense because there is no
library generated (at least I've never known a compiler to do that) and
so they are not made available as an external library procedure,
accessible for other applications to use. They exist only as a part of
this compilation. But my confusion included the fact that I had
realized that contains could be used outside of a module.

--

Gary Scott
mailto:garyscott@ev1.net

Fortran Library: http://www.fortranlib.com

Support the Original G95 Project: http://www.g95.org
-OR-
Support the GNU GFortran Project: http://gcc.gnu.org/fortran/index.html

Why are there two? God only knows.


If you want to do the impossible, don't hire an expert because he knows
it can't be done.

-- Henry Ford

I wrote:
> > They have the syntax of external procedures - they aren't
> > after a contains.

Gary L. Scott <garyscott@ev1.net> wrote:

> It just seems to me that CONTAINS is superfluous in this case.

So? You seem to be trying to make things much more complicated than they
are, bringing in irrelevant things. They have the syntax of external
procedures - period.

> It makes
> perfect sense for those procedures in the same source file to be treated
> as internal since ALL of the same information is available.

You are bringing in irrelvancies and tyrying to reason backwards. The
definition of an internal procedure is that it appears after a contains
in its host procedure.

The definition is not "has information available". That is a property of
internal procedures, but it is not the definition. Having such
information does not make something internal. Internal procedures also
have other properties. For example, they get host association, and their
name is local to their host. Your other procedures in the same file
don't have those properties. Furthermore, other kinds of procedures can
also have information available (notably module procedures).

You are taking one particular property that an internal procedure
has,and you are treating that as though it were the definition of an
internal procedure. It isn't. If you try to treat that as the
definition, you won't be able to get very far.

> They're
> certainly not "external" in the literal sense because there is no
> library generated

They certainly *ARE* in the literal sense. The literal definition is
syntactic. Their source code is in a propgram unit not contained in any
other program unit. That's the literal definition. There is nothing
about "libraries" in the definition at all. Nor is it even particularly
related. Absolutely all Fortran code can go in libraries. That includes
main programs, external procedures, modules, block data. For that
matter, internal procedures and statement functions are also in
libraries insomuch as they are in procedures that are in the libraries.
None of that has *ANYTHING* to do with the standard or its classication
of procedures.

Again, I think you are using some definition of your own. I'm not even
quite sure what this definition is, but it clearly isn't the one of the
standard.

--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain

> I suppose intrinsics are just another library. I guess they come first.

The important distinction is that the compiler knows about the intrinsics.
For instance, the DEC compilers have always translated them into an external
name with a namespace prefix, e.g., FOR$ for Fortran specific stuff and MTH$
for the more general stuff such as the trig functions. Thus, you can have an
XYZ() call in a Fortran component and an XYZ() call in a C component, but the
linker will actually link to two different routines.

Jan

Jan Vorbrüggen wrote:

>> I suppose intrinsics are just another library. I guess they come first.

> The important distinction is that the compiler knows about the intrinsics.
> For instance, the DEC compilers have always translated them into an
> external name with a namespace prefix, e.g., FOR$ for Fortran specific
> stuff and MTH$ for the more general stuff such as the trig functions.
> Thus, you can have an XYZ() call in a Fortran component and an XYZ()
> call in a C component, but the linker will actually link to two
> different routines.

The FOR$ and MTH$ are VMS library routines. (I don't think DEC
compilers before VAX did that.) VMS has a language independent
library, along with %VAL(), %REF() and %DESCR() to allow programs
to call routines in another language using a different calling convention.

Otherwise, in many cases calling a different name is required for
generic to work. You could even call XYZ() from another Fortran
routine and expect it to work.

It used to be that intrinsic was generated inline, though the only
difference that should make is speed (and size). Making everything
intrinsic allows them to be generated inline. A different external
name means you normally won't notice the difference.

-- glen

-- glen

> It used to be that intrinsic was generated inline, though the only
> difference that should make is speed (and size).

I don't think the VMS compilers ever put the trig intrinsics inline,
for instance. Type conversion etc. is a different matter, of course.
But as you say, implementation shouldn't make a difference here.

Jan

Jan Vorbrüggen <jvorbrueggen-not@mediasec.de> wrote:

> The important distinction is that the compiler knows about the intrinsics.
> For instance, the DEC compilers have always translated them into an external
> name with a namespace prefix, e.g., FOR$ for Fortran specific stuff and MTH$
> for the more general stuff such as the trig functions. Thus, you can have an
> XYZ() call in a Fortran component and an XYZ() call in a C component, but the
> linker will actually link to two different routines.

This is much like the underscore convention (or, I should say
conventions, as there are multiple variations) for many Unix and other
compilers.

I worked with at least one compiler once that didn't do this. Or anyway,
it didn't do it by default and I couldn't find a way to make it do so
(perhaps there was an option I never found). It was on an HP unix system
- some years ago, not a real recent one.

My f77 codes used to stick strictly to the standard 6-character limit. I
eventually gave into somewhat longer names even before f90, but in the
early f77 days, I stuck pretty strictly to 6, having been burned by
compilers that didn't accept longer names (or abused longer names in
ways that I hesitate to mention in polite company. Skip to the close
parens if you are under 21. Quietly allowed long names, but only
considered the first 8 characters significant. There, I've said it.)

Anyway, 6 characters is sort of limiting, particularly if you try for
any semblance of meaning. You are likely to use names such as fread and
fseek, as I did. Those names were form before I knew enough C/Unix to
know better. I could not have both the system one and mine in the sam
eprogram - or anyway, I couldn't figure out how to at the time. I wasn't
going to get anywhere useful without the system one. Mine had to have a
name change. The painful part wasn't in changing the name in my own
code; that was simple enough. But my code provided a library used by
many other people at my site. Those names were part of my documented
API. (That was from before I knew the buzzword "API", but I still had
one, without the buzzword). So all my users would have to change their
code also. Fortunately, we didn't have a lot of users on the HP system.
So I left the API as was for most systems; I just documented the HP as
an exception. That seemed simpler than making the incompatible change
everywhere.

--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain| experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain

glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:

> Richard Maine wrote:

> > Basically, the list of those [intrinsics] that can
> > be passed as actual arguments hasn't changed since days of yore. Might
> > be that one or two got added somewhere. I'd have to check to make sure
> > of that, but mostly the list of ones that can be passed has stayed
> > stagnant, while the list of intrinsics that exist has grown greatly.
>
> OK, I see now. It does seem that the ones that can be passed as actual
> arguments has increased somewhat, but not quite as fast as the overall
> number. I was basing it on how many had bullets indicating that they
> couldn't be passed.

There might be a few more bullets in that table. I'll believe that
without bothering to check. The big thing is that most of the intrinsics
aren't even in the table at all, with or without bullets, as that is a
table of the specific names. Intrinsics that only have generic names
aren't there.

(Yes, I saw from the rest of your post that you understood correctly. I
just thought I'd add this slight elaboration.)

--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain| experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain

Richard Maine wrote:
> I wrote:
>
>>> They have the syntax of external procedures - they aren't
>>>after a contains.
>
>
> Gary L. Scott <garyscott@ev1.net> wrote:
>
>
>>It just seems to me that CONTAINS is superfluous in this case.
>
>
> So? You seem to be trying to make things much more complicated than they
> are, bringing in irrelevant things. They have the syntax of external
> procedures - period.
>
>
>>It makes
>>perfect sense for those procedures in the same source file to be treated
>>as internal since ALL of the same information is available.
>
>
> You are bringing in irrelvancies and tyrying to reason backwards. The
> definition of an internal procedure is that it appears after a contains
> in its host procedure.
>
> The definition is not "has information available". That is a property of
> internal procedures, but it is not the definition. Having such
> information does not make something internal. Internal procedures also
> have other properties. For example, they get host association, and their
> name is local to their host. Your other procedures in the same file
> don't have those properties. Furthermore, other kinds of procedures can
> also have information available (notably module procedures).
>
> You are taking one particular property that an internal procedure
> has,and you are treating that as though it were the definition of an
> internal procedure. It isn't. If you try to treat that as the
> definition, you won't be able to get very far.
>
>
>>They're
>>certainly not "external" in the literal sense because there is no
>>library generated
>
>
> They certainly *ARE* in the literal sense. The literal definition is
> syntactic. Their source code is in a propgram unit not contained in any
> other program unit. That's the literal definition. There is nothing
> about "libraries" in the definition at all. Nor is it even particularly
> related. Absolutely all Fortran code can go in libraries. That includes
> main programs, external procedures, modules, block data. For that
> matter, internal procedures and statement functions are also in
> libraries insomuch as they are in procedures that are in the libraries.
> None of that has *ANYTHING* to do with the standard or its classication
> of procedures.
>
> Again, I think you are using some definition of your own. I'm not even
> quite sure what this definition is, but it clearly isn't the one of the
> standard.
>
I was suggesting how it might have been. I was not arguing how it is
presently defined in the standard.

--

Gary Scott
mailto:garyscott@ev1.net

Fortran Library: http://www.fortranlib.com

Support the Original G95 Project: http://www.g95.org
-OR-
Support the GNU GFortran Project: http://gcc.gnu.org/fortran/index.html

Why are there two? God only knows.


If you want to do the impossible, don't hire an expert because he knows
it can't be done.

-- Henry Ford

Gary L. Scott <garyscott@ev1.net> wrote:

> I was suggesting how it might have been. I was not arguing how it is
> presently defined in the standard.

Oh. Sorry. I didn't pick up on that.

Yes, the standard could have defined the concept of a source file. And
had it done so, it could have specified... I don't know... lots of
things about it, maybe including the things you mentioned. I guess I
have no comment along that line, then.

--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain