
The troubled POLY instruction of the VAX [pdf] - madflame991
http://simh.trailing-edge.com/docs/vax_poly.pdf#
======
cstone
As the article notes, DEC's OSes largely dodged the bullet by having good
workarounds and in-kernel implementations for the missing instructions.

Open-source VAX OSes weren't so lucky. BSD's libm used EMOD pretty heavily
(for modf() and the like), and this caused problems in unexpected places if
you happened to be running on a newer machine that didn't have these
instructions (stuff like: awk would crash!). So the OSes had to follow suit as
well, at least for the instructions that libraries / compilers would emit
(which fortunately excluded most uses of the G and H floating types). The
documentation available at the time was okay but.. imprecise.

source: I wrote the EMOD implementation for OpenBSD/vax a long time ago; POLY
had already been done by NetBSD. It's still there!
[http://cvsweb.openbsd.org/cgi-
bin/cvsweb/~checkout~/src/sys/...](http://cvsweb.openbsd.org/cgi-
bin/cvsweb/~checkout~/src/sys/arch/vax/vax/unimpl_emul.s?rev=1.9&content-
type=text/plain)

------
paulsutter
The article also mention EDIV, which caused the most hilarious bug explanation
I ever heard.

I worked on a VMS device driver in 1990. We had to resolve every single crash,
because DEC support tracked the outcome of each crash dump file.

Our driver was crashing a VAX 9000 at Abbot Labs, a nightmare because it was a
mainframe-class machine. In every crash dump I could show that the registers
contained impossible values for the code sequence, always traced back to code
involving an EDIV instruction (used to get a remainder).

DEC decided the problem was "alpha particles penetrating the encapsulant". At
first I thought they were joking, but they were serious. They replaced the
water cooling module around the CPU. That didn't fix the problem, so they
pushed it back to us.

After much back and forth, they realized it was a microcode bug in the EDIV
instruction, and their microcode patch fixed it.

------
userbinator
I wonder what VAX would be capable of today if they had the same level of
resources as e.g. Intel. From what I've seen there are some super-powerful
instructions, but the opcode map[1] is extremely irregular - even x86 has an
octal structure to it - so superscalar decoding would be far more difficult.
It's also not as compact of an encoding as x86, so the code density would be
lower; x86, despite being CISC, tends to have more frequently used
instructions be shorter, e.g. ~1/4 of the 1-byte opcode map is register-
register/register-memory ALU operations.

[1] [https://www.cs.auckland.ac.nz/references/macvax/op-
codes/VAX...](https://www.cs.auckland.ac.nz/references/macvax/op-codes/VAX-
Opcodes-num.html)

~~~
gsg
DEC deliberately moved away from VAX to work on Alpha, which performed quite
well for its time.

John Mashey made some interesting comments on the (lack of) future prospects
for the VAX here:
[http://yarchive.net/comp/vax.html](http://yarchive.net/comp/vax.html)

~~~
Someone
But reading
[http://web.eece.maine.edu/~vweaver/papers/iccd09/iccd09_dens...](http://web.eece.maine.edu/~vweaver/papers/iccd09/iccd09_density.pdf),
Alpha didn't have high code density. Caveat here is that they may have been
better at hand-optimizing CPUs they are familiar with or where information is
easier to Google. That would favor x86, for instance. Note, however, that they
get way smaller code for PDP-11 and VAX than for Alpha.

~~~
peterfirefly
Due to the way instruction fetch and dispatch worked on the first few
generations of the Alpha, you had to put in lots of NOPs to get decent
performance.

------
DonHopkins
Pff. If you're not working with 36 bits, you're not working with a full DEC.

-Doug Humphrey (DIGEX)

------
MichaelCrawford
Two years after I logged a bug in Apple's MPW C compiler, I received a
developer CD with release note that explained how to reproduce my bug but then
said "don't do that".

Mac C compilers added "pascal" as a reserved word, this enabled one to link to
toolbox apis that had the pascal calling convention.

I wrote a c++ test tool for MacTCP in which a member function returned a
pointer to a pascal C function, for use as a callback from the network driver.

My first attempt produced faulty machine code. While regressing the bug I
found that increasing the lengths of the names of the member function or of
its parameters would crash the compiler. Not the resulting binary - the
compiler itself.

On the old mac os that took down the entire machine.

------
MichaelCrawford
Tracy Kidder, "The Soul of the New Machine".

After they shipped the guy who did the timing changed careers, to take up
farming.

~~~
rjsw
He didn't really change careers. He built a 32-bit processor for
Computervision fairly soon after leaving Data General and has done plenty of
stuff since [1].

[1]
[http://www.polybus.com/hdlmaker/Resume.html](http://www.polybus.com/hdlmaker/Resume.html)

~~~
krylon
:( Now I'm sad. That was such a great story.

