I’m still playing with PCC2. I’ve solved the issue with building an ILP32 version, but the ’stin’ file remains equally intriguing and mysterious.
Unfortunately, it seems that PCC2 retargeting manual is lost - so this list appears my best source.
From the paper that Clem shared, I get the general idea behind PCC2 and its tree tile covering algorithm: it does a full top-down search, matching on the basis of operations (“OPCODES”) and addressing modes (“SHAPES”). In general, the cost of a tile is estimated as the sum of the number of memory accesses and the number of instructions (normally 1).
The SHAPES section of a ’stin’ file defines the addressing modes, and the OPCODES section defines instructions for operations. The instructions are specified as macros, similar in style to PCC or the dmr compiler. What I find difficult to understand is the role of the “needs” field.
The grammer for the ’stin’ pre-processor has the following comment about the ’needs’ field:
1,2,3 Number of needed registers
$P need pairs
$< share left
$> share right
$L result left
$R result right
$1,2,3 result in reg 1, 2, 3
$C operation produces correct condition codes
$N no value produced: side effects only
$A need them all
$[ share left, RHS is preferred (if a temp register)
$] share right, RHS is preferred (if a temp register)
$l left side is referenced once more
$r right side is referenced once more
I am puzzled as to how 'needs' should be read. Are the needs properties of or requirements for the tile? Or both?
For example, here is two lines from the ’stin’ file for the 68K:
operation: =
shapes: SAWD[sus], SAWD[sus] (means: operands must be "signed/unsigned addressable short words")
needs: {$C}
macro: "mov.w AR,AL"
operation: =
shapes: LAWD[lul], LAWD[lul]
needs: {$C $l $r}
macro: "mov.l AR,AL”
Does this mean that instruction sets the condition codes as a side effect, or does it say that the line must be used when the conditions codes are required?. Why are the left and right side used once more for move.l but not for move.w? And why is the below a separate definition on yet another line?
operation: =
shapes: LAWD[lul], LAWD[lul]
needs: {$R $l $r}
macro: “RL!R mov.l AR,AL”
Hopefully there is somebody on the list who has worked with PCC2 and still remembers about the ’needs’ field.
Paul
Thank you, that Usenix paper is most helpful.
In short, there were (at least) 4 generations of PCC: PCC, PCC2, QCC and RCC. The first two by SCJ and the latter two by Kristol.
PCC2 seems to go back to about 1980, and QCC and RCC were created in the first half of 1985. The C compiler in 8th Edition seems to be PCC2 based.
Anybody who has some more info on how to read a “stin” file, please share.
Paul
yes i'll mail under separate cover a scan
ᐧOn Sun, Apr 25, 2021 at 11:47 AM Paul Ruizendaal <
pnr@planet.nl> wrote:
By now found some more clues, in particular this link:
http://computer-programming-forum.com/47-c-language/fab825b2dce1aa59.htm
Apparently I am talking about PCC and PCC2 in the below question.
The first post mentions 4 papers. They can be found online, apart from the USENIX one:
"Four Generations of Portable C Compiler" by D.M. Kristol (1986 Summer USENIX Conference Proceedings)
Anybody have that?
The second post mentions official documentation:
"In porting QCC, a useful text is the "Portable C Compiler -
Version 2 (PCC2) Internals". It includes documentation of
stin file formats, PCC2 tree forms, debugging flags, and
compiler #defines. The manual is expensive so it's worth it
most if you buy it before you figure it all out doing a
port. Since the manual is based on PCC2 (and hasn't been
updated), it's a good starting point, but doesn't have the
latest information.”
Anybody have that? (It is not on bitsavers)
Paul
> On 25 Apr 2021, at 14:49, arnold@skeeve.com wrote:
>
> Not an answer to your questions, but you may want to take a look
> at the PCC Revived project. It lives in CVS, but I have a git mirror at
> git://github.com/arnoldrobbins/pcc-revived
>
> HTH,
>
> Arnold
>
> Paul Ruizendaal <pnr@planet.nl> wrote:
>
>> For clarity and ease of reference:
>>
>> - The “Tour of paper” is for instance here: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.48.3512 <http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.48.3512>
>>
>> - A machine description for the VAX that matches with that paper is for instance in the SysIII source: https://www.tuhs.org/cgi-bin/utree.pl?file=SysIII/usr/src/cmd/cc/vax/pcc/table.c <https://www.tuhs.org/cgi-bin/utree.pl?file=SysIII/usr/src/cmd/cc/vax/pcc/table.c>
>>
>> - The new style description in 8th edition is here: https://www.tuhs.org/cgi-bin/utree.pl?file=V8/usr/src/cmd/ccom/vax/stin <https://www.tuhs.org/cgi-bin/utree.pl?file=V8/usr/src/cmd/ccom/vax/stin>
>>
>> - The program that translates the “stin” file to a “table.c” file is here: https://www.tuhs.org/cgi-bin/utree.pl?file=V8/usr/src/cmd/ccom/common/sty.y <https://www.tuhs.org/cgi-bin/utree.pl?file=V8/usr/src/cmd/ccom/common/sty.y>
>>
>>
>> ====
>>
>> Sometimes one thing leads to another.
>>
>> Following the recent mention of some retro-brew 68K single board systems, I decided to build a CB030 board (in progress). I figure it is a rough proxy for a 1980 VAX and would allow for some experimentation with the 32V / SysIII / 8th edition code.
>>
>> My first thought was to use the M68K compiler that is included with the Blit sources (see THUS Archive for this), as I had used that before to explore some of the Blit source. That compiler is LP32, not ILP32 - which may be a source of trouble. Just changing the SZINT parameter yielded some issues, so I started looking at the PCC source.
>>
>> This source does not have a “table.c” in the well known format as described in the “A tour of the portable C compiler” paper. Instead it uses a file “stin” which appears to be in a more compact format and is translated into a “table.c” file by a new pre-processor ("sty.y”). Then looking at the VAX compilers for 8th and 10th edition, these too use this “stin” file.
>>
>> All the other m68K compilers (based on pcc) that I found appear to derive from the V7/32V/SysIII lineage, not from the 8th edition lineage.
>>
>> A quick google did not yield much background or documentation on the STY format.
>>
>> Anybody on this list that can shed some light on the history of the STY table and on how to use it? Any surviving reports or memos that would be useful?
>>
>> Many thanks in advance
>>
>> Paul
>>