compilation dependencies
Wood Cantrell
to F90. I am trying to figure out the compile dependency problem.
All that I have read says that there is a comile depency between any
routine and any "use" files. Also that you can't define an
"interface" for a module procedures. This sounds like if you use
modules for everything, every change requires a recompile of every
module up the chain to the main routine, even if the interface is
unchanged. This doesn't sound good for a large program!
In the C/C++ world, (for instance Large Scale C++ Software
Development", by Lakos) there is a distinction between interface and
implementation files and a definite strategy to minimize the recompile
problem. A recompile by a client is necessary only if the interface
changes.
What are the tricks here that I am not seeing? Where can I find
guidelines for large scale program develoment?
(Expected environment will be Sun, SGI, & NT, if any of that matters.)
James Giles
Wood Cantrell wrote in message ...
Unfortunately, you have described the problem very clearly.
The only way to avoid the cascade of recompilations is to avoid
using MODULE procedures.
So, you could continue to work as you did with F77: write
procedures separately and link them together, but providing
explicit interface declarations of these in the code that calls the
procedures (using INCLUDE, for example). You could even
put the explicit interfaces into a MODULE and USE that, but
still compile the actual procedures separately from that MODULE.
Unfortunately, these techniques will (usually) not provide any
automatic check that the explicit interfaces actually match the
declarations in the procedure itself.
--
J. Giles
Jos Bergervoet
>>modules for everything, every change requires a recompile of every
>>module up the chain to the main routine, even if the interface is
>>unchanged. This doesn't sound good for a large program!
> Unfortunately, you have described the problem very clearly.
> The only way to avoid the cascade of recompilations is to avoid
> using MODULE procedures.
I don't believe that is the correct conclusion. You only need to
use a compiler that does NOT require this whole-chain recompilation
(which means that it uses only the interface information from
modules that are used.)
You even could, at the end of development, do a complete rebuild,
with inter-module optimization on (which means that in that case
the compiler can use more than the interface information).
A good compiler should provide both modes of compilation. A Fortran
compiler could easily do that (and a C compiler as well, although
in that case the programmer has the tedious task of keeping the
interfaces consistent with the code).
Or do I overlook some roadblock in the Fortran standard?
-- Jos
Wood Cantrell
wrote:
I agree that the problem is NOT ADDRESSED AT ALL in the standard, or
at least the documents that I have read. I have been learning from
Sun and SGI documentation, and a few resources "found on the web" for
generating a make file that all seem to agree. Do you have any
specific knowledge of a compiler or make tool with a different model?
James Giles
Jos Bergervoet wrote in message <8hend8$a4s$2...@news.IAEhv.nl>...
>James Giles <james...@worldnet.att.net> wrote:
>> Wood Cantrell wrote in message ...
>>>...
>>>modules for everything, every change requires a recompile of every
>>>module up the chain to the main routine, even if the interface is
>>>unchanged. This doesn't sound good for a large program!
>
>> Unfortunately, you have described the problem very clearly.
>> The only way to avoid the cascade of recompilations is to avoid
>> using MODULE procedures.
>
>I don't believe that is the correct conclusion. You only need to
>use a compiler that does NOT require this whole-chain recompilation
>(which means that it uses only the interface information from
>modules that are used.)
Yes, and you could also make a decision to use only those
implementations which check procedure calls for correctly
matched interfaces at load-time: which eliminates the need for
interfaces altogether. If the choice of implementation is
only based on one criterion, you're severly limited in
what implementations you can choose.
There is no *portable* way to avoid the cascading recompilation
without avoiding MODULE procedures.
--
J. Giles
Jos R Bergervoet
> > >> The only way to avoid the cascade of recompilations is to avoid
> >> using MODULE procedures.
> >
> >I don't believe that is the correct conclusion. You only need to
> >use a compiler that does NOT require this whole-chain recompilation
>
> without avoiding MODULE procedures.
Why wouldn't my recommendation be portable? :-)
But actually, if you transfer your code to another platform, you
will have to compile all modules anyway. The first problem to
solve is in what order they should be compiled (you could do
that by hand by inspecting the modules, but a good compiler will
do it for you) and the second problem is, if you change the code,
whether the whole chain or only one module and main needs
recompilation (you could find that out by inspecting the compiler
documentation).
> ... If the choice of implementation is
> only based on one criterion, you're severly limited in
> what implementations you can choose.
???
If you add more criteria, the choice will just be more limited.
-- Jos
James Giles
Jos R Bergervoet wrote in message <393B76...@philips.com>...
>James Giles wrote:
>> > >> The only way to avoid the cascade of recompilations is to avoid
>> >> using MODULE procedures.
>> >
>> >I don't believe that is the correct conclusion. You only need to
>> >use a compiler that does NOT require this whole-chain recompilation
>>
>> There is no *portable* way to avoid the cascading recompilation
>> without avoiding MODULE procedures.
>
>Why wouldn't my recommendation be portable? :-)
Your recommendation was to pick only a small subset of the
possible implementations - those which permit an option that
doesn'r require the cascading recompilation. Avoiding the majority
of implementations is a directly anti-portability act.
>But actually, if you transfer your code to another platform, you
>will have to compile all modules anyway. [...]
Yes, and that's just the first time you'll have to do so. You'll
continue to have to do so from then on as the code is further
developed and maintained. It's not reasonable to require
that development and maintenence be done on a different
implementation than the production version - too many
possible maintenence headaches. It's better to do the
development and maintenence on the same platform as your
productive use, and use the language in such a way as the
cascading compilation problem *portably* doesn't occur.
>???
>If you add more criteria, the choice will just be more limited.
No. If you have only one criterion, then only implementations
that meet that criterion are acceptable. If you have more than
one, you weight their importance and sum the weighted performance
of each implementation in the light of *all* those criteria. The
more criteria, the more implementations remain in the pool
of possible choices.
For example, suppose I have ten criteria - only one of which is
the ability to turn off the cascading recompilation problem with
MODULEs. If the weighted average of all those criteria favor
implementations that don't have that one feature, then those are
the the implementations I'll choose from. Your idea of selecting
based on only the single feature would rule out those. Probably
denying me features that are much more important.
--
J. Giles
Jos R Bergervoet
>
> ... Your idea of selecting
> based on only the single feature would ...
In none of my postings in this thread you'll find that it was
_my_ idea to select on only this single feature (it must have
been you who brought in this exclusiveness :-)
I did of course write that it (avoiding the cascading problem)
is a desirable feature. Do you think it would have to be added
to the Fortran standard as a genuine requirement for a standard
conforming compilation system?
Does the C standard have this requirement?
Does it (the C standard) still leave open the possibility to
use (optionally) the other mode, in which inter-module
optimization leads to the cascading situation?
-- Jos
(Sorry, the last 2 questions are slightly off-topic in c.l.f.)
James Giles
Jos R Bergervoet wrote in message <393BCC...@philips.com>...
>James Giles wrote:
>>
>> ... Your idea of selecting
>> based on only the single feature would ...
>
>In none of my postings in this thread you'll find that it was
>_my_ idea to select on only this single feature (it must have
>been you who brought in this exclusiveness :-)
You wrote:
> I don't believe that is the correct conclusion. You only need to
> use a compiler that does NOT require this whole-chain recompilation
> (which means that it uses only the interface information from
> modules that are used.)
This proposed solution to the problem only works if you can find
*any* compiler that does as you suggest. And it only works if you
have that as an manditory condition for the compiler you will
accept.
>I did of course write that it (avoiding the cascading problem)
>is a desirable feature. Do you think it would have to be added
>to the Fortran standard as a genuine requirement for a standard
>conforming compilation system?
In fact, I believe that the standard requires complete
reprocessing of a program unit any time *any* part of a module
used by that program unit has changed. It's an extension to the
standard to permit modules to change in some way without
requiring such complete reprocessing of all users of that module.
As such, you can't rely on any implementation having that feature.
If your present implementation has such a feature, it may not retain
it into any future revisions. It's a bad idea to rely upon this ability
when you decide upon how to manage your programmng projects.
An extralinguistic tool to generate explicit interfaces from procedure
definitions would permit a discipline of processing which avoided
such recompilations on *all* implementations of Fortran. Each time
you compile your procedure you also generate a new interface for
it. You then compare that interface to the one on file for that procedure.
If they're the same, no user of the procedure need be recompiled.
This whole process could be automated with fairly simple shell
scripts/batch files (whatever your system uses). The interfaces
would be inside an INCLUDE file (thereby avoiding the problem
that MODULE processing is strangely inconsistent among
implementations anyway).
--
J. Giles
Jos Bergervoet
> In fact, I believe that the standard requires complete
> reprocessing of a program unit any time *any* part of a module
> used by that program unit has changed.
I would be surprised if it made such presumptuous demands! Can you
please give chapter and verse?
> If your present implementation has such a feature, it may not retain
> it into any future revisions. It's a bad idea to rely upon this ability
> when you decide upon how to manage your programmng projects.
Even Fortran itself may not be available on tomorrows platform. We can
rely on nothing, but we can use the abilities that are available, and
keep other options open (like cascaded compilation).
Can we rely on non-cascaded compilation even if we avoid module
procedures? Where in the standard is the guarantee?
> An extralinguistic tool to generate explicit interfaces from procedure
> definitions would permit a discipline of processing which avoided
> such recompilations on *all* implementations of Fortran. Each time
No. If a module procedure is inlined in another module, any change in
the procedure will require recompilation of the other module. even if
its interface (of the procedure in the first module) is unchanged.
-- Jos
James Giles
Jos Bergervoet wrote in message <8hgreg$2fl$1...@news.IAEhv.nl>...
>James Giles <james...@worldnet.att.net> wrote:
...
>> An extralinguistic tool to generate explicit interfaces from procedure
>> definitions would permit a discipline of processing which avoided
>> such recompilations on *all* implementations of Fortran. Each time
>
>No. If a module procedure is inlined in another module, any change in
>the procedure will require recompilation of the other module. even if
>its interface (of the procedure in the first module) is unchanged.
That's why the part of my paragraph that you elided explicitly
pointed out that *NO* MODULE use was involved. That's what
makes the technique portable. Period. No inlining is possible
either, but if you want to improve the probability that your
implementation can inline, you should use internal procedures
instead of modules anyway. In fact, I can think of only
one thing I would recommend modules for, and that's
sharing a common definition of a derived data type among
independently compiled program units.
As for your other questions about what the standard requires
and/or permits, you obviously haven't read section C.11.2 of
the F90 standard document. It points out that previous versions
of the standard permitted completely independent processing
of the various program units of your program, while MODULEs
introduce new dependencies. There is no provision for a
standard compliant program to avoid these dependencies - even
if only the interfaces of the used modules have changed.
--
J. Giles
Jos Bergervoet
>>
>>No. If a module procedure is inlined in another module, any change in
>>the procedure will require recompilation of the other module. even if
>>its interface (of the procedure in the first module) is unchanged.
> That's why the part of my paragraph that you elided explicitly
> pointed out that *NO* MODULE use was involved. That's what
If a procedure is inlined in another procedure, this other procedure
requires recompilation if the first is changed. Also if they are
external procedures, residing in different files. The standard does
not talk about these 'files' and does in no way prevent the
compilation system from peeking into whatever part of the total code
it wants to see. You'll have to rely on the compiler vendor to prevent
this from happening, which you obviously don't want.
(Even when treating the "Include line" the standard does not talk
about an include FILE, but of "referenced source text" :-)
> makes the technique portable. Period. No inlining is possible
Why not? Where in the standard is the guarantee? As far as I can
see the compilation system may inline every procedure on every
ocasion (it should be careful with recursive ones, I admit.)
> As for your other questions about what the standard requires
> and/or permits, you obviously haven't read section C.11.2 of
> the F90 standard document. It points out that previous versions
> of the standard permitted completely independent processing
^^^^^
C.11.2 states that the old standard PERMITTED it, not that it
guaranteed it!
Likewise, the current standard PERMITS the compilation system to
work in a way that does NOT require cascaded compilation (again,
no guarantee). Maybe the standard should explicitely claim that
it permits this. In view of our discussion, that would seem to be
at least as useful as explaining what the old standard did or did
not permit. Maybe an idea for the f2k draft? (yes I did read it,
thanks to your resolving the accessibility issue a few moths ago).
-- Jos
James Giles
Jos Bergervoet wrote in message <8hh718$enr$1...@news.IAEhv.nl>...
>James Giles <james...@worldnet.att.net> wrote:
>>>
>>>No. If a module procedure is inlined in another module, any change in
>>>the procedure will require recompilation of the other module. even if
>>>its interface (of the procedure in the first module) is unchanged.
>
>> That's why the part of my paragraph that you elided explicitly
>> pointed out that *NO* MODULE use was involved. That's what
>
>If a procedure is inlined in another procedure, this other procedure
>requires recompilation if the first is changed. Also if they are
Fine. You find even one widely used implementation which inlines
external procedures as the default (or only) means of processing
procedures and I'll worry about it. Meanwhile, until the ability to
use module procedures *without* causing such recompilation
cascades is the default (or only) means of processing module
procedures is commonplace the most effective means of avoiding
the problem is not to use such module procedures if avoiding such
cascades is important.
No other aspect of this discussion is important. As I said before,
you *may* use an implementation that checks argument type
compatibility at load-time. This eliminates any need to use
modules, or even explicit interfaces. Until such implemenations
are commonplace this possibility is just as "useful" as the
position you've been promoting: that is, not at all.
--
J. Giles
Jos R Bergervoet
>
> Fine. You find even one widely used implementation which inlines
> external procedures as the default (or only) means of processing
> procedures and I'll worry about it.
But then you rely on the implementations to have a feature that the
standard is only permitting, not demanding! (namely, the feature of
independent compilation). Whereas on Mon, 05 Jun 2000 17:02:22 GMT,
you wrote about features:
>> If your present implementation has such a feature, it may not retain
>> it into any future revisions. It's a bad idea to rely upon this ...
> ... Meanwhile, until the ability
> to use module procedures *without* causing such recompilation
> cascades is the default (or only) means of processing module
> procedures is commonplace ...
But isn't it commonplace then? Are there (m)any compilers that
require cascaded re-compilation (in default optimization mode?)
-- Jos
James Giles
Jos R Bergervoet wrote in message <393CD2...@philips.com>...
>James Giles wrote:
>>
>> Fine. You find even one widely used implementation which inlines
>> external procedures as the default (or only) means of processing
>> procedures and I'll worry about it.
>
>But then you rely on the implementations to have a feature that the
>standard is only permitting, not demanding! (namely, the feature of
>independent compilation). Whereas on Mon, 05 Jun 2000 17:02:22 GMT,
>you wrote about features:
>
>>> If your present implementation has such a feature, it may not retain
>>> it into any future revisions. It's a bad idea to rely upon this ...
Please reread C.11.2. Thos things that is says are intended to be
permitted are actually the intent of the committee. The committee
often wimps out with respect to pragmatic issues. A conforming
implementation *can* fail to provide for separate compilation
of external procedures (I've never seen a non-interpretive implementation
do so). In the same way, a conforming implementation *can*
provide one-digit decimal precision REALs with a range of 0.1
to 10.0. I've never seen an implementation which did so.
A conforming implementation *can* specify that no integers
are within the set of supported I/O unit numbers. Etc.
Yes, the committee should actually grapple with some of these
issues more directly. In the meantime, for the issue at hand,
your advice (to avoid implementations that don't have a very
rare capability) is useless to most users. My advice (to rely
on a feature which, as far as I can tell, is universal) is not
useless.
>> ... Meanwhile, until the ability
>> to use module procedures *without* causing such recompilation
>> cascades is the default (or only) means of processing module
>> procedures is commonplace ...
>
>But isn't it commonplace then? Are there (m)any compilers that
>require cascaded re-compilation (in default optimization mode?)
All f90 compilers that I've used require recompilation of code which
USEs modules if those modules have changed *in*any*way* (in
*all* optimization modes). I've heard of one compiler that has
a directive to allow this not to be required (but it's not the default
mode) . There may be others. I've not used them. The feature
seemes to be very rare, and rarely used. Not surprising. For
most people, the preference would be for module procedures to
be optimized, *always*, to the greatest extent allowed by the
standard and supported by the compiler. This is because there
is already a way (using external procedures) to get independent
compilation for those procedures for which that's important. You
don't need a compiler switch to change module procedures for that.
--
J. Giles
Jos Bergervoet
>> But then you rely on the implementations to have a feature that the
>> standard is only permitting, not demanding! (...)
>
> Please reread C.11.2. Thos things that is says are intended to be
> permitted are actually the intent of the committee.
That's because the committee is of such high authoroty, isn't it?
I can understand that; if our Queen says: "We permit you to leave",
then you know you are not allowed to stay!
>> But isn't it commonplace then? Are there (m)any compilers that
>> require cascaded re-compilation (in default optimization mode?)
>
> All f90 compilers that I've used require recompilation of code which
> USEs modules if those modules have changed *in*any*way*
Strange... I never noticed anything like that (but I admit I didn't
look for it, and my final compilation would usually be cascaded, fully
optimized).
I am now trying to find an example. I tried DVF f90, NAG f95, HP f90,
Imagine1 F, but I can't get them to produce wrong results. It seems
like they all "permit" independent re-compilation of modules if the
interfaces don't change. I even tried optimization (NAG -O4, or
HP +O3) and even then, no problems.
You wouldn't, by any chance, have an example of some code that shows
the problem?
-- Jos
Paul van Delst
I've been following you two trade ideas for a while and have a question:
Aren't the compilation dependencies defined in the makefile (if you use
one) ?
Unless I specifically define the module dependencies, modules that
depend on modules that have changed (and thus get recompiled) don't get
recompiled. E.g. I have a module called type_kinds.f90 that contains all
the definitions for kinds of floats, ints, etc. *All* my code depends on
it. However, if I change the file and compile it, only the type_kinds
module gets recompiled. If I do the following in my make file:
# -- Define modules
TYPE_FILE = type_kinds.o
MODULE_FILES = this_module.o \
that_module.o \
one_more_module.o ....
OBJ_FILES = $(TYPE_FILE) $(MODULE_FILES)
# -- Define module dependencies
$(MODULE_FILES) : $(TYPE_FILE)
etc...
then the last dependency definition means changing type_kinds.f90 causes
*all* the other modules to get recompiled.
Is this what you guys are talking about? I don't see how any particular
compiler implementation has anything to do with it (unless the interface
changes of course - but that would generate a compilation error). Does
the standard address this sort of thing?
anyway....
cheers,
paulv
--
Paul van Delst Ph: (301) 763-8000 x7274
CIMSS @ NOAA/NCEP Fax: (301) 763-8545
Rm.202, 5200 Auth Rd. Email: pvan...@ncep.noaa.gov
Camp Springs MD 20746
Peter S. Shenkin
--
"Paul van Delst" <pvan...@ncep.noaa.gov> wrote in message
news:393D6B00...@ncep.noaa.gov...
...
> I've been following you two trade ideas for a while and have a question:
>
> Aren't the compilation dependencies defined in the makefile (if you use
> one) ?
...
> # -- Define modules
> TYPE_FILE = type_kinds.o
> MODULE_FILES = this_module.o \
> that_module.o \
> one_more_module.o ....
> OBJ_FILES = $(TYPE_FILE) $(MODULE_FILES)
>
> # -- Define module dependencies
> $(MODULE_FILES) : $(TYPE_FILE)
>
> etc...
>
> then the last dependency definition means changing type_kinds.f90 causes
> *all* the other modules to get recompiled.
>
> Is this what you guys are talking about
Your example illustrates the problem. The MODULE_FILES have to be
recompiled no matter what change occurs in type_kinds.f. In fact,
MODULE_FILES might not really have to be recompiled unless there is are
changes in the public module variables or in the interfaces to the public
procedures in type_kinds.f.
In C, this is avoided because the interfaces (function prototypes) are kept
in a separate file under user control (a .h file). For instance if module.h
contains the interfaces to the code contained in module.c, and if foo.c
calls module functions, we have:
foo.o: foo.c module.h
cc -c foo.c
Only when the interfaces in module.h change does foo.c need to be
recompiled; if module.c changes, foo.c does not have to be recompiled.
In fact, many or most f90 compilers keep the interfaces in separate files,
often called .mod files. However, their names -- even their existence -- is
not under user control. If one does know that the .mod file contains the
interface information, then one might be tempted to write something like:
TYPE_MOD = type_kinds.mod
TYPE_OBJ = type_kinds.o
MODULE_FILES = this_module.o \
that_module.o \
one_more_module.o ....
OBJ_FILES = $(TYPE_OBJ) $(MODULE_FILES)
# -- Define module dependencies
$(MODULE_FILES) : $(TYPE_MOD)
There are several problems with this, however.
1. type_kinds.mod may not be produced by the compiler in question, and if
it is, it might have another name (like TYPE_KINDS.mod, or even involving
the use of a different suffix).
2. Usually, when type_kinds.o is produced, a new type_kinds.mod is produced
by the compiler as well. Therefore, in the most naive implementation, as
shown above, extra compilation won't be avoided. It can be made to work by
means of temporarily moving type_kinds.mod to another name, then comparing
the new type_kinds.mod with the old one, and if they're the same, moving the
old one back to the name type_kinds.mod, preserving the date. But this is a
hassle.
3. With some compilers, .mod files made from exactly the same source will
differ depending on things like optimization level, date and phase of the
moon. So the extra work described in the previous paragraph isn't
guaranteed to be useful.
4. Even if the above procedure can be carried out, there is no guarantee
that the information in the module file is sufficient to specify the
interfaces. In fact, without guarantees, depending on the module files to
specify this could lead to errors when type_kinds.o is recompiled but one of
the dependent files is not. There's no guarantee that a dependent file
won't have to peak into the latest type_kinds.o to know how to operate
properly.
In view of all these problems, most people who use F90 do what you did in
your makefile example -- and spend many more hours compiling than they need
to do. Exception: Projects in an IDE may know all about the dependencies
and be able to avoid unneeded compilations.
-P.
--
Peter S. Shenkin
Work: she...@schrodinger.com; Play: she...@mindspring.com
James Giles
Paul van Delst wrote in message <393D6B00...@ncep.noaa.gov>...
...
>Is this what you guys are talking about? I don't see how any particular
>compiler implementation has anything to do with it (unless the interface
>changes of course - but that would generate a compilation error). Does
>the standard address this sort of thing?
The language definition (and most compiler documents) say that
you must recompile uses of changed modules. Period. They make
no distinctions between interface changes and other changes.
I'm told that one compiler explicitly documents the extension
that it only requires recompilation of uses if the interface information
changes (I don't have that compiler). I don't have any others
that document such an extension. To be sure that what you're
doing is safe, and will remain so, you should always recompile
all uses of a module which has changed.
--
J. Giles
James Giles
Jos Bergervoet wrote in message <8hjoem$f3o$1...@news.IAEhv.nl>...
...
>> All f90 compilers that I've used require recompilation of code which
>> USEs modules if those modules have changed *in*any*way*
>
>Strange... I never noticed anything like that (but I admit I didn't
>look for it, and my final compilation would usually be cascaded, fully
>optimized).
>
>I am now trying to find an example. I tried DVF f90, NAG f95, HP f90,
>Imagine1 F, but I can't get them to produce wrong results. It seems
>like they all "permit" independent re-compilation of modules if the
>interfaces don't change. I even tried optimization (NAG -O4, or
>HP +O3) and even then, no problems.
>
>the problem?
No, because I've never tried it. The compilers are are not documented
to allow a module to change (in fact, the documents repeat the rules
from that standard, usually) without recompiling the uses. So, I assume
that it is unsafe to try. How would you be *sure* that some specific
instance wasn't really broken?
In any case, my experience with vendors indicates that when a
capability is not documented to work, it usually means that they're
reserving the right for it not to work on some future revision ("we
never said you could do that, in fact the dcument says you can't").
Only if the document of the compiler actually *said* that recompilation
wasn't necessary would I even bother to try.
As I said, I can already get separate compilation by not using
module procedures anyway. I don't need for the compiler to
provide a way of doing it *with* module procedures. It's an
irrelevant "feature". I'd prefer, for those few thinge I use module
procedures to do (encapsulation of operations on derived types),
that they be optimized to the full extent the compiler/language
allows. Inlined, if possible.
--
J. Giles
Jan Vorbrueggen
> No, because I've never tried it. The compilers are are not documented
> to allow a module to change (in fact, the documents repeat the rules
> from that standard, usually) without recompiling the uses. So, I assume
> that it is unsafe to try. How would you be *sure* that some specific
> instance wasn't really broken? [...] I'd prefer, for those few thinge I use
> module procedures to do (encapsulation of operations on derived types),
> that they be optimized to the full extent the compiler/language
> allows. Inlined, if possible.
As I see it, a module file can contain two things: the interface definitions
and other structural information of the module concerned, and code to be
inlined. The fact that Jos hasn't had a problem with changing code while
keeping the interface and using the previous incarnation of the module file
means that those compilers do not contain code to be inlined - unless that is
done by the linker, which I find unlikely (you would be missing a lot of
optimization possibilities in this case).
Moral: We should all bith at F95 compiler vendors for not implementing inling
of module procedures and functions.
Jan
USEnet Subsystem
From: berg...@natlab.research.philips.com (Bergervoet J.R.M.)
In <%th%4.514$ee3....@bgtnsc04-news.ops.worldnet.att.net>
"James Giles" <james...@worldnet.att.net> writes:
>
> The language definition (and most compiler documents) say that
> you must recompile uses of changed modules. Period.
A search through the complete text of the standard gives only about
twenty occurences of the string "compile" and only in section C.8 do
they have any connection with the topic discussed here.
And the point is that the standard simply does not say what you claim
it says (unless it does so without using the string "compile", so I
must ask you again: can you tell us where you find this satement?
Would it be possible to quote the text?)
-- Jos
Richard Maine
> The language definition (and most compiler documents) say that
> you must recompile uses of changed modules. Period.
"Period" (implying an unarguable end of the topic) seems a bit strong
here. Unless it slipped by me, I recall that the standard is almost
paranoid about avoiding discussion of the compilation process. It
uses terminology like "processor" to avoid even using the word
"compile" in most contexts. A Fortran processor does not necessarily
have to involve a compiler (though I haven't seen an F90 interpreter,
and it doesn't seem like a very marketable product).
I've used at least one Fortran processor where USE was implemented by
rescanning the source code of the modules. (But I must admit, it was
the worst alleged Fortran processor I've ever tried. I use the term
"alleged" because I never actually managed to get it to sucessfully
run anything useful. And I concluded that its implementation of
modules would be unacceptable for real use even if it had technically
worked; a user's main program that referenced even one of my top-level
library procedures would have had to explicitly name every one of the
source code files directly or indirectly relevant to that procedure,
and in the proper order, on its compilation command line. For the
curious, it was a Parasoft product).
But back to the standard...
I see in C.8.2 (Dependent Compilation)
"The exact meaning of the requirement that the public portions of a
module be available at the time of reference is processor dependent."
It then goes on to give an example of what this might mean in some
implementations. And indeed the example reasonably matches common
implementation practice, which is probably no great coincidence.
But I find it awfully hard to interpret the above quote as unarguable
proof that the standard requires recompilation. It sounds to me more
like the standard is intentionally and explicitly avoiding the subject.
Admitedly, this is in Annex C, which isn't normative. But that's
because the normative text doesn't say much at all (unless I've completely
missed it). Just the one short sentence that C.8.2 is elaborating on.
--
Richard Maine
ma...@altair.dfrc.nasa.gov
James Giles
USEnet Subsystem wrote in message ...
> <%th%4.514$ee3....@bgtnsc04-news.ops.worldnet.att.net>
>From: berg...@natlab.research.philips.com (Bergervoet J.R.M.)
>
>In <%th%4.514$ee3....@bgtnsc04-news.ops.worldnet.att.net>
>>
>> The language definition (and most compiler documents) say that
>> you must recompile uses of changed modules. Period.
>
>twenty occurences of the string "compile" and only in section C.8 do
>they have any connection with the topic discussed here.
>
>And the point is that the standard simply does not say what you claim
>it says (unless it does so without using the string "compile", so I
>must ask you again: can you tell us where you find this satement?
>Would it be possible to quote the text?)
I was paraphrasing. The standard says that the public parts
of a module (which includes the code parts of any modules
procedures that are public) must be available at the time
any uses of that module are procesed. The program is
not standard conforming if different USEs of a module
are associated with different versions of the module.
So, if you change a module, and you expect those changes
to be effective in your program, then all USEs of the
program must be "reprocessed" with the new version
of the module "available" at the time such processing
is done. If your implemenation is compiler based, this
means recompilation of all USEs.
In any case, I have yet to actually see *any* implementation
document any clear description of what changes to a module
require recompilation of USEs and what changes do not. I'm
told that there is one (but I don't have access to that compiler's
documentation). It's certainly not a portable assumption that
only changes to the "interface" require recompilation of USEs.
It is not even a stated aim of most implementations that such
be the case. I would prefer that implementations *not* do such
a thing (except, perhaps, as a non-default option). Instead, I'd
like to see them optimize module code the the greatest degree
allowed by the standard.
--
J. Giles
James Giles
Richard Maine wrote in message ...
> [...] Unless it slipped by me, I recall that the standard is almost
>paranoid about avoiding discussion of the compilation process. It
>uses terminology like "processor" to avoid even using the word
>"compile" in most contexts. A Fortran processor does not necessarily
>have to involve a compiler (though I haven't seen an F90 interpreter,
>and it doesn't seem like a very marketable product).
...
Yes, it's too bad the standard is so reticent to address the pragmatics
of the language or to address the most common mode of processing
the language. Perhaps a supplimentary standard. Something along the
lines of "Standard protocols for compiler-based Fortran implementations".
One of the arguments use by proponents of switching large coding
projects away from Fortran is that there is no consistency between
different implementations on the way MODULEs are handled by
the processor. Does the source have to be present when you
compile USEs? Is there a .mod file? Is there a special directory
that the module's object code has to be in? Etc...For good or ill,
other languages don't seem to have these problems (or, are
perceived as not having them).
The present debate could be solved too, if only the will to address
the question existed. Of course, it would even be simpler if something
like Van Snyder's "Separating interface from implementation" proposal
(J3/98-104) were adopted. You could then have a simple rule such
as: "any changes to the senior part of a module require recompilation
of all USEs of the module, no changes to any junior part of a module
ever require such recompilation." Since the senior parts are allowed
to contain code, that code could be inlined by implementations and
recompilation would be required. Code for public procedures,
or even whole private procedures, could be in junior parts of the
module and any changes to those would be guaranteed not to
require recompilation. But, again, all this is really unnecessary
since you can already achieve the desired result (as a practical
matter) by using external procedures when independent compilation
is desired and only using module procedures when you desire
optimization and are willing to recompile USEs whenever they
change.
--
J. Giles
--
J. Giles
Phillip Helbig
<ma...@altair.dfrc.nasa.gov> writes:
>"Period" (implying an unarguable end of the topic) seems a bit strong
>here. Unless it slipped by me, I recall that the standard is almost
>paranoid about avoiding discussion of the compilation process. It
>uses terminology like "processor" to avoid even using the word
>"compile" in most contexts. A Fortran processor does not necessarily
>have to involve a compiler (though I haven't seen an F90 interpreter,
>and it doesn't seem like a very marketable product).
Slightly off-topic here, but this reminds me of an amusing story.
Richard Feynman described a computing set-up at Los Alamos during the
war consisting of women in a room with mechanical calculators. A
program would consist of a flow chart saying where the input and output
to and from each person went, and a "compiler" would instruct the
individual women on the steps they had to do. Theoretically, I suppose,
one could implement a Fortran processor in this way.
Richard Maine
> Slightly off-topic here, but this reminds me of an amusing story.
> Richard Feynman described a computing set-up at Los Alamos during the
> war consisting of women in a room with mechanical calculators. A
> program would consist of a flow chart saying where the input and output
> to and from each person went, and a "compiler" would instruct the
> individual women on the steps they had to do. Theoretically, I suppose,
> one could implement a Fortran processor in this way.
Yep. And not really that much off-topic.
We had several "things" called computers when I came to Dryden 30
years ago. One of them was that electronic behemoth (IBM 360/40) down
in the machine room. Another was named Roxanah Yancey. And there
were some others, but Roxanah is the one I most remember. (Hope I
spelled her name right). She didn't do Fortran, though. The IBM did.
--
Richard Maine
ma...@altair.dfrc.nasa.gov
Balaji
> Your example illustrates the problem. The MODULE_FILES have to be
> recompiled no matter what change occurs in type_kinds.f. In fact,
> MODULE_FILES might not really have to be recompiled unless there is are
> changes in the public module variables or in the interfaces to the public
> procedures in type_kinds.f.
>
> In C, this is avoided because the interfaces (function prototypes) are kept
> in a separate file under user control (a .h file). For instance if module.h
> contains the interfaces to the code contained in module.c, and if foo.c
> calls module functions, we have:
>
> foo.o: foo.c module.h
> cc -c foo.c
>
> Only when the interfaces in module.h change does foo.c need to be
> recompiled; if module.c changes, foo.c does not have to be
> recompiled.
Not necessarily true: if you edited module.h and inserted a comment,
the Makefile would still recompile foo.c, though there is no need to.
It's the same problem as the f90 use cascade: 'make'-like tools do not
distinguish between innocuous and significant changes.
However, 'make -t' can be your friend (-t means "touch all the files
you need to make, and pretend you made them, and I won't tell
anyone"), so if foo.f90 is a low-level module used by lots of others,
and bar.f90 is the main program, you could type:
% make foo.o
% make -t bar.o
% make a.out
and you should get a quick, correct (on any compiler I've tried, but
not guaranteed) compilation.
>
> In fact, many or most f90 compilers keep the interfaces in separate files,
> often called .mod files. However, their names -- even their
> existence -- is
The compilers I principally work with (Cray) do not produce .mod
files. The header info is read directly from the .o files.
PS. And for good measure, let me throw in a plug for my dependency
analyzer:
http://www.gfdl.gov/~vb/mkmf.html
--
Balaji 1 609.452.6516
SGI/GFDL Princeton University