Editing PL/C (section)

== Design and implementation ==
[[Image:PL C source listing and run printout for CS 100 at Cornell University 1973.jpg|thumb|upright=0.8|left|Line printer listing of PL/C program, from a Cornell first-semester programming class in 1973]]

The implementation of the PL/C compiler itself was done in [[IBM Basic Assembly Language and successors|IBM 360 Assembly Language]], with a heavy use of [[Macro (computer science)|assembly language macros]].<ref name="afips-plc"/>  It was done as a [[Multi-pass compiler|three-pass compiler]], with the first pass doing [[syntax analysis]] and error correction of syntactical mistakes, the second pass doing [[Semantic analysis (compilers)|semantic analysis]] and further error correction, and the third pass doing [[Code generation (compiler)|code generation]].<ref name="afips-plc"/>  PL/C needed to avoid the longstanding problem of "cascading diagnostics", wherein one error is internally but often mistakenly "fixed" by the compiler, resulting in a secondary, tertiary and additional series of unhelpful error messages.<ref>{{cite web | url=https://www.cs.odu.edu/~zeil/cs252/latest/Public/dealingWithErrors/index.html | title=Dealing with Error Messages | author-first=Steven | author-last=Zeil | access-date=September 24, 2022 | publisher=Department of Computer Science, Old Dominion University }}</ref>  The design of the [[intermediate language]] used between the passes and of the accompanying [[symbol table]] was tailored towards, and key to the achievement of, the error-repair and diagnostic reporting capabilities of PL/C.<ref name="PLCConwayWilcox"/>  While a number of these techniques dated from the Cornell CORC and CUPL efforts, here they were being used for the first time on large programming language with a full set of commercial-grade features.<ref name="PLCConwayWilcox"/>  This was especially notable given that the PL/I language was notoriously challenging for compilers to deal with.<ref>{{cite book | title=Programming Languages: Design and Implementation | author-first=Terrence W. | author-last=Pratt | publisher=Prentice-Hall | location=Englewood Cliffs, New Jersey | year=1975 | pages=385–386, 415}}</ref>

The compilation speed of PL/C was quite good – some 10,000–20,000 sources lines of code per minute on an [[IBM System/360 Model 65]].<ref name="PLCConwayWilcox"/>  The work done on PL/C was described in a paper presented at an [[AFIPS]] joint conference in Spring 1971.<ref name="afips-plc"/>  More prominent was the paper "Design and Implementation of a Diagnostic Compiler for PL/I" by Conway and Wilcox, published in the March 1973 issue of the flagship journal ''[[Communications of the ACM]]'', which gave the project considerable visibility within the computer science world.<ref name="PLCConwayWilcox"/>

PL/C was implemented as a [[compile and go system]],<ref name="PLCConwayWilcox"/> similar to WATFOR.<ref>{{cite book|title=Systems Software|first1=I.A.|last1=Dhotre|first2=A.A.|last2=Puntambekar|publisher=Technical Publications|year=2008|<!--isbn=9788184315004|-->page=3-2}}</ref>  It ran on the [[IBM System/360]] and [[System/370]] under [[OS/360 and successors|OS]] and [[Houston Automatic Spooling Priority|HASP]].<ref name="sigcse-cs100"/>  As such, it was designed to run within a 128K byte partition, where the PL/C software and the generated object code took a maximum of 100K bytes.<ref name="afips-plc"/>  Error correction was attempted at runtime as well, with the PL/C execution supervisor trapping or otherwise detecting use of uninitialized variables, division by zero, out-of-range array indexes, and the like, by issuing a diagnostic and making some adjustment to allow the program to keep running.<ref name="PLCConwayWilcox"/>  Overall, use of PL/C significantly reduced the severity of the wait-times-for-batch-runs problem (although Cornell itself developed a job entry system for turning around most student batch jobs very quickly).<ref name="cornell-history-computing"/>
{{clear}}