

The Itanium processor, part 3: The Windows calling convention - Mister_Snuggles
http://blogs.msdn.com/b/oldnewthing/archive/2015/07/29/10631311.aspx

======
lorenzhs
Previous instalments of the series on HN:

Part 1:
[https://news.ycombinator.com/item?id=9955652](https://news.ycombinator.com/item?id=9955652)

Part 2:
[https://news.ycombinator.com/item?id=9961506](https://news.ycombinator.com/item?id=9961506)

------
com2kid
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.

~~~
elwin
> 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.

~~~
Aloha
> 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.

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

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

