Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!husc6!hao!ames!pioneer!lamaster From: lamaster@pioneer.arpa (Hugh LaMaster) Newsgroups: comp.arch Subject: Re: The 360 was a design landmark (360 vs vax) Message-ID: <2595@ames.arpa> Date: Wed, 26-Aug-87 15:46:40 EDT Article-I.D.: ames.2595 Posted: Wed Aug 26 15:46:40 1987 Date-Received: Fri, 28-Aug-87 06:25:38 EDT References: <855@tjalk.cs.vu.nl> <2683@hoptoad.uucp> <916@haddock.ISC.COM> <418@astroatc.UUCP> <26444@sun.uucp> Sender: usenet@ames.arpa Reply-To: lamaster@ames.UUCP (Hugh LaMaster) Organization: NASA Ames Research Center, Moffett Field, Calif. Lines: 82 In article <26444@sun.uucp> guy%gorodish@Sun.COM (Guy Harris) writes: (someone else writes:) >> The 360 designers saw fit (or did they just guet luckie...I don't >> think so!) to design *PIPELINING-CAPABILITY* into the 360. > >I dunno about that; when did the first pipelined machines come out? Well, the 360/91 was pipelined, and was a very competitive machine to the CDC 6600; the 360/370/195 was pipelined, and was a very competitive machine to the CDC 7600 (mid 60's to early 70's for these landmarks). If the trade press is to be believed, the reason IBM got out of the big machine market during the early seventies was because of the famous CDC/IBM lawsuit and the Justice Dept. antitrust suit, and because it was seen as politic to leave some niche markets untouched, not because IBM couldn't build faster machines. IBM has gotten back in in a modest way with the 3090/VF machines. The 360/370 architecture is amenable to a modest amount of pipelining, and it is certainly easier to implement pipelined versions than the VAX architecture, for all the reasons mentioned by previous posters: simple instruction decode, simple addressing modes (but not a load/store machine, which complicates some things) which are known at decode time, register usage known upon decode, etc., etc. The 360 architecture is as much a RISC machine as several widely marketed "RISC" machines, though still a CISC machine by comparison with MIPS, say. Had it been a load/store machine like CDC, it would have been easier to pipeline. By comparison, the VAX is much more difficult. Face it: DEC tried for a long time before producing the 8600, falling further and further behind the general marketplace in price/performance and performance. A lot of companies like MIPS, Sun, Sequent, etc, might not exist if DEC hadn't. > >> reason the ancint 360/370 stuff is still alive, while DEC's vaxen >> are falling by the wayside (despite DES's best efforts) > >VAXes falling by the wayside? I dunno about that, either. DEC, VAXes, and VMS >seem to be doing quite well for themselves. I think the person meant in performance, which is certainly true. Not in marketing :-) > >> is that 360's *CAN* be pipelined (tho not necessarily real easily) and >> VAXen can't! > >VAXes can't be pipelined? Gee, I suspect some of the 8600's designers would be >surprised to hear that. > Only very limited pipelining is possible with the VAX architecture. It is just about the worst in that respect of any major computer architecture. In fact, it seems to have been a reaction to the VAX which brought about the revival of ultra-pure RISC machines (RISC concepts had been in use all along on some other machines, e.g. CDC). As was previously noted, a good compiler can produce rather dense code for the VAX. The 64,000 MIPS question is: how important is that? Was it ever that important? If memory utilization was that important even in 1977, why didn't the paging hardware support direct LRU? DEC's success with the VAX was due to the 32 bit virtual memory environment- a first for minicomputers at the time- not performance or price/performance. I would second the statements of many previous posters that the 360 architecture has proven to be very versatile, and has certainly been implemented over a wider range of hardware complexity and performance than any other architecture. Too bad about that MVS stuff... Hugh LaMaster, m/s 233-9, UUCP {seismo,topaz,lll-crg,ucbvax}! NASA Ames Research Center ames!pioneer!lamaster Moffett Field, CA 94035 ARPA lamaster@ames-pioneer.arpa Phone: (415)694-6117 ARPA lamaster@pioneer.arc.nasa.gov "IBM will have it soon" (Disclaimer: "All opinions solely the author's responsibility")