🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.arch
Article #2194

Re: Memory utilization & inter-process contention

#2194
From: John R. Levine
Date: Tue, 12 Sep 1989 02:31
34 lines
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!johnl
References: <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