Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site duke.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!harpo!decvax!mcnc!duke!bcw
From: bcw@duke.UUCP (Bruce C. Wright)
Newsgroups: net.micro.pc
Subject: Re: Digital Research Compilers ???
Message-ID: <4370@duke.UUCP>
Date: Wed, 16-May-84 13:55:28 EDT
Article-I.D.: duke.4370
Posted: Wed May 16 13:55:28 1984
Date-Received: Thu, 17-May-84 04:19:19 EDT
References: <12400005@acf4.UUCP>
Organization: Duke University
Lines: 47

I've been using the Digital Research PL/I compiler, and have found it
a fair (I don't think I would say 'good') implementation.  The compiler
generates very large code (contrary to some of the benchmarks I saw,
which was one of the reasons I bought it), especially if you do any
string operations at all (it likes to generate lots of temporaries
for example, and NEVER re-uses the space!!!).  It claims to be an
optimizing compiler, but it looks to me that it must only have a
peephole optimizer at most (and I tend to agree with Ullmann (?) that
a peephole optimizer is simply another way of saying reasonable code
generation, not optimization).  It is incapable of discovering what
it has in registers, for example:

	j = x (i) + y (i)

will generate code like

	MOV	SI,I
	MOV	AL,X[SI]
	MOV	DI,I		; !!!
	ADD	AL,Y[DI]
	MOV	J,AL

and so forth.  This is taken literally from a program fragment
with the names changed to protect the innocent.  From what I have
seen in other reviews, this is typical of DR compilers, notably the
DR C compiler (I think there's a review of several C compilers in the
latest PC World or maybe PC, and the DR C compiler comes out rather
bad in code generation, as might be expected since I have heard that it
uses the same code generator as the PL/I compiler).

The compiler has a number of bugs, some serious, some not so serious.
It is a rather weak implementation of PL/I.  There are a number of bugs
in the utilities, notably the assembler.

On the other hand, the documentation and packaging are well-done.  It's
nice to have a reasonable manual, although for most of my purposes
except for compiler pecularities and assembler interfacing conventions
I don't really need a PL/I manual.

On balance I would probably reccommend that the current version of the
compiler is not worth the rather stiff price unless you have PL/I
programs which you need to transport to the 8086 architecture but 
which don't use much of the language.  In all fairness I don't know how
much of this also applies to other DR languages ... and I'm not sure I
want to find out.

				Bruce C. Wright