On 19/06/2022 13:12, Thomas Koenig wrote:
> Ev. Drikos <drikosev@gmail.com> schrieb:
>
>> Does anybody know why there is such a restriction?
>>
>>
>> ----------------------------------------------
>> $ gfc --version 2>&1 | head -n1
>> GNU Fortran (GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)) 3.2.2 20030222
>> (Red Hat Linux 3.2.2-5)
>
> Without looking at the code: g77 has not been maintained for a really
> long time, and it only implements f77 + some extensions. I would not
> be surprised by any restrictions of anything f90-like or later.
>

Thanks for the feedback, the OP discussed F77. In this case version 8
issues a similar error as well:

$ gfortran8 -ffixed-form icep.f
icep.f:20:11:

read(goes(icep:icep),*) nn
1
Error: UNIT specification at (1) must be an INTEGER expression or a
CHARACTER variable

On 19/06/2022 13:21, Ev. Drikos wrote:
> ...
>
> $ gfortran8 -ffixed-form icep.f
> icep.f:20:11:
>
>        read(goes(icep:icep),*) nn
>            1
> Error: UNIT specification at (1) must be an INTEGER expression or a
> CHARACTER variable
>

Ok, an extra assignment to a variable could solve this issue, ie:

ch = go(icep:icep) !an extra assignment to a variable
read(ch, *) nn
goto(10,11) nn

Due to the fixed form format, the example is readable in my gists:
https://gist.github.com/drikosev/7f24acb6435f441d5d6f7be220efdbe9

Yet, the question remains open. Is it perhaps a compiler specific bug
or a standard restriction?

Ev. Drikos <drikosev@gmail.com> schrieb:
> On 19/06/2022 13:12, Thomas Koenig wrote:
>> Ev. Drikos <drikosev@gmail.com> schrieb:
>>
>>> Does anybody know why there is such a restriction?
>>>
>>>
>>> ----------------------------------------------
>>> $ gfc --version 2>&1 | head -n1
>>> GNU Fortran (GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)) 3.2.2 20030222
>>> (Red Hat Linux 3.2.2-5)
>>
>> Without looking at the code: g77 has not been maintained for a really
>> long time, and it only implements f77 + some extensions. I would not
>> be surprised by any restrictions of anything f90-like or later.
>>
>
> Thanks for the feedback, the OP discussed F77. In this case version 8
> issues a similar error as well:
>
> $ gfortran8 -ffixed-form icep.f
> icep.f:20:11:
>
> read(goes(icep:icep),*) nn
> 1
> Error: UNIT specification at (1) must be an INTEGER expression or a
> CHARACTER variable

OK.

A look at the F2018 standard tells us, in 12.4, "Internal Files":

An internal file is a record file with the following properties.

• The file is a variable of default, ASCII, or ISO 10646 character
kind that is not an array section with a vector subscript.

and a bit further down

R1201 io-unit is file-unit-number
or *
or internal-file-variable

R1203 internal-file-variable is char-variable

and further up

R905 char-variable is variable
C905 (R905) char-variable shall be of type character.

and finally

R903 variable-name is name
C903 (R903) variable-name shall be the name of a variable.

And if anybody wonders what a variable is, it's defined in

3.154 variable
data entity that can be defined and redefined during execution of a program

So, since a parameter cannot be redefined during execution, using
an internal I/O statement on it is an error, and the processor
needs to be able to diagnose it.

On 6/19/22 8:49 AM, Ev. Drikos wrote:
> On 19/06/2022 13:21, Ev. Drikos wrote:
>> ...
>>
>> $ gfortran8 -ffixed-form icep.f
>> icep.f:20:11:
>>
>>         read(goes(icep:icep),*) nn
>>             1
>> Error: UNIT specification at (1) must be an INTEGER expression or a
>> CHARACTER variable
>>
>
> Ok, an extra assignment to a variable could solve this issue, ie:
>
>  ch = go(icep:icep) !an extra assignment to a variable
>  read(ch, *) nn
>  goto(10,11) nn
>
> Due to the fixed form format, the example is readable in my gists:
> https://gist.github.com/drikosev/7f24acb6435f441d5d6f7be220efdbe9
>
> Yet, the question remains open. Is it perhaps a compiler specific bug
> or a standard restriction?

It is a standard restriction in f77. I remember similar situations many
times in the 1980s.

12.2.5.1 Internal File Properties. An internal file has the following
properties:
(1) The file is a character variable, character array element, character
array, or character substring.

Most compiler writers interpreted that to mean that it could not be
either a literal or a parameter constant. I seem to recall there were
some exceptions, but I always took those exceptions as extensions to the
standard, so if portability was important, I avoided using parameters or
literal constants as internal files.

To be portable, you need to do the assignment, or you need to declare
goes(*) as a variable rather than a parameter. I never understood why
the limitation was in the standard. In my codes, I usually left a
comment explaining why the code was written that way so that I would not
change it a month later by mistake. That comment was, of course, a
separate line beginning with C or *, it was not on the same line. F77
was so limited in so many ways.

$.02 -Ron Shepard

On Sunday, June 19, 2022 at 7:48:57 AM UTC-7, Ron Shepard wrote:

(snip)

> It is a standard restriction in f77. I remember similar situations many
> times in the 1980s.

There were some strange restrictions in Fortran 66, some of which
were removed in Fortran 77.

The I/O list of READ and WRITE statements contains variables (and arrays)
but not constants or expressions. That is obvious for READ, but not
for WRITE.

I believe at the time, actually using WATFIV before 1977, that expressions
in the I/O list of WRITE statements was my favorite new feature.

In Fortran 66, the format part of a READ/WRITE statement is either a
statement number (of a FORMAT statement) or an array with a run-time
format, character data read in A format, or initialized in DATA statements.

Even if it fit i a scalar, it was required to be an array.

Fortran 77 added internal I/O, putting a character variable in place
of the unit number. There are some not so obvious restrictions on it,
but similar to above, can't be a constant.

And now, so many years later, we wonder why.

In article <66596868-5be6-48c3-8120-73977567ac22n@googlegroups.com>,
gah4 <gah4@u.washington.edu> writes:

> The I/O list of READ and WRITE statements contains variables (and arrays)
> but not constants or expressions. That is obvious for READ, but not
> for WRITE.

Vice versa?

On Wednesday, June 15, 2022 at 5:34:32 AM UTC+10, Lynn McGuire wrote:
> On 6/13/2022 7:19 PM, gah4 wrote:
> > On Monday, June 13, 2022 at 4:29:18 PM UTC-7, Lynn McGuire wrote:
> >
> > (snip)
> >
> >>> Depends on what you mean by regular Fortran. In f2003 and later the limit is 255, but in f95 it's 39 in free form, 19 in fixed form.
> >> I meant Standard Fortran.
> >
> > 66, 77, 90, 95, 2008, 2013, or 2018?
> >
> > There is a famous quote:
> >
> > "The nice thing about standards is that we have so many to choose from."
> Heh.
>
> F77 apparently allowed 19 continuation lines.
..
The standard required a minimum of 19 continuation lines.
..
> Open Watcom Fortran 77 is
> extended to allow up to 61 continuation lines.
..
Any compiler can exceed the minimum of 19.

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
> >> maintain the information
> > .
> > GO TO LAB(NN);
> > is still simpler in PL/I.
> > .
> >> program testit
> >> implicit none
> >> integer :: nn
> >> integer,parameter :: EQUALS(*)=[&
> >> +1, -2, -3, +4, +5, -6, -7, -8, +9, -10, &
> >> +11, -12, -13, +14, +15, +16, +17, -18, -19, -20, &
> >> +21, +22, +23, +24, -25, +26, -27, -28, -29, -30, &
> >> -31, +32, -33, -34, -35, -36, -37, -38, -39, -40, &
> >> +41, +42, +43, +44, -45, +46, -47, -48, -49, -50, &
> >> +51, +52, -53, -54, +55, -56, -57, +58, -59, -60, &
> >> +61, -62, +63, -64, -65, -66, +67, +68, -69, +70, &
> >> -71, -72, +73, -74, -75, -76, -77, -78, -79, -80, &
> >> -81, -82, +83, +84, -85, -86, -87, -88, -89, +90, &
> >> +91, +92, +93, -94, -95, -96, +97, +98, -99, -100, &
> >> -101, +102, +103, +104, -105, -106, -107, +108, +109, +110, &
> >> +111, +112, +113, +114, +115, +116, +117, +118, +119, +120, &
> >> +121, +122, +123, +124, +125, +126, +127, +128, +129, +130, &
> >> -131, -132, -133, +134, +135, +136, +137, +138, +139, +140, &
> >> +141, -142, -143, -144, -145, -146, +147, -148, -149, -150, &
> >> +151, -152, -153, -154, -155, -156, -157, -158, -159, +160, &
> >> -161, -162, -163, +164, -165, -166, +167, +168, +169, +170, &
> >> +171, +172, +173, -174, +175, -176, -177, -178, +179, -180, &
> >> -181, -182, -183, -184, +185, +186, +187, +188, +189, +190, &
> >> -191, -192, -193, +194, -195, -196, -197, -198, -199, +200, &
> >> -201, +202, -203, -204, -205, -206, +207, -208, -209, -210, &
> >> +211, +212, -213, -214, +215, -216, -217, -218, -219, +220, &
> >> +221, +222, +223, -224, +225, +226, +227, +228, -229, -230, &
> >> -231, -232, -233, -234, -235, +236, -237, +238, +239, +240, &
> >> -241, -242, -243, -244, +245, -246, -247, -248, +249, -250, &
> >> -251, +252, +253, +254, -255, -256, -257, -258, -259, -260, &
> >> -261, -262, -263, -264, -265, -266, -267, -268, -269, -270, &
> >> -271, -272, -273, +274, -275, +276, -277, +278, +279, +280, &
> >> +281, +282, -283, -284, +285, -286, -287, -288, +289, -290, &
> >> -291, -292, -293, +294, +295, +296, +297, +298, +299, +300, &
> >> -301, -302, -303, -304, -305, -306, -307, -308, -309, -310, &
> >> -311, -312, -313, -314, -315, +316, +317, +318, +319, +320, &
> >> +321, +322, +323, +324, +325, +326, +327, +328, -329, -330, &
> >> +331, +332, -333, -334, -335, -336, +337, +338, +339, +340, &
> >> -341, -342, -343, -344, +345, -346, -347, -348, +349, +350]
> >> ! CHECK THE COMMANDS WHICH SHOULD HAVE EQUAL SIGN
> >> ! + no equal sign required
> >> ! - equal sign required
> >> write(*,*)size(equals)==350
> >> do nn=1,size(equals)
> >> if(equals(nn)>0)then
> >> write(*,*)nn,'equal sign required'
> >> else
> >> write(*,*)nn,'equal sign not required'
> >> endif
> >> enddo
> >> end program testit
..
> So ? We are not talking about PL/I.
..
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.

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.

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
>>>> maintain the information
>>> .
>>> GO TO LAB(NN);
>>> is still simpler in PL/I.
>>> .
>>>> program testit
>>>> implicit none
>>>> integer :: nn
>>>> integer,parameter :: EQUALS(*)=[&
>>>> +1, -2, -3, +4, +5, -6, -7, -8, +9, -10, &
>>>> +11, -12, -13, +14, +15, +16, +17, -18, -19, -20, &
>>>> +21, +22, +23, +24, -25, +26, -27, -28, -29, -30, &
>>>> -31, +32, -33, -34, -35, -36, -37, -38, -39, -40, &
>>>> +41, +42, +43, +44, -45, +46, -47, -48, -49, -50, &
>>>> +51, +52, -53, -54, +55, -56, -57, +58, -59, -60, &
>>>> +61, -62, +63, -64, -65, -66, +67, +68, -69, +70, &
>>>> -71, -72, +73, -74, -75, -76, -77, -78, -79, -80, &
>>>> -81, -82, +83, +84, -85, -86, -87, -88, -89, +90, &
>>>> +91, +92, +93, -94, -95, -96, +97, +98, -99, -100, &
>>>> -101, +102, +103, +104, -105, -106, -107, +108, +109, +110, &
>>>> +111, +112, +113, +114, +115, +116, +117, +118, +119, +120, &
>>>> +121, +122, +123, +124, +125, +126, +127, +128, +129, +130, &
>>>> -131, -132, -133, +134, +135, +136, +137, +138, +139, +140, &
>>>> +141, -142, -143, -144, -145, -146, +147, -148, -149, -150, &
>>>> +151, -152, -153, -154, -155, -156, -157, -158, -159, +160, &
>>>> -161, -162, -163, +164, -165, -166, +167, +168, +169, +170, &
>>>> +171, +172, +173, -174, +175, -176, -177, -178, +179, -180, &
>>>> -181, -182, -183, -184, +185, +186, +187, +188, +189, +190, &
>>>> -191, -192, -193, +194, -195, -196, -197, -198, -199, +200, &
>>>> -201, +202, -203, -204, -205, -206, +207, -208, -209, -210, &
>>>> +211, +212, -213, -214, +215, -216, -217, -218, -219, +220, &
>>>> +221, +222, +223, -224, +225, +226, +227, +228, -229, -230, &
>>>> -231, -232, -233, -234, -235, +236, -237, +238, +239, +240, &
>>>> -241, -242, -243, -244, +245, -246, -247, -248, +249, -250, &
>>>> -251, +252, +253, +254, -255, -256, -257, -258, -259, -260, &
>>>> -261, -262, -263, -264, -265, -266, -267, -268, -269, -270, &
>>>> -271, -272, -273, +274, -275, +276, -277, +278, +279, +280, &
>>>> +281, +282, -283, -284, +285, -286, -287, -288, +289, -290, &
>>>> -291, -292, -293, +294, +295, +296, +297, +298, +299, +300, &
>>>> -301, -302, -303, -304, -305, -306, -307, -308, -309, -310, &
>>>> -311, -312, -313, -314, -315, +316, +317, +318, +319, +320, &
>>>> +321, +322, +323, +324, +325, +326, +327, +328, -329, -330, &
>>>> +331, +332, -333, -334, -335, -336, +337, +338, +339, +340, &
>>>> -341, -342, -343, -344, +345, -346, -347, -348, +349, +350]
>>>> ! CHECK THE COMMANDS WHICH SHOULD HAVE EQUAL SIGN
>>>> ! + no equal sign required
>>>> ! - equal sign required
>>>> write(*,*)size(equals)==350
>>>> do nn=1,size(equals)
>>>> if(equals(nn)>0)then
>>>> write(*,*)nn,'equal sign required'
>>>> else
>>>> write(*,*)nn,'equal sign not required'
>>>> endif
>>>> enddo
>>>> end program testit
> .
>> So ? We are not talking about PL/I.
> .
> 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.

Lynn

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.

Lynn

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.

Lynn McGuire <lynnmcguire5@gmail.com> wrote:
> 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

On 7/12/2022 12:49 PM, p.kinsler@ic.ac.uk wrote:
> Lynn McGuire <lynnmcguire5@gmail.com> wrote:
>> 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.

Lynn

On Tuesday, July 12, 2022 at 10:54:05 AM UTC-7, p.ki...@ic.ac.uk wrote:
> Lynn McGuire <lynnmc...@gmail.com> wrote:
> > 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.

gah4 <gah4@u.washington.edu> schrieb:
> On Tuesday, July 12, 2022 at 10:54:05 AM UTC-7, p.ki...@ic.ac.uk wrote:
>> Lynn McGuire <lynnmc...@gmail.com> wrote:
>> > 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 :-)

On Wednesday, July 13, 2022 at 5:54:05 AM UTC+12, p.ki...@ic.ac.uk wrote:
> Lynn McGuire <lynnmc...@gmail.com> wrote:
> > 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.

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.

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?

$.02 -Ron Shepard

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>

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.

Ron Shepard <nospam@nowhere.org> schrieb:
> 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?

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 :-)

On 7/13/2022 11:51 AM, Thomas Koenig wrote:
> Ron Shepard <nospam@nowhere.org> schrieb:
>> 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?
>
> 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.

Lynn

Lynn McGuire <lynnmcguire5@gmail.com> schrieb:
> On 7/13/2022 11:51 AM, Thomas Koenig wrote:
>> Ron Shepard <nospam@nowhere.org> schrieb:
>>> 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?
>>
>> 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.

"Ron Shepard" wrote in message news:JstzK.25578$kY1.19305@fx06.iad...

> 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?

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

D:\gfortran\clf\blockloop>blockloop
1 12
123
1234
12345
123456
1234567
12345678
123456789
1234567890
12345678901
123456789012
1234567890123
12345678901234
123456789012345