Intel Itanium IA-64 Support Removed with the Linux 6.7 Kernel
phoronix.com
phoronix.com
https://upload.wikimedia.org/wikipedia/commons/8/88/Itanium_...
Statistics and modeling are complicated, granted. But when your model diverges from reality 5 years in a row, perhaps you should just extrapolate the current line next time around.
(In the case of the Itanic, that would have been the line at 0. Still a better forecast than what they did!)
"There's no way this level of growth can be sustainable."
"Surely we've hit a stable level by now."
"Maybe that last year was a fluke."
Love to see it. :)
Those are GW of added capacity per year, their prediction flatlining is predicting sustaining the same level of growth.
E.g. if a solar panel factory (simplifying into a single entity) already exists, is there any reason not to run it at 100% production capacity? What consumables are used?
Afaik, it's more strict metallurgy (materialurgy?): temperature, time, some physical process.
Point being, I'd be curious on the actual cost of material inputs, if the price of solar panels crashes. How low can they go... and still be worth making?
From https://news.ycombinator.com/item?id=38150735, it’s very energy intensive.
> if the price of solar panels crashes. How low can they go... and still be worth making?
Boules are very storable, so it’s the financials of pausing production and storing materials until the price (or new tech) makes it profitable. Not the most socially responsible thing to do in decarbonisation times, but done with aluminium and other energy intensive storables all the time.
- Czochralski purification of silicon to produce a "boule"
- saw boule into "wafers" (surprisingly important, see "reduced kerf diamond wire saw")
- wafers can be used for microchips, or doped into solar cells
- apply contacts to top face
- package into a panel with glass and aluminium frames
The "wafer" market is somewhat independent. Purification depends on the price of energy (it's very energy intensive). Better sawing reduces waste and increases wafers per boule.
More factories come online all the time. Panels themselves are now extremely cheap, and it's worth looking at "balance of system" (labour, permitting, frames and racks, inverters).
I believe market data firms track all the relevant info, although they don't necessarily give the resulting info away on the internet.
Our most recent near-miss at a statewide outage happened because of unexpectedly low wind. It’s happening in Texas first because we have a smaller grid and it’s deregulated to the point where cheap but unreliable renewables can crowd out other sources of generation. The eastern and western grids will face the same problems in the long run the more and more renewables come to replace other sources of power.
Renewables, especially construction of new renewables, is a big, lucrative, growing business of its own. That’s actually a direct implication of the triumphant statistics people keep sharing about how much renewable power generation gets built out every year. So the “fossil fuel industry” is not unique in its vested interest to propagandize against its competition. And this incentive is only increased by the movement towards ESG in finance. But if we’re done accusing each other of being shills, let’s get to the substance of the matter at hand here.
> For example, the 2021 winter outages were caused by power plant operators not wanting to spend money making their plants more robust.
This included the renewables too, of course, along with the entire rest of the state’s infrastructure. But the near outage this summer was directly caused by low wind. There are probably issues with solar as well—heat, and cooling demand along with it, peak in the early evening just as sunlight starts to diminish—but usually wind manages to cover that gap. That doesn’t always happen though.
And, yes, renewables are becoming a big industry but it’s nowhere near as big as the fossil fuel industry and orders of magnitude less lavishly subsidized. Texas Republicans tried to ban wind and solar expansion because that party has been owned by the oil industry for decades and the renewable industry has nowhere near the same level of lobbying clout.
I can’t find any good source about your claim of thermal plants going offline in the September incident. ERCOT’s statements consistently blame the combination of high demand and low wind. The federal Department of Energy even issued an order authorizing Texas power plants to exceed normal emissions limits in such an emergency, which is inconsistent with your claim that they “go offline” in these conditions: https://www.ercot.com/about/legal/doe202c
> And, yes, renewables are becoming a big industry but it’s nowhere near as big as the fossil fuel industry and orders of magnitude less lavishly subsidized.
I thought we were done accusing each other of being shills. I’ll just point out that there’s significantly more propaganda in favor of renewable energy than in favor of natural gas or nuclear. But this is Hacker News and I am assuming good faith of you rather than accusing you of parroting talking points that were fed to you by Chinese photovoltaic manufacturers or annoying Swedish teenagers. And I am simply asking the same courtesy from you.
> Texas Republicans tried to ban wind and solar expansion because that party has been owned by the oil industry for decades
I think there is a good faith reason for such a policy. And while I do live in Texas and usually vote for Republicans, I am asking you to engage with me in good faith instead of calling me a shill. Are you capable of that or is the idea that someone can disagree with you about energy policy in good faith beyond your comprehension? Because you seem to be using this idea as a thought-terminating cliche.
https://www.bloomberg.com/news/articles/2023-08-29/texas-ask...
https://www.iea.org/reports/renewable-energy-market-update-j...
Intel wanted in on this space and didn't want AMD to be able to produce compatible parts so... enter EPIC [1]. The projections (as you point to) were wildly optimistic. Of course the whole thing was heavily delayed, produced in small volume, offered limited to no performance gain, required a ground up write of pretty much everything and was super expensive. What could go wrong?
What did AMD do? It just invented 64 bit extensions to x86 (ie x86-64). Was it ideal? No. You probably wouldn't design an instruction set and architecture this way if you were starting from nothing but you aren't starting from nothing. AMD released the wildly successful Opteron (and Athlon 64) and for 5-10 years completley ate Intel's lunch. Cheap parts, good performance, easy migration part, etc. Intel got to use these extensions by the same licensing agreement.
This coincided with the Gigahertz wars on the desktop front. From the Pentium for almost a decade Intel focused on Gigahertz and once thought they could run this up all the way to 10GHz+. We know how that went. Clock speed was a key marketing bullet point. AMD processors had higher IPC but that (at that time) was a harder sell.
About the time Opteron came out the Gigahertz wars were hitting the 3GHz barrier and Intel was stuck. At the same time their mobile parts used a completely different architecture. Thsi was Centrino with the Core Duo processors. These had much higher IPC (than Pentium lines) and more power efficiency. Some early enthusiasts constructed desktops from these mobile chips and the results were great.
Losing out to Opteron/Athlon and hitting the 3GHz barrier ultimately forced Intel to abandon their desktop architecture in favor of Centrino. Intel hung on as long as they could to milk some extra profit but eventually Core Duo was the future and this ultimately because the foundation for the Core processors we have today (but by now there have been many revisions). It might be more accurate to describe the Pentium years as the Netburst architecture years (IIRC).
But the lesson here is that a complete rewrite was an almost fatal mistake for Intel. It's almost always a mistake. You can't ignore what's there now and your desire to lock out competition doesn't necessarily translate to something customers actually want or need.
[1]: https://en.wikipedia.org/wiki/Explicitly_parallel_instructio...
ARM is cheaper and the performance hit is smaller than the savings. For scalable workloads you can easily just run more ARM and save money. Also, a lot (lot) of workloads are memory or I/O bound so the performance hit is negligible. ARM has gotten pretty optimized in both the CPU architecture and the tooling thanks to mobile uses.
What AWS offers and what Google offers are not even close: on AWS, our workloads actually perform better (as in, higher QPS/core, resulting in fewer pods/instances), in addition to being more cost effective (both in terms of per-instance price to begging with, and less instances in total, due to aforementioned higher QPS/core serving same amount of total requests). For the limited ARM offer from Google we tested, the performance is worse than equivalent x86 instances, in addition to no price incentives.
It's pretty funny.
> with the characteristics of the processor architecture nor with processor performance.
Why did AMD introduce Genoa and Intel is developing equivalent products too? There is market for CPUs with a very high number of low-powers cores and it seems ARM had an advantage there. Even now the price per core (which are good enough for many applications) for Ampere/Gravitron cores is significantly lower.
When you're running commercial software at $$$$ per license, the customers basically have to stick to whatever hardware is explicitly supported. And the vendors are going to be narrow there. Fewer platforms keep support costs down, and prevent exposure to uncompetitive corners of the market. As long as $expensive_product is only officially supported for x86, nobody needs to know it's riotously unperformant on ARM in ways that will require wholesale rewrites to fix.
When it's all open stuff, nothing stops people from compiling it for ARM, RISC-V, and hell 65C816, letting the market choose which platform fits their needs best. For many audiences it might not be "maximum performance under cost-no-object hardware"; it might be "what's the cheapest way to serve a fixed N workload units per month, when you include the purchase cost, electricity cost, rack-space rental cost, etc."
As a second-order effect, I expect removing license cost from the equation also impacts the metrics people care about. When the software price is the dominant aspect of the bill, nobody's going to make much of a case of "we can save 55 of the annual cost up front by using cheaper good-enough hardware" or "we'll save 1% per month on the energy bill".
AArch64 and AMD64 has more in common than Itanium which is a bag of hurt from hardware to compiler.
ARM on Server actually saves money at the scale being deployed, while Itanium has zero cost advantage, and that is before adding the cost of software which was order of magnitude worst than any estimate had made at the time.
Most Server software operate on Open Source software. From Linux to Nginx, MySQL, Postgres, Memcache or Redis and tons and tons OSS. Which makes changes far easier than waiting for vendor to support AArch64.
AArach64 has a much bigger market to fine tune its software stack and toolchain from Smartphones. There are currently 4.5+Billion of Smartphone in uses, that is larger than all the x86 usage in the world. Compare that to IA64 /Itanium.
So for a few HPC type things, it was an a leap forward, for everything else, it sucked.
It was like the arm based windows surface laptops a few years ago. Lots of promise, none of the software that you actually wanted.
When you looked at the opteron which was 64 bit, run faster, cheaper than the intel and could run vanilla 32bit apps without any changes faster than before, it was a no brainer.
Many people don’t realize ARM can trace its origins back to the BBC Micro. For a variety of reasons it found a niche in low power applications, even 30+ years ago. ARM, the company, simply sells licenses without producing its own silicon. There’s concern now with it going public that it will seek revenue by jacking up licensing costs.
It’s mobile devices where ARM flourished and entered public consciousness. There used to be other platforms but they died off. Intel sold XScale years ago because of a lack of vision.
ARM processors got sufficiently powerful to be in servers and power efficiency became a big deal. Google really transformed this space with sub-1.1 PUEs when no one outside even believed that was possible. Performance per Watt became a really big deal.
Also, I’m not sure if this is entirely fair but I credit Apple with a lot of ARM’s success. They bought a company called PA Semi and pushed the envelope with what ARM can do. I think that may have been the best $400 million (IIRC) ever spent.
This makes it sound as if xscale was an alternative platform to ARM. Intel xscale cores implemented the ARMv5 isa.
Starting a CPU company and selling CPUs to customers has always been difficult since you need to compete with other CPU packagers and Intel had the largest scale so could always put you out of business if you became a threat.
With the rise of big cloud server giants (AWS, Azure, Google), they can license the cores from ARM, build their own CPUs and cut out the middle-man. They are their own CPU customers so don't have to worry about building a market.
It's the rise of vertical integration from tech giants.
The machine it originally ran in is humming away too, albeit with a replacement Pentium M using a socket 478 adapter.
I keep it as a reminder that even billions of dollars can't see around the future corner.
The NetBurst microarchitecture of Pentium 4 was killed off and a 64-bit version of the P6 Variant Enhanced Pentium M microarchitecture took the baton.
* no byte operations
* no flags, thus no reasonable way to check for overflow (similar to one of the problems RISC-V is having, though at least they pretend to care).
> The processor may lose track of your LDx_L if you perform any memory access other than a matching STx_C, or if you perform a branch instruction, or if you trigger a trap (such as executing an emulated instruction), or if you execute more than 20 instructions after the LDx_L.
(LDxL and STxC are locked load and conditional store)
The answer is to be careful as a dev, and hopefully let the compiler and your libraries take care of the finer details.
The memory consistency model was pretty crazy, though.
1. Windows NT, which is the ancestor of modern Windows, was originally released on multiple platforms including Alpha and, I believe, MIPS; and
2. DEC, for awhile at least, had one of the most popular Web search engines: AltaVista. It wasn’t a commercial enterprise. It was mostly a technology demonstration for Alpha. For the time it was pretty good. No one at this time (the 1990s) thought there was a future in search engines. Many (including Yahoo) seemed to think curated directories were the future. Search engines were viewed as a solved problem, except by Larry Page and Sergei Brin who founded Google.
The highly underrated show “Halt and Catch Fire” covers this early era of computing really well and is worth watching.
FWIW the alpha design teams ended up cannibalized between AMD and Intel. The original Opteron and the first generations of Core i have a ton of AXP DNA in them, from a uarch standpoint. So in a sense, Intel and AMD did continue Alpha... sort of.
However. I feel that Alpha gets over fetishized on the internet sometimes. It was a clean arch, mainly because it was a clean 64bit design from the get go. But as far as uArch, it was pretty generic. Most of the uArch themes the AXP design teams used, which a lot of people think were native inventions to Alpha, came straight from industry/academia research, and plenty of other processors implemented them as well.
We used HP boxes and I want to say it was around 2002/2003 when this was going on. We were supposed to be a huge public showpiece client for both intel and HP. It… did not go very well. I remember the absolute defeated looks of the HP / Intel people when we pulled the plug and told them the discounts / free hardware still couldn’t justify the engineering efforts we had gone through for the last 18-24 months. This was right as opterons were coming out and that project jumped ship to them.
Credit especially goes to the people who stayed on the various x86 processor teams. Itanium’s single greatest source of failure was that successive Penguin generations undercut the advantage of x86 compatibility by adding the option of not migrating at all and still getting better performance. They probably saved the company but I doubt that got much praise at the time since it required acknowledging how badly the Itanium project had failed.
All that Itanium was, at the end of the day, was an in-order PA-RISC/SPARC hybrid that exposed a lot of the superscalar innards to the programmer (compiler)
VLIW scheduling even back then wasn't as much of a mystery as the usenet and register flamewars implied. It really is pretty straightforward for a compiler to behave like an in-order superscalar scheduler. And since the compiler has a much global information about the instruction stream it can do much more optimizations and static ordering than a normal in-order HW superscalar scheduler alone.
Plus itanium had plenty of dynamic microarchitectural components to complement the static ordering done by the compiler and increase FU utilization.
If anything, things like predication and its adverse effect in power consumption had a much worse impact on itanium than the compilers.
What killed the itanium was just simple economics; its performance was fine (for the time, at least for itanium2). It's performance/price ratio, however, was not.
Banias was the Israeli team asking how do we make an incredibly efficient mobile CPU and the answer was finish your work quickly and go to sleep.
In order to finish quickly, you had to be fast and efficient. Someone said well what if we don't actually go to sleep?
IIRCC, Core was a combination of the Banias CPU architecture, an evolution of P3, combined with the Netburst bus architecture from P4.
Pentium 4 was heavily marketing driven, to win the Gigahertz war.
The fab side of Intel had a huge priority in setting early architectural themes. And some of the CMOs flows in lab, in mid 90s, were showing huge speed scaling, but they had very restrictive design rules and cell libraries. But with the payout of extreme GHz scaling.
From that point of view, the P4 made sense; a narrow architecture with very deep pipelines. Where each stage used the tiny datapaths between latches/registers those libraries supported. Netburst makes sense in terms of dealing with extremely deep out of order pipelines.
However, those processes never met the scaling roadmaps. While the power consumption scaled horribly, and things like thermal, leakage and variability started to become first order limiters.
How did they get to the point of finish-your-work-quickly? Short pipelines?
So for Banias started with the P3 pipeline which was already short and added the microop fusion that I believe was introduced in P4. As well a cribbing a lot of other enhancements from Netburst.
It's been several years since I read up on it so I'm rust on all the details.
For the sake of humanity, we need to crowdfund a blimp with this quote that just flies back and forth between Cupertino/Mountain View and San Mateo for the next 5 or 10 years.
I can't wait for ARM to eat their lunch. And dinner.
I do believe that whoever drove the Centrino movement (from mobile originally to desktop) saved the company. They laid the foundation for Intel's next 15 years of success.
The original licensing agreement with AMD is an interesting part of Intel history too. Were that to happen today, it would probably be viewed as a disaster. In our modern era of short term corporate decision-making, it would probably be viewed negatively too.
But it led to Intel's complete dominance thanks to x86 for decades. It killed pretty much every other architecture (other than ARM). It's only in the last 5-10 years that dominance has really wavered.
Intel's big strength had always been their ability to fab chips at scale with low failure rate so the parts were hugely profitable. For decades the likes of AMD just didn't have that manufacturing capacity at the same scale and price. Intel led die-shrinking that was a huge driver to profits. It's only when they tried to move to 10nm that it all fell apart. Now TSMC has eaten their lunch. Intel is at risk of moving from being a first-party designer and fab of chips to producing third-party chips.
If someone woke up from a 20 year coma and you told them about Intel's market position and fate they would be shocked. That's how big of a fall from grace it's been. But that's largely on the fab side, not the design side. Only recently has the Core architecture really hit its limit where Intel CPUs consume too much power and run too hot to eke out the last ounce of power.
Itanium was a joint venture betwen HP and Intel. We can certainly look back now and say it was bad. I'm not convinced that determination was as easy at the time although it did have its critics.
They have had failed products, no doubt.
But I don't think you understand also how insanely good at execution Intel was during the 80s and 90s.
That part didnt happen because Intel bribed OEMs. Just DELL alone was receiving ~$1B a year to exclusively sell Intel.
Drake pointing: Runs IA-32
On the other hand, it's a bit of a shame to formally, officially lose another option out of the computing ecosystem.
there's an altix 3000 on ebay that I'm kinda tempted by https://www.ebay.com/itm/174917876903
it only runs like one specific version of suse or red hat
Do you have anything specific you'd do with an Altix 3000?
(I don't mean to sound snooty)
nope, I just like weird computers and distributed systems, itanium is possibly the weirdest CPU architecture that modern linux can run on, and SGI is an interesting part of computer history.
I assume Porting Linux to the pre-MIPS Tandem line would be a challenge. The Proprietary CPU was 'stack based' and very different from x86. Also, I don't know if Tandem ever sold compilers to do the sort of 'low level' system stuff to port another OS..
The rackmount Tezros and Origin 350s sound like they belong at the airport.
They're fun if you want to run the demos or load fsn and tell everyone in earshot "this is a Unix system! I know this!" But they're not even useful as X consoles to a Linux box these days, because of the compilation nightmare of getting recent network tools installed.
The Chicken and the Egg The very first effort that is considered a direct ancestor of UEFI technology had a very specific tactical goal. In the course of 1997 people at Intel were working on how to boot computers based on the prospective Itanium® Processor family...."
from https://www.intel.com/content/dam/www/public/us/en/documents...
https://itanium-cxx-abi.github.io/cxx-abi/abi.html
My understanding is this was first created for Itanium but is now used for other architectures.
Sort of a half joke, I can see no way OFW could have made the jump to the pc world.
For a time, you could easily download a devkit for EFI on x86 which included tools and source code for EFI 1.1.
It killed their manufacturing based on hype, where as they all established a firm install base before itanium ever got rolling, which has ensured they continue to be (halfheartedly) maintained.
But today? Moving some of the adaptions from the hardware scheduler to process lifetime persistence (as in JIT VM) or even into the software distribution infrastructure could be delightfully transparent.
GPUs have taken over much of the niche where these processors excel, number crunching where you have entirely pre-determined memory / compute access patterns.
It guzzled power. This was the biggest problem, not solvable in its lifetime with its resources.
"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."
Huge box with a huge PSU. And we had some cheapo desktop HPs with dual Pentium2(3? (the card edge ones)) at like 450 or 533.
Which basically ran circles and sipped power by comparison. Don't remember the exact numbers but only 2 per 15A circuit; with 4 of the x86 per.
advfs addvol -> zpool add
advfs advscan -> zpool import
advfs clonefset -> zpool clone
advfs mkfset -> zfs create
advfs rvdump -> zfs send
advfs rvrestore -> zfs receive
advfs showfsets -> zfs get/list
advfs verify -> zpool scrubDidn't sound like Itanic played a part at all.
The end result was that they had to restart development of EV7 then restart its production again, because many, many ex-DEC customers didn't want to move to Itanium (customers running Tru64 mostly moved to Linux on amd64 or occasionally to other RISC vendors instead of dealing with HP-UX, whereas OpenVMS customers kept to Alphas which outperformed Itanium usually or moved off the platform completely, with stragglers now moving to amd64)
By the time HP bought Compaq, AXP was on legacy mode. Plus Itanium was as much of an HP architecture as it was intel's, so it made no sense for HP to develop AXP further.
I don't think many of the arm chair CPU experts really understand how expensive it is to design a high performance CPU core.
I had to find a Server 2003 ia64 CD to install the OS (and work through the awful UEFI CLI incantations required to get the damn thing to boot). Once installed I was always struck by just how incredibly slow the machine was. It was just such a drag to use. Once we no longer needed to support ia64 I was thrilled that I’d never need to use that thing again.
Good riddance.
I understand that there are exotic addressing modes involved. I'm not versed enough to understand.
So if they wanted to keep pushing their own designs they needed a new architecture, and ARM64 was their best option. The modern SVE extensions were co-designed by ARM and Fujitsu based on their HPC experience.
It's pretty tragic how this has turned out. Still no mainstream CPU languages that are good for parallelism and all the action is happening in the GPU side with the tragic fragmented mutually incompatible buggy properietary dev stacks (and C++ baggage to top it off), going on for 15+ years.
Turns out it was more like IBM's MCA / PS2 rather than the future.
Compatibility and ubiquity wins. As nearly always.
> The failure of this chip to do anything more than exist as a niche processor sealed the fate of Intel—and perhaps the entire industry, since from 1997 to 2001 everyone waited for the messiah of chips to take us all to the next level.
> It did that all right. It took us to the next level. But we didn't know that the next level was below us, not above. The next level was the basement, in fact. Hopefully Intel won't come up with any more bright ideas like the Itanium. We can't afford to excavate another level down.
The DEC Alpha architecture was planned for 25 years and it certainly was not technical barriers that killed the Alpha 21464.
DEC should have bought MIPS, and ported VMS to it.
Had they made that decision, they might still exist.
So when samples arrived they were 2-3 years later than they should have been and MIPs had made some headway in the same space.
DEC - actually Bob Supnik - decided that even though Prism was the better arch, MIPS products would bring in revenue more quickly.
Which was true. But... then Prism was killed, which led to a mass walkout. The remains were resurrected a year later with some updates as Alpha. But by then it was too late for that particular market.
Prism was a solid arch - some quirks, but nothing unworkable. And very, very fast.
But it was a workstation-grade processor, not a mainstream PC-grade processor.
DEC completely failed to understand the PC market, and it's not obvious what would have happened if Prism had survived. IMO it would have gone the way of MIPS anyway, because the workstation market was already being squeezed hard, and the PC and Mac markets had already made their choices.
It might have had a good run against SPARC for a decade or so, but that would have been it.
DEC's terminals? killed by PCs. The VAX lineup? killed by RISC chips, and the VAX 9000 consumed a huge chunk of their cash reserves before embarrassingly being rendered obsolete by their own NVAX.
This was a time of change from minicomputers to microcomputers and DEC made costly decision after costly decision. They kept selling off profitable "non-core" portions of the business that in the process incurred a loss.
Not defending Itanium. But the average article on computer architecture has been garbage for decades now, it's fascinating.
Of course, it's also possible that by that point Sun was already paralysed by infighting between various splinter groups, with no big bad DEC to fight against.
Linus Torvalds in 2003: https://yarchive.net/comp/linux/x86.html
>Itanium 2 doesn't hold a candle to a P4 on any real-world benchmarks.
I’m not particularly confused about Intel’s perspective on compatibility: Even at the time, there were several examples of successful platform CPU transitions across architectural “full breaks”. Apple going from 68k to PowerPC is the closest analogy for Intel, and if the Itanium performance and software (compiler) story had played out as Intel envisioned they likely would have been fine.
But as for ubiquity, I’m befuddled. As far as I’ve been able to determine—having lived through it and followed many retrospective threads like this looking for new evidence—Intel had no plans on any useful timeline to turn Itanium into a (non-workstation) desktop or laptop chip. Did they really think the market would stay bifurcated between “big iron” architectures and x86 personal machines for another decade? I can’t imagine they would have believed that.
Oh but they did :)
Going back to at least the i432, Intel seems to have had a deep vein of “mainframe envy” in their culture and strategic thinking. It seems that somehow the market (and a bit of trailblazing into x86-64 by AMD) saved them from themselves.
Direct quote from Wikipedia https://en.m.wikipedia.org/wiki/Intel_iAPX_432
""" Intel's iAPX432 was intended to be Intel's major design for the 1980s. Unlike the 8086, which was designed the following year as a successor to the 8080, the iAPX 432 was a radical departure from Intel's previous designs meant for a different market niche...
Referred to as a "micromainframe", the iAPX 432 was designed to be programmed entirely in high-level languages. """
Folklore describes the 8086 as a stop-gap design, an extension of the popular (but tiny) 8080 CPU. The "real" design project at Intel was the i432, which supported object-oriented programming and was THE FUTURE OF ALL COMPUTING.
A cut-down version of the object oriented support was carried over into the x86 architecture, in its segmented memory model and page-description registers. You're welcome.
I think they knew they could fall back on x86 if everything went wrong - but what they did NOT expect was x86-64 to just smash everything. That caught them on backfoot.
They are basically just building a better version of the same product they were selling 20 years ago… so much opportunity missed here.
But even that goes back to the P6->P5->486->386->286->8086->8088->8080->8008->CTC lineage of 50+yrs. It literally just cuts out the few years of the abandoned NetBurst architecture.
I can. The x86 hegemony was overpowering in the PC space but the moment you left that corner of the market we had a lot more ISA diversity then than in the following years. In a world that seemed to have no problem with Macs on PowerPC, PCs on x86, and workstations/servers on SPARC/MIPS/PA-RISC, just consolidating workstations and servers probably seemed reasonable. You can even see an analog in the way we've kept x86 on "real computers" while ARM has dominated mobile. IMHO the only reason it didn't work out is because workstations and servers merged with PCs.
Alpha was clearly the future -- and Itanic ruined Alpha. We didn't even get to see it live on inside some other corporate sarlacc.
[0] https://bcantrill.dtrace.org/2008/07/18/revisiting-the-intel...
In this case, that means AMD showing up with the first x86-compatible 64-bit CPUs killed Itanium dead. For big software projects already running on x86, there were 2 options:
- Port everything to a new architecture that only looked good in specific benchmarks, cross your fingers, and hope for the best.
- Keep running your code on new 64-bit CPUs that were backward compatible with your existing code, then recompile for 64-bit as you got around to it.
As a bonus, amd64/x86-64 CPUs were faster than the P4 chips that practically needed 3 phase power to boot up.
It was kind of a no brainer.
It was quite a bit worse than that. If you ignore the horror of IBM vendor lock-in, which in retrospect made the whole thing untenable, and the overpriced nature of the systems, MCA was a fine thing for its time. The PS/2s had some nice features. They were compatible with everyone's DOS and Windows stuff, even if IBM would have preferred you use OS/2, and so on.
Itanium was a piece of crap, even if you could somehow ignore the cost and lock-in.
Counterexample: GPU compute.
I'm not sure that was Itanium's only problem. Intel's Itanium launch focused on a market that was not captured by the so-called "Wintel" monopoly: high performance servers. The software support needed in this market was relatively narrow. Nevertheless, it failed there too.
The biggest issue with Itanium is that the juice was never worth the squeeze. It was expensive. The cost to migrate your existing 64bit systems never made sense. So, you might ask, what about 32-bit shops that needed to make the leap to 64 bits? Well, by the time intel and its vendors started getting costs under control, the AMD Opteron hit the scene with commodity 64bit hardware that had the added benefit of full backwards compatibility. And that pretty much killed it.
Once the patents expire I hope someone makes a RISC-V design that just tries to get their, e.g., virtual and backless memory working with Linux. That seems like it would be worthwhile in and of itself.
If you’re ever on funky hardware and want to ensure continuing Linux compatibility, I guess it pays to subscribe.
Itanic also contributed EFI and popular 64-bit ABI conventions.
Perhaps VLIW should've been proven workable and advantageous with realistic modeling first before betting billions in development.
Good riddance.
yeah, have the compiler do the work of ordering
instructions particularly crafty so it wouldn't stall
A ridiculous percentage of a modern CPU's transistor count (and design complexity) is devoted to speculative execution and other "smarts" that intel proposed shifting to the compiler. Which theoretically lets you ditch all that speculative execution hardware in the CPU and spend it on more badass cool performance stuff. Theoretically.