On April last, it was reported that Fortran had returned to the top 20 languages, according to the TIOBE index.
Now, the July report shows that Fortran climbed to the 14th. position: https://www.tiobe.com/tiobe-index/
and still going up; possibly to the 13th. or 12th. position in the next report.
I think this is auspicious news.
What do you think were the causes of this renewed raise on the interest of Fortran?
On April last, it was reported that Fortran had returned to the top 20 languages, according to the TIOBE index.
Now, the July report shows that Fortran climbed to the 14th. position: https://www.tiobe.com/tiobe-index/
and still going up; possibly to the 13th. or 12th. position in the next report.
I think this is auspicious news.
What do you think were the causes of this renewed raise on the interest of Fortran?
..
People start to realize there aren't many languages that have:
1) A language evolution based on steady, backward-compatible changes.
2) An unambiguous language definition, maintained by a standardization committee.
3) A high enough age to be reasonably complete despite the very
slow progress guaranteed by points 1) and 2).
4) A large code base and libraries for most things you need.
5) A compiler included in the public domain gcc compiler suite.
6) An excellent reputation for execution speed.
7) Parallel programming as integrated part of the language.
It is understandable that this took some time to sink in, since some of
these things are a bit paradoxical. Especially the fact that Fortran
is as advanced as it is precisely because it is as old as it is.
But I think the list shows that the TIOBE ranking is well-deserved.
..
I wonder how many of the programmers even know Fortran and understandI wonder how many Fortran programmers know where in the standard "automatic zero initialization" is discussed ?
nuances such as automatic zero initialization ?
Lynn
On 7/7/2021 10:28 AM, Rudi Gaelzer wrote:.
On April last, it was reported that Fortran had returned to the top 20 languages, according to the TIOBE index.
Now, the July report shows that Fortran climbed to the 14th. position: https://www.tiobe.com/tiobe-index/
and still going up; possibly to the 13th. or 12th. position in the next report.
I think this is auspicious news.
What do you think were the causes of this renewed raise on the interest of Fortran?
Lots of very old programs out there are written in F66 or F77.
and their.
mainframes are going away. Time to port to Windows, Linux, or Unix !
I wonder how many of the programmers even know Fortran and understand
nuances such as automatic zero initialization ?
On 21/07/07 5:28 PM, Rudi Gaelzer wrote:.
On April last, it was reported that Fortran had returned to the top 20 languages, according to the TIOBE index.People start to realize there aren't many languages that have:
Now, the July report shows that Fortran climbed to the 14th. position: https://www.tiobe.com/tiobe-index/
and still going up; possibly to the 13th. or 12th. position in the next report.
I think this is auspicious news.
What do you think were the causes of this renewed raise on the interest of Fortran?
1) A language evolution based on steady, backward-compatible changes.
2) An unambiguous language definition, maintained by a standardization committee..
3) A high enough age to be reasonably complete despite the very.
slow progress guaranteed by points 1) and 2).
4) A large code base and libraries for most things you need.
5) A compiler included in the public domain gcc compiler suite.
6) An excellent reputation for execution speed.
7) Parallel programming as integrated part of the language.
It is understandable that this took some time to sink in, since some of
these things are a bit paradoxical. Especially the fact that Fortran
is as advanced as it is precisely because it is as old as it is.
But I think the list shows that the TIOBE ranking is well-deserved.
People start to realize there aren't many languages that have:.
On 21/07/07 5:28 PM, Rudi Gaelzer wrote:
On April last, it was reported that Fortran had returned to the top 20 languages, according to the TIOBE index.
Now, the July report shows that Fortran climbed to the 14th. position: https://www.tiobe.com/tiobe-index/
and still going up; possibly to the 13th. or 12th. position in the next report.
I think this is auspicious news.
What do you think were the causes of this renewed raise on the interest of Fortran?
People start to realize there aren't many languages that have:
1) A language evolution based on steady, backward-compatible changes.
On April last, it was reported that Fortran had returned to the top 20 languages, according to the TIOBE index.
Now, the July report shows that Fortran climbed to the 14th. position: https://www.tiobe.com/tiobe-index/
and still going up; possibly to the 13th. or 12th. position in the next report.
I think this is auspicious news.
What do you think were the causes of this renewed raise on the interest of Fortran?
On Thursday, July 8, 2021 at 7:36:03 AM UTC+10, Jos Bergervoet wrote:
On 21/07/07 5:28 PM, Rudi Gaelzer wrote:.
On April last, it was reported that Fortran had returned to the top 20 languages, according to the TIOBE index.People start to realize there aren't many languages that have:
Now, the July report shows that Fortran climbed to the 14th. position: https://www.tiobe.com/tiobe-index/
and still going up; possibly to the 13th. or 12th. position in the next report.
I think this is auspicious news.
What do you think were the causes of this renewed raise on the interest of Fortran?
1) A language evolution based on steady, backward-compatible changes.
A number of old features are no longer standard and have been deleted
or are due to be deleted.
A number of old "features" that continue to be used, were never standard.
.
2) An unambiguous language definition, maintained by a standardization.
committee.
Ambiguous definitions arise in the case of certain COMPLEX constructs
that are error-prone.
.
The KIND specification is ambiguous, and can catch anyone.
.
3) A high enough age to be reasonably complete despite the very.
slow progress guaranteed by points 1) and 2).
4) A large code base and libraries for most things you need.
5) A compiler included in the public domain gcc compiler suite.
6) An excellent reputation for execution speed.
7) Parallel programming as integrated part of the language.
It is understandable that this took some time to sink in, since some of
these things are a bit paradoxical. Especially the fact that Fortran
is as advanced as it is precisely because it is as old as it is.
But I think the list shows that the TIOBE ranking is well-deserved.
People start to realize there aren't many languages that have:.
One such language is PL/I, which was introduced as an an improved
FORTRAN -- and a vast improvement it was! (and still is).
On Thursday, July 8, 2021 at 6:02:34 AM UTC+10, Lynn McGuire wrote:
I wonder how many Fortran programmers know where in the standard "automatic zero initialization" is discussed ?
I wonder how many of the programmers even know Fortran and understand
nuances such as automatic zero initialization ?
Lynn
It is my impression this is not assumed in the standard, but I must be a Fortran user who doesn't know.
On Thursday, July 8, 2021 at 6:02:34 AM UTC+10, Lynn McGuire wrote:
On 7/7/2021 10:28 AM, Rudi Gaelzer wrote:.
On April last, it was reported that Fortran had returned to the top 20 languages, according to the TIOBE index.
Now, the July report shows that Fortran climbed to the 14th. position: https://www.tiobe.com/tiobe-index/
and still going up; possibly to the 13th. or 12th. position in the next report.
I think this is auspicious news.
What do you think were the causes of this renewed raise on the interest of Fortran?
Lots of very old programs out there are written in F66 or F77.
and FORTRAN IV
.
and their.
mainframes are going away. Time to port to Windows, Linux, or Unix !
I wonder how many of the programmers even know Fortran and understand
nuances such as automatic zero initialization ?
There is no automatic zero initialization.
On 7/7/2021 10:28 AM, Rudi Gaelzer wrote:
On April last, it was reported that Fortran had returned to the top 20Given the manner in which those rankings are computed, I don't believe there's any way to prove any correlation to any real application of
languages, according to the TIOBE index.
Now, the July report shows that Fortran climbed to the 14th. position:
https://www.tiobe.com/tiobe-index/
and still going up; possibly to the 13th. or 12th. position in the
next report.
I think this is auspicious news.
What do you think were the causes of this renewed raise on the
interest of Fortran?
Fortran.
At the level of those numbers; wild fluctuations are possible and mostly
what it "measures" is just random noise.
All Fortran code developed on Univac 1108s or IBM mainframes or using
the Unix F77 compiler had automatic zero initialization as a feature.
Most Fortran programmers never realized that local variables should be initialized until it was too late.
No, automatic zero initialization for local variables was never a part
of the standard. It came into place as the mainframes had multiple
users and would zero initialize memory pages before usage by a program
to keep programs from accessing what was there by a previous user.
Modern cpus put random values, not zeros, into memory pages before usage
now.
Unfortunately, programmers started to assume that local variables did
not require initialization and wrote software accordingly. So Fortran software dating to the 1960s, 1970s, and 1980s will probably have
problems with local variable initialization. YMMV (your mileage may
vary !).
On 21/07/08 6:25 AM, Robin Vowels wrote:.
On Thursday, July 8, 2021 at 7:36:03 AM UTC+10, Jos Bergervoet wrote:
On 21/07/07 5:28 PM, Rudi Gaelzer wrote:.
On April last, it was reported that Fortran had returned to the top 20 languages, according to the TIOBE index.People start to realize there aren't many languages that have:
Now, the July report shows that Fortran climbed to the 14th. position: https://www.tiobe.com/tiobe-index/
and still going up; possibly to the 13th. or 12th. position in the next report.
I think this is auspicious news.
What do you think were the causes of this renewed raise on the interest of Fortran?
1) A language evolution based on steady, backward-compatible changes.
A number of old features are no longer standard and have been deleted
or are due to be deleted.
A number of old "features" that continue to be used, were never standard.
In the first decades of its life, FORTRAN fooled around just like.
those young languages we see around us now! But with age comes responsibility, and that's probably what we're seeing here.
.
2) An unambiguous language definition, maintained by a standardization.
committee.
Ambiguous definitions arise in the case of certain COMPLEX constructs
that are error-prone.
.
The KIND specification is ambiguous, and can catch anyone.
If any ambiguities still pop up then at least an 'interpretation' of.
the rules can be given by the standardization body to resolve the
issue.
.3) A high enough age to be reasonably complete despite the very.
slow progress guaranteed by points 1) and 2).
4) A large code base and libraries for most things you need.
5) A compiler included in the public domain gcc compiler suite.
6) An excellent reputation for execution speed.
7) Parallel programming as integrated part of the language.
It is understandable that this took some time to sink in, since some of
these things are a bit paradoxical. Especially the fact that Fortran
is as advanced as it is precisely because it is as old as it is.
But I think the list shows that the TIOBE ranking is well-deserved.
People start to realize there aren't many languages that have:.
One such language is PL/I, which was introduced as an an improved
FORTRAN -- and a vast improvement it was! (and still is).
But PL/I doesn't have points 4), 5) and 7), to name a few..
On 7/7/2021 11:14 PM, Robin Vowels wrote:.
On Thursday, July 8, 2021 at 6:02:34 AM UTC+10, Lynn McGuire wrote:Fortran IV is Fortran 66.
On 7/7/2021 10:28 AM, Rudi Gaelzer wrote:.
On April last, it was reported that Fortran had returned to the top 20 languages, according to the TIOBE index.
Now, the July report shows that Fortran climbed to the 14th. position: https://www.tiobe.com/tiobe-index/
and still going up; possibly to the 13th. or 12th. position in the next report.
I think this is auspicious news.
What do you think were the causes of this renewed raise on the interest of Fortran?
Lots of very old programs out there are written in F66 or F77.
and FORTRAN IV
.
and their.
mainframes are going away. Time to port to Windows, Linux, or Unix !
I wonder how many of the programmers even know Fortran and understand
nuances such as automatic zero initialization ?
There is no automatic zero initialization.
All Fortran code developed on Univac 1108s or IBM mainframes.
or using.
the Unix F77 compiler had automatic zero initialization as a feature.
Most Fortran programmers never realized that local variables should be initialized until it was too late.
Unfortunately, programmers started to assume that local variables did
not require initialization and wrote software accordingly.
The previous comment about IBM virtual memory reminded me of something
odd. IBM thought that virtual memory was about dividing up the physical memory into smaller address spaces (e.g. for CMS time sharing among
multiple users), while most other vendors used the term to describe
using external disk space in order to run programs that were larger than
the physical memory. From that perspective, those two were almost the opposite meaning.
Nice way to rationalize *whatever* might be going on that simply cannot be understood exactly but which makes Fortran move up the ranking!
This graph at the same ranking site might also be revealing, suggesting whatever is going on might be fleeting:
https://www.tiobe.com/tiobe-index/fortran/
On Friday, July 9, 2021 at 3:38:04 AM UTC+10, Jos Bergervoet wrote:
On 21/07/08 6:25 AM, Robin Vowels wrote:.
On Thursday, July 8, 2021 at 7:36:03 AM UTC+10, Jos Bergervoet wrote:
On 21/07/07 5:28 PM, Rudi Gaelzer wrote:.
On April last, it was reported that Fortran had returned to the top 20 languages, according to the TIOBE index.People start to realize there aren't many languages that have:
Now, the July report shows that Fortran climbed to the 14th. position: https://www.tiobe.com/tiobe-index/
and still going up; possibly to the 13th. or 12th. position in the next report.
I think this is auspicious news.
What do you think were the causes of this renewed raise on the interest of Fortran?
1) A language evolution based on steady, backward-compatible changes.
A number of old features are no longer standard and have been deleted
or are due to be deleted.
A number of old "features" that continue to be used, were never standard.
In the first decades of its life, FORTRAN fooled around just like.
those young languages we see around us now! But with age comes
responsibility, and that's probably what we're seeing here.
.
2) An unambiguous language definition, maintained by a standardization >>>> committee..
Ambiguous definitions arise in the case of certain COMPLEX constructs
that are error-prone.
.
The KIND specification is ambiguous, and can catch anyone.
If any ambiguities still pop up then at least an 'interpretation' of.
the rules can be given by the standardization body to resolve the
issue.
The ambiguities cited (COMPLEX, kind values) cannot be "resolved"
by an "interpretation". Those are deficiencies in the design.
30 years have now elapsed since these design flaws were introduced
and still these flaws have not been fixed.
.
.3) A high enough age to be reasonably complete despite the very.
slow progress guaranteed by points 1) and 2).
4) A large code base and libraries for most things you need.
5) A compiler included in the public domain gcc compiler suite.
6) An excellent reputation for execution speed.
7) Parallel programming as integrated part of the language.
It is understandable that this took some time to sink in, since some of >>>> these things are a bit paradoxical. Especially the fact that Fortran
is as advanced as it is precisely because it is as old as it is.
But I think the list shows that the TIOBE ranking is well-deserved.
People start to realize there aren't many languages that have:.
One such language is PL/I, which was introduced as an an improved
FORTRAN -- and a vast improvement it was! (and still is).
But PL/I doesn't have points 4), 5) and 7), to name a few..
What? You think that PL/I does not lave a large code base and libraries
for most things that you need?
What? You think that PL/I does not have a public domain compiler?
What? You think that PLI has no parallel programming? PL/I has
had this since PL/I-F in 1966.
What else do you think that PL/I does not have?
Well, it does not have ambiguous definitions.
On Thursday, July 8, 2021 at 1:45:01 PM UTC-7, Lynn McGuire wrote:
(snip)
All Fortran code developed on Univac 1108s or IBM mainframes or using
the Unix F77 compiler had automatic zero initialization as a feature.
Most Fortran programmers never realized that local variables should be
initialized until it was too late.
IBM mainframes didn't (and don't) automatically zero initialization, but
it can be done. One I knew (OS/360 days) initialized to X'81'.
It is complicated, though. Such data isn't initialized at all by the compiler,
but left has 'holes' in the object program. Each record (card) of the object program has a start address and length. None cover uninitialized data.
The linkage editor then takes object programs and combines them.
It likes to write out larger records, and so has to fill-in smaller such blocks. Older ones left whatever was in its own memory space.
Later ones would initialize that space.
But larger ones are not written to the load module, but, as with the
object program are left out. In this case, it is whatever is in memory
before load module fetch. Part of that is the initiator that opens
data sets, and otherwise gets things ready, and then reads in the
actual load module records. So this also has to be changed to actually initialize Fortran variables. As noted, it can be done.
That is all before MVS. OS/360 uses only real storage addresses.
OS/VS1 and OS/VS2 use a single virtual address space with all
programs in it. By the time of MVS, it is likely that security
requirements disallowed one program's data from being seen by
others, but not from itself.
But note as above, there are two places that have to be changed.
Even if the OS zeros all pages, it still reads in the load module which
might have already initialized such blocks with whatever is left
over in the linkage editor memory.
Fortran E, G, H, and VS Fortran all used only static allocation.
As well as I know, there is no IBM supplied Fortran 90 or
later compiler for descendants of OS/360.
What? You think that PLI has no parallel programming? PL/I has
had this since PL/I-F in 1966.
How are co-arrays defined and how are the images synchronized? Is that
in the official PL/I language standard?
Fortran E, G, H, and VS Fortran all used only static allocation.
As well as I know, there is no IBM supplied Fortran 90 or
later compiler for descendants of OS/360.
We only ported to the IBM 370 and newer systems. I have no idea what
the IBM 360 system was like.
On 7/8/2021 8:21 PM, gah4 wrote:.
On Thursday, July 8, 2021 at 1:45:01 PM UTC-7, Lynn McGuire wrote:
(snip)
All Fortran code developed on Univac 1108s or IBM mainframes or using
the Unix F77 compiler had automatic zero initialization as a feature.
Most Fortran programmers never realized that local variables should be
initialized until it was too late.
IBM mainframes didn't (and don't) automatically zero initialization, but
it can be done. One I knew (OS/360 days) initialized to X'81'.
It is complicated, though. Such data isn't initialized at all by the compiler,
but left has 'holes' in the object program. Each record (card) of the object
program has a start address and length. None cover uninitialized data.
The linkage editor then takes object programs and combines them.
It likes to write out larger records, and so has to fill-in smaller such blocks. Older ones left whatever was in its own memory space.
Later ones would initialize that space.
But larger ones are not written to the load module, but, as with the
object program are left out. In this case, it is whatever is in memory before load module fetch. Part of that is the initiator that opens
data sets, and otherwise gets things ready, and then reads in the
actual load module records. So this also has to be changed to actually initialize Fortran variables. As noted, it can be done.
That is all before MVS. OS/360 uses only real storage addresses.
OS/VS1 and OS/VS2 use a single virtual address space with all
programs in it. By the time of MVS, it is likely that security
requirements disallowed one program's data from being seen by
others, but not from itself.
But note as above, there are two places that have to be changed.
Even if the OS zeros all pages, it still reads in the load module which might have already initialized such blocks with whatever is left
over in the linkage editor memory.
Fortran E, G, H, and VS Fortran all used only static allocation.
As well as I know, there is no IBM supplied Fortran 90 or
later compiler for descendants of OS/360.
We only ported to the IBM 370 and newer systems. I have no idea what.
the IBM 360 system was like.
On Saturday, July 10, 2021 at 9:20:49 AM UTC+10, Lynn McGuire wrote:
On 7/8/2021 8:21 PM, gah4 wrote:.
On Thursday, July 8, 2021 at 1:45:01 PM UTC-7, Lynn McGuire wrote:
(snip)
All Fortran code developed on Univac 1108s or IBM mainframes or using
the Unix F77 compiler had automatic zero initialization as a feature.
Most Fortran programmers never realized that local variables should be >>>> initialized until it was too late.
IBM mainframes didn't (and don't) automatically zero initialization, but >>> it can be done. One I knew (OS/360 days) initialized to X'81'.
It is complicated, though. Such data isn't initialized at all by the compiler,
but left has 'holes' in the object program. Each record (card) of the object
program has a start address and length. None cover uninitialized data.
The linkage editor then takes object programs and combines them.
It likes to write out larger records, and so has to fill-in smaller such >>> blocks. Older ones left whatever was in its own memory space.
Later ones would initialize that space.
But larger ones are not written to the load module, but, as with the
object program are left out. In this case, it is whatever is in memory
before load module fetch. Part of that is the initiator that opens
data sets, and otherwise gets things ready, and then reads in the
actual load module records. So this also has to be changed to actually
initialize Fortran variables. As noted, it can be done.
That is all before MVS. OS/360 uses only real storage addresses.
OS/VS1 and OS/VS2 use a single virtual address space with all
programs in it. By the time of MVS, it is likely that security
requirements disallowed one program's data from being seen by
others, but not from itself.
But note as above, there are two places that have to be changed.
Even if the OS zeros all pages, it still reads in the load module which
might have already initialized such blocks with whatever is left
over in the linkage editor memory.
Fortran E, G, H, and VS Fortran all used only static allocation.
As well as I know, there is no IBM supplied Fortran 90 or
later compiler for descendants of OS/360.
We only ported to the IBM 370 and newer systems. I have no idea what.
the IBM 360 system was like.
Like the /370, only slower.
We had considerable problems porting to the IBM 370. It was our first 8
bit machine. Before, we developed on the Univac 1108 (36 bit) and
ported to the CDC 7600 (60 bit), both 6 bit machines. Since the Univac
1108 supported six characters per word, we had assumed that would work everywhere. We had to rewrite all of our statements storing 6HXXXXXX
into an integer to storing 4HXXXX and 2HXX in two integers. Quite painful.
On Friday, July 9, 2021 at 11:00:27 PM UTC-7, Lynn McGuire wrote:.
(snip)
We had considerable problems porting to the IBM 370. It was our first 8I was last week working with Spice 2g6, the last of the Fortran Spice programs.
bit machine. Before, we developed on the Univac 1108 (36 bit) and
ported to the CDC 7600 (60 bit), both 6 bit machines. Since the Univac
1108 supported six characters per word, we had assumed that would work everywhere. We had to rewrite all of our statements storing 6HXXXXXX
into an integer to storing 4HXXXX and 2HXX in two integers. Quite painful.
I believe it was most often run on VAX 40 or so years ago.
It uses double precision for most of its data (except COMPLEX), and the double
precision includes character data of up to 8 characters. (All names are only significant to the first 8 characters.)
That is a little tricky, as not all machines accurately compare floating point
data with characters in them. In most places, it just compares them, but
in some it uses a subroutine to do the comparison. The subroutine in
the version I have just compares them, but it could be replaced with a fancier one.
There is also a subroutine to copy characters from one to another, which (usually) has double precision arguments, but the dummy variables
are arrays of bytes. It would have used LOGICAL*1 for the IBM/370 version, and maybe BYTE for the VAX version, but seems to work with INTEGER(1)
on gfortran. It might be that I am the first to compile it in 28 years.
I believe that the IBM/370 can reliably compare character data in REAL*8 variables.
Also, S/370 doesn't normalize on assignment, which would.
destroy character data. Spice has many 8H constants. For S/370 and VAX,
you could even use COMPLEX*16 for 16 characters.
One that I haven't figure out yet, gfortran allows initializing double precision
variables with 8H constants, but not apostrophe delimited constants.
On Friday, July 9, 2021 at 3:42:04 AM UTC-7, Jos Bergervoet wrote:
(snip, someone wrote)
What? You think that PLI has no parallel programming? PL/I has
had this since PL/I-F in 1966.
How are co-arrays defined and how are the images synchronized? Is that
in the official PL/I language standard?
PL/I has multitasking. Not quite the same as multithreading.
The usual use would be to start a subtask, and then some time later WAIT (that is the statement) for it to finish. There are EVENT variables, which correspond to OS/360 ECBs (event control blocks).
I believe this is usually described as coarse grain multitasking, as
opposed to the fine grain of multithreading.
Maybe more obvious, it is also used for asynchronous I/O, which I believe Fortran now has.
Among others, PL/I compilers generate not only reentrant routines
that can be used for recursion, but also reentrant for multiple tasks
at the same time. Among others, it complicates I/O, where different
tasks have different I/O streams from the same code.
One that I haven't figure out yet, gfortran allows initializing double precision
variables with 8H constants, but not apostrophe delimited constants.
Is this something important?, since for 40+ years, FORTRAN has had
CHARACTER variables.
On Friday, July 9, 2021 at 11:00:27 PM UTC-7, Lynn McGuire wrote:
(snip)
We had considerable problems porting to the IBM 370. It was our first 8
bit machine. Before, we developed on the Univac 1108 (36 bit) and
ported to the CDC 7600 (60 bit), both 6 bit machines. Since the Univac
1108 supported six characters per word, we had assumed that would work
everywhere. We had to rewrite all of our statements storing 6HXXXXXX
into an integer to storing 4HXXXX and 2HXX in two integers. Quite painful.
I was last week working with Spice 2g6, the last of the Fortran Spice programs.
I believe it was most often run on VAX 40 or so years ago.
It uses double precision for most of its data (except COMPLEX), and the double
precision includes character data of up to 8 characters. (All names are only significant to the first 8 characters.)
That is a little tricky, as not all machines accurately compare floating point
data with characters in them. In most places, it just compares them, but
in some it uses a subroutine to do the comparison. The subroutine in
the version I have just compares them, but it could be replaced with a fancier one.
There is also a subroutine to copy characters from one to another, which (usually) has double precision arguments, but the dummy variables
are arrays of bytes. It would have used LOGICAL*1 for the IBM/370 version, and maybe BYTE for the VAX version, but seems to work with INTEGER(1)
on gfortran. It might be that I am the first to compile it in 28 years.
I believe that the IBM/370 can reliably compare character data in REAL*8 variables. Also, S/370 doesn't normalize on assignment, which would
destroy character data. Spice has many 8H constants. For S/370 and VAX,
you could even use COMPLEX*16 for 16 characters.
One that I haven't figure out yet, gfortran allows initializing double precision
variables with 8H constants, but not apostrophe delimited constants.
There was no double precision or character data in 1975 when we did our
first port to the IBM 370.
On Saturday, July 10, 2021 at 2:03:42 PM UTC-7, Lynn McGuire wrote:
(snip)
There was no double precision or character data in 1975 when we did our
first port to the IBM 370.
CHARACTER didn't come until Fortran 77, or VS Fortran for the 370.
But double precision, including its use for A8 format and Hollerith constants goes back to sometime in the Fortran II days, and definitely in all the 360 and 370 compilers. Many programs written for single precision on 36 but predecessors, needed double precision for S/360.
A small number of systems would normalize, or otherwise change the value
of floating point variables, but S/370 is fine. COMPLEX works, too.
If you want to play with the bits, shift and mask them, then it is harder.
As above, Spice uses a subroutine to do all the moving of characters,
which could be in assembly if it can't be done in Fortran. But on S/370
it can be done with LOGICAL*1 and EQUIVALENCE.
Spice does all the comparisons in double precision. For individual characters, it fills a variable with blanks (from an H constant), replaces the leftmost characters (with a subroutine) and the compares to
an H constant. Doing the move in one subroutine localizes the
machine dependence to one place.
On Saturday, July 10, 2021 at 3:44:45 AM UTC-7, Robin Vowels wrote:I am puzzled why you have held onto storing character data in non-character variables or arrays for so long. Is this a personal challenge?
(snip, I wrote)
And some programs are older than that.One that I haven't figure out yet, gfortran allows initializing double precisionIs this something important?, since for 40+ years, FORTRAN has had CHARACTER variables.
variables with 8H constants, but not apostrophe delimited constants.
Spice2 is 1975, following Spice1 earlier.
As well as I know, descendants of ECAP originally written
in Fortran II.
The ECAP that I have came from an IBM 1130, which uses a subset
version of Fortran IV. No logical variables or logical IF. Only five character
variable names. It seems that they took all the six character names
(from an earlier compiler), removed the middle two letters and replaced
them with Z. There are some WRITE statement that give the name of the variable that they are writing out. I believe it goes back to about 1963.
For ECAP, all language keywords are recognized by only the first two characters, and most programs abbreviate them.
On 7/10/2021 3:29 AM, gah4 wrote:.
On Friday, July 9, 2021 at 11:00:27 PM UTC-7, Lynn McGuire wrote:
(snip)
We had considerable problems porting to the IBM 370. It was our first 8
bit machine. Before, we developed on the Univac 1108 (36 bit) and
ported to the CDC 7600 (60 bit), both 6 bit machines. Since the Univac
1108 supported six characters per word, we had assumed that would work
everywhere. We had to rewrite all of our statements storing 6HXXXXXX
into an integer to storing 4HXXXX and 2HXX in two integers. Quite painful.
I was last week working with Spice 2g6, the last of the Fortran Spice programs.
I believe it was most often run on VAX 40 or so years ago.
It uses double precision for most of its data (except COMPLEX), and the double
precision includes character data of up to 8 characters. (All names are only
significant to the first 8 characters.)
That is a little tricky, as not all machines accurately compare floating point
data with characters in them. In most places, it just compares them, but
in some it uses a subroutine to do the comparison. The subroutine in
the version I have just compares them, but it could be replaced with a fancier one.
There is also a subroutine to copy characters from one to another, which (usually) has double precision arguments, but the dummy variables
are arrays of bytes. It would have used LOGICAL*1 for the IBM/370 version, and maybe BYTE for the VAX version, but seems to work with INTEGER(1)
on gfortran. It might be that I am the first to compile it in 28 years.
I believe that the IBM/370 can reliably compare character data in REAL*8 variables. Also, S/370 doesn't normalize on assignment, which would
destroy character data. Spice has many 8H constants. For S/370 and VAX,
you could even use COMPLEX*16 for 16 characters.
One that I haven't figure out yet, gfortran allows initializing double precision
variables with 8H constants, but not apostrophe delimited constants.
There was no double precision or character data in 1975 when we did our.
first port to the IBM 370.
On Saturday, July 10, 2021 at 2:03:42 PM UTC-7, Lynn McGuire wrote:
(snip)
There was no double precision or character data in 1975 when we did our
first port to the IBM 370.
CHARACTER didn't come until Fortran 77, or VS Fortran for the 370.
But double precision, including its use for A8 format and Hollerith constants goes back to sometime in the Fortran II days, and definitely in all the 360 and 370 compilers. Many programs written for single precision on 36 but predecessors, needed double precision for S/360.
On Sunday, July 11, 2021 at 5:35:36 AM UTC+10, gah4 wrote:
On Saturday, July 10, 2021 at 3:44:45 AM UTC-7, Robin Vowels wrote:I am puzzled why you have held onto storing character data in non-character variables or arrays for so long. Is this a personal challenge?
(snip, I wrote)
And some programs are older than that.One that I haven't figure out yet, gfortran allows initializing double precisionIs this something important?, since for 40+ years, FORTRAN has had
variables with 8H constants, but not apostrophe delimited constants.
CHARACTER variables.
Spice2 is 1975, following Spice1 earlier.
As well as I know, descendants of ECAP originally written
in Fortran II.
The ECAP that I have came from an IBM 1130, which uses a subset
version of Fortran IV. No logical variables or logical IF. Only five character
variable names. It seems that they took all the six character names
(from an earlier compiler), removed the middle two letters and replaced
them with Z. There are some WRITE statement that give the name of the
variable that they are writing out. I believe it goes back to about 1963.
For ECAP, all language keywords are recognized by only the first two
characters, and most programs abbreviate them.
In the early 80's I converted a number of pre-F77 Fortran codes for both character and generic intrinsics.
Plan out the changes by defining new data structures and they became fairly easy to implement and test.
Now, with F90's ALLOCATE and derived types, this task is never difficult and the sooner these data structures were more clearly described, the easier it was for further development.
The most annoying part of this update was the lack of documentation of the compiler and hardware architecture used for initial development.
Many programs were moved between CDC and Vax/Pr1me and then later onto Apollo/Sun and PC. Now, for me at Ryzen it has been quite a journey.
Back to the OP, my focus in recent years has been OpenMP, which provides significant gains. Fortran does this very well here but outside the standard. Does this feature in the TIOBE space?
If so, I am not sure that the Univac 1108 and CDC 7600 supported double precision.
If so, I am not sure that the Univac 1108 and CDC 7600 supported double precision. Of course, we moved to a Prime 450 (32 bit single precision)
in 1978 for our development.
On Sunday, July 11, 2021 at 7:03:42 AM UTC+10, Lynn McGuire wrote:We could not use it anyway. We were at the linker limit on the Univac
On 7/10/2021 3:29 AM, gah4 wrote:.
On Friday, July 9, 2021 at 11:00:27 PM UTC-7, Lynn McGuire wrote:
(snip)
We had considerable problems porting to the IBM 370. It was our first 8 >>>> bit machine. Before, we developed on the Univac 1108 (36 bit) andI was last week working with Spice 2g6, the last of the Fortran Spice programs.
ported to the CDC 7600 (60 bit), both 6 bit machines. Since the Univac >>>> 1108 supported six characters per word, we had assumed that would work >>>> everywhere. We had to rewrite all of our statements storing 6HXXXXXX
into an integer to storing 4HXXXX and 2HXX in two integers. Quite painful. >>>
I believe it was most often run on VAX 40 or so years ago.
It uses double precision for most of its data (except COMPLEX), and the double
precision includes character data of up to 8 characters. (All names are only
significant to the first 8 characters.)
That is a little tricky, as not all machines accurately compare floating point
data with characters in them. In most places, it just compares them, but >>> in some it uses a subroutine to do the comparison. The subroutine in
the version I have just compares them, but it could be replaced with a
fancier one.
There is also a subroutine to copy characters from one to another, which >>> (usually) has double precision arguments, but the dummy variables
are arrays of bytes. It would have used LOGICAL*1 for the IBM/370 version, >>> and maybe BYTE for the VAX version, but seems to work with INTEGER(1)
on gfortran. It might be that I am the first to compile it in 28 years.
I believe that the IBM/370 can reliably compare character data in REAL*8 >>> variables. Also, S/370 doesn't normalize on assignment, which would
destroy character data. Spice has many 8H constants. For S/370 and VAX,
you could even use COMPLEX*16 for 16 characters.
One that I haven't figure out yet, gfortran allows initializing double precision
variables with 8H constants, but not apostrophe delimited constants.
There was no double precision or character data in 1975 when we did our.
first port to the IBM 370.
DOUBLE PRECISION has been available on IBM mainframes since
at least the IBM 360, and was therefore available on the IBM 370
On Saturday, July 10, 2021 at 5:18:44 PM UTC-7, Lynn McGuire wrote:
(snip)
If so, I am not sure that the Univac 1108 and CDC 7600 supported double
precision. Of course, we moved to a Prime 450 (32 bit single precision)
in 1978 for our development.
The standard required it, so everyone had it. But sometimes in software,
and much slower than single precision hardware.
That was especially true for CDC, where 60 bits was more like other's
double precision.
DEC had two forms for the PDP-10, one in software for the KA-10,
and a different one in hardware for later models.
CDC 60-bit floating-point was 1 sign bit and an 11-bit exponent
including bias, with a 48-bit bit-normalized mantissa.
The CDC 6000/7000 instruction set included double precision instructions
for addition, subtraction, and multiplication. They operated on 60-bit quantities, just as single precision numbers.
Double precision numbers were just two single precision numbers
back-to-back, with the second exponent being essentially redundant. It
was a waste of 12 bits, but you still got 96 bits of precision.
On Sunday, July 11, 2021 at 2:56:35 PM UTC-7, dpb wrote:.
(snip)
CDC 60-bit floating-point was 1 sign bit and an 11-bit exponentI thought CDC was one where if the value is an integer in the appropriate range, it stores it unnormalized, and with zero exponent, such that it has the integer value. Saves the need for separate integer instructions.
including bias, with a 48-bit bit-normalized mantissa.
The CDC 6000/7000 instruction set included double precision instructions for addition, subtraction, and multiplication. They operated on 60-bit quantities, just as single precision numbers.
Double precision numbers were just two single precision numbers back-to-back, with the second exponent being essentially redundant. ItYes, that is what IBM S/370 does with extended (quad) precision.
was a waste of 12 bits, but you still got 96 bits of precision.
It makes it easier to do in software.
60-bit integers are 60-bit integers.
All 60 bits of an integer were used for storing an integer.
Where the machine was deficient was in an integer multiply instruction.
If the floating-point multiply instruction saw that the upper 12 bits
as being zero or all ones, it did an integer multiplication,
otherwise it did a floating-point multiplication.
So, if an integer drifted into the high 12 bits, "Integer multiply"
gave garbage.
On Sunday, July 11, 2021 at 7:47:09 PM UTC-7, Robin Vowels wrote:.
(snip)
60-bit integers are 60-bit integers.
All 60 bits of an integer were used for storing an integer.
Where the machine was deficient was in an integer multiply instruction.
If the floating-point multiply instruction saw that the upper 12 bits
as being zero or all ones, it did an integer multiplication,
otherwise it did a floating-point multiplication.
So, if an integer drifted into the high 12 bits, "Integer multiply"
gave garbage.
I believe that isn't the right description for what it does..
But yes, there are 60 bit integer add/subtract.
When it normalizes numbers, it prefers an exponent of zero, and the binary point to the right of the LSB. It doesn't "check" for an integer,
but it happens
naturally with the floating point format. And if a floating point multiply gives
an integer result that fits in the 48 bits, it will give the right integer result.
And if integer multiply is too big, then it gives the proper floating point result.
On Sunday, July 11, 2021 at 7:47:09 PM UTC-7, Robin Vowels wrote:.
(snip)
60-bit integers are 60-bit integers.
All 60 bits of an integer were used for storing an integer.
Where the machine was deficient was in an integer multiply instruction.
If the floating-point multiply instruction saw that the upper 12 bits
as being zero or all ones, it did an integer multiplication,
otherwise it did a floating-point multiplication.
So, if an integer drifted into the high 12 bits, "Integer multiply"
gave garbage..
I believe that isn't the right description for what it does..
But yes, there are 60 bit integer add/subtract.
When it normalizes numbers, it prefers an exponent of zero, and the binary point to the right of the LSB. It doesn't "check" for an integer, but it happens
naturally with the floating point format. And if a floating point multiply gives
an integer result that fits in the 48 bits, it will give the right integer result.
And if integer multiply is too big, then it gives the proper floating point result.
The manual explicitly states that the Integer Multiply instruction (IM) checks for zero (+ or -, i.e. all zeors or all ones) in the upper 12 bits
of both 60-bit operands. It then performs an integer multiply. The instruction
op code is the same as the floating-point multiply instruction, and the operation is performed by the floating-point hardware.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 159 |
| Nodes: | 16 (0 / 16) |
| Uptime: | 99:32:49 |
| Calls: | 3,209 |
| Files: | 10,563 |
| Messages: | 3,009,786 |