Fortran Lesson: Are these equivalent?
Eric
newer
'do-end do' style. Using this snippet:
do 10 i=1,m
c write (6, *) "I ", i
do 5 j=1,n
c write (6, *) "J ", j
if (j .eq. 3) then
goto 10
end if
write (6, *) "J ", j
5 continue
write (6, *) "I ", i
10 continue
<and so on...>
What I've seen is, when execution hits 'goto 10' another iteration of
the outer loop is started. Is this the expected/prescribed behavior
and not something that can vary between (properly written) compilers?
In which case I can just replace 'continue' with 'end do' and remove
the
labels in the 'do' statements.
Couldn't this sequence: 'goto 10' --> '10 continue' --> <and so on...>
happen too?
TIA,
eric
Richard Maine
> I'm looking to convert some older f77 'do <label>' constructs to the
> newer
> 'do-end do' style. Using this snippet:
>
> do 10 i=1,m
> c write (6, *) "I ", i
> do 5 j=1,n
> c write (6, *) "J ", j
> if (j .eq. 3) then
> goto 10
> end if
> write (6, *) "J ", j
> 5 continue
> write (6, *) "I ", i
> 10 continue
> <and so on...>
>
> What I've seen is, when execution hits 'goto 10' another iteration of
> the outer loop is started. Is this the expected/prescribed behavior
> and not something that can vary between (properly written) compilers?
> In which case I can just replace 'continue' with 'end do' and remove
> the labels in the 'do' statements.
Yes, that is specified by the standard. You could also replace the goto
with an appropriate cycle. I'd probably write the above as
outer: do i = 1 , m
...
inner: do j = 1 , m
...
if (j==3) cycle outer
...
end do inner
...
end do outer
Well, actually, I might be tempted to rewrite further, depending on what
was in the .... parts. The above is pretty much just a straight syntax
change to do the same thing, without touching anything else.
> Couldn't this sequence: 'goto 10' --> '10 continue' --> <and so on...>
> happen too?
No.
--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
Glen Herrmannsfeldt
As long as the loops ends in CONTINUE, yes.
DO loops can end in other statements, in which case the GOTO
is to that statement.
do 1 i=1,10
if(i.lt.5) goto 1
write(*,*) i
1 write(*,*) '*'
can be replaced with
do i=1,10
if(i.lt.5) goto 1
write(*,*) i
1 write(*,*) '*'
enddo
-- glen
Eric
Thanks, Richard. I've seen EXIT but CYCLE is new to me. Can CYCLE
punch
through an arbitrarily deep nest?
eric
Terence
locate DO loops terminated with non-CONTINUE statements.
A problem is that you can replace the statement without its label, and
supply a following labelled CONTINUE statement, if and only if that
label is not branched to from elsewhere in the loop. In that case,
such a change would not execute the branched-to statement. Quite
tricky to code, but I got it correct.
I am quite happy to use the original form of the DO loop as the only
kind needed; I never found a use for the others.
The one joy was getting to use that added IF...THEN...ELSE structure,
to get rid of labels and get some more logical structure in my
programs.
But then you really have to indent to keep track of the nesting
Richard Maine
> On Feb 7, 4:24 pm, nos...@see.signature (Richard Maine) wrote:
> > outer: do i = 1 , m
> > ...
> > inner: do j = 1 , m
> > ...
> > if (j==3) cycle outer
> > ...
> > end do inner
> > ...
> > end do outer
> >
> Thanks, Richard. I've seen EXIT but CYCLE is new to me. Can CYCLE
> punch through an arbitrarily deep nest?
Yes, provided that you use a construct name as I did above (that's the
"inner" and "outer", which are just names I arbitrarily chose.) If you
don't specify a construct name on an exit or cycle, it applies to the
innermost loop. My personal style is to always use a construct name when
the construct hs an exit or cycle; I think it helps clarity to have the
statement specifically say what it is exiting or cycling (particularly
with exit, as it would be easy to misread exit as meaning to exit
various possible things, including the procedure, or even the whole
program).
Eric
Wait, what? You're saying this (for instance):
do 666 i=1,10
...
666 write (*, *) ...
Is the same as this:
do 666 i=1,10
...
write (*, *) ...
666 continue
So long as there are no 'GOTO 666' statements inside the loop?
Yes, I'm keeping an eye out for these booby traps.
In my case, I'm using do/end-do blocks. The hitch is, in the
original program, the original author has multiple do loops
all terminating at a single CONTINUE which, in some cases, is
also the target of GOTOs. Just nutty.
Regards,
eric
Eric
Neat. I didn't know you could label end-do that way. Are those
labels
functional or just for readability (i.e. does the compiler pay
attention
to those labels)? And this is "proper" (not obsolescent) in f90 on
up?
I seem to recall that gfortran (-pedantic ?) complains when I try to
do
stuff like this:
do 666 i=1,10
...
666 end do
Which is just a bass-ackwards version of what you posted.
Do you (or anyone else, really) know of a text editor that can
highlight
corresponding do/end-do lines? Preferably something linuxy and free.
Regards,
eric
Richard Maine
> In my case, I'm using do/end-do blocks. The hitch is, in the
> original program, the original author has multiple do loops
> all terminating at a single CONTINUE which, in some cases, is
> also the target of GOTOs. Just nutty.
Watch out for a big gotcha there. In particular, all the gotos must be
from within the innermost of the loops that terminate on that statement.
Otherwise the code is nonstandard. I have seen codes like
do 100 i = 1 , n
...
if (something) goto 100 !--- This is wrong.
...
do 100 j = 1 , n
...
if (something_else) goto 100 !--- This one is ok
...
100 continue
There have been compilers that accepted this nonstandard code. There
have been programers that wrote code depending on the particular
compiler behavior. I have talked to multiple such programers who were
convinced (but were wrong) that this was standard conforming code. I've
also coresponded with one compiler developer (for SGI, so yes, it was a
while ago) who was equally convinced that the standard allowed this. It
took a while, but I finally helped the compiler developer understand
where he had gone wrong. He had used his own concept of what the range
of a DO loop would be, rather than reading the actual definition of the
standard. I recall thinking that he'd have run into lots of
inconsistencies if he had tried to apply his definition throughout, but
I think it was more something that he had used to rationalize his answer
than to actualy derive it.
Anyway, don't do that one. If you have old code that does it, you need
to study code fairly carefully to make sure you know what it was trying
to do. Odds are that the first goto was trying to cycle the outer loop
and the second one was trying to cycle the inner loop, but when you have
nonstandard code like this, you can't always be sure. That's sometimes
the intent, but I have also seen cases where it was just plain a bug in
the code on the order of a typo in the statement number in the goto.
Richard Maine
> On Feb 7, 6:00 pm, nos...@see.signature (Richard Maine) wrote:
> > Eric <einazaki...@yahoo.com> wrote:
> > > On Feb 7, 4:24 pm, nos...@see.signature (Richard Maine) wrote:
> > > > outer: do i = 1 , m
> > > > ...
> > > > inner: do j = 1 , m
> > > > ...
> > > > if (j==3) cycle outer
> > > > ...
> > > > end do inner
> > > > ...
> > > > end do outer
> >
> > > Thanks, Richard. I've seen EXIT but CYCLE is new to me. Can CYCLE
> > > punch through an arbitrarily deep nest?
> >
> > Yes, provided that you use a construct name as I did above
> Neat. I didn't know you could label end-do that way. Are those labels
> functional or just for readability (i.e. does the compiler pay attention
> to those labels)? And this is "proper" (not obsolescent) in f90 on up?
Yes, the compiler pays attention. It will bitch if you use them and they
they don't match. In the case above the construct name is actually
important to tell the compiler which loop it is you are cycling. Without
the construct name, it would cycle the inner loop, which isn't what you
wanted. Yes, it tells the compiler in addition to the human reader.
And yes, it is all "proper" current form and in no danger at all of
being obsolescent.
> I seem to recall that gfortran (-pedantic ?) complains when I try to
> do stuff like this:
>
> do 666 i=1,10
> ...
> 666 end do
Hmm. I'm not sure what is obsolescent about that. I'm not entirely
convinced that it is, though I'd believe it could be. Not worth checking
at the moment. It isn't a style I'd use anyway, as it mixes the old
numeric label with the newer do/enddo style, but I think it is valid.
> Do you (or anyone else, really) know of a text editor that can highlight
> corresponding do/end-do lines? Preferably something linuxy and free.
I suspect they exist, but I'm not up on that. Emacs is almost bound to
be able to, but that's just because it can do pretty much anything; I
haven't actually checked that particular feature. Someone else?
Eric
Man, you're just all kinds of helpful. It turns out that the program
I'm
working on was originally built with SGI's f77 compiler. This would
be
around IRIX 3/4 which is around early to mid '90s. I should take a
harder look at that program on Monday.
Thanks,
eric
Richard Maine
> Man, you're just all kinds of helpful.
Thank you. I love getting comments like that. Pretty much makes my day.
Eric
> > In my case, I'm using do/end-do blocks. The hitch is, in the
> > original program, the original author has multiple do loops
> > all terminating at a single CONTINUE which, in some cases, is
> > also the target of GOTOs. Just nutty.
>
> Watch out for a big gotcha there. In particular, all the gotos must be
> from within the innermost of the loops that terminate on that statement.
> Otherwise the code is nonstandard. I have seen codes like
>
> do 100 i = 1 , n
> ...
> if (something) goto 100 !--- This is wrong.
> ...
> do 100 j = 1 , n
> ...
> if (something_else) goto 100 !--- This one is ok
> ...
> 100 continue
>
> Richard Maine | Good judgment comes from experience;
> email: last name at domain . net | experience comes from bad judgment.
> domain: summertriangle | -- Mark Twain
Wait, how is that non-compliant? I thought gotos can jump to anywhere
and with do loops, it's only a no-no to jump into them? I should do
more reading.
Does this make your snippet kosher?
do 101 i = 1 , n <-- changed label
...
if (something) goto 101 <-- changed target
...
do 100 j = 1 , n
...
if (something_else) goto 100
...
100 continue
101 continue <-- added
Even if the above is correct, I'm still not getting it.
Just to be clear, you're talking about what the standard
allows, not what's good programming practice, right? For
instance, spaghetti code is always bad practice but not
necessarily non-compliant.
Regards,
eric
Richard Maine
> On Feb 7, 10:46 pm, nos...@see.signature (Richard Maine) wrote:
> > do 100 i = 1 , n
> > ...
> > if (something) goto 100 !--- This is wrong.
> > ...
> > do 100 j = 1 , n
> > ...
> > if (something_else) goto 100 !--- This one is ok
> > ...
> > 100 continue
> Wait, how is that non-compliant? I thought gotos can jump to anywhere
> and with do loops, it's only a no-no to jump into them?
Well, there are quite a few restrictions on where gotos can go to, but
yes, that's the relevant one here. Because this is a jump into the inner
loop. That's exactly the problem (and the misunderstanding of the SGI
developer I referred to). The 100 counts as being in both loops.
> Does this make your snippet kosher?
>
> do 101 i = 1 , n <-- changed label
> ...
> if (something) goto 101 <-- changed target
> ...
> do 100 j = 1 , n
> ...
> if (something_else) goto 100
> ...
> 100 continue
> 101 continue <-- added
Yes, because then the first goto isn't jumping into the inner loop.
> Just to be clear, you're talking about what the standard
> allows, not what's good programming practice, right?
Right. It is non-compliant (and lots of compilers will refuse to compile
it).
Dr Ivan D. Reid
wrote in <1iusb8o.9vb4wi4eec6oN%nos...@see.signature>:
> Eric <einaz...@yahoo.com> wrote:
>> Do you (or anyone else, really) know of a text editor that can highlight
>> corresponding do/end-do lines? Preferably something linuxy and free.
> I suspect they exist, but I'm not up on that. Emacs is almost bound to
> be able to, but that's just because it can do pretty much anything; I
> haven't actually checked that particular feature. Someone else?
I tend to just use emacs as it comes out of the box. In that case
tabbing on each line indents each loop to an appropriate depth. It also
will briefly highlight a block if you type "end<tab>" and add the
appropriate 'do', 'subroutine' etc. for you, including the name if it's a
named block. It can probably do more, but coming from the land of TECO I
don't expect much of my editors. I just typed this nonsense programme in,
with a source extension of .f90 and only typed "end<tab>" on each of the
appropriate lines (and a tab on each of the other lines). The
upper-casing of keywords is a customisation available through the Options
menu. There's colouring too, but short of posting a URL to a screen-grab I
can't show that on Usenet.
PROGRAM foo
outer: DO i=1,10
IF (j.EQ.3) CYCLE
inner: DO j=1,10
x=x+1
END DO inner
END DO outer
WRITE (*,*)x
END PROGRAM foo
--
Ivan Reid, School of Engineering & Design, _____________ CMS Collaboration,
Brunel University. Ivan.Reid@[brunel.ac.uk|cern.ch] Room 40-1-B12, CERN
KotPT -- "for stupidity above and beyond the call of duty".
Gary Scott
I'm still amazed anyone would use emacs, but C'est la vie :)
--
Gary Scott
mailto:garylscott@sbcglobal dot 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
If you want to do the impossible, don't hire an expert because he knows
it can't be done.
-- Henry Ford
Ron Shepard
nos...@see.signature (Richard Maine) wrote:
> > I seem to recall that gfortran (-pedantic ?) complains when I try to
> > do stuff like this:
> >
> > do 666 i=1,10
> > ...
> > 666 end do
>
> Hmm. I'm not sure what is obsolescent about that.
I seem to remember something related to this regarding the
mil-std-1753 extensions to f77. I forget now if the statement
labels were required or if they were not allowed, but I don't think
they were optional. However, many (most?) compilers that
implemented do-enddo allowed the numeric labels in an optional way,
which was really an extension to an extension.
The practical difference in labeled do loops and numeric statement
labels, as far as compilers are concerned, is the idea of "tame"
labels. A tame label is a statement label that has only limited
branches to it, whereas a wild label can be accessed by anywhere
within the subprogram. F77 introduced some limitations on the wild
numeric statement labels in earlier dialects of fortran (e.g. it
eliminated "extended do loop ranges"), and the labeled (and
unlabeled) do loops in f90 extend that general idea even further.
$.02 -Ron Shepard
Dr Ivan D. Reid
wrote in <bwDjl.15697$YU2....@nlpi066.nbdc.sbc.com>:
> I'm still amazed anyone would use emacs, but C'est la vie :)
Au contraire, mon ami, c'est la guerre! ;-)
But seriously, I use cygwin/X11/fvwm2 on my work and home PCs to
access mainly Linux machines at work, at home, and at CERN. I can access
more than a dozen different machines in a typical work-day, before we even
consider the Grid jobs. It's a simple solution that works.
John Keenan
> do 10 i=1,m
> c write (6, *) "I ", i
> do 5 j=1,n
> c write (6, *) "J ", j
> if (j .eq. 3) then
> goto 10
> end if
> write (6, *) "J ", j
> 5 continue
> write (6, *) "I ", i
> 10 continue
> <and so on...>
For the specific example you have shown (termination of inner loop as a
function of inner loop index) I would write it as follows:
do i=1,m
do j=1,2
write (6, *) "J ", j
end do
write (6, *) "I ", i
end do
<and so on...>
John
Richard Maine
I'd also be tempted by at least something along those lines. But be
careful. It does take some attention to get everything right. Note that
the OP's code does not actually just terminate the inner loop. It cycles
the outer one (that being why I suggested the cycle statement). Yes,
there is a difference. The WRITE statement for i will be executed m
times in your version, but will never be executed in the OP's version if
n exceeds 2.
nm...@cam.ac.uk
Dr Ivan D. Reid <Ivan...@brunel.ac.uk> wrote:
>On Sun, 08 Feb 2009 10:12:49 -0600, Gary Scott <garyl...@sbcglobal.net>
> wrote in <bwDjl.15697$YU2....@nlpi066.nbdc.sbc.com>:
>
>> I'm still amazed anyone would use emacs, but C'est la vie :)
>
> Au contraire, mon ami, c'est la guerre! ;-)
Indeed, and I am on the losing side :-(
I use Emacs, with some hairy customisation (to disable as many of
its gimmicks and gotchas as I trip across) because it is the only
way that I can run a WYSIWYG text editor with even half-tolerable
ergonomics. If there is a better hole, I would go to it. For
those who knew it, the one with the best ergonomics was BBC VIEW;
it has, as far as I know, never been equalled - even though it was
nowhere near optimal.
Regards,
Nick Maclaren.
William Clodius
> In article <1iusb8o.9vb4wi4eec6oN%nos...@see.signature>,
> nos...@see.signature (Richard Maine) wrote:
>
> > > I seem to recall that gfortran (-pedantic ?) complains when I try to
> > > do stuff like this:
> > >
> > > do 666 i=1,10
> > > ...
> > > 666 end do
> >
> > Hmm. I'm not sure what is obsolescent about that.
>
> I seem to remember something related to this regarding the
> mil-std-1753 extensions to f77. I forget now if the statement
> labels were required or if they were not allowed, but I don't think
> they were optional.
They wer required in 1753.
<snip>
--
Bill Clodius
Change lost to los to email
robin
news:9233be64-e0b8-48be...@r41g2000prr.googlegroups.com...
No. The terminal statement (10) is always part of (i.e., inside) the loop.
viper-2
> I'm looking to convert some older f77 'do <label>' constructs to the
> newer
> 'do-end do' style.
I'm in the process of reconstructing an old Fortran 77 program that I
wrote back
in 1982 - 1983 too. I haven't coded in Fortran since back then and I'd
been
wondering whether to stick with g77 or upgrade to maybe GFortran,
which would
allow me to use Fortran 95. I decided to stick with Fortran 77 to keep
the
relearning curve as short as possible, but then I came across this
thread and
was simply intrigued by how CYCLE and EXIT make the code so much
prettier than
all those CONTINUEs and GOTOs that I used to rely on.
I found that EMACS just wouldn't indent the code to show off the
labels for the
DOs though. I used M-x indent-region after selecting the region to
indent.
Here's the code; it's an example I modified from chapter 5 of
"Computer
Programming in FORTRAN" by Arthur S. Radford in order to play with
CYCLE and
EXIT. I bought this book a couple of decades ago and I now finally
have the
opportunity to use it. I'm at chapter 5, but I just couldn't help
experimenting
with the DOs in this thread.:-) :
program ifwithdo
real max
logical alarm
! This program reads in a number N whose value
! determines whether or not there the file has ended.
! If the file is not ended, a second number is read,
! which triggers an alarm depending on its value.
max = 20
index : do i = 1, 3
sum = 10
print *, 'Enter value for N'
read *, n
if (n .lt. 0) then
print *, 'End of File'
exit index
else
alarmer : do j = 1, 5
if (sum .gt. max) then
alarm = .true.
print *, alarm, ' Sum is greater than Max'
cycle index
else
print*, 'Sum is less than Max'
print *, 'Enter value for X'
read *, x
sum = sum + x
end if
end do alarmer
end if
end do index
stop
end
Could the problem with the indentation be my version of g77? I'm using
gcc 3.2 (yes, very old box this one).
agt
--
Freedom - no pane, all gaiGN!
Code Art Now
http://codeartnow.com
Email: a...@codeartnow.com
dpb
> On Feb 7, 4:42 pm, Eric <einazaki...@yahoo.com> wrote:
>> I'm looking to convert some older f77 'do <label>' constructs to the
>> newer
>> 'do-end do' style.
>
>
> I found that EMACS just wouldn't indent the code to show off the
> labels for the DOs though. I used M-x indent-region after selecting
> the region to indent.
>
...
> Could the problem with the indentation be my version of g77? I'm using
> gcc 3.2 (yes, very old box this one).
I don't know or use EMACS but can't see how the choice of the specific
compiler would/could possibly matter.
I would think the interaction would be based on the customizations and
what EMACS assumes about file formatting based on the edited file name
extension (.f, .for, .f90/.f95, etc., etc., ...) would control what it
knows about source formatting. But, that's just guessing...
--
viper-2
> viper-2 wrote:
>
> ...> Could the problem with the indentation be my version of g77? I'm using
> > gcc 3.2 (yes, very old box this one).
>
> ...
>
> I don't know or use EMACS but can't see how the choice of the specific
> compiler would/could possibly matter.
>
> I would think the interaction would be based on the customizations and
> what EMACS assumes about file formatting based on the edited file name
> extension (.f, .for, .f90/.f95, etc., etc., ...) would control what it
> knows about source formatting. But, that's just guessing...
>
No you're not guessing. I was just about to post back with an "oops,
brain is tired" remark. I've been far too obsessed with deciding on
g77 vs g95 vs gfortran.
Of course it's not the compiler, I really meant to cite my version of
EMACS, and not g77-gcc. I'm running EMACS 21.1. A more recent version
of EMACS would probably handle the indentation for .f files better.
G77 will compile .f, .for, or .FOR files. It's quite possible that
EMACS might treat these filetypes slightly differently. Otherwise, I
would need to code my own EMACS customizations to correct the problem.
I probably won't spend time doing this just now though, time is tight.
dpb
...
> No you're not guessing. I was just about to post back with an "oops,
> brain is tired" remark. I've been far too obsessed with deciding on
> g77 vs g95 vs gfortran.
>
> Of course it's not the compiler, I really meant to cite my version of
> EMACS, and not g77-gcc. I'm running EMACS 21.1. A more recent version
> of EMACS would probably handle the indentation for .f files better.
> G77 will compile .f, .for, or .FOR files. It's quite possible that
> EMACS might treat these filetypes slightly differently. Otherwise, I
> would need to code my own EMACS customizations to correct the problem.
> I probably won't spend time doing this just now though, time is tight.
...
Ah, makes sense.
I'd only suggest choosing between the F95 compilers rather than an
F77-limited one, particularly since they are almost completely a superset.
If you have existing code to port, I'd try it w/ them and see if there's
something they don't handle that is actually owing to the difference in
language (ie, not an extension).
--
viper-2
> ...
>
> Ah, makes sense.
>
> I'd only suggest choosing between the F95 compilers rather than an
> F77-limited one, particularly since they are almost completely a superset.
>
> If you have existing code to port, I'd try it w/ them and see if there's
> something they don't handle that is actually owing to the difference in
> language (ie, not an extension).
>
Thanks!
Before I began the project to relearn Fortran last week, I did some
Googling on the GNU compilers. Apparently, gfortran compiles all of
fortran 77 code whereas g95 doesn't always. The plan, right now, is to
reconstruct the f77 code primarily as f77 with some of the nice f90
features allowed by g77 - like CYCLE and EXIT.
When I have more time, I'll consider upgrading the code to the Fortran
95 or 2003 standard. Who knows, maybe by then I'll want to play with
Fortress?
As for upgrading EMACS, gcc etc etc, it might be easier to install a
new GNU/Linux distribution rather than get into rpm dependency
headaches and never ending library upgrades.:-(
Richard Maine
> Apparently, gfortran compiles all of
> fortran 77 code whereas g95 doesn't always.
Really? What particular f77 features are you referring to?
In particular, I wonder whether you are actually talking about f77 or
about some extensions. That's a question that needs to be asked because
some people have been known to define "f77" as meaning whatever their
particular program uses, which doesn't always have much to do with the
f77 standard, and occasionally includes features that didn't work on
most f77 compilers.
If you are talking about such extensions, I can well imagine it. I
actually tend to think that accepting too large a plethora of extensions
can be a negative for several reasons, but that's a side matter.
I don't recall running into any standard f77 features that g95 didn't
support. But then, there are some f77 features that I don't tend to use
and thus might not notice. The ASSIGN statement and its "friends" occur
to me. That one has some subtle points that can make implementation
tricky. And it is one I never use (well, not in the last several
decades; I think I used some in the early 70's) and so might not have
noticed being omitted.
Ian Bush
>
> I found that EMACS just wouldn't indent the code to show off the
> labels for the
> DOs though. I used M-x indent-region after selecting the region to
> indent.
>
It's because of a slightly obscure example of a fixed-format/free-
format
mix up.
Short answer: Make sure you are in f90-mode rather than fortran-mode
and then try indent region ( or f90-indent-region, that's what I
always
use ). That turns it into
end program ifwithdo
Slightly longer answer: Fortran mode is really for fixed format
Fortran.
Now while fixed format is still perfectly legal, fortran mode in emacs
does not seem to have been changed to accept any f90 features or
beyond,
except for those that were common f77 extensions. f90-mode is for
free format Fortran and understands the new stuff, so can indent
correctly.
And yes, this is a pain for old code which has been written in fixed
format
and you want to modernise. However I do not have anywhere near the
knowledge
of how to update Fortran mode to do the right thing, but it would be
really
nice if someone, somewhere bot does and has the inclination to update
it.
For existing fixed format code you might be able to stick it through
a format converter and then use f90-mode. Have a look near the bottom
of
http://www.fortran.com/tools.html
However you may have other constraints on the project that stop you
doing this,
Hope this helps,
Ian
robin
news:1iusbq6.a09noy1u48xhcN%nos...@see.signature...
> Eric <einaz...@yahoo.com> wrote:
>
> > In my case, I'm using do/end-do blocks. The hitch is, in the
> > original program, the original author has multiple do loops
> > all terminating at a single CONTINUE which, in some cases, is
> > also the target of GOTOs. Just nutty.
>
> Watch out for a big gotcha there. In particular, all the gotos must be
> from within the innermost of the loops that terminate on that statement.
> Otherwise the code is nonstandard. I have seen codes like
>
> do 100 i = 1 , n
> ...
> if (something) goto 100 !--- This is wrong.
> ...
> do 100 j = 1 , n
> ...
> if (something_else) goto 100 !--- This one is ok
> ...
> 100 continue
>
> There have been compilers that accepted this nonstandard code.
In old codes, there is only one possible interpretation of
the meaning.
When the terminal statement was reached, the control variable
of the most recently executed DO statement was incremented.
However, the 1966 standard was quite explicit that the first GOTO above
was illegal: If there is a GOTO to the terminal statement
of multiple DOs, that GOTO can be only in the innermost DO.
viper-2
Yes, f90 mode is simply magical! The wonders of EMACS!
I saved the .f file with a .f90 extension and used M-x indent region;
I got the identical result you did.
Of course, g77 refuses to compile the file , even with the -ff90, -
ffree-form, or -fno-fixed-form options. It seems I'll have to spend
some time upgrading and installing gfortran or g95. I'll leave that
headache for now though and just work with g77.
> And yes, this is a pain for old code which has been written in fixed
> format
> and you want to modernise. <snip>
> For existing fixed format code you might be able to stick it through
> a format converter and then use f90-mode. Have a look near the bottom
> of
>
> http://www.fortran.com/tools.html
>
> However you may have other constraints on the project that stop you
> doing this,
Yes, there is a significant constraint - I don't have the original
code either in electronic or hardcopy format. All I've got is my
typist's 1983 interpretation of the printout, which is quite useless
for reconstruction. You can see a copy here under the directory
"HThesis":
http://www.codeartnow.com/code/download/c-graph-1/c-graph-1-buffet
Thank you, this really helped. It would have taken me some more time
to discover f90 mode. I'll save copies in f90 format as I go along so
I can compile and test at the end with the new compiler to be
installed. Of course EMACS would have an f90 mode.:-)
viper-2
> viper-2 <visio...@mail.infochan.com> wrote:
> > Apparently, gfortran compiles all of
> > fortran 77 code whereas g95 doesn't always.
>
> Really? What particular f77 features are you referring to?
>
I don't recall the details now. In realised that there were two
apparently competing GNU Fortran compilers and Googled g95 vs gfortran
(and vice-versa). Among the hits were information for transitioning
from 95 from 77:
http://74.125.113.132/search?q=cache:rY97I28kTjsJ:www.soks.org/view/Fortran95ForFortran77Programmers+fortran+95+standard+77&hl=en&client=firefox-a&hs=xTq&gl=jm&strip=1
which listed Fortran 95 deletions, Constructs considered harmful, and
Constructs considered obsolete; as well as discussions like this one:
http://www.megasolutions.net/fortran/g95-versus-gfortran-50009.aspx.
From what I gather, Fortran 77 is a proper subset of Fortran 90, but
not of Fortran 95. It is possible that the g95 developers strictly
adhered to the standards, while gfortran allowed everything from
Fortran 77. This is just my impression from Googling; I could be
wrong.
Kevin G. Rhoads
>the labels in the 'do' statements.
Your basic questions have already been answered by others.
Now, I am going to recommend you DO NOT change the code.
1) It ain't broke, don't fix it.
2) While "end do" may be more elegant, I find it LESS USEFUL than
labelled CONTINUE to end DO loops.
a) you can always group the DO and the END DO when reading code
b) CYCLE and EXIT are limited to one up and all the way out, if
you have more than two levels of looping, only labels will allow
you to pop to specific intermediates higher than one up
3) writing DO ... END DO is easier. Use it for new code, if you want.
I don't. But that's my preference.
I know most of the clf regulars will disagree with me on this point.
This is not so much a right/wrong as a style/preference issue. I prefer
the added (to me) clarity of numbered/labelled DO loops. Other people
find END DO clearer. DO what works BEST FOR YOU.
BUT as an engineer, who writes a lot of code and reuses old code, I
must say my bottom line onf this is still "it ain't broke, don't fix it"
MHOO -- YMMV
Sincerely
Kevin
(GOTOs considered harmful) considered harmful.
Craig Powers
It would be more accurate, I think, to state that both groups of
developers are attempting to produce standard-conforming f95 (and
beyond) compilers that also handle a "useful" set of f77 and extension
features. The definition of what is "useful" (and not too much trouble
to implement) will naturally vary from one group of developers to
another, also depending on whether someone is motivated to develop a
particular extension---I believe the Cray pointer feature in gfortran
was primarily developed outside the primary team of developers, to pick
an example.
viper-2
>
> Yes, f90 mode is simply magical! The wonders of EMACS!
>
> I saved the .f file with a .f90 extension and used M-x indent region;
> I got the identical result you did.
By the way, I do realise that simply typing M-x f90-mode in the .f
buffer toggles f90 mode.:-)
viper-2
>
> It would be more accurate, I think, to state that both groups of
> developers are attempting to produce standard-conforming f95 (and
> beyond) compilers that also handle a "useful" set of f77 and extension
> features. The definition of what is "useful" (and not too much trouble
> to implement) will naturally vary from one group of developers to
> another, also depending on whether someone is motivated to develop a
> particular extension---I believe the Cray pointer feature in gfortran
> was primarily developed outside the primary team of developers, to pick
> an example.
That may indeed be more accurate. I know next to nothing about the
history behind the decision to take two development paths. It may be a
good thing; programmers have diverse needs.
Ian Bush
>
>
> Of course, g77 refuses to compile the file , even with the -ff90, -
> ffree-form, or -fno-fixed-form options. It seems I'll have to spend
> some time upgrading and installing gfortran or g95. I'll leave that
> headache for now though and just work with g77.
>
Installing either is only a few minutes work. For g95 just download
the
binary. Can't quite remember what you have to do for gfortran, it's a
while since I've done it, but I do remember it was quick.
> > For existing fixed format code you might be able to stick it through
> > a format converter and then use f90-mode. Have a look near the bottom
> > of
>
> >http://www.fortran.com/tools.html
>
> > However you may have other constraints on the project that stop you
> > doing this,
>
> Yes, there is a significant constraint - I don't have the original
> code either in electronic or hardcopy format. All I've got is my
> typist's 1983 interpretation of the printout, which is quite useless
> for reconstruction. You can see a copy here under the directory
> "HThesis":
>
> http://www.codeartnow.com/code/download/c-graph-1/c-graph-1-buffet
>
Yuck ! Oh well, best of luck !
> Thank you, this really helped.
Glad to be of help,
Ian
viper-2
<ianbush.throwaway.acco...@googlemail.com> wrote:
> On 12 Feb, 17:39, viper-2 <visio...@mail.infochan.com> wrote:
>
> > Of course, g77 refuses to compile the file , even with the -ff90, -
> > ffree-form, or -fno-fixed-form options.
Apparently, G77 only understands .f .for or .FOR files; source.f90 is
not accepted at all.
It seems I'll have to spend
> > some time upgrading and installing gfortran or g95. I'll leave that
> > headache for now though and just work with g77.
>
> Installing either is only a few minutes work. For g95 just download
> the
> binary. Can't quite remember what you have to do for gfortran, it's a
> while since I've done it, but I do remember it was quick.
I downloaded the binary file from www.g95.org. You're right, no
problems at all with the installation - except that Andy Vaught ought
to change the directory for the executable "i686-suse-linux-gnu-g95"
to "i686-pc-linux-gnu-g95" or something generic to match the notes in
his installation manual.
G95 compiles the .f90 file OK.
I've been spending a lot of time coding in law instead of Fortran or C
or Lisp and so forth. The last time I tried installing anything on GNU/
Linux was a couple of years ago. I used tarballs, debs with Alien, and
rpms. I remember wanting to tear my hair out as I encountered
dependencies. I resorted sometimes to nodeps, but decided that was not
a good idea. I do everything in a hurry, hence the need for shortcuts
and avoiding installing anything, so the G95 install was a pleasant
surprise. I'll install Gfortran later.
Thanks again!
Craig Powers
> On 12 Feb, 17:39, viper-2 <visio...@mail.infochan.com> wrote:
>>
>> Of course, g77 refuses to compile the file , even with the -ff90, -
>> ffree-form, or -fno-fixed-form options. It seems I'll have to spend
>> some time upgrading and installing gfortran or g95. I'll leave that
>> headache for now though and just work with g77.
>>
>
> Installing either is only a few minutes work. For g95 just download
> the
> binary. Can't quite remember what you have to do for gfortran, it's a
> while since I've done it, but I do remember it was quick.
For gfortran, just download the binary (as long as your system is
suitably similar to the system used to generate it, in particular at
least on of the gfortran binaries requires a relatively recent glibc).
Richard Maine
> b) CYCLE and EXIT are limited to one up and all the way out, if
> you have more than two levels of looping, only labels will allow
> you to pop to specific intermediates higher than one up
Either I misunderstand what you are trying to say, or you are incorrect.
I'm not sure which. CYCLE and EXIT most definitely do let you cycle/exit
any intermediate at any level of nesting. Of course, you have to use
construct names to do so, but than I consider that good and normal
practice anyway.
I personally *ALWAYS* use construct names with cycle/exit, regardless of
nesting. And I usually use construct names when there is nesting, even
if no cycle or exit is involved. Those are two of my personal style
rules for construct names. The third is that I use a construct name on
any loop that is even moderately large, regardless of nesting or
cycle/exit.
Eric
> Kevin G. Rhoads <kgrho...@alum.mit.edu> wrote:
>
> > b) CYCLE and EXIT are limited to one up and all the way out, if
> > you have more than two levels of looping, only labels will allow
> > you to pop to specific intermediates higher than one up
>
> Either I misunderstand what you are trying to say, or you are incorrect.
> I'm not sure which. CYCLE and EXIT most definitely do let you cycle/exit
> any intermediate at any level of nesting. Of course, you have to use
> construct names to do so, but than I consider that good and normal
> practice anyway.
>
> I personally *ALWAYS* use construct names with cycle/exit, regardless of
> nesting. And I usually use construct names when there is nesting, even
> if no cycle or exit is involved. Those are two of my personal style
> rules for construct names. The third is that I use a construct name on
> any loop that is even moderately large, regardless of nesting or
> cycle/exit.
>
Having just learned about named DO constructs I find myself doing all
those
things. The really odd one is naming large loops because its
usefulness
wasn't immediately apparent, but it does pay.
Nothing like working on a program you don't understand in a language
you
barely remembered to bring out good work habits (maybe it's the
reverse).
eric
Kevin G. Rhoads
>I'm not sure which. CYCLE and EXIT most definitely do let you cycle/exit
>any intermediate at any level of nesting. Of course, you have to use
>construct names to do so, but than I consider that good and normal
>practice anyway.
I was unclear.
Without using names, what I said is true. With names, as you correctly
point out, it is not. Names are not syntactically or semantically
required (good practice, as you also pointed out), so, *by default*,
the situation I described would obtain.
Using labelled CONTINUEs with old-style DO loops, the ability to
CYCLE or EXIT to any level is automatically obtained.
When construct names are religiously used, then, the modern syntax
has all the advantages of the old style plus.
I personally would have preferred that the F77 -> next standard had
allowed alphanumerics statement labels (and longer than 5 characters
in non-fixed statement format) similar (or even the same syntax) as
what C has allowed since K&R days. But, that did not happen.
The major trouble with DO ... END DO in my mind is that names
are NOT required. That seems a throw-back to the days when
implicit typing was considered a feature.
MHOO -- YMMV
viper-2
> Ian Bush wrote:
> >
> > Installing either is only a few minutes work. For g95 just download
> > the
> > binary. Can't quite remember what you have to do for gfortran, it's a
> > while since I've done it, but I do remember it was quick.
>
> For gfortran, just download the binary (as long as your system is
> suitably similar to the system used to generate it, in particular at
> least on of the gfortran binaries requires a relatively recent glibc).
I installed one of the binaries for older glibc. It requires glibc of
at least 2.3.4.
$gfortran ifwithdo.f90 -o ifwithdo.out
gives the following error:
/opt/gcc-trunk-old/bin/../libexec/gcc/i686-pc-linux-gnu/4.4.0/f951: /
lib/i686/libc.so.6: version `GLIBC_2.4' not found (required by /opt/
gcc-trunk-old/bin/../libexec/gcc/i686-pc-linux-gnu/4.4.0/f951)
/opt/gcc-trunk-old/bin/../libexec/gcc/i686-pc-linux-gnu/4.4.0/f951: /
lib/i686/libc.so.6: version `GLIBC_2.3.4' not found (required by /opt/
gcc-trunk-old/bin/../libexec/gcc/i686-pc-linux-gnu/4.4.0/f951)
My glibc is 2.2.93-5, so I'll have to install GFortran after I find
the time to upgrade. In the meantime, g95 works so I'll run with that.
viper-2
>
> $gfortran ifwithdo.f90 -o ifwithdo.out
>
That looks like g77 mode, but it does actually work. It seems standard
format
for both gfortran and g95 is more like:
$g95 ifwithdo -o ifwithdo.f90
I must say that I'm really happy that I saw this thread, otherwise it
might have
been quite a while before discovering EMACS' f90 mode and that g95
would
actually be a no-headache installation.:-)
Thanks again!
Clive Page
<nos...@see.signature> writes
>> Apparently, gfortran compiles all of
>> fortran 77 code whereas g95 doesn't always.
>
>Really? What particular f77 features are you referring to?
One of the legal F77 features that g95 does not support is DO loops with
REAL or DOUBLE PRECISION loop counters. This is deleted from F95, but
gfortran still supports it.
--
Clive Page
viper-2
Noted. I found your comprehensive page on Fortran Resources. In
particular, your course notes "Fortran 90 for Fortran 77 Programmers"
promise to be extremely useful for those of us making the transition.
nm...@cam.ac.uk
viper-2 <visi...@mail.infochan.com> wrote:
>
>Noted. I found your comprehensive page on Fortran Resources. In
>particular, your course notes "Fortran 90 for Fortran 77 Programmers"
>promise to be extremely useful for those of us making the transition.
I haven't, and would be interested to see it, if it is intended to
be public! I have a course on conversion, and the slides may be
be seen in http://www-uxsup.csx.cam.ac.uk/courses/OldFortran.
They are a bit dated, and I would change a few things in the light
of more experience.
Incidentally, if anyone can remember CDC Fortran, please contact me!
Regards,
Nick Maclaren.
viper-2
> In article <bedb55ed-ea6b-4326-9645-ec6c508cc...@u1g2000vbb.googlegroups.com>,
>
> viper-2 <visio...@mail.infochan.com> wrote:
>
> >Noted. I found your comprehensive page on Fortran Resources. In
> >particular, your course notes "Fortran 90 for Fortran 77 Programmers"
> >promise to be extremely useful for those of us making the transition.
>
> I haven't, and would be interested to see it, if it is intended to
> be public! I have a course on conversion, and the slides may be
> They are a bit dated, and I would change a few things in the light
> of more experience.
>
> Incidentally, if anyone can remember CDC Fortran, please contact me!
>
> Regards,
> Nick Maclaren.
As usual, I'm in a hurry and forgot the url.:-)
The url for Clive's Fortran resources is here:
http://www.star.le.ac.uk/%7Ecgp/fortran.html
You may find his Fortran 90 for Fortran 77 programmers here:
http://www.star.le.ac.uk/~cgp/f90course/f90.html
nm...@cam.ac.uk
viper-2 <visi...@mail.infochan.com> wrote:
>
>As usual, I'm in a hurry and forgot the url.:-)
>
>The url for Clive's Fortran resources is here:
>http://www.star.le.ac.uk/%7Ecgp/fortran.html
Ah! Thanks. I misunderstood, and thought that it was Richard Maine's
pages - yes, I knew about Clive's.
Regards,
Nick Maclaren.
Glen Herrmannsfeldt
(snip)
> Incidentally, if anyone can remember CDC Fortran, please contact me!
How about:
http://www.bitsavers.org/pdf/cdc/7600/60280400A_7600_FORTRAN_Dec70.pdf
-- glen
nm...@cam.ac.uk
Glen Herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
>
>> Incidentally, if anyone can remember CDC Fortran, please contact me!
>
>How about:
>
>http://www.bitsavers.org/pdf/cdc/7600/60280400A_7600_FORTRAN_Dec70.pdf
Thanks very much! They hadn't scanned it when I last checked, and
I couldn't find anyone with a copy.
In due course, I will update my historical lecture, not that anyone
at Cambridge seems very interested in me giving it :-( But I realised
that I was almost the last person here who could write it, so I did.
Regards,
Nick Maclaren.
Richard Maine
> Incidentally, if anyone can remember CDC Fortran, please contact me!
I used it (well, them, as I recall some distinctly different compilers
under the CDC brand) quite a bit in its day. For a bit over a decade
(circa 1973-1984) CDCs were the main machines I used. I recall many
things about them, and occasionally use them as counterexamples to
things that "everybody knows". But it was long enough ago that many
details have gotten hazy. I sometimes see things about them and react
with "I had forgotten about that, but now that you mention, it sounds
familliar."
Clive Page
writes
>I haven't, and would be interested to see it, if it is intended to
>be public!
They are public, perhaps the URL is just a bit too obscure. I know I
need to reorganise the web stuff and update it, and will get around to
it soon, I hope.
See: http://www.star.le.ac.uk/~cgp/fortran.html
And for the f77 --> f90 stuff (also sadly out of date, since written
before Fortran95 arrived) see
http://www.star.le.ac.uk/~cgp/f90course/f90.html
Comments/corrections welcome, of course.
>I have a course on conversion, and the slides may be
>be seen in http://www-uxsup.csx.cam.ac.uk/courses/OldFortran.
>They are a bit dated, and I would change a few things in the light
>of more experience.
That is a very useful practical guide to converting old code, and
deserves to be better known.
>Incidentally, if anyone can remember CDC Fortran, please contact me!
I can (just) remember using a CDC 6600 (I think) in Manchester, we later
got Cyber-72 and -73 machines in Leicester on which we ran a lot of
Fortran code. I thought that I might still have a CDC Fortran manual on
my shelves, but I can't find it - I guess I must have ditched it in some
office move. Pity.
--
Clive Page (cgp [at] star.le.ac.uk)
Tim Prince
>
>> I have a course on conversion, and the slides may be
>> be seen in http://www-uxsup.csx.cam.ac.uk/courses/OldFortran.
>> They are a bit dated, and I would change a few things in the light
>> of more experience.
>
> That is a very useful practical guide to converting old code, and
> deserves to be better known.
>
>> Incidentally, if anyone can remember CDC Fortran, please contact me!
>
> I can (just) remember using a CDC 6600 (I think) in Manchester, we later
> got Cyber-72 and -73 machines in Leicester on which we ran a lot of
> Fortran code. I thought that I might still have a CDC Fortran manual on
> my shelves, but I can't find it - I guess I must have ditched it in some
> office move. Pity.
>
I overhauled some CDC 6600 Fortran applications as recently as 20 years
ago. It certainly wasn't f77. It did stop us from going overboard with
real*8 and the like. I (mis)used some extensions of statement functions
myself which worked in several brands of extended f66 but not in f77. The
only f66 I ever saw supporting recursion was on Prime.
Extended range was a bummer, those compilers failed to diagnose all manner
of misuse which "happened to work."
nm...@cam.ac.uk
Tim Prince <tpr...@nospamcomputer.org> wrote:
>>
>I overhauled some CDC 6600 Fortran applications as recently as 20 years
>ago. It certainly wasn't f77. It did stop us from going overboard with
>real*8 and the like. I (mis)used some extensions of statement functions
>myself which worked in several brands of extended f66 but not in f77. The
>only f66 I ever saw supporting recursion was on Prime.
If I recall, Egtran supported it, and that was a variant of Fortran II!
But I have almost given up on finding any documentation on Egtran.
>Extended range was a bummer, those compilers failed to diagnose all manner
>of misuse which "happened to work."
Too right! It had its uses, but needed a real expert to use correctly.
We had one professor, MOST of whose code relied on it, and he was
distinctly unhappy when we dropped support for the last genuine
Fortran 66 compiler ....
Regards,
Nick Maclaren.
nm...@cam.ac.uk
>In article <TWgnl.2252$Lr6....@flpi143.ffdc.sbc.com>,
>Tim Prince <tpr...@nospamcomputer.org> wrote:
>>>
>>I overhauled some CDC 6600 Fortran applications as recently as 20 years
>>ago. It certainly wasn't f77. It did stop us from going overboard with
>>real*8 and the like. I (mis)used some extensions of statement functions
>>myself which worked in several brands of extended f66 but not in f77. The
>>only f66 I ever saw supporting recursion was on Prime.
>
>If I recall, Egtran supported it, and that was a variant of Fortran II!
>But I have almost given up on finding any documentation on Egtran.
However, just on the off-chance, I did a Web search, and have found
a quotation from the Computer Journal 8(4) 1965 in
http://hopl.murdoch.edu.au/showlanguage2.prx?exp=2934
The FORTRAN compiler compiles from a dialect of FORTRAN II called EGTRAN
which is not appropriate to discuss at length here. All the usual
facilities of FORTRAN II are included, together with certain additional
facilities peculiar to EGTRAN. In particular the following may be noted:
(1) A facility for varying the dimensions of arrays at run time without
sacrificing the optimization of subscripts.
(2) Recursive functions and subroutines, with preservation of the
values of variables between recursions if required.
(3) Some additional statements for transferring whole arrays to or from
disc or magnetic tape, rather than the normal FORTRAN `list' of
variables. This makes it possible to make transfers proceed
simultaneously with each other and with central processor calculations,
which cannot be done (except to a very limited extent) with `list' type
statements because of the need for store protection.
Now, WHY did I fail to notice that when I looked at that article (on
paper)?
A definite statement that my memory was correct - recursion, dynamic
arrays and asynchronous I/O, all in a Fortran II.
Regards,
Nick Maclaren.