forums.silverfrost.com

[mecej4]

The tiny program below consists of a main program and a contained subprogram. An erroneous EXTERNAL declaration is given for the contained subprogram. The compiler should have given an error message and aborted the compilation.

The solution is obvious and easy in this simple case, but the bug may be worthwhile to fix because spotting this type of error can be more difficult with a large program.

[PaulLaidler]

mecej4

Thank you for the feedback. I have made a note that this needs fixing.

[LitusSaxonicum]

Mecej4,

As a matter of interest, what actual harm does the EXTERNAL declaration actually do?

Eddie

PS. I never saw the point of EXTERNAL before I saw ClearWin ... although I did read somewhere that including named BLOCK DATA subprograms in EXTERNAL statements meant that the compiler checked that they were actually included. Even that seemed rather bonkers to me.

[mecej4]

Eddie, think of I(nstruction)Space and D(ata)Space. Fortran variables may be classified as to whether they are code entities held in Ispace (user subroutines, user written functions, compiler-provided or 3rd party library routines) or data entities held in Dspace.

In the von Neumann world, the same memory can hold instruction bits/bytes/words or data bits/bytes/words. That we do not care to distinguish between dytes (data bytes) and cytes (code bytes) speaks to how pervasive the von Neumann model has become.

In the Harvard world, the Dspace and the Ispace are separate. In the original Harvard Mark-1, the Dspace was implemented in electro-mechanical counters, and the Ispace resided on paper tapes.

Note, however, that most modern microprocessors have von Neumann main memory and Harvard processor caches, further complicated by whether the caches are private to each core or are shared between all the cores in a processor.

In terms of Fortran programs, the EXTERNAL attribute establishes that the variable represents the base address of a sequence of instructions. Without external, the variable represents the base address of a data sequence. Imagine the consequences of executing data bytes (e.g.,floating point numbers) or performing arithmetic with two code words. A couple of analogies for that kind of mishap: (i) the inmates running the (mental) institution, (ii) the schoolboys caning the teacher.

I remember a few occasions decades ago when I went to the university computer center to pick up my output fanfold, only to find a piece of paper or half a punched card saying, "Your program executed data".

Passing subprograms as part of the argument list to another subprogram is essential for writing programs that involve nonlinear mathematical relations. If you write a library routine for solving a scalar nonlinear equation using, say, Newton's method, when you program the Newton subroutine you do not know what a future user of your subroutine will use for f(x). All that you know is that your subroutine should call the not-yet-written user-supplied function. The compiler does not know what will be in that function, and leaves it to the linker to connect the user-written future function to your Newton solver subroutine.

[LitusSaxonicum]

Hi Mecej4,

An interesting reply, from which I learned a lot, including that von Neumann seems to have independently discovered a Turing model! It�s a lot like Diesel discovering the Hornsby engine, Casagrande discovering how to draw Richardson�s flow nets, or the Americans calling a Nissen hut a Quonset hut after they appropriated the design!

The other thing I got from your reply is that (i) you disapprove of government, where the lunatics definitely run the asylum, and (ii) you must have had more pleasant schooldays than I did!

I have also inferred that you have a potentially fruitful career as a politician, as in the course of a lengthy and information-full reply (which I found interesting in itself), you neatly sidestepped the question! What you answered was �Why is EXTERNAL needed?� not �What harm does it do if EXTERNAL is there, but not used?�

Now, is it not the case that, to quote you:

�In terms of Fortran programs, the EXTERNAL attribute establishes that the variable represents the base address of a sequence of instructions.�

But this applies only to the use of a subprogram name in the argument list of another subprogram in a place where a (data) variable would otherwise be assumed. EXTERNAL itself (as I understand it, and am prepared to be corrected) says nothing about any base address.

Surely, the use of a FUNCTION or SUBROUTINE declaration somewhere in the program establishes the actual �base address of a sequence of instructions�. To be pedantic (What? Me?) there seem to be several steps in this, only finally resolved partially by the linker and finally when the program loads.

If that base address is then not used as an argument in a subprogram, then surely that usage is simply forgotten? Or if remembered, takes no more that the space required for an address or to �remember� a symbolic name? (Or both).

It seems to me that unnecessary EXTERNAL declarations have very little, if any, adverse effects on a program, whereas to omit EXTERNAL when it is genuinely required is probably devastating. I suppose that it all boils down to the scoping rules in force for all sorts of symbolic names.

Eddie

[mecej4]

Apart from declaring a variable as External when the Fortran language rules require doing so, in the days of implicit typing (F-II, 66, 77), declaring a variable as External when not required to do so was intended to document the intent of the variable for the benefit of future readers/editors of the source code (including, perhaps, the original author).

Sometimes, however, as we can see in an earlier thread ( http://forums.silverfrost.com/viewtopic.php?t=4511&highlight=external ), the compiler can punish the programmer for providing External declarations when they are not strictly needed.

Writing down "External" can reduce ambiguity, as well. If a line of a program says

[PaulLaidler]

mecej4

This diagnostic has been added for the next release of FTN95.

It will appear as a warning to avoid the possibility of breaking existing code.