21 Mar
2007
21 Mar
'07
1:39 p.m.
From: "Chuck Guzis" <cclist at
sydex.com>
On 21 Mar 2007 at 12:12, Roger Holmes wrote:
One of my bosses at Marconi Avionics thought that compilers should
only have one error message because as a compiler cannot find all
errors (such as a mistyped number), you should not rely on it to find
errors in your programs. You should only ever submit 100% correct
code to the compiler. I think he worked on the Jaguar aircraft's
flight program, so there is some justification in that field where a
software error could cause a fast jet to take out a street or two of
a city.
I used Fortran 4 on the IBM 7094 at Imperial
College London. I
remember one day the compiler reported:
I used FORTRAN II under FMS II on the 7090 but never saw a FORTRAN IV
implementation there. It's been entirely too long ago, but, as I
recall, one punched a "B" in column 1 for boolean expressions, "D"
for double-precision and "I" for complex, as FORTRAN II still relied
on implicit typing for variables.
One of the most diagnostic-bald versions of FORTRAN I ever used was
the "USA BASIC FORTRAN" under DOS/360. The thing couldn't have had
more than about 10 diagnostic messages, most of them single-word. I was used to
syntax error messages by the dozen but this was the
first time I had seen the compiler correct an error and run the
job. Of
course we are used to warnings now, but I think it was that one
which
got me interested enough in compilers to eventually get a job
writing
them.
Pat could probably fill in details here, but Purdue for many years
used 7090/94's to run a student variant of FORTRAN called PUFFT. The
basic idea was for the compiler to 'fix" as many errors as possible
so that a program would run somehow. I believe it was described by
Saul Rosen in an ACM paper and republished in one of those
"Programming Languages Survey" books. IIRC, the 709x were also used
as I/O front ends for the CDC 6600 there, which ran Purdue's own
variant of MACE, rather than the more-or-less standard SCOPE. Greg
Mansfield was pretty proud of that. If you stuck
to floating point and small numbers but there were big
problems with word length variations when using integers.
IIRC, the 32-bit floating point word (with 4-bit normalization
granularity) of S/360 cost IBM a bunch of business in the
"scientific" world. It had one of the lowest-precision FP
representation of big iron at the time. I believe that IBM
eventually remedied this with "extended precision". I seem to
remember that some of the people who taught me to program
considered Fortran to be too close to the 7094 instruction set, in
particular they said the computed goto mapped directly onto a 7094
instruction and
hence considered it to be not very universal, and to support it
would be to
assist IBM in its domination of the computer market.
That must have been some clever propganda on the part of someone!
But conspiracy theories have always been popular. Computed GOTOs
weren't exactly the dominant feature of most programs--and they were
implemented as simple indexed jumps for the most part--a feature
scarcely unique to IBM hardware!
For small systems, FORTRAN was amazingly useful. The other day, I
ran across some code that I wrote for CP/M to convert between ISIS-II
and CP/M file formats--in FORTRAN.
Compiler design has come a long way since. In the 1970's, I recall
that a co-worker pushed a PTR in front of my face that was, frankly,
quite surprising. CDC FTN for years allowed an alternative way of
expressing Hollerith constants using any arbitrary delimiter
character, so 5HCHUCK and H*CHUCK* were equivalent ways of expressing
the same constant. Most people used asterisks or the not-equal
symbol (the standard character set didn't have quotation marks), but
the compiler would allow just about anything.
The statement in question looked something like this:
100 FORMAT( HX)=(1+BX )
Recall, that prior to FORTRAN 90, FORTRAN had no reserved words.