forums.silverfrost.com Forum Index forums.silverfrost.com
Welcome to the Silverfrost forums
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

FTN95 accepts program with EXTERNAL decl for internal sub

 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Support
View previous topic :: View next topic  
Author Message
mecej4



Joined: 31 Oct 2006
Posts: 1885

PostPosted: Sat Nov 05, 2022 2:28 am    Post subject: FTN95 accepts program with EXTERNAL decl for internal sub Reply with quote

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.

Code:
program xlsodpk
   implicit none
   external :: fweb   ! Error, declares internal subprogram as EXTERNAL
   integer :: neq
   real :: xneq
!
   neq = 7
   call fweb(neq, xneq)       
   print *, 'For neq = ',neq, ',  xneq = ',xneq
   stop
       
CONTAINS
!
    subroutine fweb(neq, xneq)
       implicit none
       integer :: neq
       real :: xneq
       
       xneq = exp(0.5*neq)
       return
       
    end subroutine fweb

end program xlsodpk
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7916
Location: Salford, UK

PostPosted: Sat Nov 05, 2022 8:25 am    Post subject: Reply with quote

mecej4

Thank you for the feedback. I have made a note that this needs fixing.
Back to top
View user's profile Send private message AIM Address
LitusSaxonicum



Joined: 23 Aug 2005
Posts: 2388
Location: Yateley, Hants, UK

PostPosted: Sat Nov 05, 2022 6:30 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1885

PostPosted: Mon Nov 07, 2022 1:35 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
LitusSaxonicum



Joined: 23 Aug 2005
Posts: 2388
Location: Yateley, Hants, UK

PostPosted: Mon Nov 07, 2022 12:41 pm    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1885

PostPosted: Mon Nov 07, 2022 1:10 pm    Post subject: Reply with quote

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

Code:
 y = func(x)


and implicit typing prevails, is x a function argument or a subscript? Is func a function of type real, or a real array variable with a forgotten declaration? In this case, does not adding "External func" clarify matters somewhat, even though the compiler/language rules do not require it?
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7916
Location: Salford, UK

PostPosted: Wed Nov 16, 2022 11:21 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message AIM Address
Display posts from previous:   
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Support All times are GMT + 1 Hour
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group