Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uflorida!haven!adm!cmcl2!yale!mfci!rodman From: rodman@mfci.UUCP (Paul Rodman) Newsgroups: comp.arch Subject: Re: In defense of the VAX Message-ID: <660@m3.mfci.UUCP> Date: 23 Feb 89 19:17:57 GMT References: <4592@tekgvs.LABS.TEK.COM> <638@m3.mfci.UUCP> <11037@tekecs.TEK.COM> <653@m3.mfci.UUCP> <2066@pembina.UUCP> Sender: rodman@mfci.UUCP Reply-To: rodman@mfci.UUCP (Paul Rodman) Organization: Multiflow Computer Inc., Branford Ct. 06405 Lines: 74 In article <2066@pembina.UUCP> cdshaw@pembina.UUCP (Chris Shaw) writes: > >year old machine will look hideously out of date. Ten year old computer >fashions look as silly as ten year old clothing fashions, and for a similar >reason: today's constraint of technology or taste is not the same as tomorrow's. You guys keep missing my point, perhaps I am not being clear. I *agree* that it very hard to predict the future in computer engineering. This is *my* point. But I belive that one of the goals of the Vax project *was* not only to build a 32 bit virtual memory machine, but to create a *computer family* for the future at the same time. DEC had taken a lot of heat and suffered internally for creating so many different incompatable machines. The Vax was *not* just trying to "build a good machine for year 197x". I belive they tried to anticipate the future to the largest extent possible. My point is that, given the above, (which you may not belive, any Vax-ers out there to pipe up on this?), isn't it amazing that so many errors were made. >One doesn't fine tune a design too much because the time is better spent >building the next iteration. > And then you run smack into your bad choices. For example, the 8600, which was the successor to the 780, took an *incredibly* long time to finish, used 110+ state-of-the art ECL gate arrays, (plus super low tech *card edge* connectors at the same time?!) and inumerable boards, and was terrible slow for all that. You might claim the 8600's problems were all due to crappy engineers, but I don't think this would be very fair. The simple fact is, the vax architecture was *not* optimized with an eye toward building a pipelined version. Considering that this was THE NEXT THING THEY DID don't you think this a bit non-optimal? This *must* have contributed to the difficultly of building the 8600. Many, many other things contributed to the birth pains of the 8600, I know, but I'll bet the architecture was one of them. Any former 8600 workers out there want to fill us in? The micro-vax 1 had a great deal pain associated with it, as I recall, and I wonder how much a simpler set of instruction alignments would have helped? Any ex-microvax I designers want to contribute. Many other machines with much poorer bit efficient instruction sets existed at the same time as the vax and never was text image size a problem, compared to raw speed. You yourself pointed out that the lifetimes of computers are so short that time to market is worth an equivalent in performance. Which do think I can design-in easier: memory or gates? Besides, it was well known at the time that memory was getting a factor of 4 denser with each iteration, with no end in sight for quite a while. The vax designers, individually, were intelligent people. But as a group, they missed the boat in several areas. At any rate, I hope we can have more interesting discussions of this nature. I'm tired of byte-sex and other "boring" topics. :-) Paul K. Rodman rodman@mfci.uucp P.S. I was suprised I didn't get a rise out of anyone when I referred to the Denelcor HEP as a "pile of junk" a while ago. Isn't anybody going to stand up for the thing? After all its the only supercomputer slower than a vax 11/780 in linpack, it *needs* a champion, :-)