Article View: comp.arch
Article #2194Re: Memory utilization & inter-process contention
From: John R. Levine
Date: Tue, 12 Sep 1989 02:31
Date: Tue, 12 Sep 1989 02:31
34 lines
2669 bytes
2669 bytes
In article <34640@apple.Apple.COM> baum@apple.UUCP (Allen Baum) writes:
>Hear, hear! I'm not particularly a fan of VAX, but its getting a lot of bad
>press from the RISC people because of its performance vs. the new chips.
>This is NOT because it is a bad design, its because its an old design, and
>the nature of the tradeoffs have changed. ...
Maybe I'm just an old grouch (and programming around all the microcode bugs
bringing up 4.1 on a /750 made me mighty grouchy) but it seems to me that
the Vax was never that good a design. The architecture was predicated on a
technological bet that microcode memory would always be faster than regular
memory, and when that turned out to be wrong the penalty for the heavily
microcoded implementation that the Vax demands has become very large.
Also, it has the distinct flavor of having been designed by a bunch of guys
sitting around saying "yeah, that would be nice, we'll put it in microcode
so it will be fast" and thereby ending up with an architecture that is
practically impossible to pipeline and has complicated instructions that
nobody uses because it's faster to get the same effect using simpler ones.
I don't doubt that the OS and compiler guys were in on the design, but a
little more scepticism about what the software guys asked for would have
helped a lot.
For comparison, consider the considerably older IBM 360 architecture. They
made a few real goofs, notably 24 rather than 32 bit addresses which they
are still slowly fixing, and hex floating point. Nonetheless, the
relatively regular architecture and fixed instruction formats have worn
well. There are relatively few instructions that nobody uses (MVZ and LNR,
perhaps.) IBM has certainly had more success with really fast 360s than DEC
has with really fast Vaxen. (The software which one runs on a really fast
360 is an entirely different argument, though.)
--
John R. Levine, Segue Software, POB 349, Cambridge MA 02238, +1 617 492 3869
johnl@esegue.segue.boston.ma.us, {ima|lotus}!esegue!johnl, Levine@YALE.edu
Massachusetts has 64 licensed drivers who are over 100 years old. -The Globe
Technical Details
Message-ID:
<1989Sep12.023158.2050@esegue.segue.boston.ma.us>Path:
arc1-ca.pugleaf.net!utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!sun-barr!decwrl!decvax!ima!esegue!johnlReferences:
<70663@yale-celray.yale.UUCP> <34640@apple.Apple.COM>Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!sun-barr!decwrl!decvax!ima!esegue!johnl From: johnl@esegue.segue.boston.ma.us (John R. Levine) Newsgroups: comp.arch Subject: Re: Memory utilization & inter-process contention Message-ID: <1989Sep12.023158.2050@esegue.segue.boston.ma.us> Date: 12 Sep 89 02:31:58 GMT References: <70663@yale-celray.yale.UUCP> <34640@apple.Apple.COM> Reply-To: johnl@esegue.segue.boston.ma.us (John R. Levine) Organization: Segue Software, Cambridge MA Lines: 34