From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HTML_FONT_LOW_CONTRAST,HTML_MESSAGE,LOTS_OF_MONEY, MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 28885 invoked from network); 30 Apr 2021 23:09:40 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 30 Apr 2021 23:09:40 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id 811C59BD1C; Sat, 1 May 2021 09:09:39 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 124419BD01; Sat, 1 May 2021 09:08:19 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=pass (1024-bit key; unprotected) header.d=planet.nl header.i=@planet.nl header.b="KFeIor1H"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id D920E9BD01; Sat, 1 May 2021 09:08:15 +1000 (AEST) Received: from cpsmtpb-ews04.kpnxchange.com (cpsmtpb-ews04.kpnxchange.com [213.75.39.7]) by minnie.tuhs.org (Postfix) with ESMTP id 00E969BCFF for ; Sat, 1 May 2021 09:08:11 +1000 (AEST) Received: from cpsps-ews20.kpnxchange.com ([10.94.84.186]) by cpsmtpb-ews04.kpnxchange.com with Microsoft SMTPSVC(8.5.9600.16384); Sat, 1 May 2021 01:08:09 +0200 X-Brand: 7abm2Q== X-KPN-SpamVerdict: e1=0;e2=0;e3=0;e4=;e6=(e1=10;e3=10;e2=11;e4=10;e6=1 0);EVW:White;BM:NotScanned;FinalVerdict:Clean X-CMAE-Analysis: v=2.4 cv=VaGUgHl9 c=1 sm=1 tr=0 ts=608c8dd9 cx=a_idp_e a=/dHbpd/3q0lrH6oA/zwSgQ==:117 a=soxbC+bCkqwFbqeW/W/r+Q==:17 a=x1i13A_MHe4A:10 a=5FLXtPjwQuUA:10 a=AoeSMSUmAAAA:8 a=kcQwxSrQAAAA:20 a=jEIl9BPeAAAA:8 a=0CDJXS7TAAAA:8 a=7vsvHZ2mAAAA:8 a=p8hWPCrPAAAA:8 a=bYUg5HSxAAAA:20 a=UFTA8MH_AAAA:8 a=Tcc2hCe0y-pQ62SAXq4A:9 a=QEXdDO2ut3YA:10 a=IA4qIw_M-6cA:10 a=Wb-sVwQH3JoA:10 a=zwvI-rEBAAAA:8 a=tVSCfV2hqTHIoYFTnUsA:9 a=cu373bAeQXcizIB2:21 a=_W_S_7VecoQA:10 a=2UY7SMgi64q-0UtCmZ5F:22 a=UbykG2d9i8y_PxD0dgl3:22 a=4UvNIUW-e2QKwwUDAY-Z:22 a=hdUzUiK6lsseaELp4_5Y:22 a=OoLSvEA_ic9EetkLKI_r:22 X-CM-AcctID: kpn@feedback.cloudmark.com Received: from smtp.kpnmail.nl ([195.121.84.45]) by cpsps-ews20.kpnxchange.com over TLS secured channel with Microsoft SMTPSVC(8.5.9600.16384); Sat, 1 May 2021 01:08:09 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=planet.nl; s=planet01; h=message-id:to:date:subject:mime-version:content-type:from; bh=CE5nzBvg3yDJ9LxfBph3vdC4W72zLjnAU1cRnNP5Bes=; b=KFeIor1HOocSeg+k+0mWEEUJapkNgqdzPQ+Cf0l4KStQhuY6WIUY+0JWF+gYprmyqAOxH2PS6W6Ed G0eanwtPGPpjT1d2yUdcjU/+zeXLivZlib1XxUwv+6M98XmWmqZg2PBlI3Un06w/nnT98Q0zTB/cc0 pDtHkfnWbXSHfj7U= X-KPN-VerifiedSender: Yes X-CMASSUN: 33|IOx8uDbtEgaHJYBnuwK4xyQSPDvWMlEU4qbQh6dwarlr5b3SeaV1aAv2PjjB99T E3HDvxd4QeAx9YUche94AjQ== X-Originating-IP: 80.101.112.122 Received: from mba2.fritz.box (sqlite.xs4all.nl [80.101.112.122]) by smtp.kpnmail.nl (Halon) with ESMTPSA id ed74e6e1-aa08-11eb-b235-005056ab7447; Sat, 01 May 2021 01:08:08 +0200 (CEST) From: Paul Ruizendaal Content-Type: multipart/alternative; boundary="Apple-Mail=_AA19E806-6C29-478E-8D7D-75EB5C41397B" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Sat, 1 May 2021 01:08:08 +0200 References: <15D66A4F-D935-4313-93C8-CBB66039E0BD@planet.nl> <202104251249.13PCnaFV031741@freefriends.org> To: TUHS main list In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3608.120.23.2.4) X-OriginalArrivalTime: 30 Apr 2021 23:08:09.0145 (UTC) FILETIME=[AF90B290:01D73E15] X-RcptDomain: minnie.tuhs.org Subject: Re: [TUHS] pcc in 8th edition X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: The Unix Heritage Society mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" --Apple-Mail=_AA19E806-6C29-478E-8D7D-75EB5C41397B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I=E2=80=99m still playing with PCC2. I=E2=80=99ve solved the issue with = building an ILP32 version, but the =E2=80=99stin=E2=80=99 file remains = equally intriguing and mysterious. Unfortunately, it seems that PCC2 retargeting manual is lost - so this = list appears my best source. =46rom 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 (=E2=80=9COPCODES=E2=80=9D) and = addressing modes (=E2=80=9CSHAPES=E2=80=9D). 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 =E2=80=99stin=E2=80=99 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 =E2=80=9Cneeds=E2=80=9D field. The grammer for the =E2=80=99stin=E2=80=99 pre-processor has the = following comment about the =E2=80=99needs=E2=80=99 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 =E2=80=99stin=E2=80=99 file for = the 68K: operation: =3D shapes: SAWD[sus], SAWD[sus] (means: operands = must be "signed/unsigned addressable short words") needs: {$C} macro: "mov.w AR,AL" operation: =3D shapes: LAWD[lul], LAWD[lul] needs: {$C $l $r} macro: "mov.l AR,AL=E2=80=9D 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: =3D shapes: LAWD[lul], LAWD[lul] needs: {$R $l $r} macro: =E2=80=9CRL!R mov.l AR,AL=E2=80=9D Hopefully there is somebody on the list who has worked with PCC2 and = still remembers about the =E2=80=99needs=E2=80=99 field. Paul > Thank you, that Usenix paper is most helpful. >=20 > 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. >=20 > For ease of reference I=E2=80=99ve put the M68K compiler that is = included in the Blit source tree = (https://www.tuhs.org/Archive/Distributions/Research/Dan_Cross_v8/ = ) = here: > https://gitlab.com/pnru/pcc2_m68k >=20 > Anybody who has some more info on how to read a =E2=80=9Cstin=E2=80=9D = file, please share. >=20 > Paul >=20 >> On Apr 25, 2021, at 7:11 PM, Clem Cole > wrote: >>=20 >> yes i'll mail under separate cover a scan >> =E1=90=A7 >>=20 >> On Sun, Apr 25, 2021 at 11:47 AM Paul Ruizendaal > wrote: >> By now found some more clues, in particular this link: >> = http://computer-programming-forum.com/47-c-language/fab825b2dce1aa59.htm = = >>=20 >> Apparently I am talking about PCC and PCC2 in the below question. >>=20 >> 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) >>=20 >> Anybody have that? >>=20 >> The second post mentions official documentation: >>=20 >> "In porting QCC, a useful text is the "Portable C Compiler -=20 >> Version 2 (PCC2) Internals". It includes documentation of=20 >> stin file formats, PCC2 tree forms, debugging flags, and=20 >> compiler #defines. The manual is expensive so it's worth it=20 >> most if you buy it before you figure it all out doing a=20 >> port. Since the manual is based on PCC2 (and hasn't been=20 >> updated), it's a good starting point, but doesn't have the=20 >> latest information.=E2=80=9D >>=20 >> Anybody have that? (It is not on bitsavers) >>=20 >> Paul >>=20 >> > On 25 Apr 2021, at 14:49, arnold@skeeve.com = wrote: >> >=20 >> > 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 = >> >=20 >> > HTH, >> >=20 >> > Arnold >> >=20 >> > Paul Ruizendaal > wrote: >> >=20 >> >> For clarity and ease of reference: >> >>=20 >> >> - The =E2=80=9CTour of paper=E2=80=9D is for instance here: = http://citeseerx.ist.psu.edu/viewdoc/summary?doi=3D10.1.1.48.3512 = = > >> >>=20 >> >> - 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=3DSysIII/usr/src/cmd/cc/vax/pcc= /table.c = = > >> >>=20 >> >> - The new style description in 8th edition is here: = https://www.tuhs.org/cgi-bin/utree.pl?file=3DV8/usr/src/cmd/ccom/vax/stin = = > >> >>=20 >> >> - The program that translates the =E2=80=9Cstin=E2=80=9D file to a = =E2=80=9Ctable.c=E2=80=9D file is here: = https://www.tuhs.org/cgi-bin/utree.pl?file=3DV8/usr/src/cmd/ccom/common/st= y.y = = > >> >>=20 >> >>=20 >> >> =3D=3D=3D=3D >> >>=20 >> >> Sometimes one thing leads to another. >> >>=20 >> >> 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. >> >>=20 >> >> 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. >> >>=20 >> >> This source does not have a =E2=80=9Ctable.c=E2=80=9D in the well = known format as described in the =E2=80=9CA tour of the portable C = compiler=E2=80=9D paper. Instead it uses a file =E2=80=9Cstin=E2=80=9D = which appears to be in a more compact format and is translated into a = =E2=80=9Ctable.c=E2=80=9D file by a new pre-processor ("sty.y=E2=80=9D). = Then looking at the VAX compilers for 8th and 10th edition, these too = use this =E2=80=9Cstin=E2=80=9D file. >> >>=20 >> >> 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. >> >>=20 >> >> A quick google did not yield much background or documentation on = the STY format. >> >>=20 >> >> 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? >> >>=20 >> >> Many thanks in advance >> >>=20 >> >> Paul >> >>=20 >>=20 --Apple-Mail=_AA19E806-6C29-478E-8D7D-75EB5C41397B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
I=E2=80=99m still = playing with PCC2. I=E2=80=99ve solved the issue with building an ILP32 = version, but the =E2=80=99stin=E2=80=99 file remains equally intriguing = and mysterious.

Unfortunately, it = seems that PCC2 retargeting manual is lost - so this list appears my = best source.

=46rom 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 (=E2=80=9COPCODES=E2=80=9D) and addressing modes = (=E2=80=9CSHAPES=E2=80=9D). 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 =E2=80=99stin=E2=80=99 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 =E2=80=9Cneeds=E2=80= =9D field.

The grammer for the = =E2=80=99stin=E2=80=99 pre-processor has the following comment about the = =E2=80=99needs=E2=80=99 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 =E2=80=99stin=E2= =80=99 file for the 68K:

operation: =3D
shapes: SAWD[sus], SAWD[sus] = (means: operands must be "signed/unsigned addressable short = words")
needs: = {$C}
macro: = "mov.w AR,AL"

operation: =3D
shapes: LAWD[lul], = LAWD[lul]
needs: = {$C $l $r}
macro: = "mov.l AR,AL=E2=80=9D

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: =3D
shapes: LAWD[lul], = LAWD[lul]
needs: = {$R $l $r}
macro: = =E2=80=9CRL!R mov.l AR,AL=E2=80=9D

Hopefully there is somebody on the list who has = worked with PCC2 and still remembers about the =E2=80=99needs=E2=80=99 = 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.
For ease of reference I=E2=80=99ve put = the M68K compiler that is included in the Blit source tree (https://www.tuhs.org/Archive/Distributions/Research/Dan_Cross_v= 8/) here:
https://gitlab.com/pnru/pcc2_m68k

Anybody who has some more info on how = to read a =E2=80=9Cstin=E2=80=9D file, please share.

Paul

On Apr 25, 2021, at 7:11 PM, Clem Cole <clemc@ccc.com> = wrote:

yes  i'll mail under = separate cover a scan
3D""=E1=90=A7
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/fab825b2dce= 1aa59.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.=E2=80=9D

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 =E2=80=9CTour of = paper=E2=80=9D is for instance here: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=3D10.1.1.48.35= 12 <http://citeseerx.ist.psu.edu/viewdoc/summary?doi=3D10.1.1.48.35= 12>
>> 
>> - 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=3DSysIII/usr/src/cmd= /cc/vax/pcc/table.c <https://www.tuhs.org/cgi-bin/utree.pl?file=3DSysIII/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=3DV8/usr/src/cmd/cco= m/vax/stin <https://www.tuhs.org/cgi-bin/utree.pl?file=3DV8/usr/src/cmd/cco= m/vax/stin>
>> 
>> - = The program that translates the =E2=80=9Cstin=E2=80=9D file to a = =E2=80=9Ctable.c=E2=80=9D file is here: https://www.tuhs.org/cgi-bin/utree.pl?file=3DV8/usr/src/cmd/cco= m/common/sty.y <https://www.tuhs.org/cgi-bin/utree.pl?file=3DV8/usr/src/cmd/cco= m/common/sty.y>
>> 
>> 
>> =3D=3D=3D=3D
>> 
>> 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 =E2=80=9Ctable.c=E2=80=9D in the well known format as = described in the =E2=80=9CA tour of the portable C compiler=E2=80=9D = paper. Instead it uses a file =E2=80=9Cstin=E2=80=9D which appears to be = in a more compact format and is translated into a =E2=80=9Ctable.c=E2=80=9D= file by a new pre-processor ("sty.y=E2=80=9D). Then looking at the VAX = compilers for 8th and 10th edition, these too use this =E2=80=9Cstin=E2=80= =9D 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
>> 

=
= --Apple-Mail=_AA19E806-6C29-478E-8D7D-75EB5C41397B--