Minimalists & Maximalists (Re: Integrating C preproc[.,...]parser)

[I missed the base-note for this discussion thread;
  I hope this isn't repetitive.] [Actually, it's almost completely unrelated,
but the issue of error reporting in compilers is always with a look. -John]


In article <1990Mar24.184358.1573@esegue.segue.boston.ma.us>,
pgl@cup.portal.com wrote:
>
>IBM's "new" C/370 compiler does much of what has been described.


I confess that I have no experience with the C/370 compiler, but
I have a lot of experience with other IBM--and CDC--mainframe compilers.


>[1] when an error occurs (and the source listing option is on),
> the parser prints the line a second time with full
> macro expansion and points at the offending token.
                                                                              $ :-)
My vague recollection is that the old IBM FORTRAN IV G compiler (ca. 1970)
for their System/360 included a "$" positioned underneath the column in
which a syntax error was detected (IEY013I was the diagnostic code, if
dusty-deck memory serves), although it didn't say *what* the syntax error
was. The G compiler, however, was not IBM's top-of-the-line for FORTRAN.
The "H" compiler line (also FORTRAN IV) was, and it was legendary for
its ability to optimize code. Of course, FORTRAN has no macros to expand.


>[2] optionally, macro expansion can be interlisted with source.
>[3] optionally, assembler output can be interlisted with source.
>[4] the output of the preprocessor alone can be produced.


This seems to be part of the "style" (for lack of a better word)
of the compilers produced by the major (or perhaps formerly major)
mainframe manufacturers. It is also what their customers came to expect.


>This is accomplished despite the compiler being 3-phases;
>information is passed among the phases using work files.
>This compiler has been available for about two years.


A whole 3 phases ?
The IBM PL/I F compiler (ca. 1971) for their System/360 had approximately
90 phases (NINETY, not a typo for nine; the numbers 88 and 92 stick in my
mind as candidates for the actual number), and provided 2 of the 3 features
above way back then (the preprocessor listing was separate from the source
and in-line assembler). It had so many phases because it was designed to
run in as little user memory as 40 (FORTY, not a typo for four hundred) KB.
At my campus' computer center, we commonly used 128KB (1/8 MB) for small
PL/I compilations--and that was *full* PL/I, in all its elephantine glory !


>After using typical Unix compilers with no output listings
>and terrible syntax error handling,
>the IBM compiler was a joy.
          ^^^ ^^^
Nope. It's the Berkeley Pascal compiler that was originally a Joy. :-)
Bill Joy, that is. He left IBM years ago, and is rumored wealthy at Sun.


Perhaps in contrast to the UN*X "minimalist" style,
the mainframe style could be called "maximalist".


>[5] in most cases, errors do not "cascade".
                                                                      ^^^^^^^
The IBM PL/I compilers tended to cascade--in their own way--but at least
they didn't let semantic errors (e.g.: undeclared identifiers) confuse
their syntactic analysis (e.g.: matching beginning and ending brackets),
unlike some nonmainframe compilers that I've seen.


The standard mainframe-compiler feature that I miss most is an identifier
cross-reference listing that understands scope rules. I would love to find
a Pascal cross-reference tool that does. Berserkeley "pxref" does not,
as far as I can tell, and is not very solid overall.


>Unfortunately, IBM does not provide a "lint" with the compiler.


If it were true to the maximalist style, the moral equivalent of "lint"
would be provided by user-selection of "warning" (i.e.: "low" severity)
or "informational" (i.e.: even lower severity) as the minimum level of
diagnostic messages that would be produced for the compilation.
The lower bound on the severity of error messages produced is likely
a compiler-installation option that can be overriden when you invoke it.


Although separate "lint" and "xref" seem to be elegant ideas following
the minimalist style, it's too easy in practice for "lint", "xref", and
"the compiler" to get out of step--for managerial and other nontechnical
reasons--a situation that I have suffered with at times in the past.
Combining "lint", "xref", and "the compiler" seems most practical to me,
especially considering that the separate tools must repeat much of
the compiler's analysis. Nowadays, users of IBM PCs have more memory
available to them than most mainframe users had 2 decades ago, when
the "maximalist" compilers mentioned above were in widespread use.
--
Clay Phipps
Intergraph APD: 2400#4 Geng Road, Palo Alto, CA 94303; 415/852-2327
UseNet (Intergraph internal): ingr!apd!phipps
UseNet (external): {apple,pyramid,sri-unix}!garth!phipps EcoNet: cphipps
[I always liked Fortran H because of its extremely pompously worded error
messages, e.g. THE STATEMENT CONTAINS AN A MISPLACED COMMA. -John]

Return to the comp.compilers page.
Search the comp.compilers archives again.