From Wikipedia, the free encyclopedia
Jump to: navigation, search
WikiProject Computing (Rated C-class, High-importance)
WikiProject icon This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
C-Class article C  This article has been rated as C-Class on the project's quality scale.
 High  This article has been rated as High-importance on the project's importance scale.

Emulated Vaxen?[edit]

Should we perhaps include emulators such as simh in the list of Vax hardware? (I'm running one right now in fact) Or at least some pointer to the fact that emulators exist, and actually work pretty darned well. Likewise about the DECUS/Encompass hobbyist license program?

I wouldn't put the software emulators in the list of models but I think it's definitely worth adding a short section on VAX emulation. VMS hobbyist licences should probably be mentioned in the OpenVMS article though. Letdorf 15:16, 8 August 2007 (UTC).

VAX Clustering[edit]

Although I am probably not qualified to add the comments, perhaps some recognition of Digital's work with loosely coupled processors through the VAX Cluster architecture may be in order. While IBM had been accomplishing much with more tightly coupled processing in its 360 architecture, the VAX Cluster offerred scalability, load balancing and redundancy at a fraction of the cost of IBM and, I believe, at a fraction of the complexity in OS administration.

There's no doubt that VAX clustering (now "VMS Clustering") is notable, but it tends to be more of an attribute of OpenVMS than of VAX hardware per se. We probably ought to include a better reference out to the other articles (and get them sorted out/improved).
Atlant 13:36, 21 February 2006 (UTC)

VAX as a real-time processor[edit]

It might also be useful to point out that the VAX/VMS served as the successor operating system to the highly successful PDP-11 RSX-11 operating system, which supported real-time, processor interrupt driven applications that were highly critical to shop floor and factory automation applications.

I'd offer the same comment as I offered in #VAX Clustering above; realtime performance was more an attribute of the operating system than the hardware, and even DEC realized that VMS was not a sufficiently-potent follow-on to RMS; they eventually offered VAXELN (and eventually VxWorks on Alpha) to meet the hard-core realtime marketplace. But a mention inthe VAX article would certainly be appropriate.
Atlant 13:36, 21 February 2006 (UTC)

ECL, TTC, MOS[edit]

Greg, are you sure the 11-780 was ECL? I vaguely thought it was TTL. Certainly the 11-750 a year or two later was TTL. 8700 was ECL but that came much later.

Yep, The 11/780 was TTL the MicroVAX was NMOS and the sucessors were CMOS with the top-line servers being ECL. See :
To see which model is TTL/ECL/MOS (except the MicroVaxen which were all MOS) take a look there fr:VAX. fr:Utilisateur:Poil


VAX65X0 was codenamed Mariah. VAX 66X0 was codenamend NVAX (I worked on them) VAX62X0 was Codenamed Calypso, the 63X0 had another codename, can't remeber

The lockstep redundant VAX[edit]

What was the model number/codename of the dual-processor lockstep redundant VAX that was sold in limited quantities? It was based on the Scorpio chipset, wasn't it?

Atlant 23:22, 14 August 2005 (UTC)

The VAX as a mainframe?[edit]

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)

VAX slogan[edit]

The earliest reference to the "Nothing sucks like a Vax!" slogan that I can find on usenet is I can't find any images of the slogan... Has anyone actually seen the adverts/commercials for themselves? Maybe it's apocryphal? --StuartBrady 21:26, 6 February 2006 (UTC)

Well, as far as I can remember it's been in the Jargon File for quite a while, so even if it could still be apocryphal it's at least wide-spread =) --wwwwolf (barks/growls) 16:38, 26 May 2006 (UTC)
Hah! some googling later, I found an ad picture: "Nothing sucks like an Electrolux" - and according to the Jargon file [1], this was the original phrase, VAX just copied it. Additional bits are here and here. --wwwwolf (barks/growls) 16:46, 26 May 2006 (UTC)

External link[edit]

The 57-byte instruction[edit]

Everywhere on the web one can read that the maximum length of a VAX instruction is 57 bytes, but I couldn't find an example. Maybe this would fit in the trivia section? --RolandIllig, 2006-02-20

EMODH #5345.1524[r7],@mul_ext_ptr[r0],#3.141592765[r5],@int_table[r1],@frac_table[r2] is 2+18+6+18+6+6, or 56 bytes. The first and third operands consist of a 1-byte specifier, 16-byte H_floating literal, and 1-byte index. The [r5] and [r7] indices are ignored, but allowed. The other three operands are 6 bytes: a 1-byte specifier, 4-byte address, and a 1-byte index. (talk) 01:17, 27 September 2010 (UTC)
Another fun thing is the maximum number of page faults one instruction can produce. I'm pretty certain it comes from MOVTUC, which deals with three in-memory arrays of characters, two of them up to 64Kbytes. Jeh (talk) 22:55, 16 March 2011 (UTC)
The VAX CASEL instruction has a selector, upper and lower bounds, and a variable-length branch table operand that consists of 16-bit branch offsets (with a fall-through to the instruction following the table if the selector is out of bounds). The bounds could be from 0 to 4,294,967,295 so the instruction could theoretically be a little over 8GB, but the address space is only 4GB, making a 4GB CASEL the maximum length of any VAX instruction. (talk) 21:00, 8 May 2011 (UTC)
With only 16-bit offsets, it seems plausible that the microcode would behave oddly if one attempted to make a table larger than 64kb. TEDickey (talk) 21:24, 8 May 2011 (UTC)
POLY takes a pointer to an array of floating values and a size of that array, which could be as big as the whole 4g address space. But, like CASEL, the instruction itself does not contain the actual array, merely its address (or a way of finding it). — Preceding unsigned comment added by (talk) 11:03, 8 June 2011 (UTC)

The Name[edit]

The section in the main article, titled "The Name," is more-or-less from the Jargon File.

I'd like to delete the sentence, "In the historical context, ... this seemed much less ridiculous than today," which appears to have been originated by Packrat on 04:08, 25 November 2003. My main concerns about that sentence are: it seems more editorial than encyclopedic; the appropriateness of DEC's business decision to enter into that non-competition agreement seems beyond the scope of this section, and probably of the entire article; also, I think it's best to avoid the word "today" without a date reference, especially in an article about such a rapidly changing technological and business environment. Do you disagree? If you find the sentence worth keeping in some form, perhaps you might rewrite it to describe only the historical context of the time when the agreement was made. --Rich Janis 02:40, 5 February 2007 (UTC)

My opinion is that you should not delete the sentence entirely, maybe just find a different word or phrase for the "ridiculous" part which is very POV-ish. It is still important to note the industrial electronics makers thing specifically for the context.  ?maybe make the sentence parenthetical () to make it sort-of a reference to the previous sentence? I don't know for sure... Dzubint 13:11, 6 February 2007 (UTC)
Thanks. I took out the POV. I'll let others with knowledge of the business environment assess the remaining statement's validity. --Rich Janis 10:01, 8 February 2007 (UTC)

VAX 11/788?[edit]

Does anyone know anything about this model? It's listed in some DEC software documentation but I can't find any other info about it....Letdorf 23:05, 12 July 2006 (UTC).

Nothing sucks like a VAX[edit]

In the section "The name", the "VAX" brand of vacuum-cleaners is mentioned, and it is said that

The advertising slogan of a rival vacuum cleaner manufacturer, Electrolux, was humorously punned on by users of VAX computers to the slogan "Nothing sucks like a Vax".

But in the webpage VAX, from the Jargon File, it is said that the slogan "Nothing sucks like a VAX" was adapted from Electrolux to the VAX vacuum cleaners. So I think we should put in the Wikipedia article that the slogan was indeed used by the vacuum-cleaners-makers. Jorge Peixoto 02:48, 9 March 2007 (UTC)

A quick check of Google tells me that the slogan was used by Vax_(vacuum) sometime after Electrolux used it. The timing seems to suggest that the VAX company started using the slogan sometime after it was appropriated by the VAX computer detractors. Frotz 04:04, 9 March 2007 (UTC)

Ubersoft, VAX and wikipedia...[edit]

Just an FYI... Mr. Berry 01:33, 24 March 2007 (UTC)

Vax 11/630?[edit]

What about the Vax 630? I've only seen it once and only remember that it was yet weaker than the 750 I was responsible for in the 80's, but a quick Google confirms that such a beast exists but it's not mentioned anywhere in this page.

Amos Shapira 01:29, 11 May 2007 (UTC)

I take it you are referring to the "Industrial VAX 630". I've added an entry for this based on Google results. Sounds like quite a rarity. Letdorf 10:38, 11 May 2007 (UTC).


This article has a lot of trivial detail while missing basic information about the hardware. How much memory did a VAX have? This article doesn't say anywhere. So I look on the web, find stuff like a "64MB MEMORY KIT FOR VS4000/MV3100/VAX4100" and come back to find when that was made. In the long list of all the VAX models, it neglects to mention when they were made. Nowhere in the article can you even find when the MicroVAX architecture started being made. But, oh yes, we need to know the details of the Processor Status Register. (Grumpy)--Prosfilaes 17:15, 2 October 2007 (UTC)

I have a complaint in a different direction -- the VAX profoundly reshaped the computing industry, but you'd hardly know it from reading this article. I'd be happy to see more discussion about the VAX's impact if anyone has something to contribute. -- Random person, June 2011 — Preceding unsigned comment added by (talk) 19:33, 19 June 2011 (UTC)

MicroVAX merger proposal[edit]

User Letdorf (talk · contribs) has suggested merging MicroVAX here. Since this article already covers the MicroVAX, it would only add a paragraph or two. Let's see what the consensus is. Cheers, CWC 13:53, 30 October 2007 (UTC)

  • Support. CWC 13:53, 30 October 2007 (UTC)
  • Support. There seems to be an error in the MicroVAX article. It states that the MicroVAX 2000 was the first VAX targeted at universities. It seems to me that universities were very much in mind all along. Frotz 20:36, 30 October 2007 (UTC)
  • Weak oppose. I think an organization along the lines of #Proposed expansion makes more sense. Each of the subarticles probably has more than enough references to support expansion. There should probably be a one or two paragraph summary in this page of the microvax with a "see main article". --mikeu talk 15:15, 9 November 2008 (UTC)
Given that the proposal was from last year and the merge was recently reversed, so I wouldn't worry about it too much. Rilak (talk) 05:22, 10 November 2008 (UTC)
Yes, my merge proposal referred to an earlier incarnation of the MicroVAX article, which was pretty poor and content-free. Letdorf (talk) 01:07, 15 November 2008 (UTC).

VAXen - VAXes[edit]

I think VAXen is thoroughly supported as a plural for VAX.[2] Gwen Gale (talk) 14:27, 20 February 2008 (UTC)

I think so too. Adamantios (talk) 17:32, 20 February 2008 (UTC)

Proposed expansion[edit]

I have a rough plan to expand this article. The plan requires very major changes. After it has been implemented, I don't think that the article will even resemble the current version.

The plan is:

  • Remove the listing of VAX systems from this article into something like "List of VAX-based systems".
  • Expand the article with two tables, one detailing the discreet-component VAX processors and one detailing the VLSI VAX processors. The information for the VLSI VAX processors can be easily found in issues of the Digital Technical Journal, while information for the others is harder to come by. For VLSI VAX processors, four more sections can be added to the article to discuss them:
  • MicroVAX
  • CVAX
  • Rigel and Mariah
  • NVAX and NVAX+

Not directly related to this article but, the current "List of VAX-based systems" is not detailed enough. I propose creating articles for each major VAX family, which will detail the separate models. My current scheme is to create these articles:

  • MicroVAX
  • VAX-11
  • VAX 4000
  • VAX 6000
  • VAX 8000
  • VAX 7000/10000 (redirect to DEC 7000/10000 AXP as it is similar, but expand the target article with more VAX info)
  • VAX 9000
  • VAXft
  • VAXstation

This is of course a very rough plan and it requires major changes. I am also not particularly familiar with VAX, so some of the groupings (eg. Rigel and Mariah) may be inappropriate for a reason that I am not aware of. Because of this I want to know what everyone thinks about it and what can be done better before taking any action. Any thoughts or comments? Rilak (talk) 05:16, 3 August 2008 (UTC)

The trouble with the VAX range is that it is quite tricky to categorize. For instance, some of the VAX 8xxx models could be considered part of the VAX-11 range; some, but not all, VAXstation models were related to MicroVAX models and the VAX 4000 series could be considered part of the MicroVAX family. I considered turning the list into a table, but in the end I decided a nested list reflected the relationships between the different models better (plus it would have been a lot of work!). AFAIK, Rigel and Mariah were fairly closely related, but V-11 and SOC and should be added to your list of VLSI VAX processors. Letdorf (talk) 11:56, 3 September 2008 (UTC).
Was the SOC entirely new design? I think I read somewhere that it was a single chip version of an older multichip VAX. If that is the case, it might be better for the SOC to be covered in the article for the multichip VAX. I don't know about the V-11 (haven't looked that far back), but I'll get to it as soon as I can. As for the VAX range, perhaps categorization by architecture isn't achievable, but surely categorization by brand would work? Rilak (talk) 12:34, 3 September 2008 (UTC)
I think it's a good idea to reorganize the page, but it think a better approach would be to start with the CPU families, instead of the machine families. You then have a list which expands with what machines used the different CPUs. Also, the introduction seems to be implying that virtual memory was a new thing in the VAX, which it didn't inherit. That is wrong. It is Virtual Address eXtension. Ie. it extended the virtual address concept and design from the PDP-11. Not just some general concepts about the instruction set. One of the big reasons behind the design of the VAX was the address space problems DEC had already hit with the PDP-11. They didn't want a repeat of this, so they aimed for a much larger virtual address space. / (talk) 13:58, 29 March 2010 (UTC)

Citation needed[edit]

I've added a citation for the VAX being "the ultimate CISC processor". HughesJohn (talk) 16:41, 4 October 2008 (UTC)

And taken it out again 'cos the original edit said it wanted a citation for "(We need a citation for the polynomial evaluation thing. I've heard it before, but a brief search of VAX docs on HP's site showed no sign of it.)" or so sez User:Simetrical. Looking around the instruction seems to be the POLY instruction. But where to find a citation? User:Tedickey says "(the programmer's manual would not be an appropriate cite)", I suppose 'cos it's too much WP:OR. Hum. HughesJohn (talk) 17:19, 4 October 2008 (UTC)
Ok, found a citation for the POLY instruction. HughesJohn (talk) 17:37, 4 October 2008 (UTC)

The next complaint is The "native" VAX operating system is DEC's VAX/VMS (renamed to OpenVMS in 1991 or 1992 when it was ported to DEC Alpha, "branded" by the X/Open consortium, and modified to comply with POSIX standards[2][citation needed]).

What do we want here? A citation for the name change? The X/Open branding? User:Tedickey says "[...] Still need a GOOD ref on X/Open site, since this is undated and secondary.)" HughesJohn (talk) 17:50, 4 October 2008 (UTC)

I don't know if this is a GOOD ref: DEC explains shift to OpenVMS moniker - explains renaming of VAX/VMS operating system —Preceding unsigned comment added by HughesJohn (talkcontribs) 17:53, 4 October 2008 (UTC)

Fine, we have the cite and this is years later but... Why on earth would the DEC VAX architecture manual not be an appropriate cite for the existence of the POLY instruction and its function (evaluating polynomials)? How would this be WP:OR? Granted it's a primary source, not secondary, but primary sources are acceptable as long as there is no interpretation or synthesis. Jeh (talk) 01:43, 31 October 2011 (UTC)

List of VAXen[edit]

My proposal to have articles or each of the major VAX product lines has been carried out. This means that the list of VAXen at the bottom of this article won't be useful for very long as information there is included and expanded in dedicated articles. Should it be moved to something like List of VAX computers? Rilak (talk) 12:12, 23 October 2008 (UTC)

Yes, I think it should be preserved in some form. "List of..." sounds reasonable. Letdorf (talk) 13:33, 23 October 2008 (UTC).
I probably get to it when the information in question has been fully integrated into the VAX articles. Rilak (talk) 10:20, 25 October 2008 (UTC)


There seems to be a bit of an edit war brewing over whether "VXT" is a VAX OS. From what I've found on the web, the VXT-2000 was indeed an X terminal, but it was based on a SOC VAX CPU with SPX graphics, and its resident software (which could, maybe, be described as an OS) was referred to as VXT. Apparently VXT may also have supported VT1300 X terminals (i.e. MicroVAX 3100/30) and VAXstation 2000s. This paper mentions the VXT-2000 and there's a sporadic discussion about VXT on the cctech mailing list here. I guess the InfoServer Software could count as a VAX OS too? Letdorf (talk) 12:36, 30 January 2009 (UTC).

Perhaps - but it might be nice to build up a (sourced) topic to link to, first Tedickey (talk) 14:13, 30 January 2009 (UTC)
There is EWS which is VAXELN based X terminal softeare. See the info at --mikeu talk 17:28, 30 January 2009 (UTC)
What applications would run on a VXT? As an X terminal, it sounds more like an embedded use than a system. Tedickey (talk) 17:36, 30 January 2009 (UTC)

Does the text version of the paper (HP only has text copies for older volumes of the DTJ) have Table 1? This table says that the VXT 2000 ran the "special operating system". Better copies of the DTJ (with graphics) can be found here Rilak (talk) 04:05, 31 January 2009 (UTC)

It does, but it doesn't go into much detail. Tedickey (talk) 00:19, 3 February 2009 (UTC)

Processor architecture[edit]

Does the "Processor architecture" section really belong in an encyclopedia article? They read like something from a technical manual. Srck (talk) 10:07, 22 October 2009 (UTC)

I think that the bit about the processor status register is perhaps a bit too much for an encyclopedia, but the virtual memory map and privilege modes are appropriate since these are essential features of any modern high-performance architecture. Perhaps it reads like a technical manual because the article does not discuss why these features are important and what implications these features have? Rilak (talk) 06:03, 23 October 2009 (UTC)

Most operands out of any instruction set?[edit]

A single VAX instruction allows up to 6 explicit specifier-based operands, with up to two of them being write operands (EMODx and EDIV), up to 12 explicit registers (6 base and 6 index) with up to 6 autoincrement/decrements, 1-4 bytes of displacement or 1-16 bytes of immediate data per specifier, an unlimited number of branch displacement operands (see CASEx, which has the format opcode selector.rx, base.rx, limit.rx, displ[0].bw, ..., displ[limit].bw, with an ellipsis in the operand list!), and some instructions can also implicitly use R0-R5 and/or the stack (like MOVTUC, srcaddr.ab, esc.rb, tbladdr.ab,, dstaddr.ab, {R0-5.wl} and CALLS numarg.rl, dst.ab, {-(SP).w*} and POLYH arg.rh,, tbladdr.ab, {R0-5.wl,-16(SP):-1(SP).wb}). Do VAX instructions have the largest number of operands out of any CPU architecture, ever? (talk) 21:34, 30 September 2010 (UTC)

Instruction set section - RISC vs. CISC, etc.[edit]

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 (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[edit]

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[edit]

A video of some MILVAX circuit boards. Bizzybody (talk) 06:01, 11 October 2012 (UTC)

autodecrement deferred?[edit]

I thought this was not copied from the PDP 11 addressing modes. - Denimadept (talk) 07:12, 21 June 2013 (UTC)