"The Skills Gap For Fortran Looms Large In HPC" by Timothy Prickett Morgan
https://www.nextplatform.com/2023/05/02/the-skills-gap-for-fortran-looms-large-in-hpc/

"A better question might be: What is going to happen to Fortran, and
that is precisely the one that has been posed in a report put together
by two researchers at Los Alamos National Laboratory, which has quite a
few Fortran applications that are used as part of the US Department of
Energy’s stewardship of the nuclear weapons stockpile for the United
States. (We covered the hardware issues relating to managing that
stockpile a few weeks ago, and now we are coincidentally talking about
separate but related software issues.) The researchers who have
formalized and quantified the growing concerns that many in the HPC
community have talked about privately concerning Fortran are Galen
Shipman, a computer scientist, and Timothy Randles, the computational
systems and software environment program manager for the Advanced
Simulation and Computing (ASC) program of the DOE, which funds the big
supercomputer projects at the major nuke labs, which also includes
Sandia National Laboratories and Lawrence Livermore National Laboratory."

"The report they put together, called An Evaluation Of Risks Associated
With Relying On Fortran For Mission Critical Codes For The Next 15
Years, can be downloaded here. It is an interesting report, particularly
in that Shipman and Randles included comments from reviewers that
offered contrarian views to the ones that they held, just to give a
sense that this assessment for Fortran is not necessarily universal. But
from our reading, it sure looks like everyone in the HPC community that
has Fortran codes has some concerns at the very least."
https://permalink.lanl.gov/object/tr?what=info:lanl-repo/lareport/LA-UR-23-23992

Lynn

On Thursday, May 4, 2023 at 4:09:26 PM UTC-7, Lynn McGuire wrote:
> "The Skills Gap For Fortran Looms Large In HPC" by Timothy Prickett Morgan
>
(snip)
> https://permalink.lanl.gov/object/tr?what=info:lanl-repo/lareport/LA-UR-23-23992
And no mention of quantum computers.

On 5/4/2023 6:50 PM, gah4 wrote:
> On Thursday, May 4, 2023 at 4:09:26 PM UTC-7, Lynn McGuire wrote:
>> "The Skills Gap For Fortran Looms Large In HPC" by Timothy Prickett Morgan
>>
> (snip)
>> https://permalink.lanl.gov/object/tr?what=info:lanl-repo/lareport/LA-UR-23-23992
>
> And no mention of quantum computers.

Is there a quantum computer operating anywhere not in a lab ?

And are quantum computers programmable with a language like Fortran or C ?

Lynn

On Thursday, May 4, 2023 at 7:45:39 PM UTC-7, Lynn McGuire wrote:

(snip, I wrote)
> > And no mention of quantum computers.

> Is there a quantum computer operating anywhere not in a lab ?
> And are quantum computers programmable with a language like Fortran or C ?
The paper is supposed to be about the next 15 years.

Quantum computers might be in the lab now, but maybe not in 15 years.
(And besides, LASL is a lab.)

I wouldn't want to be that they won't be used in 15 years.

On 5/5/2023 12:43 AM, gah4 wrote:
> On Thursday, May 4, 2023 at 7:45:39 PM UTC-7, Lynn McGuire wrote:
>
> (snip, I wrote)
>>> And no mention of quantum computers.
>
>> Is there a quantum computer operating anywhere not in a lab ?
>
>> And are quantum computers programmable with a language like Fortran or C ?
>
> The paper is supposed to be about the next 15 years.
>
> Quantum computers might be in the lab now, but maybe not in 15 years.
> (And besides, LASL is a lab.)
>
> I wouldn't want to be that they won't be used in 15 years.

You did not answer my question that are the quantum computers
programmable with Fortran or C ?

Thanks,
Lynn

On Friday, May 5, 2023 at 4:05:42 PM UTC-7, Lynn McGuire wrote:

(snip)

> You did not answer my question that are the quantum computers
> programmable with Fortran or C ?

Maybe not.

But the question is about: "risks associated with relying on Fortran for mission
critical codes for the next 15 years".

That might change if quantum computers start being useful.

Lynn McGuire <lynnmcguire5@gmail.com> schrieb:

> https://permalink.lanl.gov/object/tr?what=info:lanl-repo/lareport/LA-UR-23-23992

# Compiler technology costs are significant for Fortran and are
# trending upwards. Estimates of tens of millions of dollars have
# been discussed recently.

Hm, I haven't seen any o those tens of millions of dollars on my
personal bank account. Maybe this could be made more profitable
for people who volunteer :-)

On 05.05.2023 01.09, Lynn McGuire wrote:
> "The Skills Gap For Fortran Looms Large In HPC" by Timothy Prickett Morgan
>
> https://www.nextplatform.com/2023/05/02/the-skills-gap-for-fortran-looms-large-in-hpc/
>
> "A better question might be: What is going to happen to Fortran, and
[...]
I think that like Cobol, Fortran will live on for decades yet, if only
because of all the legacy programs around.
--
Dieter Britz

On 5/7/2023 8:39 AM, db wrote:
> On 05.05.2023 01.09, Lynn McGuire wrote:
>> "The Skills Gap For Fortran Looms Large In HPC" by Timothy Prickett
>> Morgan
>>
>> https://www.nextplatform.com/2023/05/02/the-skills-gap-for-fortran-looms-large-in-hpc/
>>
>> "A better question might be: What is going to happen to Fortran, and
> [...]
> I think that like Cobol, Fortran will live on for decades yet, if only
> because of all the legacy programs around.

Yup. The problem comes when they want to recompile and the code was
developed with F66 or F77 compilers. If, they can find the source code.
The F66 code is the worst but both have severe issues with zero
initialization and file handling.

Lynn

On 5/7/2023 4:19 AM, Thomas Koenig wrote:
> Lynn McGuire <lynnmcguire5@gmail.com> schrieb:
>
>> https://permalink.lanl.gov/object/tr?what=info:lanl-repo/lareport/LA-UR-23-23992
>
> # Compiler technology costs are significant for Fortran and are
> # trending upwards. Estimates of tens of millions of dollars have
> # been discussed recently.
>
> Hm, I haven't seen any o those tens of millions of dollars on my
> personal bank account. Maybe this could be made more profitable
> for people who volunteer :-)

Are you a volunteer or a paid employee ?

I have fixed a few bugs in the Open Watcom C, C++, and F77 compiler
suite with the help of the old programmers. It is a total mess with
over 2.1 million lines of mostly C code.

I can just imagine what the GCC compiler suite looks like. Probably 10X
the size at least and more complicated to boot.

Lynn

Lynn McGuire <lynnmcguire5@gmail.com> schrieb:
> On 5/7/2023 4:19 AM, Thomas Koenig wrote:
>> Lynn McGuire <lynnmcguire5@gmail.com> schrieb:
>>
>>> https://permalink.lanl.gov/object/tr?what=info:lanl-repo/lareport/LA-UR-23-23992
>>
>> # Compiler technology costs are significant for Fortran and are
>> # trending upwards. Estimates of tens of millions of dollars have
>> # been discussed recently.
>>
>> Hm, I haven't seen any o those tens of millions of dollars on my
>> personal bank account. Maybe this could be made more profitable
>> for people who volunteer :-)
>
> Are you a volunteer or a paid employee ?

Volunteer.

My day-time job has absolutely nothing to do with compiler writing,
I use gfortran for a few projects, but that's about it.

> I have fixed a few bugs in the Open Watcom C, C++, and F77 compiler
> suite with the help of the old programmers. It is a total mess with
> over 2.1 million lines of mostly C code.
>
> I can just imagine what the GCC compiler suite looks like. Probably 10X
> the size at least and more complicated to boot.

To contribute to gfortran, you do not need to know about all of gcc.
gfortran is a front end, which translates Fortran to a gcc internal
representation not too dissimilar to C.

If you're interested, https://gcc.gnu.org/wiki/GFortranHacking has
a very rough overview on how to start

On Friday, May 5, 2023 at 4:05:42 PM UTC-7, Lynn McGuire wrote:

(snip)

> You did not answer my question that are the quantum computers
> programmable with Fortran or C ?

Looking again, there is:
"6. It is very likely that Fortran will preclude effective use of important
advances in computing technology."

They could have been more specific on the "advances", but that might include
quantum computing.

As well as I know it, from the stories that leaked out, LASL has some programs
that are millions, or maybe 10s of millions of lines.

https://www.lanl.gov/conferences/salishan/salishan2004/chandler.pdf

On 5/8/2023 12:25 AM, Thomas Koenig wrote:
> Lynn McGuire <lynnmcguire5@gmail.com> schrieb:
>> On 5/7/2023 4:19 AM, Thomas Koenig wrote:
>>> Lynn McGuire <lynnmcguire5@gmail.com> schrieb:
>>>
>>>> https://permalink.lanl.gov/object/tr?what=info:lanl-repo/lareport/LA-UR-23-23992
>>>
>>> # Compiler technology costs are significant for Fortran and are
>>> # trending upwards. Estimates of tens of millions of dollars have
>>> # been discussed recently.
>>>
>>> Hm, I haven't seen any o those tens of millions of dollars on my
>>> personal bank account. Maybe this could be made more profitable
>>> for people who volunteer :-)
>>
>> Are you a volunteer or a paid employee ?
>
> Volunteer.
>
> My day-time job has absolutely nothing to do with compiler writing,
> I use gfortran for a few projects, but that's about it.
>
>> I have fixed a few bugs in the Open Watcom C, C++, and F77 compiler
>> suite with the help of the old programmers. It is a total mess with
>> over 2.1 million lines of mostly C code.
>>
>> I can just imagine what the GCC compiler suite looks like. Probably 10X
>> the size at least and more complicated to boot.
>
> To contribute to gfortran, you do not need to know about all of gcc.
> gfortran is a front end, which translates Fortran to a gcc internal
> representation not too dissimilar to C.
>
> If you're interested, https://gcc.gnu.org/wiki/GFortranHacking has
> a very rough overview on how to start

Thanks, but I am old (62 !) and horribly busy. I am converting my
743,000 lines of F77 code with 50,000 lines of C/C++ to 64 bit. I am
having to fix many, many sins of the past. It has been a very long time
since I ran this code in pure Fortran 66 on a CDC 7600.

BTW, the Open Watcom compiler suite is an intermediate language also.
Watcom is the old Waterloo Fortran compiler. There is a guy trying to
upgrade it to 64 bit but it is going slow, very slow.
https://github.com/open-watcom

Lynn

On Monday, May 8, 2023 at 2:05:45 PM UTC-7, Lynn McGuire wrote:

(snip)

> BTW, the Open Watcom compiler suite is an intermediate language also.
> Watcom is the old Waterloo Fortran compiler. There is a guy trying to
> upgrade it to 64 bit but it is going slow, very slow.
> https://github.com/open-watcom

The WATCOM C compiler, and I believe the Fortran compiler, will generate
large model 32 bit code.

Then all you need is an OS to run it.

On 5/8/2023 8:29 PM, gah4 wrote:
> On Monday, May 8, 2023 at 2:05:45 PM UTC-7, Lynn McGuire wrote:
>
> (snip)
>
>> BTW, the Open Watcom compiler suite is an intermediate language also.
>> Watcom is the old Waterloo Fortran compiler. There is a guy trying to
>> upgrade it to 64 bit but it is going slow, very slow.
>> https://github.com/open-watcom
>
> The WATCOM C compiler, and I believe the Fortran compiler, will generate
> large model 32 bit code.
>
> Then all you need is an OS to run it.

The Watcom Compiler Suite will generate six ??? modes of 16 bit code
(small (compact ?), medium, large, huge, OS/2, Win16), and four modes of
32 bit code (DPMI, Win32 console, Win32 windowed, and OS2). Jiri Malek
is working on the 64 bit code generator, linker, the runtime libraries,
and all of the tools (visual debugger, IDE, etc) for about 3 or 4 years
now.

Lynn

On Monday, May 8, 2023 at 7:30:19 PM UTC-7, Lynn McGuire wrote:
> On 5/8/2023 8:29 PM, gah4 wrote:

(snip)

> > The WATCOM C compiler, and I believe the Fortran compiler, will generate
> > large model 32 bit code.
> > Then all you need is an OS to run it.

> The Watcom Compiler Suite will generate six ??? modes of 16 bit code
> (small (compact ?), medium, large, huge, OS/2, Win16), and four modes of
> 32 bit code (DPMI, Win32 console, Win32 windowed, and OS2). Jiri Malek
> is working on the 64 bit code generator, linker, the runtime libraries,
> and all of the tools (visual debugger, IDE, etc) for about 3 or 4 years
> now.
There are two different questions.

The small, compact, medium, large, and huge are addressing modes,
a compile time option.

Then Win16, OS/2, and some others, are the library routines,
a link time option.

Some 16 bit addressing modes use 16 bit pointers,
others use a segment selector and offset, 32 bit pointers.

The 32 bit compilers can generate small model (32 bit pointers),
or large model, segment selector and offset (48 bit pointers).

As well as I know, OS/2 2.x, the 32 bit versions of OS/2, can run
large model code. Well, they can run large model 16 bit code,
and some of the ability to keep track of segment selectors
stayed in. At least I believe it does, but never tried it.

On Monday, May 8, 2023 at 7:30:19 PM UTC-7, Lynn McGuire wrote:

> The Watcom Compiler Suite will generate six ??? modes of 16 bit code
> (small (compact ?), medium, large, huge, OS/2, Win16), and four modes of
> 32 bit code (DPMI, Win32 console, Win32 windowed, and OS2).

The wlink system directive has 8 options for 16 bit code,
and 29 for 32 bit code.

https://open-watcom.github.io/open-watcom-v2-wikidocs/lguide.pdf

For nt, for example, there is character mode, window mode, and dll.

Not to mention, the different systems that the compilers and linker
themselves can run on.

On 5/8/2023 10:12 PM, gah4 wrote:
> On Monday, May 8, 2023 at 7:30:19 PM UTC-7, Lynn McGuire wrote:
>
>
>> The Watcom Compiler Suite will generate six ??? modes of 16 bit code
>> (small (compact ?), medium, large, huge, OS/2, Win16), and four modes of
>> 32 bit code (DPMI, Win32 console, Win32 windowed, and OS2).
>
> The wlink system directive has 8 options for 16 bit code,
> and 29 for 32 bit code.
>
> https://open-watcom.github.io/open-watcom-v2-wikidocs/lguide.pdf
>
> For nt, for example, there is character mode, window mode, and dll.
>
> Not to mention, the different systems that the compilers and linker
> themselves can run on.

I believe that character mode is called console mode.

I build all three of those NT modes for my calculation engine software.

Lynn