wood@dg_rtp.UUCP (Tom Wood) (06/11/87)
We're considering using PCC as a means of providing a C compiler
for a new architecture. I'd appreciate any helpful pointers or
opinions.
Are there a variety of PCC versions (V.3, 4.3, ...)?
If so, which one is better to use as a base?
I'm currently reviewing the 4.3 PCC version with the help of the
April 1986 version of "A Tour Through the Portable C Compiler" by
Johnson and Seeley.
Anybody know of any more documentation?
I may be misled on this one, but I heard that the 4.2/4.3 versions
of Pascal and Fortran target the PCC intermediate language.
Is this true?
Does this mean that the additional cost of retargeting
Pascal and Fortran given a PCC is free or very small?
Thanks much for your comments and opinions!
--
Tom Wood (919) 248-6067
Data General, Research Triangle Park, NC
{the known world}!mcnc!rti-sel!dg_rtp!woodjouvelot@mit-vax.UUCP (06/12/87)
In article <2082@dg_rtp.UUCP> wood@dg_rtp.UUCP (Tom Wood) writes: >I'm currently reviewing the 4.3 PCC version with the help of the >April 1986 version of "A Tour Through the Portable C Compiler" by >Johnson and Seeley. > > Anybody know of any more documentation? When I ported PCC to the french ISIS supercomputer, I found the "Detailled Tour Through the Portable C Compiler" a very helpful document. It has been published as a TechReport at the Case Western Reserve University (sp?) in the beginning of 1980s (sorry, I don't remember the name of the author). This report goes deeper inside the (PDP11 version) of PCC and describes the porting towards the H/6 computer (a sort of weird architecture). If the precise reference is neeeded, I may be able to find it ... within a week when I'll be at home (i.e., Paris). >I may be misled on this one, but I heard that the 4.2/4.3 versions >of Pascal and Fortran target the PCC intermediate language. > > Is this true? This is true for F77 (at least). Good luck ! Pierre -- Pierre Jouvelot Room NE43-403 ARPA: jouvelot@xx.lcs.mit.edu Lab for Computer Science USENET: decvax!mit-vax!jouvelot MIT (or mcvax!litp!pj) 545, Technology Square Cambridge, MA 02139 USA
gwyn@brl-smoke.UUCP (06/14/87)
In article <2082@dg_rtp.UUCP> wood@dg_rtp.UUCP (Tom Wood) writes: > Are there a variety of PCC versions (V.3, 4.3, ...)? > If so, which one is better to use as a base? Yes, the best version for most regular architectures is QCC which is the cc found on SVR3.0 (most likely also SVR3.1) for the 3B2 -- the System V "porting base".
darryl@ism780c.UUCP (Darryl Richman) (06/15/87)
In article <5975@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >In article <2082@dg_rtp.UUCP> wood@dg_rtp.UUCP (Tom Wood) writes: >> Are there a variety of PCC versions (V.3, 4.3, ...)? >> If so, which one is better to use as a base? > >Yes, the best version for most regular architectures is QCC which is >the cc found on SVR3.0 (most likely also SVR3.1) for the 3B2 -- the >System V "porting base". No, the best base is the newer RCC, available on the 3B's and the 386; it is a QCC compiler that allows multiple, overlapping register sets to be specified for different register requirements. It's a very nice job! --Darryl Richman, INTERACTIVE Systems Corp. ...!cca!ima\ >-!ism780c!darryl ...!sdcrdcf/ The views expressed above are my opinions only.
guy@gorodish.UUCP (06/16/87)
> >Yes, the best version for most regular architectures is QCC which is > >the cc found on SVR3.0 (most likely also SVR3.1) for the 3B2 -- the > >System V "porting base". > > No, the best base is the newer RCC, available on the 3B's and the 386; it > is a QCC compiler that allows multiple, overlapping register sets to be > specified for different register requirements. It's a very nice job! Is the C compiler supplied with S5R3.0 for the 3B2 QCC or RCC? If the latter, you're both really saying the same thing.... Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com
mcg@omepd.UUCP (06/17/87)
QCC and RCC are almost the same thing. They differ in the exact algorithm
used for instruction selection. RCC does a complex (and time-expensive)
cost comparison among certain alternatives. QCC operates on an
ordered list of alternatives, and simply picks the first one that applies.
The only files that would differ between the two versions are scommon/cost.c
and scommon/match.c.
The belief is that this generates the best code most of the time, and
is substantially faster in compiler speed. QCC is the 'Quick RCC'.
I believe that the version on 3B's is actually QCC - RCC is a research tool.
V.3 also includes an optimizer which, while not any better than c2,
appears to be easier to retarget ('port' is really the wrong word
for re-doing compiler backends).
What V.3 *still* does not have, and would do the reputation of PCC-based
compilers a world of good, is a (mostly) machine-independent
intermediate code optimizer (between the first and second passes)
doing things like strength reduction, dead variable elimination, etc.
This would destroy the one-pass ("filter") aspect of PCC, but would
generate substantially better code.
S. McGeadyjss@hector.UUCP (06/17/87)
Pcc, pcc2, stincc, qcc and rcc are, in historical order, versions of the same compiler. (Although pcc and pcc2 coexisted for a while.) The major differences between them were in their code generators. The biggest break was between pcc and pcc2, since the latter introduced a "stin file" containing code generation templates. These names were used internally to mark significant changes. No distinction was ever made externally, and there were many changes that were not marked by a name. In general, the more recent the compiler the "better". All of these are AT&T code. NONE of these is in the public domain. Mostly, source licences are only available as part of a UNIX source licence. Jerry Schwarz Former member of the AT&T UNIX Language Department
jss@hector..UUCP (Jerry Schwarz) (06/18/87)
In article <801@omepd> mcg@omepd.UUCP (Steven McGeady) writes: > >QCC and RCC are almost the same thing. They differ in the exact algorithm >used for instruction selection. RCC does a complex (and time-expensive) >cost comparison among certain alternatives. QCC operates on an >ordered list of alternatives, and simply picks the first one that applies. >The only files that would differ between the two versions are scommon/cost.c >and scommon/match.c. > McGeady is confusing rcc with pcc2. Pcc2 was the version that did the code selection based on costs. The "r" in rcc stands for "register". Jerry Schwarz Former member of AT&T UNIX Language Department
mcg@omepd (Steven McGeady) (06/18/87)
In article <> (Jerry Schwarz) writes: >In article <801@omepd> mcg@omepd.UUCP (Steven McGeady) writes: >> >>QCC and RCC are almost the same thing. ... >> >McGeady is confusing rcc with pcc2. Pcc2 was the version that >did the code selection based on costs. The "r" in rcc stands for >"register". > >Jerry Schwarz >Former member of AT&T UNIX Language Department Mr. Schwarz is correct. My confusion resulted from seeing only the end product, not the genealogy. The correct story is, to quote from an AT&TIS memo (dated June 30, 1985, by David M. Kristol): "PCC2, a successor to the Portable C Compiler (PCC), has itself spawned two successors, QCC and RCC. QCC is a compiler technology that has the favorable maintainability properties of PCC2, along with faster compilation speed than PCC or PCC2. RCC, in turn, is a derivative of QCC that can deal with irregular architectures through the definition of *register sets*. To create a RCC compiler from a PCC2 compiler, it is easiest to go through the intermediate stage of a QCC. The steps are simple, and it is not necessary to get a working QCC, in the sense that it compiles all available C code ..." To give more background, the memo "Speeding up the Portable C Compiler", by David M. Kristol and R.B. Murray, dated February 8, 1985 (and a Bell Labs memo, rather than AT&T IS) says: "PCC2 is an evolutionary outgrowth of PCC, the fundamental difference being the matching algorithm. Since the leaves of the tree correspond to its shapes, PCC begins code generation one level above the leaves. At each step PCC uses the first template it finds for which the OP and shapes in the template match the tree.... PCC2 uses a dynamic programming algorithm to choose the *best set* of templates that represents the semantics of the tree, where *best* is based on a cost measure. The compiler writer supplies costs for templates and shapes. The compiler effectively does an exhaustive search over all possible code generations for a given expression before choosing the cheapest." S. McGeady
mike@hcr.UUCP (Mike Tilson) (06/19/87)
In a discussion of QCC and RCC, Steven McGeady (mcg@omepd.UUCP) writes: > ... > What V.3 *still* does not have, and would do the reputation of PCC-based > compilers a world of good, is a (mostly) machine-independent > intermediate code optimizer (between the first and second passes) > doing things like strength reduction, dead variable elimination, etc. > This would destroy the one-pass ("filter") aspect of PCC, but would > generate substantially better code. You may be interested to know that exactly such a thing has already been developed. An early version of HCR's "Portable Code Optimizer" (PCO) was described in the Portland USENIX/85 proceedings. PCO can be dropped in between "pass 1" and "pass 2" of the AT&T compilers, and it does most of the things that you would expect from a "globally optimizing" compiler. It also works for f77. (We recently ran a few benchmarks where UNIX V.2 f77 using PCO on a Vax 750 actually beat DEC's optimizing Vax/VMS Fortran.) Some "cutting and fitting" is required, so the technology is provided to OEMs rather than directly to end users. Every RT PC running AIX is shipped with PCO. It also runs on the CDC Cyber 180, the new Gould machines, and several others we can't talk about yet. (About the only thing we don't do is strength reduction -- it was a low payoff for C. But we do most everything else, including automatic in-lining of functions. Strength reduction will come in the future to improve Fortran.) Adding optimization to PCC (and successors) has several advantages: You don't change language semantics (a new optimizing compiler built from the ground up invariably seems to have a slightly different definition of C -- someday the ANSI standard may fix this, but not yet), existing engineering is retained (e.g. code generator, local optimizer), and PCC extensions such as "asm" can be retained (although functions using asm aren't globally optimized). One goal of the project was to be able to compile the UNIX kernel with PCO and still have it work, and this goal was met. (By the way, as most of you know, global optimization doesn't buy much on the kernel -- it has already been hand-tuned for years, and real "hot spots" are written in hand-coded assembler.) /Michael Tilson, {utzoo,ihnp4,...}!hcr!mike /HCR Corporation /130 Bloor St. West, 10th Floor /Toronto, Ontario, M5S 1N5 Canada /416-922-1937
mash@mips.UUCP (John Mashey) (06/21/87)
In article <2684@hcr.UUCP> mike@hcr.UUCP (Mike Tilson) writes: >In a discussion of QCC and RCC, Steven McGeady (mcg@omepd.UUCP) writes: >> What V.3 *still* does not have, and would do the reputation of PCC-based >> compilers a world of good, is a (mostly) machine-independent >> intermediate code optimizer... > >You may be interested to know that exactly such a thing has already been >developed. An early version of HCR's "Portable Code Optimizer" (PCO) was >described in the Portland USENIX/85 proceedings.... >Adding optimization to PCC (and successors) has several advantages: You >don't change language semantics (a new optimizing compiler built from >the ground up invariably seems to have a slightly different definition >of C -- someday the ANSI standard may fix this, but not yet), existing >engineering is retained (e.g. code generator, local optimizer), and PCC >extensions such as "asm" can be retained (although functions using asm >aren't globally optimized). One goal of the project was to be able to >compile the UNIX kernel with PCO and still have it work, and this goal >was met. (By the way, as most of you know, global optimization doesn't >buy much on the kernel -- it has already been hand-tuned for years, and >real "hot spots" are written in hand-coded assembler.) All of this is indeed a reasonable compromise approach, and is probably the easiest way for many to get a better level of optimization. A few notes in defense of from-scratch optimizers: a) A complete language system amortizes the overhead of having an optimizer by using common components for multiple frontends. In some domains, it IS important to support C, FORTRAN, PASCAL, PL/I, ADA, etc, etc, in a coherent way. [This is not to say that the PCO approach can't be used, just that you can think of developing technology easier if you know you're going to use it broadly.] b) At least some optimizers do compile the kernel [we do, so do others]. c) In our case, we gain about 15% performance by adding the first level of global optimization, over some pretty good local optimization. That may not seem like much, but it is about the equivalent of an extra VAX 11/785 on our systems. (Actually, most of the current kernels aren't bad to optimize; the various namei incarnations are the worst, but also useful, since you DON'T want to recode them in assembler!) Mike is right in noting that you get less benefit for the kernel than for most user-level code. You do get some, and it is noticable when you use the systems. d) I am curious to know if PCO is used to optimize device drivers. Even common subexpression elimination can surprise you if you don't support volatile. -- -john mashey DISCLAIMER: <generic disclaimer, I speak for me only, etc> UUCP: {decvax,ucbvax,ihnp4}!decwrl!mips!mash, DDD: 408-720-1700, x253 USPS: MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086
mike@hcr.UUCP (Mike Tilson) (06/26/87)
John Mashey (mash@mips.UUCP), in response to my posting about the PCO optimizer for UNIX compilers, comments: > ... A few notes in defense of from-scratch optimizers: > a) A complete language system amortizes the overhead of having > an optimizer by using common components for multiple frontends. > In some domains, it IS important to support C, FORTRAN, PASCAL, > PL/I, ADA, etc, etc, in a coherent way. [This is not to say that the > PCO approach can't be used, just that you can think of developing > technology easier if you know you're going to use it broadly.] This is true I think. However, for this to really pay off you have to be fully committed to proper support of *all* of the languages. The cost savings of using one "general" back end can be eaten up by the cost of designing and building PL/I, COBOL, and Ada front ends. For this reason many organizations select compilers from vendors who specialize in each language (i.e. buy COBOL from COBOL experts, buy Ada from Ada experts, etc.) Developers who have decided they would support "everything" have frequently produced mediocre implementations. In the case of MIPS, the compiler technology has been integral to the hardware design, and so this kind of effort may well be justified. > b) At least some optimizers do compile the kernel [we do, so do others]. I should add that as far as I can tell, MIPS has produced high quality compilers around, and my caution should not be applied to them. > c) In our case, we gain about 15% [kernel] performance by adding the first > level of global optimization ... I didn't mean to imply that optimization won't help, and it's always good to have more performance. However, some more naive people see the usual "Puzzle sped up by xx%" benchmarks, and expect similar things from the kernel. > d) I am curious to know if PCO is used to optimize device drivers. > Even common subexpression elimination can surprise you if you don't > support volatile. We can do three things: 1) By default all non-local storage is volatile -- this is needed if the C version doesn't have the "volatile" keyword. 2) A compiler flag can be set to assume that all storage is non-volatile. (A customer can in fact make this the default behavior.) 3) The "volatile" keyword can be supported. (In fact, we haven't yet done this because we haven't yet installed PCO in a compiler with "volatile", but as a result of (1) and (2) the necessary facilities exist.) A lot of thought and work was required to make sure this works correctly. Prior to the invention of "volatile", we named such storage "evil" internally. /Michael Tilson, HCR Corporation, {utzoo,ihnp4,...}!hcr!mike
woutput@ji.Berkeley.EDU (Andrew Purshottam) (07/06/87)
The paper mention from case was by Sam Leffler, and
was called "A Detailed Tour through the /6 C Complier."
It's quite useful, if you are going to start with pcc1.
A Graham student also wrote a paper on the pcc1 IR.
It had a bell copyright warning, and I am not sure of its
status.
An adventurous alternative: consider using gcc, RMS's
new C compiler now in beta release. It's free, though
you can legally make proprietary subversions.
(I wonder at the enforcablity of this, though; if there
is one thing I have learned as a CS undergrad here,
it's been how to "continuously deform" one program into another,
with no trace of ancestry. Of course, none of us would ever
do that :-)
Andy
Cheers, Andy (...!ucbvax!woutput woutput@ji.berkeley.edu)
(cond ((lovep you (quote LISP)) (honk)) (t (return ())))grr@cbmvax.UUCP (George Robbins) (07/24/87)
In article <826@omepd> mcg@omepd.UUCP (Steven McGeady) writes: > > Mr. Schwarz is correct. My confusion resulted from seeing only the end > product, not the genealogy. The correct story is, to quote from an AT&TIS > memo (dated June 30, 1985, by David M. Kristol): > > "PCC2, a successor to the Portable C Compiler (PCC), has > itself spawned two successors, QCC and RCC........ To put things in a practical vein, which of these wonder compilers were included with which source release? Specifically, SVr2-vax seems to include PCC and SVr2-motorola seems to be PCC2. Is this really the case? What release would I need to get this RCC? As he comtemplates some fun and games... -- George Robbins - now working for, uucp: {ihnp4|seismo|rutgers}!cbmvax!grr but no way officially representing arpa: cbmvax!grr@seismo.css.GOV Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)
gwyn@brl-smoke.ARPA (Doug Gwyn ) (07/25/87)
In article <2153@cbmvax.UUCP> grr@cbmvax.UUCP (George Robbins) writes: >To put things in a practical vein, which of these wonder compilers were included >with which source release? Specifically, SVr2-vax seems to include PCC and >SVr2-motorola seems to be PCC2. Is this really the case? What release would >I need to get this RCC? As he comtemplates some fun and games... That's correct, and current AT&T SGS (SVR3 3B2, for example) appears to be based on QCC. I've been told that QCC and RCC are essentially the same sources, with only the multiple register classes of RCC handled differently. Your best bet would be to get the absolutely latest AT&T SGS you can and proceed from there. You might also consider working with Green Hills or HCR or some other popular compiler vendor; why is it so important to have the AT&T RCC product?
darryl@ism780c.UUCP (Darryl Richman) (07/28/87)
You will find an RCC compiler in the 386 version of SVR3.0.
--Darryl Richman, INTERACTIVE Systems Corp.
...!cca!ima\
>-!ism780c!darryl
...!sdcrdcf/
The views expressed above are my opinions only.