[Info-vax] Vaxes shutting off this week

[johnwallace4 at yahoo.co.uk]

On Mar 2, 12:25 pm, "Richard B. Gilbert" <rgilber... at comcast.net>
wrote:
> JF Mezei wrote:
> > Glen Herrmannsfeldt wrote:
>
> >> With VAX and address mode bytes it is horribly complicated
> >> to decode instruction boundaries.  VAX works well for a
> >> microprogrammed serial instruction processor, reading bytes
> >> and operating on them.
>
> > The could have decided to do what they did to the 8086. Have a front end
> > decoder that generates RISC instructions from the complex CISC instructions.
>
> > Or, they could have focused on making the simple instructions very fast
> > and the remainder addressijg modes less optimised and then ask compiler
> > writers t generate code that uses the fast instructions.
>
> > If Intel was able to make the 8086 toy controller into a very
> > respectable chip, then Shirley Digital could have done the same with VAX.
>
> > Unfortunatly, at the time the decision was made to dump VAX in favour of
> > Alpha, they did not have the advantage of hindsight and
> > didn'T know that Intel would succeed in getting the 8086 to break so
> > many barriers.
>
> > And lets not forget that at the time, there was Sun breathing down
> > Digital's neck with its own risc chips with Sun/Apolllo systes getting
> > better price performance than VAX. (that was a marketing issue with
> > prices for DEC gear still priced too high)
>
> > Had DEC lowered prices of VAX sufficiently, it could have competed
> > against Sun, especially since VMS clustering did allow distributed
> > ocmputing amongst many nodes.
>
> Really?  I suspect that if anyone at DEC had seriously suggested
> lowering prices, he would have become a former employee within minutes
> or, at most, hours!  If DEC had been both willing and able to compete on
> price, there would probably still be a Digital Equipment Corporation!
> They couldn't, or wouldn't, so Sun and Silicon Graphics rolled right
> over them!
>
> Some people can learn to cross the road ONLY by being run over by a truck!

By the time the low end PCI Alphas were around (AlphaStations and
later the PWS family) the manufacturing costs of an Alpha box were
almost indisguinguishable from a comparable x86 box; the main
technical differences were the CPU and core chipset. Everything else
was common with the PC world. There was an x86 variant of the
AlphaStation 400 (EV4), with an upgrade programme to go from x86 to
Alpha, and there were x86 variants of the PWS family (EV5). The PWS
family used "industry standard" NLX motherboards and daughtercards -
though it may not be an industry standard many readers have heard of.

Like a lot of DEC product, these were still a bit upmarket from the
run of the mill dirt cheap ATX-based PeeCees, but there were ATX
motherboards available too in the right circumstances. Some of them
were available at reasonable cost, but the marketing people didn't
want the cheaper ones to run VMS so either they were
"unsupported" (same principle as in the white box Windows-only
AlphaServer/AlphaStations) or the traditional VMS-incompatible memory
management was implemented (21164PC? [1]) so they could (only) run
Windows, Linux, Tru64, BSD...

Added to that marketing decision, what is now routine technology
(chunky power supplies and fan-cooled CPUs) was back then considered
high risk by the clone builders, and in due course Billco withdrew
their support for NT Alpha (not that they'd ever done a proper job
anyway), and the DigitalSemi and OEM groups were sold off, so that
market (such as it ever was) went away.

So, some people in DEC did suggest there was value in volume, and for
a while it looked a bit like it might have had a chance to work, but
then things changed at the top, and the rest is well known history.

[1] http://h18002.www1.hp.com/cpq-alphaserver/technology/literature/164pcpb.pdf