Dr Dobbs has been gone for 12, which is still a long time, but when I first read the intro my brain transposed the two and I had a proper freak out before I realized what I'd done.
The Alpha 21264 CPU: NT's Greatest RISC (1998)
31–40 of 91 posts
Re: The Alpha 21264 CPU: NT's Greatest RISC (1998)
#32Earlier quoted context omitted.
what did they not implement from 754? Given the design of the processor i can imagine them being very aggressive with assumptions around exception handling / traps - iirc this is actually the original reason why Tomasulo algorithm exists because the first out-of-order processors didn't actually make any guarantees about the order that you would observe these side effects.
Alpha punts handling of denormals, infinities and NaNs to software emulation, but that wasn't particularly unusual: some sparc CPUs and early implementations of Arm VFP floating point did the same. Looking at the alpha architecture manual, the fp emulation traps are imprecise, which imposes constraints on codegen to make it work right: the "trap shadow" extends from the potentially trapping insn until a following tra…
Re: The Alpha 21264 CPU: NT's Greatest RISC (1998)
#33It’s so good to re-read Tom Halfhill’s articles. I wonder where he’s been in the past… checks notes… 30 years I haven’t seen his writings.
Re: The Alpha 21264 CPU: NT's Greatest RISC (1998)
#34Earlier quoted context omitted.
Without AMD, maybe it would have.
No, it wouldn't have. Without AMD rescuing x86, PowerPC wouldn't have died. MIPS wouldn't have died, and faces with the need to brake the 4Gn barrier on consumer equipment microsoft would have had windows running on three or four competing architectures until 2013 when everything would have switched to ARM. Itanium would have already been a rotting corpse. AMD rescued Intel from its own management.
Re: The Alpha 21264 CPU: NT's Greatest RISC (1998)
#35Having the free hardware mostly worked, but there was a long time before all of the data alignment bugs got sorted out. It got to the point where my CS classes had progressed enough that I started looking for them myself. Literally the first development tasks I got paid to do was code reviewing for word alignment bugs on 64 bit code. It was a long goddamned time ago so it's pretty fuzzy but IIRC not all 3 processors had exactly the same restrictions for all data types. So if it worked on Alpha it usually worked on the other 2 but not 100%.
I didn't have to deal with 64 bit software at work again for another 10 years, at which point people looked at me like I was trying to be edgy when I just shrugged. No, really, I was looking at 64 bit code errors 10 years ago.
Re: The Alpha 21264 CPU: NT's Greatest RISC (1998)
#36The 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 actuall…
There was a problem with that idea, DEC engineers working for AMD made K7 too fast for Alpha to compete.
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.
Re: The Alpha 21264 CPU: NT's Greatest RISC (1998)
#37In those days, I was using SGI machines to build web sites for folks .. the Indy was very popular for this purpose. One day I was given a DEC Alpha machine to evaluate and see if it was a worthwhile addition to our inventory. It came with NT, so there was some friction to just adding it to our services. These days were very frustrating - Microsoft was hell-bent on killing Unix, and later Linux also - and there was a…
From Microsoft’s POV they soundly beat Unix in the 1990s because they were primarily focused on the GUI workstation market. In 1991 the market for high-end desktop software like engineering, video editing and 3D modeling tools was dominated by Unix and classic Mac. In 1999 all of those applications were on Windows NT. Vendors like Autodesk and Avid were building for Windows first. New graphics acceleration hardware t…
Between 1997 and 2007, I worked at 3 different companies, in 3 different countries (2 in Europe + Israel) as Design Engineer in electronics.
All the serious engineering programs for EDA/CAD were run on Solaris and accessed from Windows with X-terminal programs.
Towards the end of that decade, the Opteron-based servers were both much faster and much cheaper than the Sun servers or the Fujitsu servers, so the EDA/CAD programs were migrated from Solaris to Linux, while the Windows computers continued to run only the X-terminal programs for accessing the servers.
At the beginning of that decade, I also used a Sun workstation, but those disappeared after 1999, because they were much too slow in comparison with a PC with Intel Pentium III or with AMD Athlon.
It is likely that the reason why those EDA/CAD programs did not have Windows versions at that time was that they already required a lot of memory, typically much more than 4 GB, so they migrated from Solaris to Linux only after the availability of x86-64 servers, while having a Windows version was not possible before mid 2006, when Intel joined AMD in providing 64-bit CPUs even for PCs, not only for servers, so the market share of 64-bit PCs became non-negligible.
Re: The Alpha 21264 CPU: NT's Greatest RISC (1998)
#38In those days, I was using SGI machines to build web sites for folks .. the Indy was very popular for this purpose. One day I was given a DEC Alpha machine to evaluate and see if it was a worthwhile addition to our inventory. It came with NT, so there was some friction to just adding it to our services. These days were very frustrating - Microsoft was hell-bent on killing Unix, and later Linux also - and there was a…
From Microsoft’s POV they soundly beat Unix in the 1990s because they were primarily focused on the GUI workstation market. In 1991 the market for high-end desktop software like engineering, video editing and 3D modeling tools was dominated by Unix and classic Mac. In 1999 all of those applications were on Windows NT. Vendors like Autodesk and Avid were building for Windows first. New graphics acceleration hardware t…
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 progressively that shifted).
By 2001, many of those machines were x86 which were then often as fast as the SGIs and Alphas, even with x86's stack-based floating point architecture which handicapped it a bit, and the significantly higher memory bandwidth and larger caches of the SGIs.
Re: The Alpha 21264 CPU: NT's Greatest RISC (1998)
#39Earlier quoted context omitted.
There was a problem with that idea, DEC engineers working for AMD made K7 too fast for Alpha to compete.
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 mi…
Re: The Alpha 21264 CPU: NT's Greatest RISC (1998)
#40Earlier quoted context omitted.
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 mi…
"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."
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.