Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84 SMI; site sun.uucp
Path: utzoo!linus!decvax!decwrl!sun!guy
From: guy@sun.uucp (Guy Harris)
Newsgroups: net.arch
Subject: Re: Range-checking isn't an architecture issue (change in
Message-ID: <2884@sun.uucp>
Date: Sat, 12-Oct-85 19:19:20 EDT
Article-I.D.: sun.2884
Posted: Sat Oct 12 19:19:20 1985
Date-Received: Tue, 15-Oct-85 07:16:30 EDT
References: <796@kuling.UUCP> <2580002@csd2.UUCP> <191@graffiti.UUCP> <1911@bmcg.UUCP>
Organization: Sun Microsystems, Inc.
Lines: 26

> 2.  The architecture should be efficient w.r.t. the programming language, 
>     so that the compiler writer (and thus the compiler) can spend time and
>     effort in implementing the scheme, rather than in just coping with the
>     inhospitability of typical architectures.  The compiler must be simple
>     enough to have a good chance of being correct (!), and thus, the 
>     underlying architecture has to be good for the purpose.

What do you mean by "efficient with respect to the programming language?"
Not all architectural features which "look" like they make it easier to
implement a language on that architecture really help.  Adding features can
result in increasing the complexity of the hardware and the microcode in
exchange for reduced complexity in the compiler, and this may or may not be
a good tradeoff.

Furthermore, it's not even clear that it will simplify the compiler.  Good
optimizing compilers can make a difference even on stack machines, and
possibly even on the iAPX432 - in the article "Computers, Complexity, and
Controversy", by Colwell, Hitchcock, Jensen, Sprunt, and Kollar, in the
September 1985 IEEE Computer, the authors indicate that

	The 432's Ada compiler performs almost no optimization.
	The machine is frequently forced to make unnecessary
	changes to its complex addressing environment, and it often
	recomputes costly, redundant subexpressions.

	Guy Harris