Uninitialized garbage on ia64 can be deadly (2004)

https://devblogs.microsoft.com/oldnewthing/20040119-00/?p=41003

by HeliumHydride • 8 months ago

98 83 8 months ago

devblogs.microsoft.com

vardump2• 8 months ago

Pretty surprising. So IA64 registers were 65 bit, with the extra bit describing whether the register contains garbage or not. If NaT (Not a Thing) is set, the register contents are invalid and that can cause "fun" things to happen...

Not that this matters to anyone anymore. IA64 utterly failed long ago.

msla3• 8 months ago

In case someone hasn't heard:

https://en.wikipedia.org/wiki/Itanium

In 2019, Intel announced that new orders for Itanium would be accepted until January 30, 2020, and shipments would cease by July 29, 2021.[1] This took place on schedule.[9]

ashleyn• 8 months ago

There are modern VLIW architectures. I think Groq uses one. The lessons on what works and what doesn't are worth learning from history.

addaon• 8 months ago

A more everyday example is the Hexagon DSP ISA in Qualcomm chips. Four-wide VLIW + SMT.

bri3d• 8 months ago

VLIW works for workloads where the compiler can somewhat accurately predict what will be resident in cache. It’s used everywhere in DSP, was common in GPU for awhile, and is present in lots of niche accelerators. It’s a dead end for situations where cache residency is not predictable, like any kind of multitenant general purpose workload.

vardump2• 8 months ago

I meant narrowly only about IA64. There is sure some lessons learned value.

0dyl• 8 months ago

The new TI C2000 F29 series of microcontrollers are VLIW

msla3• 8 months ago

IA64 was EPIC, which, itself, was a "lessons learned" VLIW design, in that it had things like stop bits to explicitly demarcate dependency boundaries so instructions from multiple words could be combined on future hardware with more parallelism, and speculative execution and loads, which, well, see the article on how the speculative loads were a mixed blessing.

https://en.wikipedia.org/wiki/Explicitly_parallel_instructio...

kragen9• 8 months ago

It matters to people designing new hardware and maybe new virtual machine instruction sets.

nottorp• 8 months ago

Or to people caring about their software working on more than just Chrome.

... oh wait, on more than x86(64).

ronsor• 8 months ago

Yet another reason IA64 was a design disaster.

VLIW architectures still live on in GPUs and special purpose (parallel) processors, where these sorts of constraints are more reasonable.

nneonneo• 8 months ago

I mean, there is a reason why these sorts of constructs are UB, even if they work on popular architectures. The problems aren’t unique to IA64, either; the better solution is to be aware that UB means UB and to avoid it studiously. (Unfortunately, that’s also hard to do in C).

awesome_dude• 8 months ago

The bigger problem is that a user cannot avoid an application where someone was writing code with UB, unless they both have the source code, and expertise in understanding it.

loeg• 8 months ago

It's a very weird architecture to have these NAT states representable in registers but not main memory. Register spilling is a common requirement!

MindSpunk• 8 months ago

Are any relevant GPUs VLIW anymore? As far as I'm aware they all dropped it too, moving to scalar ISAs on SIMT hardware. The last VLIW GPU I remember was AMD TeraScale, replaced by GCN where one of the most important architecture changes was dropping VLIW.

Joker_vD2• 8 months ago

Raymond Chen has a whole "Introduction to IA-64" series of posts on his blog, by the way. It's such an unconventional ISA that I am baffled that Intel seriously thought they would've been able to persuade anyone to switch to it from x86: it's very poorly suited for general-purpose computations. Number crunching, sure, but anything more freeform, and you stare at the specs and wonder how the hell the designers supposed this thing to be programmed and used.

yongjik• 8 months ago

Well, they did persuade HP to ditch their own homegrown PA-RISC architecture and jump on board with Itanium, so there's that. I wonder how much that decision contributed to the eventual demise of HP's high performance server division ...

classichasclass2• 8 months ago

A lot, I think. PA-RISC had a lot going for it, high performance, solid ISA, even some low-end consumer grade parts (not to the same degree as PowerPC but certainly more so than, say, SPARC). It could have gone much farther than it did.

Not that HP was the only one to lose their minds over Itanic (SGI in particular), but I thought they were the ones who walked away from the most.

msla3• 8 months ago

"We don't care, we don't have to, we're Intel."

Plus, DEC managed to move all of its VAX users to Alpha through the simple expedient of no longer making VAXen, so I wonder if HP (which by that point had swallowed what used to be DEC) thought it could repeat that trick and sunset x86, which Intel has wanted to do for very nearly as long as the x86 has existed. See also: Intel i860

https://en.wikipedia.org/wiki/Intel_i860

kruador• 8 months ago

The 8086 was a stop-gap solution until iAPX432 was ready.

The 80286 was a stop-gap solution until iAPX432 was ready.

The 80386 started as a stop-gap solution until iAPX432 was ready, until someone higher up finally decided to kill that one.

AndrewStephens3• 8 months ago

I remember when IA-64 was going to be the next big thing and being utterly baffled when the instruction set was made public. Even if you could somehow ship code that efficiently used the weird instruction bundles, there was no indication that future IA-64 CPUs would have the same limits for instruction grouping.

It did make a tiny bit of sense at the time. Java was ascendant and I think Intel assumed that JIT compiled languages were going to dominate the new century and that a really good compiler could unlock performance. It was not to be.

kragen9• 8 months ago

That is not what happened.

EPIC development at HP started in 01989, and the Intel collaboration was publicly announced in 01994. The planned ship date for Merced, the first Itanic, was 01998, and it was first floorplanned in 01996, the year Java was announced. Merced finally taped out in July 01999, three months after the first JIT option for the JVM shipped. Nobody was assuming that JIT compiled languages were going to dominate the new century at that time, although there were some promising signs from Self and Strongtalk that maybe they could be half as fast as C.

jcranmer• 8 months ago

Some guesses here:

First off, Itanium was definitely meant to be the 64-bit successor to x86 (that's why it's called IA-64 after all), and moving from 32-bit to 64-bit would absolutely have been a killer feature. It's basically only after the underwhelming launch of Itanium that AMD comes out with AMD64, which becomes the actual 64-bit version of x86; once that comes out, the 64-bitness of Itanium is no longer a differentiation.

Second... given that Itanium basically implements every weird architecture feature you've ever heard of, my guess is that they decided they had the resources to make all of this stuff work. And they got into a bubble where they just simply ignored any countervailing viewpoints anytime someone brought up a problem. (This does seem to be a particular specialty of Intel.)

Third, there's definitely a baseline assumption of a sufficiently-smart compiler. And my understanding is that the Intel compiler was actually halfway decent at Itanium, whereas gcc was absolute shit at it. So while some aspects of the design are necessarily inferior (a sufficiently-smart compiler will never be as good at hardware at scavenging ILP, hardware architects, so please stop trying to foist that job on us compiler writers), it actually did do reasonably well on performance in the HPC sector.

happosai2• 8 months ago

It appeared to me (from far outside) that Intel was trying to segment the market into "Affordable Home and office PC:s with x86" and "Expensive serious computing with itanium". Having everything so different was a feature, to justify the eyewateringly expensive itanium pricetag.

fulafel2• 8 months ago

baffled that Intel seriously thought they would've been able to persuade anyone to switch to it from x86

They did persuade SGI, DEC and HP to switch from their RISCs to it though. Which turned out to be rather good for business.

zinekeller• 8 months ago

SGI and DEC, yes, but HP? Itanium was HP's idea all along! [1]

[1] https://en.wikipedia.org/wiki/Itanium#History

fredoralive• 8 months ago

I suspect SGI and DEC / Compaq could look at a chart and see that with P6 Intel was getting very close to their RISC chips, through the power of MONEY (simplification). They weren't hitting a CISC wall, and the main moat custom RISC had left was 64 bit. Intel's 64 bit chip would inevitably become the standard chip for PCs, and therefore Intel would be able to turn its money cannon onto overpowering all 64 bit RISCs in short order. May as well get aboard the 64 bit Intel train early.

Which is nearly true 64 bit Intel chips did (mostly) kill RISC. But not their (and HP's) fun science project IA64, they had to copy AMD's "what if x86, but 64 bit?" idea instead.

kragen9• 8 months ago

They took technical risks that didn't pan out. They thought they'd be able to solve whatever problems they ran into, but they couldn't. They didn't know ahead of time that the result was going to suck. If you try to run an actual tech company, like Intel, without taking any technical risks, competitors who do take technical risks will leave you in the dust.

This doesn't apply to fake tech companies like AirBnB, Dropbox, and Stripe, and if you've spent your career at fake tech companies, your intuition is going to be "off" on this point.

eru5• 8 months ago

Computer hardware isn't the only 'tech' that exists, you know?

Problems in operations research (like logistics) or fraud detection can be just as technical.

kuschku2• 8 months ago

Thanks for this comment - that's a beautiful perspective I hadn't considered before. A clean and simple definition of technology as everything that increases human productivity.

Now I can finally explain why some "tech" jobs feel like they're just not moving the needle.

twoodfin• 8 months ago

They also aimed at what turned out to be the wrong target: When Itanium was conceived, high-performance CPUs were for technical applications like CAD and physics simulation. Raw floating point throughput was what mattered. And Itanium ended up pretty darn good at that.

But between conception and delivery, the web took over the world. Branchy integer code was now the dominant server workload & workstations were getting crowded out of their niche by the commodity economics of x86.

pjmlp7• 8 months ago

Itanium only failed because AMD for various reasons was able to come up with AMD64 and rug pull Intel's efforts.

In an alternative universe without AMD64, Intel would have kept pushing Itanium while sorting out its issues, HP-UX was on it, and Windows XP as well.

pjc505• 8 months ago

Other way round: the only way any company other than Intel was able to get a new instruction set launched into the PC space was because Intel face-planted so hard with Itanium, and AMD64 was the architecture developers actually wanted to use - just make the registers wider and have more of them, and make it slightly more orthogonal.

bell-cot2• 8 months ago

With how long it took Intel to ship expensive, incompatible, so-so performance ia64 chips - your theory needs an alternate universe where Intel has no competitors, ever, to take advantage of the obvious market opportunity.

kelnos• 8 months ago

We can't know for sure, but my guess is that Itanium still could have failed. I could imagine an alternative universe where, even with HP-UX and WinXP running on it, no one wanted to deal with porting their application software. And its emulation of 32-bit code (both in hardware and in software) was atrocious, so running existing, unported code wouldn't really take off either.

Eventually Intel gives up after motherboard/desktop/laptop makers can't build a proper market for it. Maybe Intel then decides to go back and do something similar to what AMD did with x86_64. Maybe Intel just gives up on 64-bit and tries to convince people it's not necessary, but then starts losing market share to other companies with viable 64-bit ISAs, like IMB's POWER64 or Sun's SPARC64 or whatever.

Obviously we can't know, but I think my scenario is at least as likely as yours.

pajko• 8 months ago

The first generation was complete garbage. Itanium 2 came too late and it did not get widespread due to wrong business decisions and marketing. By the time it could have been successful, AMD64 was out. And even then Intel targeted only the same high-end enterprise market segment, when they have implemented 64-bit on Xeon: https://www.cnet.com/tech/tech-industry/intel-expanding-64-b...

eru5• 8 months ago

It's such an unconventional ISA that I am baffled that Intel seriously thought they would've been able to persuade anyone to switch to it from x86 [...]

I don't know, most people don't care about the ISA being weird as long as the compiler produces reasonably fast code?

nayuki• 8 months ago

The ia64 is a very demanding architecture. In tomorrow’s entry, I’ll talk about some other ways the ia64 will make you pay the penalty when you take shortcuts in your code and manage to skate by on the comparatively error-forgiving i386.

https://devblogs.microsoft.com/oldnewthing/20040120-00/?p=40... "ia64 – misdeclaring near and far data"

https://devblogs.microsoft.com/oldnewthing/2004/01

andikleen2• 8 months ago

Early x86-64 Linux had a similar problem. The x86-64 ABI uses registers for the first 6 arguments. To support variable number of arguments (like printf) requires passing the number of arguments in an extra register (RAX), so that the callee can save the registers to memory for va_arg() and friends. Doing this for every call is too expensive, so it's only done when the prototype is marked as stdarg.

Now the initial gcc implemented this saving to memory with a kind of duffs device, with a computed jump into a block of register saving instructions to only save the needed registers. There was no boundary check, so if the no argument register (RAX) was not initialized correctly it would jump randomly based on the junk, and cause very confusing bug reports.

This bit quite some software which didn't use correct prototypes, calling stdarg functions without indicating that in the prototype. On 32bit code which didn't use register arguments this wasn't a problem.

Later compiler versions switched to saving all registers unconditionally.

veltas• 8 months ago

In the SysV ABI for AMD64 the AL register is used to pass an upper bound on the number of vector registers used, is this related to what you're talking about?

jcalvinowens• 8 months ago

At least they made the stack grow in the right direction! Well, half of it, anyway...

Uninitialized garbage on ia64 can be deadly (2004)

Related Stories