Home > Archive > Fortran > February 2005 > Tom Lahey's Fortran experiences
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Tom Lahey's Fortran experiences
|
|
| beliavsky@aol.com 2005-02-17, 8:58 pm |
| The following interesting letter by Tom Lahey of Lahey Computer
Systems describes his experiences with Fortran compilers. It's taken
from the Winter 2005 issue of Fortran Source at
http://www.lahey.com/nl05jan.pdf (which grants permission to reprint).
Did he really implement a Fortran 77 compiler in *1975* ? We should
have had F2003 compilers 4 years ago :).
---------------------------------------------------------------------
Dear Fortran Programmers,
64 bits! Can you believe it! I can, but only with a little bit of awe.
Motherboards, PC's, and software are available today. As you have seen
on page 1, Lahey is offering a 64-bit Linux Fortran Language System
that we have validated by running our test suite of 8,000 tests.
September 1957. I was born as a programmer when I learned to program
ILLIAC I at the University of Illinois. ILLIAC I, a vacuum tube
computer, had 1,024 40-bit words (2 instructions/word), Williams
memory, a drum, and paper tape i/o. Floating-point was implemented via
software and you had to have permission to use it!
April 1959. GE Computer Dept, Tempe, AZ. Fellow employee, Marcia
Mooney taught me FORTRAN. (IF( SENSE LIGHT n), IF( SENSE SWITCH n),
....) From this point on, Fortran and I became best friends.
November 1975. I began receiving royalties for the first FORTRAN 77
implemented anywhere. I implemented the language system on the 36-bit
Honeywell-Bull 636 using the DTSS operating system. After working as a
programmer for 16 years, I thought I was semi-retired, destined to
cash royalty checks for the rest of my life. This delusion existed in
spite of appreciating 16 years of computer evolution and knowing that
today's technology is done in by tomorrow's evolution.
In 1981, maybe 1980. I installed an 8080 in an office I had built in
our garage. The 8080 was an 8-bit chip using CPM and could address 64K
memory (I am concerned about remembering dates and size correctly). I
experimented and decided that I couldn't fit a meaningful FORTRAN 77
compiler in that much memory. Also, there was no hardware
floating-point. I didn't pursue the project. However, the 8080 was a
wake up call; I realized my semi-retirement was over.
1982. IBM brings the 8086 PC to market. I ordered 2 clones, one for
me, one for Bruce Bush. I implemented the compiler and wrote the
language manual; Bruce was responsible for the runtime package; Kory
Hamzeh, a senior at Rolling Hills High School, Palos Verdes, CA,
programmed the intrinsic functions. Guy Ceragioli, Marketing & Sales,
plus Karen May worked at all the detail for making it all happen.
Lahey licensed the first language system to Bill Brackett during
September 1984.
1987. True story. After I gave a talk somewhere in Nova Scotia, a
programmer told me about his migration to the 286. Before the 286, he
paid for execution time on a Cray at overnight rates. He purchased a
286 system with extended memory and ran the same jobs overnight!
Everything was the same except his costs.
1988. Lahey brought to market F77L-EM/32 for Intel's 386. The 386 was
the first chip that allowed all mainframe programs to be ported to the
PC. Ok, execution speed needed to be improved.
My point in this review of the past. Look how far we've come. From the
Fortran point-of-view, I do not see a 128-bit chip (I've been wrong
before); database applications may create a demand. When? Plot the
points on a graph and you can tell me.
Keep up the good work,
Tom
P.S. I should have pursued a FORTRAN 77 on the 8080. Even if I hadn't
finished, it would have served as the basis for F77L and we would have
been to market earlier.
| |
| Walt Brainerd 2005-02-18, 8:57 pm |
| beliavsky@aol.com wrote:
> The following interesting letter by Tom Lahey of Lahey Computer
> Systems describes his experiences with Fortran compilers. It's taken
> from the Winter 2005 issue of Fortran Source at
> http://www.lahey.com/nl05jan.pdf (which grants permission to reprint).
> Did he really implement a Fortran 77 compiler in *1975* ? We should
> have had F2003 compilers 4 years ago :).
>
<snip>
Of course, I can't vouch for any royalty checks, but
during the last phases of development of Fortran 77,
if an X3J3 vote changed something, he was out of the
room and on the phone to somebody immediately.
--
Walt Brainerd +1-877-355-6640 (voice & fax)
The Fortran Company +1-520-760-1397 (outside USA)
6025 N. Wilmot Road walt@fortran.com
Tucson, AZ 85750 USA http://www.fortran.com
| |
| Jeff Ryman 2005-02-19, 3:57 am |
| On 17 Feb 2005 13:46:05 -0800, beliavsky@aol.com wrote:
>The following interesting letter by Tom Lahey of Lahey Computer
>Systems describes his experiences with Fortran compilers. It's taken
>from the Winter 2005 issue of Fortran Source at
>http://www.lahey.com/nl05jan.pdf (which grants permission to reprint).
>Did he really implement a Fortran 77 compiler in *1975* ? We should
>have had F2003 compilers 4 years ago :).
>
>---------------------------------------------------------------------
>
[snip]
Tom is certainly an interesting person in the history of Fortran. A
number of years ago, I had the pleasure of taking a class from him on
converting from Fortran 77 to Fortran 9x. In addition to the good
instruction about learning Fortran 9x, he had some interesting stories
to tell about his personal involvement with Fortran compilers.
IIRC, he worked for a company that produced, or helped to produce, the
IBM Fortran G and H compilers. When that company folded, he bought
the rights to the unpublished language used to develop the compilers,
and used it or a derivative to produce the first Lahey compilers for
PCs.
Hope my memory is not faulty. At any rate, he is a very
knowledgeable and entertaining instructor, as well as a significant
contributor to Fortran.
Jeff Ryman
email: rymanjc_at_
excite_dot_com
| |
|
| On Fri, 18 Feb 2005 19:14:49 -0800, Jeff Ryman
<see_address@signature.com> wrote:
>On 17 Feb 2005 13:46:05 -0800, beliavsky@aol.com wrote:
>
>[snip]
>Tom is certainly an interesting person in the history of Fortran. A
>number of years ago, I had the pleasure of taking a class from him on
>converting from Fortran 77 to Fortran 9x. In addition to the good
>instruction about learning Fortran 9x, he had some interesting stories
>to tell about his personal involvement with Fortran compilers.
>
>IIRC, he worked for a company that produced, or helped to produce, the
>IBM Fortran G and H compilers. When that company folded, he bought
>the rights to the unpublished language used to develop the compilers,
>and used it or a derivative to produce the first Lahey compilers for
>PCs.
>
It wasn't the same company that produced the G and H compilers.
What company are you talking about that produced the G compiler?
The H compiler was produced by IBM and I don't believe Lahey worked
for them.
>Hope my memory is not faulty. At any rate, he is a very
>knowledgeable and entertaining instructor, as well as a significant
>contributor to Fortran.
>Jeff Ryman
>email: rymanjc_at_
> excite_dot_com
| |
| Michael Metcalf 2005-02-19, 8:56 am |
|
"john" <z2345678998765432y@sbcglobal.net> wrote in message
news:clcd115gd6u2m6q4f4i8kf5j2bl9tufi09@
4ax.com...
>
> It wasn't the same company that produced the G and H compilers.
>
> What company are you talking about that produced the G compiler?
>
> The H compiler was produced by IBM and I don't believe Lahey worked
> for them.
Correct. The H compiler was around 1969 (Lowrey and Medlock), the G and G1
later, and the H extended Optimization Enhanced, or Q, around 1980
(Scarborough and Kolsky) (see also "Fortran Optimization", 1982, 1986,
Section 8.1).
Regards,
Mike Metcalf
P.S. I remember my first encounter with Tom, at the Mt. Kisco meeting of
X3J3 in June 1987. I presented a proposal for an 'unchecked assignment'
(variable =: expression), that later became the TRANSFER function. My
proposal was shot down during a long and sometimes acrimonious debate. At
FIDS that evening Tom told me his heart would never allow him to become a
member of the committee as it wouldn't stand the sort of treatment that
'poor guy' (me) had got that afternoon. Notwithstanding that remark, he went
on to become a valuable and faithful member of both X3J3 and WG5.
| |
| Herman D. Knoble 2005-02-21, 4:01 pm |
| On Fri, 18 Feb 2005 19:14:49 -0800, Jeff Ryman <see_address@signature.com> wrote:
-|On 17 Feb 2005 13:46:05 -0800, beliavsky@aol.com wrote:
-|
-|>The following interesting letter by Tom Lahey of Lahey Computer
-|>Systems describes his experiences with Fortran compilers. It's taken
-|>from the Winter 2005 issue of Fortran Source at
-|>http://www.lahey.com/nl05jan.pdf (which grants permission to reprint).
-|>Did he really implement a Fortran 77 compiler in *1975* ? We should
-|>have had F2003 compilers 4 years ago :).
Tom Lahey is indeed a gifted teacher/leader in the field. (The name
"Tom" is interesting too - like Tom Aird, co-founder of IMSL (Now Visual
Numerics) was also a gifted leader/teacher in the field.
I was disappointd though to find out that Lahey Fortran is offering
the PathScale compiler for 64-bit platforms instead of LF95 itself.
I can understand the business choice here. And the PathScale compiler is
quite powerful and stable. PathScale is stressing performance. But
the PathScale Compiler does not (yet) have near the debug capability
that LF95 has. I view the lack of Lahey/Salford comprehensive run-time diagnostics
as a compromise in program development integrity. We humans need everything
we can get! Especially with existing modified code that has modifications
of modifications, so to speak. I hope PathScale is listening, because
a compiler can have option driven good run-time diagnostics and good
performance:-)
-|>
-|>---------------------------------------------------------------------
-|>
-|[snip]
-|Tom is certainly an interesting person in the history of Fortran. A
-|number of years ago, I had the pleasure of taking a class from him on
-|converting from Fortran 77 to Fortran 9x. In addition to the good
-|instruction about learning Fortran 9x, he had some interesting stories
-|to tell about his personal involvement with Fortran compilers.
-|
-|IIRC, he worked for a company that produced, or helped to produce, the
-|IBM Fortran G and H compilers. When that company folded, he bought
-|the rights to the unpublished language used to develop the compilers,
....
Was this unpublished work the XPL compiler-compiler?
Probably not since XPL was in fact published:
XPL Compiler-Compiler by McKeeman, Horning and Wortman,
published by Prentice-Hall, 1970, ISBN 13-155077-2.
As a matter of interest:
http://compilers.iecc.com/comparch/article/96-07-072
offers a version of XPL for Intel 486!
Skip Knoble
....
-|Jeff Ryman
-|email: rymanjc_at_
-| excite_dot_com
| |
| Gordon Sande 2005-02-21, 4:01 pm |
|
Herman D. Knoble wrote:
> On Fri, 18 Feb 2005 19:14:49 -0800, Jeff Ryman <see_address@signature.com> wrote:
>
> -|On 17 Feb 2005 13:46:05 -0800, beliavsky@aol.com wrote:
> -|
> -|>The following interesting letter by Tom Lahey of Lahey Computer
> -|>Systems describes his experiences with Fortran compilers. It's taken
> -|>from the Winter 2005 issue of Fortran Source at
> -|>http://www.lahey.com/nl05jan.pdf (which grants permission to reprint).
> -|>Did he really implement a Fortran 77 compiler in *1975* ? We should
> -|>have had F2003 compilers 4 years ago :).
>
> Tom Lahey is indeed a gifted teacher/leader in the field. (The name
> "Tom" is interesting too - like Tom Aird, co-founder of IMSL (Now Visual
> Numerics) was also a gifted leader/teacher in the field.
>
> I was disappointd though to find out that Lahey Fortran is offering
> the PathScale compiler for 64-bit platforms instead of LF95 itself.
> I can understand the business choice here. And the PathScale compiler is
> quite powerful and stable. PathScale is stressing performance. But
> the PathScale Compiler does not (yet) have near the debug capability
> that LF95 has. I view the lack of Lahey/Salford comprehensive run-time diagnostics
> as a compromise in program development integrity. We humans need everything
> we can get! Especially with existing modified code that has modifications
> of modifications, so to speak. I hope PathScale is listening, because
> a compiler can have option driven good run-time diagnostics and good
> performance:-)
At this point one has the impression that Lahey is the (re)tail on the
Lahey/Fujitsu dog. If Fujitsu does not have any interest in AMD64 then
it would be hard for Lahey to offer it. So they must have looked about
for some other OEM source of retail product.
Pure speculation as someone who has their product and reads the ads.
The undefined variable checking of the L/F combo is a great feature
on a compiler that produced pretty good code under optimization. All
too often it is either good debugging like the student oriented WatFor
or Salford or the chip vendor sponsored SPECMark achievement goals
with even good line numbers for errors a bit rare.
> -|>
> -|>---------------------------------------------------------------------
> -|>
> -|[snip]
> -|Tom is certainly an interesting person in the history of Fortran. A
> -|number of years ago, I had the pleasure of taking a class from him on
> -|converting from Fortran 77 to Fortran 9x. In addition to the good
> -|instruction about learning Fortran 9x, he had some interesting stories
> -|to tell about his personal involvement with Fortran compilers.
> -|
> -|IIRC, he worked for a company that produced, or helped to produce, the
> -|IBM Fortran G and H compilers. When that company folded, he bought
> -|the rights to the unpublished language used to develop the compilers,
> ....
> Was this unpublished work the XPL compiler-compiler?
> Probably not since XPL was in fact published:
> XPL Compiler-Compiler by McKeeman, Horning and Wortman,
> published by Prentice-Hall, 1970, ISBN 13-155077-2.
> As a matter of interest:
> http://compilers.iecc.com/comparch/article/96-07-072
> offers a version of XPL for Intel 486!
I recall something like "DynaSoft" as the vendor who did Fortran G.
They also had a contract to produce a PL/I for a customer who pulled
the plug for the usual reasons (if I believe the stories). But their
advertising agency was not told so that the back cover of CACM had
an ad saying "Ask the man who owns one" as puffery for the PL/I
when it had already been canceled for excessive under delivery. Oops!
> Skip Knoble
>
> ....
> -|Jeff Ryman
> -|email: rymanjc_at_
> -| excite_dot_com
>
| |
| Jeff Ryman 2005-02-21, 4:01 pm |
| On Sat, 19 Feb 2005 03:34:00 GMT, john
<z2345678998765432y@sbcglobal.net> wrote:
[color=darkred]
>On Fri, 18 Feb 2005 19:14:49 -0800, Jeff Ryman
><see_address@signature.com> wrote:
>
>
>It wasn't the same company that produced the G and H compilers.
>
>What company are you talking about that produced the G compiler?
>
>The H compiler was produced by IBM and I don't believe Lahey worked
>for them.
>
>
>
>
>
My memory is apparently faulty. It has been several years since the
class.
Jeff Ryman
email: rymanjc_at_
excite_dot_com
| |
| Tim Prince 2005-02-21, 8:59 pm |
|
"Gordon Sande" <g.sande@worldnet.att.net> wrote in message
news:%6pSd.7750$9a3.3177@edtnps91...
>
>
> At this point one has the impression that Lahey is the (re)tail on the
> Lahey/Fujitsu dog. If Fujitsu does not have any interest in AMD64 then
> it would be hard for Lahey to offer it. So they must have looked about
> for some other OEM source of retail product.
>
It wouldn't be accurate to say Fujitsu has no interest in the x86-64 OS.
Maybe you mean interest in producing another Fortran, with at least 4
already available.
| |
| Gordon Sande 2005-02-21, 8:59 pm |
|
Tim Prince wrote:
> "Gordon Sande" <g.sande@worldnet.att.net> wrote in message
> news:%6pSd.7750$9a3.3177@edtnps91...
>
>
> It wouldn't be accurate to say Fujitsu has no interest in the x86-64 OS.
> Maybe you mean interest in producing another Fortran, with at least 4
> already available.
>
>
The longer form would be that if Fujitsu has no interest in retargeting
their compiler to something that Lahey is providing retail service for
then it would hard for Lahey to offer such (a nonexistent) product.
If I have it right, Fujitsu has several languages on several platforms
so one can only guess that they have to choose where to spend their
effort. They certainly cover the whole waterfront with Amdahl through
Sparc to x86 so one would expect to see the x86-64 somewhere. They may
ask Lahey for input but one expects any decisions would be made by
Fujitsu.
I have a vague recollection of seeing the Fujitsu Fortran for Win32
"available" for some time before the Lahey/Fujitsu combination was
announced. The impression then was that it may have been a product
produced to fill out the requirements of a different part of the
corporation. The limited advertising material suggested a mix of good
main frame practice with rather limited tailoring to the foibles of
personal microcomputers. As a user the Lahey/Fujitsu combination looked
like the best of both vendors and I find it a nice product. But I
expect that any extensions or follow ons have more to do with Fujitsu
than Lahey so it is a bit unfair to blame Lahey for any delays or
absences.
You are right to point out that my statement was overly abbreviated.
| |
| Greg Lindahl 2005-02-21, 8:59 pm |
| In article <2n3k1117hvp4o63ehlhna6km6htrm3g1qq@4ax.com>,
Herman D. Knoble <SkipKnobleLESS at SPAMpsu dot edu> wrote:
> But the PathScale Compiler does not (yet) have near the debug
> capability that LF95 has.
This is very true. The reason PathScale hasn't worked on such features
is that we couldn't find enough customer interest to justify spending
a fair bit of time on it. If there are any potential customers out
there who would buy our compiler if we had great debugging features,
please drop me an email.
The Lahey folks do think this is important to their existing
customers, so it may well be the case that they'll eventually work on
adding such features. Their test suite has already caused us to
improve our "dusty deck" compilation.
-- greg
(working for, not speaking for, PathScale.)
| |
| Herman D. Knoble 2005-02-22, 8:59 pm |
| Greg: Thanks. This kind of debugging probably should be designed
into a compiler for the most part. High performence is not worth
a plugged nickel if the answers are wrong because of an undetected
semantic human error. THAT's the motivation. Compiler writers need to
realize historically how serious a detectable semantic error can be in
some cases. Then they should provide the leadership to address doing
everything that they can to avert any potential disaster resulting from
a detectable programming error. That's part of computing responsibility.
(As I understand it, Intel as agreed to provide capturing run-time
errors via the -C option.)
Skip
On 21 Feb 2005 15:16:47 -0800, lindahl@pbm.com (Greg Lindahl) wrote:
-|In article <2n3k1117hvp4o63ehlhna6km6htrm3g1qq@4ax.com>,
-|Herman D. Knoble <SkipKnobleLESS at SPAMpsu dot edu> wrote:
-|
-|> But the PathScale Compiler does not (yet) have near the debug
-|> capability that LF95 has.
-|
-|This is very true. The reason PathScale hasn't worked on such features
-|is that we couldn't find enough customer interest to justify spending
-|a fair bit of time on it. If there are any potential customers out
-|there who would buy our compiler if we had great debugging features,
-|please drop me an email.
-|
-|The Lahey folks do think this is important to their existing
-|customers, so it may well be the case that they'll eventually work on
-|adding such features. Their test suite has already caused us to
-|improve our "dusty deck" compilation.
-|
-|-- greg
-|(working for, not speaking for, PathScale.)
| |
| Toon Moene 2005-02-22, 8:59 pm |
| Greg Lindahl wrote:
> In article <2n3k1117hvp4o63ehlhna6km6htrm3g1qq@4ax.com>,
> Herman D. Knoble <SkipKnobleLESS at SPAMpsu dot edu> wrote:
[color=darkred]
> This is very true. The reason PathScale hasn't worked on such features
> is that we couldn't find enough customer interest to justify spending
> a fair bit of time on it.
You betcha. I've colleagues screaming left and right about the
debugging prowess of the compilers/debuggers we (the Dutch National
Weather Institute) have available on our computers.
The fact that they complain means that they don't work on the really
important codes in our segment of the "market".
A typical run of our Numerical Weather Prediction code involves O(100)
MPI threads runnning for 40-50 minutes.
Typically, in case of a problem, something goes wrong that aborts one of
these threads after O(10 minutes).
No amount of debugging with a classical debugger will get you anywhere here.
The standard approach I use is:
1. Get a traceback from the core file.
2. Determine which array was used in the floating-point-exception abort
(segmentation faults are normally just due to insufficient stack
space allowed by the OS).
3. Find where said array was initialized.
4. Fix initialization.
(<slashdot> 5. Profit ! </slashdot>
Hope this helps,
--
Toon Moene - e-mail: toon@moene.indiv.nluug.nl - phone: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
A maintainer of GNU Fortran 95: http://gcc.gnu.org/fortran/
| |
|
| Thanks for the kind words and the memory prompts.
For the record, here are some Fortran events from the 1960s as an old
man remembers them - any corrections would be appreciated.
January 1962, La Jolla, CA. I began working at Daystrom, a small
process-control computer-company. My title: Some variation on Senior
Software Guru. My responsibility: To accept delivery of, plus
maintain and enhance, software tools for the Daystrom 636, a 15-bit
word, process control system (no hardware floating point). One of the
tools was a Fortran language system delivered by Digitek for the price
of $25,000; the language system ran in 4K 15-bit words.
Digitek, Culver City, CA, was founded by three equal partners: James
R. Dunlap, Don Ryan, and Don Peckham; with Jim being most equal; the
three had met while working at Hughes Aircraft Co., Culver City. Jim
and Digitek were mentioned in early editions of The Art of Computer
Programming, Knuth. Don Peckham was bought out; Don Ryan went on with
Dave McFarland, also from Digitek, to found Ryan-McFarland.
Jim invented (at least refined and proved economically viable) a
programming paradigm for compiler writing: POPs, Program Operations.
Jim designed a computer on paper, an instruction was a POP, e.g., RCA,
Require Character and Advance; it was "easy" to write compilers on
this paper computer that would eventually be emulated on the
customer's hardware. The principal features of this paper computer:
LIFO variable length tables, recursion, a stack, translation to, and
manipulation of Polish encryption of the program being compiled,
character-scanning and code-generation POPs.
I pursued employment with Digitek for more than a year and was
eventually hired in August 1964, the tenth or eleventh employee; I was
generously allowed to purchase one percent of Digitek for $30, each
partner selling me ten shares. During my two years plus one w of
employment, Digitek grew to more than 40(?) employees, moved to
quarters on Century Blvd near LAX, and went public; after a ten-to-one
stock split I sold shares for between $6 and $16 - regretfully not
all of them!
Digitek's first compiler customer was Scientific Data Systems, aka
SDS, a hardware company created by Max Palevsky and later acquired by
Xerox for close to $1 billion in 1969. Palevsky was also involved in
the startup of and served as a director of Intel from 1968 until his
retirement, April 2000 and is a former governing board member of the
Institute for Advanced Study in Princeton, New Jersey. SDS was
dedicated to the scientific marketplace (as was Control Data Systems),
a niche that IBM was reputed to ignore. (I never understood this
claim; clearly there was something to it because they both thrived for
a while. In my opinion, IBM led the way in Fortran for decades. In my
opinion the IBM user group, SHARE (Society to Help Relieve Redundant
Effort), lead in Fortran feature definition for decades.)
Another Digitek language-systems project: Develop a proprietary for
lease a Fortran IV compiler for the IBM 7090 series. Although 2-page
color ads appeared in Datamation, the product was never brought to
market.
While I was at Digitek, IBM had Digitek and CSC compete for a contract
to implement two Fortran language systems for the IBM 360. The firms
were paid to work on a front end, Bob Trainer was the Digitek project
leader; Digitek won and received the code generation contract. Jim
designed a DO loop optimization that I coded; the language systems were
known as Fortran D and Fortran G.
Gordon Sande, "They also had a contract to produce a PL/I for a
customer who pulled the plug for the usual reasons (if I believe the
stories). But their advertising agency was not told so that the back
cover of CACM had an ad saying, 'Ask the man who owns one' as puffery
for the PL/I when it had already been canceled for excessive under
delivery. Oops!" The PL/I compiler contract was canceled for reasons
unknown to me as I had left; I think the customer was SDS. As for the
ad, maybe its appearance was due to timing and communication problems
as opposed to intent to mislead.
I recall earlier Digitek ads that appeared in Datamation - I found
those ads compelling /direct/factual.
| |
| Melvin Klassen 2005-02-27, 4:00 pm |
| On Sat, 19 Feb 2005 03:14:49, Jeff Ryman <see_address@signature.com>
wrote:
> IIRC, he worked for a company that produced, or helped to produce, the
> IBM Fortran G and H compilers. When that company folded, he bought
> the rights to the unpublished language used to develop the compilers,
> and used it or a derivative to produce the first Lahey compilers for PCs.
The IBM FORTRAN H compiler was written in FORTRAN H,
i.e., IBM programmers compiled the source code to produce an updated
compiler.
Bootstrapping!
| |
|
| On Sun, 27 Feb 2005 16:19:58 GMT, Klassen@UVic.CA (Melvin Klassen)
wrote:
>On Sat, 19 Feb 2005 03:14:49, Jeff Ryman <see_address@signature.com>
>wrote:
>
>
>The IBM FORTRAN H compiler was written in FORTRAN H,
>i.e., IBM programmers compiled the source code to produce an updated
>compiler.
>
>Bootstrapping!
I don't believe there was any designation as a "FORTRAN H".
It might have been FORTRAN IV.
| |
| Gordon Sande 2005-02-27, 8:58 pm |
|
john wrote:
> On Sun, 27 Feb 2005 16:19:58 GMT, Klassen@UVic.CA (Melvin Klassen)
> wrote:
>
>
>
>
>
> I don't believe there was any designation as a "FORTRAN H".
>
> It might have been FORTRAN IV.
IBM for IBM/360 mainframes had multiple compilers for a single language.
Language - Fortran IV
Compiler (no 1) - Fortran G
Compiler (no 2) - Fortran H
The two compilers supported the same language (well in theory at least)
with interoperable object (subject to some early glitches) but did not
have compatible run time libraries for I/O. I believe there may even
have been a Fortran F for a while when 360s were new. The letter was
supposed to relate to memory size. Fortran G was written by a contractor
as was discussed earlier in this thread. Fortran H was IBM inhouse.
Fortran H was an optimizing compiler with either all or most of it
written in Fortran. (The optimizer was even used with their PL/I!)
Fortran G was more for debugging. The error messages in Fortran G were
of the "I got  here" type with a marker for where the compiler
gave up on the statement. Fortran H error messages were full paragraphs
that came at the end of the listing and were a quite learned discussion
of the error. Like most computer error message they were of the wrong
symptom so were much less useful that the other ones when one was
trying to sort out more typical programming errors.
| |
| glen herrmannsfeldt 2005-02-27, 8:58 pm |
| Gordon Sande wrote:
(snip)
> IBM for IBM/360 mainframes had multiple compilers for a single language.
> Language - Fortran IV
> Compiler (no 1) - Fortran G
> Compiler (no 2) - Fortran H
> The two compilers supported the same language (well in theory at least)
> with interoperable object (subject to some early glitches) but did not
> have compatible run time libraries for I/O.
There is only one library for Fortran G and H, that is the one that
starts with IHC. The H extended library, IHO, is backwards compatible
with the previous one. IBM was pretty good at keeping libraries
backward compatible, so that newer libraries would still work with older
compilers, though not always the other way around.
> I believe there may even
> have been a Fortran F for a while when 360s were new. The letter was
> supposed to relate to memory size.
Both computers and software used a sort-of binary roman numeral system,
with successive letters increasing by factors of two, and, at least for
memory, lower letters on the right added, and on the left subtracted
from the previous value. I thought the lower Fortran was E, but I
never used that one. F is 64K, G is 128K, H is 256K. The H compiler
uses overlays to fit in 256K.
> Fortran G was written by a contractor
> as was discussed earlier in this thread. Fortran H was IBM inhouse.
> Fortran H was an optimizing compiler with either all or most of it
> written in Fortran. (The optimizer was even used with their PL/I!)
I thought the amount that was Fortran was closer to half, but it
probably depends on how you measure it. The parts more related to
optimizing were in Fortran. Also, there were some extensions that were
only enabled with the XL parameter, such as functions like IAND and IOR
to do bitwise boolean operations.
> Fortran G was more for debugging. The error messages in Fortran G were
> of the "I got here" type with a marker for where the compiler
> gave up on the statement. Fortran H error messages were full paragraphs
> that came at the end of the listing and were a quite learned discussion
> of the error. Like most computer error message they were of the wrong
> symptom so were much less useful that the other ones when one was
> trying to sort out more typical programming errors.
Fortran G had a neat feature, though I never actually used it, for
debugging. You could put all your debugging code at the end, and then
use AT statements to specify were in the program they should be
executed. Slightly related to COME FROM statements, as there would be
no indication in the actual code what was being executed.
-- glen
|
|
|
|
|