Path: utzoo!mnetor!uunet!husc6!cca!mirror!ima!johnl
From: rcodi@yabbie.rmit.oz.au (Ian Donaldson)
Newsgroups: comp.compilers
Subject: Re: Compilers producing assembly language
Message-ID: <832@ima.ISC.COM>
Date: 14 Dec 87 04:00:59 GMT
References: <765@ima.UUCP> <26100001@nixpbe.UUCP> <782@ima.ISC.COM>
Sender: johnl@ima.ISC.COM
Reply-To: rcodi@yabbie.rmit.oz.au (Ian Donaldson)
Organization: RMIT Comm & Elec Eng, Melbourne, Australia.
Lines: 88
Approved: compilers@ima.UUCP

In article <782@ima.ISC.COM>, rcd@ico.isc.COM writes:
> [I've heard that an astounding fraction of PCC's time is usually spent in
> the printf() calls to write out the assembler code.  -John]

Yes, and the Berkeley Pascal compiler is similar.  I once gprof'd both
pcc and pc and found this, and then went and changed all the printf's
that had no variable part (ie: no %'s) into basically puts().
There were a lot of them.  It did speed it up significantly.

With Pascal in an environment where separate compilation is inconvenient
(do to portability problems with other compilers and OS's) one is faced
with most of the compilation time being spent in the assembly phase
with most versions of the Berkeley compiler, at least for the 68000 family.  
(I haven't seen real Berkeley pc on other than vax or 68k machines)

This is due to the span-dependent instruction resolution (SDI) being
done over the entire (often 20000-line) assembly file.   (SDI's are
long/medium/short branch optimizations).  

In the Sun version of /bin/as, there is an option (-J) that turns off
SDI optimizations so that back-references are efficient and forward
references are inefficent but will always work.   The code that comes
out is a bit slow, but compilation time is dramatically reduced.

In the Sun documentation for their assembler (SunOS 3.2 or 3.3) there
is mention of a ".proc" directive that breaks up the assembler file
into separate modules... so that SDI optimization can be done more quickly
in a localized area such as procedure or function.  Unfortunately
the compilers don't yet generate such an instruction.

At the moment, the Sun Berkeley Pascal compiler (SunOS 3.3) is about 4
times -slower- than a very old version (1984 vintage) Silicon Valley Software 
(SVS) Pascal compiler on the same machine.  With a 1800 line program, 
I get the following figures:

	pc -g -H -C test.p		17.2u 1.3s 0:24   Current Sun/Berkeley
	spc -g test.p 			 4.3u 0.8s 0:08   very old SVS

(both compiles generate run-time check code and debug code; I didn't
use -O with pc since spc doesn't have an equivalent).  The code tested
here is very typical -- 18000 line programs yield much the same result.

This is interesting, because the SVS compiler is multi-pass also, and
both first passes of each compiler take about the same time as each
other.  This means that the parser/lexical analysis is of similar quality
in each.  

Berkeley pc does the following passes:  pc0-f1-pc2-[c2]-as-pc3
(on the Sun its slightly different now, but basicaly the same)
SVS Pascal does the following passes:   pascal-code-ulinker

pc0 and pascal are about the same speed and do pretty much the same things;
ie: generate a binary description for the code generator (f1-pc2, code).

This means that the speed differences come in at the code-generation
level.  SVS's code is generated by "code" in one step after parsing.
The "ulinker" stage is a module linker that also converts the SVS object
format into UNIX .o format, and -also- scans the SVS pascal library
for library routines.  The resultant only has to be linked with the
C library to be complete.  The ulinker stage is necessary because
of the UCSD nature of the SVS pascal -- module interdependencies must
be checked.  (Its done differently on the ns32000 version).

The Berkeley pc compiler uses 3-4 passes in code generation 
(f1-pc2-[c2]-as-pc3), and this is where the big difference in speed lies.
You've got 2-3 parsers in this (one in pc2, one in c2, one in as), and
3-4 output routines (one in f1, one in pc2, one in c2 and one in as).
All this time is spent converting from binary to text and back again,
several times.

The code that pops out the end for the two compilers is comparable in quality, 
if both compilers generate 68000 code (since our -old- version of SVS
only generated 68000 code; I suspect that newer SVS's would reverse
this trend).

Prior to SunOS 3.0, the code that popped out  the end of the two compilers
was far better in SVS; now it is slightly the other way around, probably due to 
a major overhaul of the code generator in pc0 (I saw the source of 
the old version of pc distributed with the Vax 4.2 release, the one
that came with SunOS 2.0-2.2) -- the 68k code in there was
abominable in parts -- almost no register variables were used)

Ian D
--
Send compilers articles to ima!compilers or, in a pinch, to Levine@YALE.EDU
Plausible paths are { ihnp4 | decvax | cbosgd | harvard | yale | bbn}!ima
Please send responses to the originator of the message -- I cannot forward
mail accidentally sent back to compilers.  Meta-mail to ima!compilers-request