Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 (Tek) 9/26/83; site tekig1.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!harpo!seismo!cmcl2!floyd!vax135!cornell!uw-beaver!tektronix!tekig1!dont
From: dont@tekig1.UUCP (Don Taylor)
Newsgroups: net.micro.pc
Subject: Re: Re: Digital Research Compilers ???
Message-ID: <1656@tekig1.UUCP>
Date: Fri, 18-May-84 04:19:45 EDT
Article-I.D.: tekig1.1656
Posted: Fri May 18 04:19:45 1984
Date-Received: Sat, 19-May-84 01:31:24 EDT
Organization: Tektronix, Beaverton OR
Lines: 19

X
     In partial response to bcw@duke's comments about the quality of code
of Digital's compilers.  I think PART of the problem is the processor, not
the compiler writer.  Looking at early releases of the intel 286 compiler
writers guide, and the extremes necessary to generate any sort of decent
code, it is amazing we have compilers now at all.  Separate compilation is
almost out of the question, you just can't tell, without lots of hints from
the user if you need to reload registers or not.  If you want to stick to
64k of memory, and I thought escaping that limit was what all the bother
was about, you can do fairly well.  You WILL NOT have much left in the
registers to be able to reuse to make better code, the stuff just keeps
getting clobbered.  With lots of work, 3 passes through the tree, for the
code generation alone in the above reference, plus code modification and
rewrite at the link/locate point, you can avoid reloading TOO many registers.
I agree that his example looks pretty silly from the human point of view,
but I wonder what it looks like from the inside of a code generator?
(I'd rather have general registers with lots of leftovers, but thats just
 to make my job easier)
Don Taylor