Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!rutgers!ames!amdahl!nsc!voder!apple!bcase
From: bcase@apple.UUCP (Brian Case)
Newsgroups: comp.arch
Subject: Re: The 360 was a design landmark  (360 vs vax)
Message-ID: <4611@apple.UUCP>
Date: Thu, 27-Aug-87 12:57:08 EDT
Article-I.D.: apple.4611
Posted: Thu Aug 27 12:57:08 1987
Date-Received: Sat, 29-Aug-87 10:06:08 EDT
References: <855@tjalk.cs.vu.nl> <2683@hoptoad.uucp> <916@haddock.ISC.COM> <2596@ames.arpa> <18093@amdcad.AMD.COM>
Reply-To: bcase@apple.UUCP (Brian Case)
Organization: Apple Computer Inc., Cupertino, USA
Lines: 20

In article <18093@amdcad.AMD.COM> tim@amdcad.AMD.COM (Tim Olson) writes:
>In article <2596@ames.arpa>, lamaster@pioneer.arpa (Hugh LaMaster) writes:
>So, overall, the VAX was more compact, although the RT was within 10% in
>many cases, and was more compact in some.
>  [Plus other stuff about code density]

It must also be realized that *optimized* does not necessarily mean "less
code."  At certain points, it is possible to optimize for size at the
expense of speed, and vice-versa.  When choosing instruction encodings, this
is almost always the case (space/time trade-off).  The VAX simply *allows*
high code density; that is not to say that the "optimial" VAX encoding of
a given program is also the densest VAX encoding of the program.  However,
it is my belief that RISCy instruction sets allow the optimizer to operate,
most of the time, under the assumption that "if I can remove this instruction,
I'll be saving both time and space, and I know *exactly* how much space and
probably how much time."  Unfortunately, this assumption doesn't hold very
well when you start talking about scheduling (load/store, delayed branches,
etc.).

    bcase