From gah4@21:1/5 to Lynn McGuire on Tue Jun 14 13:22:25 2022
On Tuesday, June 14, 2022 at 12:34:32 PM UTC-7, Lynn McGuire wrote:
(snip)
F77 apparently allowed 19 continuation lines. Open Watcom Fortran 77 is extended to allow up to 61 continuation lines.
When I wrote above about how many lines of computed GOTO, I had forgotten
that you split that one up.
You could split up the DATA with EQUIVALENCE and two or three or four arrays.
I thought that was a good way, as it keeps your comments (which don't count
for continuation lines), but also the numbers. So no transcribing mistakes. (Not that you ever do that.)
And yes the Watcom compiler is my favorite Fortran 77 compiler.
(Well, maybe VS Fortran, but I don't have one of those.)
From Lynn McGuire@21:1/5 to All on Tue Jun 14 17:18:11 2022
On 6/14/2022 3:22 PM, gah4 wrote:
On Tuesday, June 14, 2022 at 12:34:32 PM UTC-7, Lynn McGuire wrote:
(snip)
F77 apparently allowed 19 continuation lines. Open Watcom Fortran 77 is
extended to allow up to 61 continuation lines.
When I wrote above about how many lines of computed GOTO, I had forgotten that you split that one up.
You could split up the DATA with EQUIVALENCE and two or three or four arrays.
I thought that was a good way, as it keeps your comments (which don't count for continuation lines), but also the numbers. So no transcribing mistakes. (Not that you ever do that.)
And yes the Watcom compiler is my favorite Fortran 77 compiler.
(Well, maybe VS Fortran, but I don't have one of those.)
I also have this computed goto that is going be even harder:
From Lynn McGuire@21:1/5 to All on Tue Jun 14 17:15:22 2022
On 6/14/2022 3:22 PM, gah4 wrote:
On Tuesday, June 14, 2022 at 12:34:32 PM UTC-7, Lynn McGuire wrote:
(snip)
F77 apparently allowed 19 continuation lines. Open Watcom Fortran 77 is
extended to allow up to 61 continuation lines.
When I wrote above about how many lines of computed GOTO, I had forgotten that you split that one up.
You could split up the DATA with EQUIVALENCE and two or three or four arrays.
I thought that was a good way, as it keeps your comments (which don't count for continuation lines), but also the numbers. So no transcribing mistakes. (Not that you ever do that.)
And yes the Watcom compiler is my favorite Fortran 77 compiler.
(Well, maybe VS Fortran, but I don't have one of those.)
I am slowly porting to Intel Fortran on Windows. I have got to go 64
bit. I may have to turn off the automatic module creation for now to
speed up my port. 5,000 subroutines is a lot of arguments to fix to
meet the exact type used.
From Gary Scott@21:1/5 to All on Tue Jun 14 18:56:07 2022
On 6/14/2022 3:22 PM, gah4 wrote:
On Tuesday, June 14, 2022 at 12:34:32 PM UTC-7, Lynn McGuire wrote:
(snip)
F77 apparently allowed 19 continuation lines. Open Watcom Fortran 77 is
extended to allow up to 61 continuation lines.
When I wrote above about how many lines of computed GOTO, I had forgotten that you split that one up.
You could split up the DATA with EQUIVALENCE and two or three or four arrays.
I thought that was a good way, as it keeps your comments (which don't count for continuation lines), but also the numbers. So no transcribing mistakes. (Not that you ever do that.)
And yes the Watcom compiler is my favorite Fortran 77 compiler.
(Well, maybe VS Fortran, but I don't have one of those.)
VS Fortran was one of my favs. I wrote lots of tools including one
giant interactive graphics editing program that rivaled out Mentor
Graphics workstations. Of course you had to have a graphics capable
high function terminal (3270PC AT/GX) for it to work well, but lesser
capable graphics terminals also worked where I could think of a workaround.
From gah4@21:1/5 to Lynn McGuire on Tue Jun 14 19:45:38 2022
On Tuesday, June 14, 2022 at 3:18:15 PM UTC-7, Lynn McGuire wrote:
(snip)
I also have this computed goto that is going be even harder:
IF (ICEP .EQ. -1) GO TO 562
IF (ICEP .GT. 100) GO TO 283
C ICEP 1 2 3 4 5 6 7 8 9 10
GO TO (900 ,510 ,510 ,580 ,564 ,900 ,636 ,518 ,564 ,514 ,
C ICEP 11 12 13 14 15 16 17 18 19 20
* 564 ,530 ,677 ,580 ,564 ,564 ,580 ,668 ,900 ,668 ,
C 21 22 23 24 25 26 27 28 29 30
* 564 ,580 ,900 ,580 ,562 ,564 ,620 ,513 ,510 ,900 ,
C 31 32 33 34 35 36 37 38 39 40
* 900 ,562 ,514 ,514 ,668 ,514 ,520 ,550 ,604 ,615 ,
(snip)
OK, this one has 190 different places to go.
Are these places more complicated than assigning some value,
or something else that can be done using lookup table data?
This is sort of close to the point that you could use a look up
table and 190 way computed GOTO statement. I might suggest
that when it is less than about 1/3 of the choices.
From Lynn McGuire@21:1/5 to All on Tue Jun 14 23:28:12 2022
On 6/14/2022 9:45 PM, gah4 wrote:
On Tuesday, June 14, 2022 at 3:18:15 PM UTC-7, Lynn McGuire wrote:
(snip)
I also have this computed goto that is going be even harder:
IF (ICEP .EQ. -1) GO TO 562
IF (ICEP .GT. 100) GO TO 283
C ICEP 1 2 3 4 5 6 7 8 9 10
GO TO (900 ,510 ,510 ,580 ,564 ,900 ,636 ,518 ,564 ,514 ,
C ICEP 11 12 13 14 15 16 17 18 19 20
* 564 ,530 ,677 ,580 ,564 ,564 ,580 ,668 ,900 ,668 ,
C 21 22 23 24 25 26 27 28 29 30
* 564 ,580 ,900 ,580 ,562 ,564 ,620 ,513 ,510 ,900 ,
C 31 32 33 34 35 36 37 38 39 40
* 900 ,562 ,514 ,514 ,668 ,514 ,520 ,550 ,604 ,615 ,
(snip)
OK, this one has 190 different places to go.
Are these places more complicated than assigning some value,
or something else that can be done using lookup table data?
This is sort of close to the point that you could use a look up
table and 190 way computed GOTO statement. I might suggest
that when it is less than about 1/3 of the choices.
From Ev. Drikos@21:1/5 to Lynn McGuire on Wed Jun 15 13:04:13 2022
On 13/06/2022 01:46, Lynn McGuire wrote:
So, is there a better way to code this ?
Better no, maybe more compact. If performance is an
issue one can declare ie the string as a parameter.
---------------- icep.f90 -----------------------------
! CHECK THE COMMANDS WHICH SHOULD HAVE EQUAL SIGN
! 10 - no equal sign required
! 11 - equal sign required
interface
function atoi(in) bind(c)
use, intrinsic :: iso_c_binding
integer(c_int) :: atoi
character(c_char) :: in(*)
end function
end interface
character(350) :: go
character :: ch
integer :: icep = 314 !ie
integer :: nn
From John@21:1/5 to All on Wed Jun 15 21:33:40 2022
Well, for the first one for maintainability (and not wanting to even mention ASSIGN statements) and primarily for human intelligibility I might go with a way that worked even pre-f90;. It would probably be more efficient if populated with logicals but
this format has a few advantages when a human has to manually
maintain the information
From Robin Vowels@21:1/5 to John on Fri Jun 17 00:43:29 2022
On Thursday, June 16, 2022 at 2:33:44 PM UTC+10, John wrote:
Well, for the first one for maintainability (and not wanting to even mention ASSIGN statements) and primarily for human intelligibility I might go with a way that worked even pre-f90;. It would probably be more efficient if populated with logicals but
this format has a few advantages when a human has to manually
From Lynn McGuire@21:1/5 to Robin Vowels on Sat Jun 18 15:05:10 2022
On 6/17/2022 2:43 AM, Robin Vowels wrote:
On Thursday, June 16, 2022 at 2:33:44 PM UTC+10, John wrote:
Well, for the first one for maintainability (and not wanting to even mention ASSIGN statements) and primarily for human intelligibility I might go with a way that worked even pre-f90;. It would probably be more efficient if populated with logicals but
this format has a few advantages when a human has to manually
I have to admit, this is my favorite. Especially if I could put the
data statement in the middle of the code.
One of my favorite things about C++ is that I can declare variables all
over the place. With an average of 2,000 lines of code per subroutine,
it would be nice to locate the variable declarations at their usage.
From Robin Vowels@21:1/5 to Lynn McGuire on Tue Jun 21 05:46:19 2022
On Sunday, June 19, 2022 at 6:05:16 AM UTC+10, Lynn McGuire wrote:
On 6/17/2022 2:43 AM, Robin Vowels wrote:
On Thursday, June 16, 2022 at 2:33:44 PM UTC+10, John wrote:
Well, for the first one for maintainability (and not wanting to even mention ASSIGN statements) and primarily for human intelligibility I might go with a way that worked even pre-f90;. It would probably be more efficient if populated with logicals
but this format has a few advantages when a human has to manually
.
Several languages have already been discussed in this thread, including PL/I.
.
PL/I can considerably shorten F77 code.
This instance, where a trivial PL/I statement can replace some 30-40 lines of F77,
might be worthy of further examination.
From David Jones@21:1/5 to John on Tue Jun 21 13:24:49 2022
John wrote:
Well, for the first one for maintainability (and not wanting to even
mention ASSIGN statements) and primarily for human intelligibility I
might go with a way that worked even pre-f90;.
I don't think we were told enough about the context of all this. If
this bit of code is gone through often in a single execution, it may
well be worth doing some initialisation computations that can sort out
both maintainability and readability as well as overall speed of
execution. One could start with several lists of items of different
types, such as could be extended easily as necessary, and then go
through these lists automatically (once-only) to construct sufficient cross-referencing etc. so that you can readily know what needs to be
done whenever a decision is needed.
From Lynn McGuire@21:1/5 to David Jones on Tue Jun 21 18:46:48 2022
On 6/21/2022 8:24 AM, David Jones wrote:
John wrote:
Well, for the first one for maintainability (and not wanting to even
mention ASSIGN statements) and primarily for human intelligibility I
might go with a way that worked even pre-f90;.
I don't think we were told enough about the context of all this. If
this bit of code is gone through often in a single execution, it may
well be worth doing some initialisation computations that can sort out
both maintainability and readability as well as overall speed of
execution. One could start with several lists of items of different
types, such as could be extended easily as necessary, and then go
through these lists automatically (once-only) to construct sufficient cross-referencing etc. so that you can readily know what needs to be
done whenever a decision is needed.
This code is used in initialization during the processing of the input
commands for the model. There can be thousands of input commands.
I am planning on converting this code from F77 to C++ some day and
wondering how this code will move across.
From Lynn McGuire@21:1/5 to Robin Vowels on Tue Jun 21 18:44:46 2022
On 6/21/2022 7:46 AM, Robin Vowels wrote:
On Sunday, June 19, 2022 at 6:05:16 AM UTC+10, Lynn McGuire wrote:
On 6/17/2022 2:43 AM, Robin Vowels wrote:
On Thursday, June 16, 2022 at 2:33:44 PM UTC+10, John wrote:
Well, for the first one for maintainability (and not wanting to even mention ASSIGN statements) and primarily for human intelligibility I might go with a way that worked even pre-f90;. It would probably be more efficient if populated with logicals
but this format has a few advantages when a human has to manually
.
Several languages have already been discussed in this thread, including PL/I. .
PL/I can considerably shorten F77 code.
This instance, where a trivial PL/I statement can replace some 30-40 lines of F77,
might be worthy of further examination.
In this case, the software program is 850,000 lines of F77, C and C++.
90% currently F77. Adding anything PL/1 is simply not an option.
From gah4@21:1/5 to Lynn McGuire on Tue Jun 21 18:21:42 2022
On Tuesday, June 21, 2022 at 4:44:51 PM UTC-7, Lynn McGuire wrote:
(snip)
In this case, the software program is 850,000 lines of F77, C and C++.
90% currently F77. Adding anything PL/1 is simply not an option.
PL/I has statement label variables, which in some cases make for
nicer or smaller code. For this problem, that doesn't help much.
One thing is that PL/I statement labels are alphanumeric,
(with initial letter) like variable names. Sometimes that makes
them more readable, if you give mnemonic names. If ...
It seems that Pascal uses numeric labels to discourage their use.
The WEB system used to write TeX has macros to give them names.
If it helped, you could use a macro system to rename your numeric
labels for readability. You might find that other parts could be made
more readable, too.
One of my favorite things about C++ is that I can declare variables all
over the place. With an average of 2,000 lines of code per subroutine,
it would be nice to locate the variable declarations at their usage.
I did that once with some C ... and it then ran about
ten times slower :-/
One of my favorite things about C++ is that I can declare variables all
over the place. With an average of 2,000 lines of code per subroutine,
it would be nice to locate the variable declarations at their usage.
I did that once with some C ... and it then ran about
ten times slower :-/
#Paul
That makes no sense whatsoever. I do not see that behavior in my
450,000 line C++ Windows user interface program.
One of my favorite things about C++ is that I can declare variables all over the place. With an average of 2,000 lines of code per subroutine,
it would be nice to locate the variable declarations at their usage.
I did that once with some C ... and it then ran about
ten times slower :-/
As well as I know it for C, I am less sure for C++, the allocation is the
same, independent of where the declarations are. It should not change
run time behavior.
I suppose that some optimizers might work different, depending on
such declarations, though that shouldn't actually happen.
Automatic variables are allocated on function entry.
One of my favorite things about C++ is that I can declare variables all
over the place. With an average of 2,000 lines of code per subroutine,
it would be nice to locate the variable declarations at their usage.
I did that once with some C ... and it then ran about
ten times slower :-/
As well as I know it for C, I am less sure for C++, the allocation is the same, independent of where the declarations are. It should not change
run time behavior.
I suppose that some optimizers might work different, depending on
such declarations, though that shouldn't actually happen.
Automatic variables are allocated on function entry.
Not necessarily - there is no need to reserve a stack slot
when the value is no longer needed.
Plus, sometimes it is cheaper to recompute than to spill
and reload, but that's one of the hardest decisions to
make in compilers :-)
One of my favorite things about C++ is that I can declare variables all over the place. With an average of 2,000 lines of code per subroutine,
it would be nice to locate the variable declarations at their usage.
I did that once with some C ... and it then ran about
ten times slower :-/
#Paul
Declaring variables where used was one of my favourite things about Algol 68, long before C++ was invented. The block construct lets you do it in Fortran too.
From gah4@21:1/5 to jfh on Tue Jul 12 15:01:48 2022
On Tuesday, July 12, 2022 at 2:15:13 PM UTC-7, jfh wrote:
(snip)
Declaring variables where used was one of my favourite things about Algol 68, long before C++ was invented. The block construct lets you do it in Fortran too.
Different question.
Blocks in ALGOL, BEGIN blocks in PL/I, and some others in other languages, allow for allocation of automatic variables.
(PL/I has DO blocks which are only for grouping, and not allocation or scoping.)
Actually, it might have changed over different versions of C, but at least for some there is no allocation.
From Ron Shepard@21:1/5 to jfh on Wed Jul 13 01:18:17 2022
On 7/12/22 4:15 PM, jfh wrote:
Declaring variables where used was one of my favourite things about Algol 68, long before C++ was invented. The block construct lets you do it in Fortran too.
How exactly does this work in fortran. If you have a block with local variables, are they allocated afresh when the block is entered and
deallocated upon block exit, or are they just allocated once? What if
the block is within a loop?
From pehache@21:1/5 to All on Wed Jul 13 11:33:50 2022
Le 13/07/2022 à 08:18, Ron Shepard a écrit :
On 7/12/22 4:15 PM, jfh wrote:
Declaring variables where used was one of my favourite things about
Algol 68, long before C++ was invented. The block construct lets you
do it in Fortran too.
How exactly does this work in fortran. If you have a block with local variables, are they allocated afresh when the block is entered and deallocated upon block exit, or are they just allocated once? What if
the block is within a loop?
I haven't checked, but to me a BLOCK is similar to a contained
subroutine, with the same rules concerning the variable that are
declared locally.
If the variable is "allocatable" it is automatically deallocated upon
exit of the the block.
If the variable is "save" then the compiler statically allocates it at
compile time.
For other cases it's up to the compiler to decide between a static
allocation at compile time or an automatic allocation on the stack at
runtime.
--
"...sois ouvert aux idées des autres pour peu qu'elles aillent dans le
même sens que les tiennes.", ST sur fr.bio.medecine
ST passe le mur du çon : <j3nn2hFmqj7U1@mid.individual.net>
From Robin Vowels@21:1/5 to All on Wed Jul 13 06:14:21 2022
On Wednesday, July 13, 2022 at 8:01:51 AM UTC+10, gah4 wrote:
On Tuesday, July 12, 2022 at 2:15:13 PM UTC-7, jfh wrote:
(snip)
Declaring variables where used was one of my favourite things about Algol 68, long before C++ was invented. The block construct lets you do it in Fortran too.
Different question.
Blocks in ALGOL, BEGIN blocks in PL/I,
.
and PROCEDURE blocks in PL/I
and some others in other languages, allow for allocation of automatic variables.
(PL/I has DO blocks which are only for grouping, and not allocation or scoping.)
.
PL/I does not have DO blocks. PL/I has DO groups.
Declaring variables where used was one of my favourite things about Algol 68, long before C++ was invented. The block construct lets you do it in Fortran too.
How exactly does this work in fortran. If you have a block with local variables, are they allocated afresh when the block is entered and deallocated upon block exit, or are they just allocated once? What if
the block is within a loop?
The compiler will look at the lifetime of the variable and allocate
it on the stack or in a register accordingly. A modern compiler
will, when optimizing, reuse stack slots if possible, with or
without help from the programmer through BLOCK statements.
Compilers have gotten quite good :-)
Also, the intermediate form that compilers use these days,
single static assignment, makes this optimization necessary.
Basically, any assignment to any variable creates a new
variable, so something like
i = 42
j = 2
i = i + j
j = j + i
will be translated to
i_1 = 42
j_1 = 2
i_2 = i_1 + j_1
j_2 = j_1 + i_2
and the compiler will determine that i_1 is no longer
in use, and will drop it.
Anything I learned in my C-64 Basic days about re-using
variables to save space, I had to unlearn :-)
Declaring variables where used was one of my favourite things about Algol 68, long before C++ was invented. The block construct lets you do it in Fortran too.
How exactly does this work in fortran. If you have a block with local
variables, are they allocated afresh when the block is entered and
deallocated upon block exit, or are they just allocated once? What if
the block is within a loop?
The compiler will look at the lifetime of the variable and allocate
it on the stack or in a register accordingly. A modern compiler
will, when optimizing, reuse stack slots if possible, with or
without help from the programmer through BLOCK statements.
Compilers have gotten quite good :-)
Also, the intermediate form that compilers use these days,
single static assignment, makes this optimization necessary.
Basically, any assignment to any variable creates a new
variable, so something like
i = 42
j = 2
i = i + j
j = j + i
will be translated to
i_1 = 42
j_1 = 2
i_2 = i_1 + j_1
j_2 = j_1 + i_2
and the compiler will determine that i_1 is no longer
in use, and will drop it.
Anything I learned in my C-64 Basic days about re-using
variables to save space, I had to unlearn :-)
Yup, we are memory pigs nowadays. I only start to worry about variables being too large when I declare double precision arrays of more than a
million members. It is just not worth my time to optimize the usage.
And the old memory optimizations in our code are a total pain now.
The nice thing about modern compilers is that, while they use
a lot of memory and a lot of CPU time, they are quite good at
efficient optimization, and also at saving memory if you specify
the right options. Using a modern compiler, the code two codes
above will eventually be optimized into two assignments.
Declaring variables where used was one of my favourite things about Algol 68, long before C++ was invented. The block construct lets you do it in Fortran too.
How exactly does this work in fortran. If you have a block with local
variables, are they allocated afresh when the block is entered and
deallocated upon block exit, or are they just allocated once? What if
the block is within a loop?
The compiler will look at the lifetime of the variable and allocate
it on the stack or in a register accordingly. A modern compiler
will, when optimizing, reuse stack slots if possible, with or
without help from the programmer through BLOCK statements.
Compilers have gotten quite good :-)
Also, the intermediate form that compilers use these days,
single static assignment, makes this optimization necessary.
Basically, any assignment to any variable creates a new
variable, so something like
i = 42
j = 2
i = i + j
j = j + i
will be translated to
i_1 = 42
j_1 = 2
i_2 = i_1 + j_1
j_2 = j_1 + i_2
and the compiler will determine that i_1 is no longer
in use, and will drop it.
Anything I learned in my C-64 Basic days about re-using
variables to save space, I had to unlearn :-)
Yup, we are memory pigs nowadays. I only start to worry about variables
being too large when I declare double precision arrays of more than a
million members. It is just not worth my time to optimize the usage.
And the old memory optimizations in our code are a total pain now.
Declaring variables where used was one of my favourite things
about Algol 68, long before C++ was invented. The block construct
lets you do it in Fortran too.
How exactly does this work in fortran. If you have a block with local variables, are they allocated afresh when the block is entered and deallocated upon block exit, or are they just allocated once? What if
the block is within a loop?
In some instances allocation on entry and deallocation on exit will
definitely be required. Thus the simplest implementation would be
to always do so.
D:\gfortran\clf\blockloop>type blockloop.f90
program blockloop
implicit none
integer i
do i = 1, 15
BLOCK
character(i) fun
write(*,'(*(g0))') fun()
END BLOCK
end do
end program blockloop
function fun()
implicit none
character(*) fun
integer i
do i = 1, len(fun)
fun(i:i) = achar(iachar('0')+modulo(i,10))
end do
end function fun
D:\gfortran\clf\blockloop>gfortran blockloop.f90 -oblockloop