Talk:VAX/Archives/2012

The VAX as a mainframe?

Regarding the recent categorisation of the VAX as a mainframe, I observe that it is denoted as such on a whole lot of websites around. I most certainly agree that the machine looked pretty much like "big iron", but should we actually categorise this and other superminis as belonging to the class of mainframes? --Wernher 19:19, 4 September 2005 (UTC)

While I'd never include most VAXen in that category, Digital definitely tried to market the VAX 9000 model as a mainframe. Whether they were successful at that is debateable, but given that they called it a mainframe, I'd say we should too.

Atlant 16:58, 6 September 2005 (UTC)

Wasn't the whole mainframe/mini thing really more of a marketing angle rather than a usefully descriptive term? I recall various usenet discussions about what really constitutes a mainframe and what doesn't, a few of which have some merit (ie throughput vs. CPU power) but ultimately it seemed that consensus was that it was down to whatever the vendor decided to call it. Chris 22:08, 10 July 2006 (UTC)

There's a lot to be said for that idea. Another idea, of course, and one that had a lot to do with Digital's demise in the highest-end market is that "a mainframe is any computer that runs MVS (Z/OS, etc.)". In any case, Digital definitely tried several times to enter the "mainframe" business, but the VAX 9000 was their best shot.

Atlant 00:22, 11 July 2006 (UTC)

I can't help wondering if DEC contributed to the "a mainframe is something that runs MVS" viewpoint by strongly marketing the early Vax line as a refreshing change to what were seen as stuffy old batch-oriented mainframes. I think that by distancing the Vax from the mainframe stereotype of the time and later trying to cash-in on the market was a bit of a case of trying to have their cake and eat it, and it wasn't going to happen. That's my understanding of how things were, anyway: I wasn't around in the early days and only have various other people's recollection of history to go on, but I do know that a good few Vax-heads were still vehemently of the opinion that the Vax was definitely not a mainframe (often using the argument that a Vax was a nice interactive environment and a mainframe wasn't, although I'm not sure how much most end-users bashing away at some transaction-processor would've noticed the difference). I think that'll do for today's ramble! Chris 17:51, 11 July 2006 (UTC)

(Venturing off into my own personal opinion now...) I think that another aspect that distinguishes a "mainframe" from other computers is the customer's expectations of reliability and availability. Mainframes are expected to simply always be there, and when you look at some of the directions that IBM has taken with the Z series, this becomes especially obvious. For example, they designed the microprocessors with dual cores, but not for increased throughput (as they do in their Unix servers), but instead for increased reliability; they then run the two cores in lock-step, comparing the results of each machine instruction executed. If a mis-compare occurs, they fault the instruction out to the service processor and it sorts out which core got it right, retries the failing instruction, and, if a core continues to fail, maps out that core and calls the IBM SE to come fix the problem at some convenient time. The end result is that from the user's point of view, the user's program ran flawlessly, even in the face of a failed CPU core. This is different than the approach that VAX (and VMS) took, whereby individual nodes were allowed to crash. The user could certainly restart their work, but the crash was definitely a user-visible event. Only a very few VAXen (the FT series) approached the sort of seamless operation that mainframes now routinely deliver. Even the Tandem Computers' approach isn't like this; they required the user to help program-in the recovery from hardware failures.

You see this same thing in power supply redundancy, chiller redundancy, and so on. Mainframes are just not supposed to ever trouble the user with nasty things like hardware failures.

Atlant 12:29, 12 July 2006 (UTC)

RAS (Reliability, Availability, Scalability) was a defining feature of mainframes in the eyes of mainframe customers. The 9000 had RAS features comparable to its mainframe competition, and of a character and scale unlike previous VAXes.

Tim Leonard (talk) 13:35, 11 March 2012 (UTC)

Instruction set section - RISC vs. CISC, etc.

This section was added by an IP today. I like the material in this section. As someone who wrote significant amounts of VAX assembly code, and who followed the development of RISC processors, I feel there is much value in this section, as it ties one of the most successful CISC machines to the development of RISC machines. (Though perhaps this section should be later in the article, and more information about the ISA added before this part.) However, true though it is, as it stands it's WP:OR -- it needs references. I know the references are out there; I read some of them when they were first published. (I recall one in which the researcher found it was faster to do what a CALLS or a CALLG does "manually", with individual PUSHL's.) Let's find them. Jeh (talk) 22:47, 16 March 2011 (UTC)

thanks for kind words; if someone has a copy of Hennessy & Patterson they can easily add useful refs, as well as CISC-vs-RISC (also VLIW) is well document —Preceding unsigned comment added by 70.189.170.229 (talk) 20:23, 17 March 2011 (UTC)

I like having this topic, but have a problem with much of the content. I don't remember hearing that ease of writing assembly code was a design goal. One goal may have been to reduce the abstraction gap between high-level languages and machine code (which was certainly being discussed in industry publications at the time), but if that was a goal it may have been for the purpose of making the compiler-writer's job easier, as orthogonality was. A likelier performance justification for complex instructions was the relative density and speed of microcode store compared to hardwired logic, and the expectation that it would continue to provide an advantage.

The complexity of the VAX instruction set certainly did not initiate the early research into RISC. Cocke was working on the 801 in 1975, and that may have been in response to Seymour Cray's designs from even earlier (see Gordon Bell's talk "A Seymour Cray Perspective").

The complexity of the instruction set is irrelevant except as it affects price or performance (or implementation difficulty). Many of the complex instructions (decimal instructions, some string instructions) were moved into software at little to no cost in performance. So their inclusion in the architecture was unnecessary but did no harm. The variable-length instructions made superscalar designs harder (though not impossible, as at least one militarized VAX showed by dynamically translating VAX instructions into fixed-length internal instructions) but made compiling a lot easier. One could argue that a higher quality compiler would give more users higher performance than a poorer quality compiler on faster hardware. And I'm not at all sure that architects had imagined superscalar implementations when VAX was conceived.

The fact that the relative performance of instructions was different on different implementations is true of all architectures, not just VAX, and is unrelated to the instruction complexity.

The complexity of POLY did bite us. On none of the first nine implementations did the warm (microcode) and hot (hardware) versions of POLY produce exactly the same results, despite the intention that results from all implementations would be identical to the last bit. Tim Leonard (talk) 14:44, 11 March 2012 (UTC)

Movie sighting

The movie "On Deadly Ground" shows 27 minutes in, VAX machines running the control center of the oil platform "Aegis 1". Electron9 (talk) 23:48, 13 September 2012 (UTC)

Military VAX

A video of some MILVAX circuit boards. http://www.youtube.com/watch?v=55z_0BYb5is Bizzybody (talk) 06:01, 11 October 2012 (UTC)