Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!decwrl!decvax!ima!haddock!suitti From: suitti@haddock.ima.isc.com (Stephen Uitti) Newsgroups: comp.arch Subject: Re: In defense of the VAX Message-ID: <11867@haddock.ima.isc.com> Date: 24 Feb 89 18:37:09 GMT References: <4592@tekgvs.LABS.TEK.COM> <638@m3.mfci.UUCP> <11037@tekecs.TEK.COM> <653@m3.mfci.UUCP> <2066@pembina.UUCP> <660@m3.mfci.UUCP> Reply-To: suitti@haddock.ima.isc.com (Stephen Uitti) Organization: Interactive Systems, Boston Lines: 179 In article <660@m3.mfci.UUCP> rodman@mfci.UUCP (Paul Rodman) writes: >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. This may have been a contributer to the kitchen sink approach to the VAX design. When I played with the PDP-11, I'd hoped that the VAX 11 series was really just a Virtual Address Extension PDP-11. Just get rid of the 'mark' instruction, provide just a 'jsr pc,foo' style subroutine calling sequence, and replace the post autodecrement defered addressing mode with something useful. Make the registers 32 bits and have 16 of them. Think of instructions in terms of 32 bit words with 32 bit operands. It'd be great. Then write TOPS 20 for it - the best OS available anywhere at the time (and still one of the best - POSIX notwithstanding). Make it demand paged with 1 KB pages. My hopes were dashed. When I started playing with it, I had hopes that I could use the machine the way I wanted by ignoring the other stuff. Sigh. Life doesn't work that way. >DEC had taken a lot of heat and suffered internally for creating >so many different incompatable machines. At the time, DEC had the '8, the '10, and the '11 (for popular machines). These all worked pretty well. I never understood what they meant by "all those different incompatible machines". They served such different purposes that it was OK. Just let them talk to each other - but that's just software. But the '10 didn't have enough address space to be a high end machine anymore. DEC needed a new machine. I'd hoped that they'ed come up with a '10 style machine with 64 bit words and 32 bit halfwords, so that the PC would be 32 bits. That would hold them through the rest of the century - by which time it would have incredible software. Go for the one-word per instruction that the original '10 had so you could implement it in descrete transistors like the KA-10. With a little thought the machine should scream. Of course, the "just let them talk to each other" did sort of get fixed - with DECnet. The '10 had TCP/IP, and now it is at least sort of available for VMS. The only machine without this is the '8, which seems to be pretty much dead. Why use an '8 if an '11 can be had on a chip? There are reasons to use an '11 even though a VAX can be had on a chip. >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. The VAX really is pretty nice to use. The main reason that I wouldn't have done it is "How do you make one of these things work?". An architecture with that much stuff in it will be impossible to verify and hard to make work well enough to be useful. DEC has pretty much solved these very hard problems. The 8700 series shows one way to do it. Make the core machine simple. Do the hard stuff in ucode. Noone uses it anyway. >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 error was the calls instruction. It handles register save/restore. It handles argument poping. It did the frame. There's a return instruction that knows which instruction type did the call and does "the right thing". It slices, it dices. Was it a year ago? DMR posted notes he'd sent around AT&T on his first pre-release impressions of the VAX. At the time, he liked it (the calls idea). It has taken some time for the industry gurus to decide that this wasn't such a hot idea. The industry did this to DEC. >>One doesn't fine tune a design too much because the time is better spent >>building the next iteration. DEC spent alot of time & money on the VAX design. >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. Didn't the 8700 beat the 8600 to market? Further, the 8700 was not supposed to be faster - as it was supposed to be a "medium speed" machine. It is possible that the 8650 was what the 8600 was supposed to originally do. Still, the 8600 was the 780 hardware compatible machine. It was more the 780 with new technology. The 8700 uses a new bus, etc. (They said that the new bus would be non-propriatary - then, damn their eyes, changed their mind). The CPU is of a completely different design. It is easier to make, so it shouldn't have been such a surprise that it was faster and made it out the door so quickly. The 8600 people had to do some *really hard work*. Me, I'm lazy. I'd never have done it. Laziness turns out to be one of those forces of nature right next to gravity. Don't fight it. >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. Rumor has it that the VAX 730 was the most bug-free version of the VAX. No pipelining. No problems with instructions getting in each other's way. Its biggest problem was that software was written on 780s, and the '730 didn't have enough speed to support the overhead that was OK on the '780. I write DOS applications on a 4.77 MHz 8088 for this reason. You need at least '750 performance to be a good machine. Maybe today's faster silicon could make the '730 design into the critical mass speed VAX for cheap. On the other hand, the uVAX II has this market. Also, people don't seem to want a machine that works. They seem to want a machine that is fast. Sigh. >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. Yes. I agree. I was always amazed how bit efficient the '10 was. The '10 didn't look like it ought to be. You could only do one main memory reference per instruction. Shouldn't that mean you often have to do two instructions? Apparently that isn't a problem. The '11 is really bit efficient. VAX code is twice the size of '11 code. The PC is twice the size on the VAX. Data space is nearly always the problem. Of course, a large program load image takes more disk space and takes longer to load into memory - even with demand paging (so you don't have to load the whole thing in). Shared text (instruction space) helps alot. >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? The design still has to be long-term. As portable as UNIX is (there are nearly enough people who know how port it), the industry is still at the point where the software installed base is important. People still buy (and will continue to buy) binary versions of software. They don't want to buy a machine and have to repurchase software. Of course, the software industry could provide inexpensive "upgrades" for customers for their supported set of hardware. A great idea for a startup company would be aid in porting and supporting software on the plethora of available hardware - the one company has copies of the millions of differant available machines so that not everyone has to have all that capital equipment. People buying their first machine(s) can buy whatever they want, but many people will still buy it from IBM or DEC if they think that the machine will be supported in 10 years. DEC still supports PDP-11s big time. Even all the OSs on that machine. Even all the silly revisions and versions of that machine. I'd be real surprized if you asked DEC for support on writing WCS (writable control store) on your PDP 11/60 and DEC said "no". >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 end was always in sight. Someone would say, "we can't do the next factor of 4 because of 'x'." Real soon, of course, someone (else) would say - "I've got this solution to 'x' - and it doesn't even break physics too badly." The same has been true in the speed arena. So which side am I on, anyway? - yes. >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, :-) My favorite supercomputer in (I think it was) 1983 was a VAX 780 with a third party vector processor. With a little software, one could get nearly 40 MFLOPs out of it. The Cyber 205 only yielded 170 MFLOPS (same problem & code). For about $400K, it was *very* cost effective for a number of applications. the Cyber was much more than 5 times more expensive. Nowadays, the '780 part is much cheaper, bringing the cost to under $100K. The vector part is faster and the software is lots better. Stephen. suitti@haddock.ima.isc.com, ...harvard!haddock!suitti