3 ms·

The bit about how the AMD Athlon (K7) uses the same bus, and how they planned to make Slot A Alphas where the only adjustment an Althon motherboard would need i

The bit about how the AMD Athlon (K7) uses the same bus, and how they planned to make Slot A Alphas where the only adjustment an Althon motherboard would need is a different BIOS. Imagine what might have been, especially as Alpha Windows 2000 had a built in FX!32. Cheap Alpha systems with a good x86 compatibility story, it could've been a contender. (Yeah, I know, several stars would've had to align for it to actually work).

krylon 2mo ago
"Cheap" and "Alpha" would have been hard to pull of simultaneously. But it would have been really cool.
- microtonal 2mo ago
  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.
  - kjs3 2mo ago
    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.
rasz 2mo ago
There was a problem with that idea, DEC engineers working for AMD made K7 too fast for Alpha to compete.
- hinkley 2mo ago
  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.
  - rhelz 2mo ago
    "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."
    - hinkley 2mo ago
      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.

krylon 2mo ago

"Cheap" and "Alpha" would have been hard to pull of simultaneously. But it would have been really cool.

microtonal 2mo ago
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.
- kjs3 2mo ago
  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.

rasz 2mo ago

There was a problem with that idea, DEC engineers working for AMD made K7 too fast for Alpha to compete.

hinkley 2mo ago
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.
- rhelz 2mo ago
  "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."
  - hinkley 2mo ago
    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.