upvote
"Cheap" and "Alpha" would have been hard to pull of simultaneously. But it would have been really cool.
reply
The AXPpci 33 boards were pretty cheap at some point. I had one at the end of the 90s and I think it was 100-200 Dutch guilders.
reply
Pretty cheap and pretty slow, relative to other Alphas. The various ATX-sized PC164s motherboards were the ones that should have sealed the deal for Digital, but intel had PPro at about the same time, with similar performance, less cost and probably most importantly ran all the software people already had and vendors didn't have to port to a new arch[1].

What might have been.

[1] Yes, yes...PPro sucks on 16-bit software. My personal experience was that was a red herring by the benchmark-jockies, because it wasn't that much slower, and virtually none of the many, many PPro machines I was responsible for ran DOS/Win3 software.

reply
There was a problem with that idea, DEC engineers working for AMD made K7 too fast for Alpha to compete.
reply
There was a second problem with that, Digital proved in court that Intel stole their architecture to put into the Pentium.

Part of the settlement was that Intel had to fab for Digital for a long time and pay for a bunch of their patents. The Digital folks made it sound like it was a victory for them but it felt like the beginning of the end, and sure enough it was.

I think Alpha's big problem was people were still migrating to 32 bit code and here was a bunch of smartasses trying to push 64 bit processors 10 years before x86-64 became the flagship for Intel-compatible processors. During the time when 'Internet time' was a thing people said regularly and unironically. 10 years was forever.

reply
Sounds like similar paper "win" to DEC OpenVMS lawsuit against Microsoft where MS penalty was supporting Alpha while DEC trained its enormous sales/engineering arm to sell and support NT thus killing any incentives to buy DEC hw in the first place. DEC moved upstream the value chain and Microsoft moved tons of NT to all existing DEC corporate customers.
reply
"I am old, and have lived through four ages of the west, (the 8, 16, 32, and 64-bit ages), and have seen many defeats, and many fruitless victories."
reply
Some wise person in the 90's looked at the 16-32 bit transition, and side-eyed the 64 bit machines that were already available. He noted how differently we write software on 32 bit hardware (flat memory addressing, virtual memory, etc), and wondered what sorts of things we'd do differently on 64 bit. It took a while, but I think the answer is virtual machines, and multiplexing virtual addresses in a single process. There are some key techniques for highly concurrent garbage collection that use features meant for VMs to accelerate mark and sweep by switching the address space of objects that have been swept, and using some page faulting tricks to handle objects that are being written and swept at the same time.

We won't have to go to 128 bit processors for address space reasons. So I wonder what the justifications will be for doing so? And what features people will actually use it for when they have it? I suppose in some ways SIMD has skipped mostly over 128 to go to 256 and 512 bits though, hasn't it?

But I also know of 2 top-tier JITed languages that can use pointer packing to use 32 bit pointers for heap sizes under 32GB to save tons of memory. So 128 bit words would make pointers obnoxiously expensive.

reply
John Mashey?
reply
According to the mighty google (and other HN comments) we are running out of address space at about 1 bit per year or so. So most of us will not live to see the need for 128 bit computers. An interesting thing to think about is this: how extraordinary it was to live through 3 or 4 of these transitions. If we keep running out of bits at the rate of one per year (and we don't go extinct) that means that most humans will never life through any transitions. We are either the lucky ones (because we got to seee so many transitions) or the unlucky ones (because we are the ones who had to cope with the disruptions of doubling pointer lengths.)
reply