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

[Someone]

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.

[elwin]

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?

[nickpsecurity]

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. ;)