Intel Fortran Help in VS

[Gary Scott]

Hi, the latest standalone compiler appears to integrated with VS
properly, but I don't find any help function (under HELP). Is it hidden
somewhere or just not supported?

[Lynn McGuire]

On 1/22/2024 4:29 PM, Gary Scott wrote:
> Hi, the latest standalone compiler appears to integrated with VS
> properly, but I don't find any help function (under HELP).  Is it hidden
> somewhere or just not supported?

I cannot get Intellisense or function lookup to work either using the
community version of VS2019.

Lynn

[Gary Scott]

On 1/23/2024 3:31 PM, Lynn McGuire wrote:
> On 1/22/2024 4:29 PM, Gary Scott wrote:
>> Hi, the latest standalone compiler appears to integrated with VS
>> properly, but I don't find any help function (under HELP).  Is it
>> hidden somewhere or just not supported?
>
> I cannot get Intellisense or function lookup to work either using the
> community version of VS2019.
>
> Lynn
>
I'm presently researching. It appears you have to manually download zip
files and manually target to an obscure directory and extract the zip
files to that directory...sheesh...used to be so much better/turn key.

[Gary Scott]

On 1/23/2024 3:48 PM, Gary Scott wrote:
> On 1/23/2024 3:31 PM, Lynn McGuire wrote:
>> On 1/22/2024 4:29 PM, Gary Scott wrote:
>>> Hi, the latest standalone compiler appears to integrated with VS
>>> properly, but I don't find any help function (under HELP).  Is it
>>> hidden somewhere or just not supported?
>>
>> I cannot get Intellisense or function lookup to work either using the
>> community version of VS2019.
>>
>> Lynn
>>
> I'm presently researching.  It appears you have to manually download zip
> files and manually target to an obscure directory and extract the zip
> files to that directory...sheesh...used to be so much better/turn key.
OK, I've successfully set a bookmark to extracted folder in chrome.
How, 1998 of them...:(

[Lynn McGuire]

On 1/23/2024 3:48 PM, Gary Scott wrote:
> On 1/23/2024 3:31 PM, Lynn McGuire wrote:
>> On 1/22/2024 4:29 PM, Gary Scott wrote:
>>> Hi, the latest standalone compiler appears to integrated with VS
>>> properly, but I don't find any help function (under HELP).  Is it
>>> hidden somewhere or just not supported?
>>
>> I cannot get Intellisense or function lookup to work either using the
>> community version of VS2019.
>>
>> Lynn
>>
> I'm presently researching.  It appears you have to manually download zip
> files and manually target to an obscure directory and extract the zip
> files to that directory...sheesh...used to be so much better/turn key.

I would really, really, really like to open a file that I am calling in
a subroutine (open file is greyed out on the right mouse menu) and have
intellisense tell me something when I hover over the call. Such as:

CALL DSDBSE (2,ISET,NDXPH,NDXP,NDXT,NDXCOM,
* NDXZ,NDXFSS,NDXPHI, NDXVOL)

The integration is not complete. I have 3,000 subroutines in one DLL
and 5,000 subroutines in another DLL. Having to look up a called
subroutine manually is a pain. But, if the compiler notes that a
subroutine has a problem, you can double click on the message and get
the subroutine to open. Weird.

Thanks,
Lynn

[Gary Scott]

On 1/23/2024 5:59 PM, Lynn McGuire wrote:
> On 1/23/2024 3:48 PM, Gary Scott wrote:
>> On 1/23/2024 3:31 PM, Lynn McGuire wrote:
>>> On 1/22/2024 4:29 PM, Gary Scott wrote:
>>>> Hi, the latest standalone compiler appears to integrated with VS
>>>> properly, but I don't find any help function (under HELP).  Is it
>>>> hidden somewhere or just not supported?
>>>
>>> I cannot get Intellisense or function lookup to work either using the
>>> community version of VS2019.
>>>
>>> Lynn
>>>
>> I'm presently researching.  It appears you have to manually download
>> zip files and manually target to an obscure directory and extract the
>> zip files to that directory...sheesh...used to be so much better/turn
>> key.
>
> I would really, really, really like to open a file that I am calling in
> a subroutine (open file is greyed out on the right mouse menu) and have
> intellisense tell me something when I hover over the call.  Such as:
>
>             CALL DSDBSE (2,ISET,NDXPH,NDXP,NDXT,NDXCOM,
>      *                   NDXZ,NDXFSS,NDXPHI, NDXVOL)
>
> The integration is not complete.  I have 3,000 subroutines in one DLL
> and 5,000 subroutines in another DLL.  Having to look up a called
> subroutine manually is a pain.  But, if the compiler notes that a
> subroutine has a problem, you can double click on the message and get
> the subroutine to open.  Weird.
>
> Thanks,
> Lynn
>
I'm pretty sure they don't understand the meaning of "IDE integration"
any more.

[Gary Scott]

On 1/23/2024 6:30 PM, Gary Scott wrote:
> On 1/23/2024 5:59 PM, Lynn McGuire wrote:
>> On 1/23/2024 3:48 PM, Gary Scott wrote:
>>> On 1/23/2024 3:31 PM, Lynn McGuire wrote:
>>>> On 1/22/2024 4:29 PM, Gary Scott wrote:
>>>>> Hi, the latest standalone compiler appears to integrated with VS
>>>>> properly, but I don't find any help function (under HELP).  Is it
>>>>> hidden somewhere or just not supported?
>>>>
>>>> I cannot get Intellisense or function lookup to work either using
>>>> the community version of VS2019.
>>>>
>>>> Lynn
>>>>
>>> I'm presently researching.  It appears you have to manually download
>>> zip files and manually target to an obscure directory and extract the
>>> zip files to that directory...sheesh...used to be so much better/turn
>>> key.
>>
>> I would really, really, really like to open a file that I am calling
>> in a subroutine (open file is greyed out on the right mouse menu) and
>> have intellisense tell me something when I hover over the call.  Such as:
>>
>>              CALL DSDBSE (2,ISET,NDXPH,NDXP,NDXT,NDXCOM,
>>       *                   NDXZ,NDXFSS,NDXPHI, NDXVOL)
>>
>> The integration is not complete.  I have 3,000 subroutines in one DLL
>> and 5,000 subroutines in another DLL.  Having to look up a called
>> subroutine manually is a pain.  But, if the compiler notes that a
>> subroutine has a problem, you can double click on the message and get
>> the subroutine to open.  Weird.
>>
>> Thanks,
>> Lynn
>>
> I'm pretty sure they don't understand the meaning of "IDE integration"
> any more.
Of course, MS doesn't make it so easy :(

[Lawrence D'Oliveiro]

On Tue, 23 Jan 2024 18:30:12 -0600, Gary Scott wrote:

> I'm pretty sure they don't understand the meaning of "IDE integration"
> any more.

Is that integration with your IDE development environment?

[Gary Scott]

On 1/24/2024 6:20 PM, Lawrence D'Oliveiro wrote:
> On Tue, 23 Jan 2024 18:30:12 -0600, Gary Scott wrote:
>
>> I'm pretty sure they don't understand the meaning of "IDE integration"
>> any more.
>
> Is that integration with your IDE development environment?
Visual Studio

[Lawrence D'Oliveiro]

On Tue, 23 Jan 2024 17:59:59 -0600, Lynn McGuire wrote:

> CALL DSDBSE (2,ISET,NDXPH,NDXP,NDXT,NDXCOM,
> * NDXZ,NDXFSS,NDXPHI, NDXVOL)

Are people still stuck with 6-letter names? I thought we left that behind
with FORTRAN 66 ...

[Thomas Koenig]

Lawrence D'Oliveiro <***@nz.invalid> schrieb:
> On Tue, 23 Jan 2024 17:59:59 -0600, Lynn McGuire wrote:
>
>> CALL DSDBSE (2,ISET,NDXPH,NDXP,NDXT,NDXCOM,
>> * NDXZ,NDXFSS,NDXPHI, NDXVOL)
>
> Are people still stuck with 6-letter names? I thought we left that behind
> with FORTRAN 66 ...

Fortran 90 relaxed that requirement, although many compilers allowed it before.

[Lynn McGuire]

On 1/24/2024 6:20 PM, Lawrence D'Oliveiro wrote:
> On Tue, 23 Jan 2024 17:59:59 -0600, Lynn McGuire wrote:
>
>> CALL DSDBSE (2,ISET,NDXPH,NDXP,NDXT,NDXCOM,
>> * NDXZ,NDXFSS,NDXPHI, NDXVOL)
>
> Are people still stuck with 6-letter names? I thought we left that behind
> with FORTRAN 66 ...

Much Fortran code was written under the F66 rules until the late 1980s
if you supported multiple platforms (we supported ten platforms in the
1980s). You can update it to longer names at your own peril.

Lynn

[Lawrence D'Oliveiro]

On Thu, 25 Jan 2024 15:31:51 -0600, Lynn McGuire wrote:

> Much Fortran code was written under the F66 rules until the late 1980s
> if you supported multiple platforms (we supported ten platforms in the
> 1980s).

Why did it take vendors so long to catch up to FORTRAN 77?

By the way, I thought the limit on identifier length had been lifted in
FORTRAN 77, but I was wrong: it took until Fortran 90 to raise the limit
to 31.

> You can update it to longer names at your own peril.

Why is that still the case? Longer names have been allowed for going back
about a third of a century now.

[Harold Stevens]

In <uovrpj$2okd6$***@dont-email.me> Lawrence D'Oliveiro:

[Snip...]

> Why is that still the case?
> Longer names have been allowed for going back
> about a third of a century now.

Suppose you're in charge of CERN, and responsibile for integrating
2 bazillion lines of particle physics code in libraries resembling
the Tower of Babel.

Chances are very good you have this tattooed on your forehead:

IF IT AIN'T BROKE, DON'T FIX IT.

--
Regards, Weird (Harold Stevens) * IMPORTANT EMAIL INFO FOLLOWS *
Pardon any bogus email addresses (wookie) in place for spambots.
Really, it's (wyrd) at att, dotted with net. * DO NOT SPAM IT. *
I toss GoogleGroup (http://twovoyagers.com/improve-usenet.org/).

[Thomas Koenig]

Harold Stevens <***@aspen.localdomain> schrieb:
> In <uovrpj$2okd6$***@dont-email.me> Lawrence D'Oliveiro:
>
> [Snip...]
>
>> Why is that still the case?
>> Longer names have been allowed for going back
>> about a third of a century now.
>
> Suppose you're in charge of CERN, and responsibile for integrating
> 2 bazillion lines of particle physics code in libraries resembling
> the Tower of Babel.

Then you have about the chance of a snowball in a Supernova of
avoiding name conflicts in your subroutines and COMMON blocks
if you stick to six-letter identifiers.

> Chances are very good you have this tattooed on your forehead:
>
> IF IT AIN'T BROKE, DON'T FIX IT.

And if you don't understand what it does, would you trust it
enough to publish a paper with? :-)

[Gary Scott]

On 1/26/2024 1:25 PM, Thomas Koenig wrote:
> Harold Stevens <***@aspen.localdomain> schrieb:
>> In <uovrpj$2okd6$***@dont-email.me> Lawrence D'Oliveiro:
>>
>> [Snip...]
>>
>>> Why is that still the case?
>>> Longer names have been allowed for going back
>>> about a third of a century now.
>>
>> Suppose you're in charge of CERN, and responsibile for integrating
>> 2 bazillion lines of particle physics code in libraries resembling
>> the Tower of Babel.
>
> Then you have about the chance of a snowball in a Supernova of
> avoiding name conflicts in your subroutines and COMMON blocks
> if you stick to six-letter identifiers.
>
I hear this a lot here, but we had a very strong and unique, consistent
naming convention for procedures and variables (many millions of lines
of code). I'm sure it happened, but I never came across an issue with
naming conflicts specifically. Misunderstanding what a particular
procedure actually was for, yes, but that happens even with verbosely
named procedures, especially if the documentation/help system is
substandard.

[Lawrence D'Oliveiro]

On Fri, 26 Jan 2024 19:25:05 -0000 (UTC), Thomas Koenig wrote:

> And if you don't understand what it does, would you trust it enough to
> publish a paper with? :-)

I assume physicists are smarter than, say, economists, who publish papers
from calculations done in (shudder) Microsoft Excel.

Unfortunately, some geneticists have done the same.

[Lawrence D'Oliveiro]

On Fri, 26 Jan 2024 03:51:06 -0600, Harold Stevens wrote:

> Suppose you're in charge of CERN, and responsibile for integrating 2
> bazillion lines of particle physics code in libraries resembling the
> Tower of Babel.

Nonsense. It’s only 1.5 bazillion lines of code.

Besides, high-energy physics uses a lot of C++ code. I know, because I
have had to set up some of it for physicist clients.

[Steve Lionel]

On 1/26/2024 3:50 AM, Lawrence D'Oliveiro wrote:
> Why did it take vendors so long to catch up to FORTRAN 77?

What makes you think that? VAX-11 FORTRAN V2 (1980) fully supported
FORTRAN 77 (published 1978); I was responsible for adding the few
remaining run-time features. I know there were other vendors with full
F77 compilers in about the same time.
--
Steve Lionel
ISO/IEC JTC1/SC22/WG5 (Fortran) Convenor
Retired Intel Fortran developer/support
Email: firstname at firstnamelastname dot com
Twitter: @DoctorFortran
LinkedIn: https://www.linkedin.com/in/stevelionel
Blog: https://stevelionel.com/drfortran
WG5: https://wg5-fortran.org

[Thomas Koenig]

Lawrence D'Oliveiro <***@nz.invalid> schrieb:
> On Thu, 25 Jan 2024 15:31:51 -0600, Lynn McGuire wrote:
>
>> Much Fortran code was written under the F66 rules until the late 1980s
>> if you supported multiple platforms (we supported ten platforms in the
>> 1980s).
>
> Why did it take vendors so long to catch up to FORTRAN 77?

Bell Labs Fortran f77 appeared in August 1978, can't get much
faster than that.

At bitsavers, I find a manuals for VS Fortran which mention a
first release in February 1981.

A Cray manual from 1984 (SR-0009J_CFT_Reference_Dec84.pdf) mentiones
Fortran 77 compliance for August 1981.

Steve Lionel already reported about VAX Fortran in 1980.

> By the way, I thought the limit on identifier length had been lifted in
> FORTRAN 77, but I was wrong: it took until Fortran 90 to raise the limit
> to 31.

It was just a very commen extension, and would bite you if you
used, for example, a Fujitsu compiler, which still enforced it,
after doing development on VS Fortran...

Where Fortran really lost out was in the decade+ between the FORTRAN
77 and Fortran 90. C was gaining traction, and scientists and
engineers learned about the benefits of dynamic memory allocation
and structs.

Fortran 90 where it went wrong - standard was very late, the
implementations came late (with the exception of NAG, which was
very fast), and g77 (which was part of the gcc suite) was F77.

[Lawrence D'Oliveiro]

On Fri, 26 Jan 2024 18:42:16 -0000 (UTC), Thomas Koenig wrote:

> Fortran 90 where it went wrong - standard was very late, the
> implementations came late (with the exception of NAG, which was very
> fast), and g77 (which was part of the gcc suite) was F77.

Still, I had a look at the spec, and Fortran 90 was quite a breathtaking
advance.

[Thomas Koenig]

Lawrence D'Oliveiro <***@nz.invalid> schrieb:
> On Fri, 26 Jan 2024 18:42:16 -0000 (UTC), Thomas Koenig wrote:
>
>> Fortran 90 where it went wrong - standard was very late, the
>> implementations came late (with the exception of NAG, which was very
>> fast), and g77 (which was part of the gcc suite) was F77.
>
> Still, I had a look at the spec, and Fortran 90 was quite a breathtaking
> advance.

Absolutely. Fortran 90 was a modern programming language including
all the useful features of C (except unsigned numbers), but
surpassing it in power by far.

But an intermediate version in the mid-1980s with only half the
features added might have worked better. Interesting question would
be which features...

[Lawrence D'Oliveiro]

On Sat, 27 Jan 2024 11:04:21 -0000 (UTC), Thomas Koenig wrote:

> Fortran 90 was a modern programming language including all
> the useful features of C (except unsigned numbers), but surpassing it in
> power by far.

It even does recursive functions/subroutines. But you must explicitly
declare them RECURSIVE, which C doesn’t.

On the plus side, seems it has a proper MODULE import facility
(reminiscent of Ada), as opposed to relying on the #include hack.

[Thomas Koenig]

Lawrence D'Oliveiro <***@nz.invalid> schrieb:
> On Sat, 27 Jan 2024 11:04:21 -0000 (UTC), Thomas Koenig wrote:
>
>> Fortran 90 was a modern programming language including all
>> the useful features of C (except unsigned numbers), but surpassing it in
>> power by far.
>
> It even does recursive functions/subroutines. But you must explicitly
> declare them RECURSIVE, which C doesn’t.

It's the functionality that counts, not the syntax.

> On the plus side, seems it has a proper MODULE import facility
> (reminiscent of Ada), as opposed to relying on the #include hack.

One of the useful things (although it took SUBMODULEs to realize its
whole potential).

[Lawrence D'Oliveiro]

On Sat, 27 Jan 2024 22:58:27 -0000 (UTC), Thomas Koenig wrote:

> Lawrence D'Oliveiro <***@nz.invalid> schrieb:
>
>> It even does recursive functions/subroutines. But you must explicitly
>> declare them RECURSIVE, which C doesn’t.
>
> It's the functionality that counts, not the syntax.

You shouldn’t need separate syntax to enable something that should be
available as a matter of course.

[Thomas Koenig]

Lawrence D'Oliveiro <***@nz.invalid> schrieb:
> On Sat, 27 Jan 2024 22:58:27 -0000 (UTC), Thomas Koenig wrote:
>
>> Lawrence D'Oliveiro <***@nz.invalid> schrieb:
>>
>>> It even does recursive functions/subroutines. But you must explicitly
>>> declare them RECURSIVE, which C doesn’t.
>>
>> It's the functionality that counts, not the syntax.
>
> You shouldn’t need separate syntax to enable something that should be
> available as a matter of course.

What "should be available as a matter of course" is very much
an opinion, and there are two sides to that argument what should
be the default.

Just one example: Stack sizes are severely limited even on modern
systems, at least by default (and sometimes even more severely
for multithreaded applications). So, it is quite possible for an
application to work fine with non-recursive subroutines, but to
crash mysteriously with recursive subrotines, on modern systems.

So, should a compiler by default follow F2018 (which makes
procedures recursive by default) or not? Hmmm...

[Lawrence D'Oliveiro]

On Sun, 28 Jan 2024 08:54:48 -0000 (UTC), Thomas Koenig wrote:

> Lawrence D'Oliveiro <***@nz.invalid> schrieb:
>
>> You shouldn’t need separate syntax to enable something that should be
>> available as a matter of course.
>
> What "should be available as a matter of course" is very much an
> opinion ...

Every modern language has that capability.

> Just one example: Stack sizes are severely limited even on modern
> systems ...

Yes, but at least we can assume we have a stack.

[Gary Scott]

On 1/28/2024 2:54 AM, Thomas Koenig wrote:
> Lawrence D'Oliveiro <***@nz.invalid> schrieb:
>> On Sat, 27 Jan 2024 22:58:27 -0000 (UTC), Thomas Koenig wrote:
>>
>>> Lawrence D'Oliveiro <***@nz.invalid> schrieb:
>>>
>>>> It even does recursive functions/subroutines. But you must explicitly
>>>> declare them RECURSIVE, which C doesn’t.
>>>
>>> It's the functionality that counts, not the syntax.
>>
>> You shouldn’t need separate syntax to enable something that should be
>> available as a matter of course.
>
> What "should be available as a matter of course" is very much
> an opinion, and there are two sides to that argument what should
> be the default.
>
> Just one example: Stack sizes are severely limited even on modern
> systems, at least by default (and sometimes even more severely
> for multithreaded applications). So, it is quite possible for an
> application to work fine with non-recursive subroutines, but to
> crash mysteriously with recursive subrotines, on modern systems.
>
> So, should a compiler by default follow F2018 (which makes
> procedures recursive by default) or not? Hmmm...
Definitely should NOT be the default.

[pehache]

Le 28/01/2024 à 16:56, Gary Scott a écrit :
> On 1/28/2024 2:54 AM, Thomas Koenig wrote:
>> Lawrence D'Oliveiro <***@nz.invalid> schrieb:
>>> On Sat, 27 Jan 2024 22:58:27 -0000 (UTC), Thomas Koenig wrote:
>>>
>>>> Lawrence D'Oliveiro <***@nz.invalid> schrieb:
>>>>
>>>>> It even does recursive functions/subroutines. But you must explicitly
>>>>> declare them RECURSIVE, which C doesn’t.
>>>>
>>>> It's the functionality that counts, not the syntax.
>>>
>>> You shouldn’t need separate syntax to enable something that should be
>>> available as a matter of course.
>>
>> What "should be available as a matter of course" is very much
>> an opinion, and there are two sides to that argument what should
>> be the default.
>>
>> Just one example: Stack sizes are severely limited even on modern
>> systems, at least by default (and sometimes even more severely
>> for multithreaded applications). So, it is quite possible for an
>> application to work fine with non-recursive subroutines, but to
>> crash mysteriously with recursive subrotines, on modern systems.
>>
>> So, should a compiler by default follow F2018 (which makes
>> procedures recursive by default) or not? Hmmm...
>
> Definitely should NOT be the default.

The standard states this must be the default, so it has to be. Maybe some
time is needed to make the appropriate changes to the compilers, but
eventually there should be no debate around this.

[Steven G. Kargl]

On Sun, 28 Jan 2024 08:54:48 +0000, Thomas Koenig wrote:

> Lawrence D'Oliveiro <***@nz.invalid> schrieb:
>> On Sat, 27 Jan 2024 22:58:27 -0000 (UTC), Thomas Koenig wrote:
>>
>>> Lawrence D'Oliveiro <***@nz.invalid> schrieb:
>>>
>>>> It even does recursive functions/subroutines. But you must explicitly
>>>> declare them RECURSIVE, which C doesn’t.
>>>
>>> It's the functionality that counts, not the syntax.
>>
>> You shouldn’t need separate syntax to enable something that should be
>> available as a matter of course.
>
> What "should be available as a matter of course" is very much an
> opinion, and there are two sides to that argument what should be the
> default.
>
> Just one example: Stack sizes are severely limited even on modern
> systems, at least by default (and sometimes even more severely for
> multithreaded applications). So, it is quite possible for an
> application to work fine with non-recursive subroutines, but to crash
> mysteriously with recursive subrotines, on modern systems.
>
> So, should a compiler by default follow F2018 (which makes procedures
> recursive by default) or not? Hmmm...

I submitted a patch to implement the NON_RECURSIVE prefix and
made the change to make procedure recursive by default. It's
in bugzilla. Janne and I had a short discussion, and we are
both leary of what might happen with the stack; particular for
an OS that provides a small stack.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101632

--
steve

[Lawrence D'Oliveiro]

On Sun, 28 Jan 2024 16:41:21 -0000 (UTC), Steven G. Kargl wrote:

> I submitted a patch to implement the NON_RECURSIVE prefix and made the
> change to make procedure recursive by default. It's in bugzilla. Janne
> and I had a short discussion, and we are both leary of what might happen
> with the stack; particular for an OS that provides a small stack.

Large objects tend to be variable in size anyway; how do you deal with
that? Do you stop and restart the program with a different global
allocation size?

In modern languages, we do most dynamic allocations, especially large
ones, in the heap.

[Thomas Koenig]

Lawrence D'Oliveiro <***@nz.invalid> schrieb:
> On Sun, 28 Jan 2024 16:41:21 -0000 (UTC), Steven G. Kargl wrote:
>
>> I submitted a patch to implement the NON_RECURSIVE prefix and made the
>> change to make procedure recursive by default. It's in bugzilla. Janne
>> and I had a short discussion, and we are both leary of what might happen
>> with the stack; particular for an OS that provides a small stack.
>
> Large objects tend to be variable in size anyway; how do you deal with
> that?

In a recent Fortran, a programmer can use

- Pointers The memory management is then done with ALLOCATE
and DEALLOCATE, much like C's malloc()/calloc() and free().
Known to be error-prone

- Allocatable variables. Allocating is done by the programmer,
deallocation can be done either manually or when the variable
goes out of scope. This can be somewhat tricky for compilers
to get right, but the burden is on the compiler writers,
where it belongs, and not on the programmers :-)

- An explicit shape with non-constant bounds, such as

subroutine foo(n)
integer :: n
real, dimension(n,n) :: a

Since Fortran 2008, this is also possible with BLOCK constructs.
This is similar to alloca() (a non-standard C construct) or
to VLAs in C.

The compiler is then responsible for handling the memory allocation
in a meaningful way - it can either allocate the memory on the
stack or on the heap.

>Do you stop and restart the program with a different global
> allocation size?

What people did in Fortran 77 and prior was usually to have a
global COMMON block which was then parcelled out piecewise.
Ugly, error-prone and no longer needed these days.

If you look at LAPACK intefaces, you still see lots of arguments
which are relatd to original and actual size of arrays - not pretty.
I wish they would use more modern features.


> In modern languages, we do most dynamic allocations, especially large
> ones, in the heap.

Assume you have a fixed-size buffer for some sort of blocked
algorithm. Where do you put it? If you make your subroutine
recursive, where it wasn't before, you suddenly end up using
a lot more stack, which then can crash a user's program.

And changing the default would cause that crash without source
code modification... which is bad.

[Lawrence D'Oliveiro]

On Mon, 29 Jan 2024 06:54:14 -0000 (UTC), Thomas Koenig wrote:

> Lawrence D'Oliveiro <***@nz.invalid> schrieb:
>
>> In modern languages, we do most dynamic allocations, especially large
>> ones, in the heap.
>
> Assume you have a fixed-size buffer for some sort of blocked algorithm.
> Where do you put it? If you make your subroutine recursive, where it
> wasn't before, you suddenly end up using a lot more stack, which then
> can crash a user's program.
>
> And changing the default would cause that crash without source code
> modification... which is bad.

Precisely my point.

[Thomas Koenig]

Lawrence D'Oliveiro <***@nz.invalid> schrieb:
> On Mon, 29 Jan 2024 06:54:14 -0000 (UTC), Thomas Koenig wrote:
>
>> Lawrence D'Oliveiro <***@nz.invalid> schrieb:
>>
>>> In modern languages, we do most dynamic allocations, especially large
>>> ones, in the heap.
>>
>> Assume you have a fixed-size buffer for some sort of blocked algorithm.
>> Where do you put it? If you make your subroutine recursive, where it
>> wasn't before, you suddenly end up using a lot more stack, which then
>> can crash a user's program.
>>
>> And changing the default would cause that crash without source code
>> modification... which is bad.
>
> Precisely my point.

Then I don't understand your point.

[pehache]

Le 28/01/2024 à 09:54, Thomas Koenig a écrit :
> Lawrence D'Oliveiro <***@nz.invalid> schrieb:
>> On Sat, 27 Jan 2024 22:58:27 -0000 (UTC), Thomas Koenig wrote:
>>
>>> Lawrence D'Oliveiro <***@nz.invalid> schrieb:
>>>
>>>> It even does recursive functions/subroutines. But you must explicitly
>>>> declare them RECURSIVE, which C doesn’t.
>>>
>>> It's the functionality that counts, not the syntax.
>>
>> You shouldn’t need separate syntax to enable something that should be
>> available as a matter of course.
>
> What "should be available as a matter of course" is very much
> an opinion, and there are two sides to that argument what should
> be the default.
>
> Just one example: Stack sizes are severely limited even on modern
> systems, at least by default (and sometimes even more severely
> for multithreaded applications). So, it is quite possible for an
> application to work fine with non-recursive subroutines, but to
> crash mysteriously with recursive subrotines, on modern systems.

I am a bit puzzled by such a debate.

First of all I don't get why the OS's define such small stack sizes by
default, given the amounts of RAM that are available on current hardware.

Second, it's up to the compilers to follow appropriate allocation
strategies, and I must say that both gfortran and Intel Fortran have IMHO
weird strategies:
- above a given size, gfortran reverts from stack allocation to static
memory (*)
- by default, Intel Fortran sticks to stack allocation for automatic
variables/arrays and for temporary arrays, without bothering at all to
check the stack size

I would expect compilers to allocate small objects on the stack, and
larger objects on the heap.

(*) by the way, it's still unclear to me what happens in gfortran with
large automatic arrays when the size is not known at compile time?

Third, every programmer should be aware that large automatic objects are
not a good idea given the usually limited stack sizes.

And last, the main reason to get away from static variables in the
routines is multithreading, much before recursion.

> So, should a compiler by default follow F2018 (which makes
> procedures recursive by default) or not? Hmmm...

Of course it should. Adherence to the standard ensures portability.

[Gary Scott]

On 1/26/2024 2:50 AM, Lawrence D'Oliveiro wrote:
> On Thu, 25 Jan 2024 15:31:51 -0600, Lynn McGuire wrote:
>
>> Much Fortran code was written under the F66 rules until the late 1980s
>> if you supported multiple platforms (we supported ten platforms in the
>> 1980s).
>
> Why did it take vendors so long to catch up to FORTRAN 77?
>
> By the way, I thought the limit on identifier length had been lifted in
> FORTRAN 77, but I was wrong: it took until Fortran 90 to raise the limit
> to 31.
>
>> You can update it to longer names at your own peril.
>
> Why is that still the case? Longer names have been allowed for going back
> about a third of a century now.
Harris VOS Fortran (~1980) had a lot of extensions beyond F77 that
eventually went into F90 (long procedure/variable names (63 chars), free
form source, full complement of end statements, async IO (although a
different form), "Purdue" bit intrinsics (1753), and many others). They
were way ahead of the standard, but there's always risk in adding
extensions. These were however essential to make the systems usable for
real-time programming (in addition to program priority control, process
initiation/termination, hardware interrupt handling/processing, shared
memory access and control, etc.)

[Lawrence D'Oliveiro]

On Fri, 26 Jan 2024 13:15:15 -0600, Gary Scott wrote:

> Harris VOS Fortran (~1980) had a lot of extensions beyond F77 that
> eventually went into F90 (long procedure/variable names (63 chars), free
> form source, full complement of end statements, async IO (although a
> different form), "Purdue" bit intrinsics (1753), and many others). They
> were way ahead of the standard, but there's always risk in adding
> extensions. These were however essential to make the systems usable for
> real-time programming (in addition to program priority control, process
> initiation/termination, hardware interrupt handling/processing, shared
> memory access and control, etc.)

Strange, isn’t it. PL/I was supposed to be the language with all of that--
I gather it was even going to be called “FORTRAN VI” at one point.

That never caught on much (outside of IBM). Yet Fortran has ended up
reinventing a lot of it.

[Lynn McGuire]

On 1/26/2024 10:43 PM, Lawrence D'Oliveiro wrote:
> On Fri, 26 Jan 2024 13:15:15 -0600, Gary Scott wrote:
>
>> Harris VOS Fortran (~1980) had a lot of extensions beyond F77 that
>> eventually went into F90 (long procedure/variable names (63 chars), free
>> form source, full complement of end statements, async IO (although a
>> different form), "Purdue" bit intrinsics (1753), and many others). They
>> were way ahead of the standard, but there's always risk in adding
>> extensions. These were however essential to make the systems usable for
>> real-time programming (in addition to program priority control, process
>> initiation/termination, hardware interrupt handling/processing, shared
>> memory access and control, etc.)
>
> Strange, isn’t it. PL/I was supposed to be the language with all of that--
> I gather it was even going to be called “FORTRAN VI” at one point.
>
> That never caught on much (outside of IBM). Yet Fortran has ended up
> reinventing a lot of it.

Prime computer used PL/1 to rewrite the Primos Operating System in from
Fortran (66, I think).

Lynn

[Lawrence D'Oliveiro]

On Fri, 26 Jan 2024 23:17:10 -0600, Lynn McGuire wrote:

> On 1/26/2024 10:43 PM, Lawrence D'Oliveiro wrote:
>
>> [PL/I] never caught on much (outside of IBM). Yet Fortran has ended up
>> reinventing a lot of it.
>
> Prime computer used PL/1 to rewrite the Primos Operating System in from
> Fortran (66, I think).

Also used to create MULTICS. You know, the project that Bell Labs exited,
to go on to create a, shall we say, anti-MULTICS.

[Lynn McGuire]

On 1/26/2024 2:50 AM, Lawrence D'Oliveiro wrote:
> On Thu, 25 Jan 2024 15:31:51 -0600, Lynn McGuire wrote:
>
>> Much Fortran code was written under the F66 rules until the late 1980s
>> if you supported multiple platforms (we supported ten platforms in the
>> 1980s).
>
> Why did it take vendors so long to catch up to FORTRAN 77?
>
> By the way, I thought the limit on identifier length had been lifted in
> FORTRAN 77, but I was wrong: it took until Fortran 90 to raise the limit
> to 31.
>
>> You can update it to longer names at your own peril.
>
> Why is that still the case? Longer names have been allowed for going back
> about a third of a century now.

I have 780,000 lines of F77 code intermixed with 60,000 lines of C and
C++ code. We have been updating the code to move from our Open Watcom
F77, C, and C++ compilers to the Visual C++ / Intel Fortran combo. We
are making enough broad changes at the moment, thank you. I will pass
on automating variable name changes just to make them longer.

Lynn