The Itanium processor, part 3: The Windows calling convention | Hacker News Reader

The Itanium processor, part 3: The Windows calling convention

blogs.msdn.com

49 pointsMister_Snuggles11 comments

Open articleView on HN

Previous instalments of the series on HN:

Part 1: https://news.ycombinator.com/item?id=9955652

Part 2: https://news.ycombinator.com/item?id=9961506

Some very cool things, some very complicated things.

I feel that if a subset of this processor had been all that was introduced, that it could have been successful.

The majority of the penalty for making a function call being negated? Wonderful! Heck it sounds like (although I skimmed the later half of the article and I didn't fully grok the first half on my single read through) the stack doesn't even need to be touched for some chains of function calls.

But there is a lot of work for the compiler here, wow. Knowing the maximum number of registers that is needed for any function call made within a function? Ouch.

Support for multiple return values is cool though. That'd be incredibly nice.

And again, rotating the registers to avoid hitting the stack, incredibly powerful.

Having that many globals accessible, also really powerful. All of a sudden the penalty for accessing your "God" object just went down by a fair bit.

> But there is a lot of work for the compiler here, wow. Knowing the maximum number of registers that is needed for any function call made within a function? Ouch.

That shouldn't be too difficult. The compiler is already type-checking the parameters of every call within the function. Remembering the highest count won't take much more work, and it's capped at 8 anyway.

> Support for multiple return values is cool though. That'd be incredibly nice.

Agreed. So many processors seem designed just to run C. Then when something extra like multiple returns appears, it goes unused.

> That shouldn't be too difficult. The compiler is already type-checking the parameters of every call within the function. Remembering the highest count won't take much more work, and it's capped at 8 anyway.

Many of the accounts that I've read indicated the largest issue with Itanium was building effective compilers.

That's true, but figuring out the maximum number of arguments passed to another function is trivial; I would think it isn't harder than determining how much space one needs for local variables in an Algol-like language.

That's definitely true, but counting function parameters was only a small part of the difficulty. Weren't most of the problems related to optimization being harder and less effective than predicted?

The compiler problem here was in explicit scheduling, not counting outgoing registers. Modern C compilers for x86 architectures already do the latter.

I recall learning that the important part of the optimization phase for Itanium was based on runtime performance analysis, not just static optimizations.

Because they had to deal with all the issues in Itanium Architecture Parts 1, 2, 3,..., n where the sum is a lot harder than this issue. ;)

> But there is a lot of work for the compiler here, wow. Knowing the maximum number of registers that is needed for any function call made within a function? Ouch.

Compilers already do that, to allocate outgoing argument space that can be reused between procedure calls. Saves needless stack manipulation for spilled outgoing parameters.

> And again, rotating the registers to avoid hitting the stack, incredibly powerful.

SPARC did this too. It's a classic RISCism: https://en.wikipedia.org/wiki/Register_window

> SPARC did this too.

I thought this experiment was a failure since most operating systems do multitasking : http://ieng9.ucsd.edu/~cs30x/sparcstack.html

Reply on news.ycombinator.com