51–60 of 91 posts
It also seems faith in IA64 was the meteor that killed most of these self developed RISC architectures.
Digital, HP, and IBM had the foresight to supply NCSA with Windows NT machines with their respective not-Intel chips in them to make sure that they had a web browser on their platforms. I got the honor of using the Alpha machine, and so it got the most QA by far. I recall spending an unnecessary amount of time not only staring at the heat sink but occasionally showing it to the new guy so they could confirm my astoni…
Most of the barriers for Alpha adoption were problems inherent in the 32-bit to 64-bit transition. Alignment problems, yes, but another killer problem was that 64-bit pointers were twice as large. The software I was writing at the time (EDA) took almost exactly twice as much memory. So if we needed more than 4GB, we could go to a 64-bit machine, but unless you bought even more than 8GB, you couldn't really run on big…
A question on terminology, I come from bsd world so prefer i386, amd64, ia64(the itanium) whereas the linux side appears to prefer x86 x86-64 Nothing wrong with it(it describes the architecture fine) but I assume that x86-64 is intel face saving propaganda.
Earlier quoted context omitted.
Yeah, even in like 1996/1997 for certain industries there were hints as to the way things were going, even if it took 4/5 years for the transition to fully take place. For example, in 1996/1997, Digital Domain (VFX industry) used a 'render farm' cluster of Carrera Alpha workstations running NT to render the Titanic film, instead of SGIs running IRIX. (SGIs were still often used on the artists workstations though, but…
In 1999, AMD Athlon became the first x86 CPU that was able to do both an addition and a multiplication during one clock cycle, for the 80-bit x87 floating-point numbers. The previous Intel CPUs of the P6 family, from Pentium Pro to Pentium III, required 2 clock cycles for that, i.e. they reached at most half the throughput of Athlon at the same clock frequency. And Athlon had an even higher clock frequency. So the la…
Hardly anyone ran NT on these beautiful chips. Tru64 was the OS of choice for these in 1998. Hence the decision by MS to cease support. Running NT on a Dec Alpha would be like running kerosene in your Ferrari’s engine. If you wanted to run Windows NT you could do so a lot cheaper on an x86 PC.
As for Alpha, funnily enough the first few years I knew of it, I knew only of NT use with them, because that's what the R&D institute my father worked at had.
For everyone who says that the Alpha was a technically-superior CPU design that should have prevailed, I will draw attention to an interesting fact: "According to Allen Baum, the StrongARM traces its history to attempts to make a low-power version of the DEC Alpha, which DEC's engineers quickly concluded was not possible." https://en.wikipedia.org/wiki/StrongARM While AArch64 has been in the top supercomputer, a phon…
The issue was that DEC lacked the resources to run a completely new microarchitecture design to target low-power platforms, and the failure was trying to push an extreme performance chip into low-power envelope instead of designing a new one.
AFAIK with ARM the difference is that they started with low-power underpowered chip and modified it to bring the performance up.
You'd have probably similar issues trying to make a phone using Fujitsu A64FX (the supercomputer ARM) into low-power chip.
Earlier quoted context omitted.
Most of the barriers for Alpha adoption were problems inherent in the 32-bit to 64-bit transition. Alignment problems, yes, but another killer problem was that 64-bit pointers were twice as large. The software I was writing at the time (EDA) took almost exactly twice as much memory. So if we needed more than 4GB, we could go to a 64-bit machine, but unless you bought even more than 8GB, you couldn't really run on big…
AMD only pressured Intel into adapting the 64-bit extensions to the x86 architecture, The Intel native 64-bit system was the Itanium. Which they were hoping would break x86 and it's messy open legacy that allowed AMD to profit off it. A question on terminology, I come from bsd world so prefer i386, amd64, ia64(the itanium) whereas the linux side appears to prefer x86 x86-64 Nothing wrong with it(it describes the arch…
There exist two different (and slightly incompatible) implementations of 64-bit x86, which the respective CPU vendors call AMD64 and Intel 64 (previous names of the latter: EM64T and IA-32e).
So, what Intel implements is not AMD64, but something slightly different.
Concerning the small incompatibilities between AMD64 and Intel 64, see for example
> https://stackoverflow.com/questions/29833938/what-is-the-com...
I heard about Alpha in that it while being more powerful than x86 it wasn't as alien as the competition. The boards had PCI slots and looked like normal PCs, it had Windows NT and Linux. So if your Exchange server was not handling the load you moved it to Alpha and it was good. It also seems faith in IA64 was the meteor that killed most of these self developed RISC architectures.
https://en.wikipedia.org/wiki/DEC_PRISM
Killing Prism sent David Cutler into the arms of Microsoft.
Another dead architecture was Jupiter: https://en.wikipedia.org/wiki/Jupiter_project
Killing Jupiter sent many of DEC's DECsystem-10 customers to IBM.
Years later, they both seem like bad decisions.
Earlier quoted context omitted.
I worked on the first PA-RISC workstations (“snakes”, 1989-1991). PA-RISC started as a fairly pure RISC design and was consequently very simple and predictable (short pipeline, 1 delay slot, no complex instructions). The philosophy of the design team was to make the system fast with high clock speeds, short pipelines, and big caches, all big fundamental variables in the performance equation. Alpha was much more sophi…
I feel like PA-RISC actually landed with a handful of useful somewhat-complex instructions. It always struck me as the best architecture from that era, making the correct trade-off of avoided microcode but adopted stuff like completers and shift-and-add operations to minimize instruction count and maximize work done per pipeline.
See: ftp.parisc-linux.org/docs/arch/pa11_acd.pdf
Edit: actually, it did have fixed point multiply via the floating point unit (opcode XMPYU). No fixed point divide, though.