4 ms·

The Itanium processor, part 3: The Windows calling convention

lorenzhs 11y ago
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 11y ago
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 11y ago
  > 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 11y ago
    > 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.
    - Someone 11y ago
      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 11y ago
      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?
    - pcwalton 11y ago
      The compiler problem here was in explicit scheduling, not counting outgoing registers. Modern C compilers for x86 architectures already do the latter.
      - acallan 11y ago
        I recall learning that the important part of the optimization phase for Itanium was based on runtime performance analysis, not just static optimizations.
    - nickpsecurity 11y ago
      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. ;)
- pcwalton 11y ago
  > 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 https://en.wikipedia.org/wiki/Register_window
  - simula67 11y ago
    > SPARC did this too. I thought this experiment was a failure since most operating systems do multitasking : http://ieng9.ucsd.edu/~cs30x/sparcstack.html http://ieng9.ucsd.edu/~cs30x/sparcstack.html

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 11y ago

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 11y ago
> 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 11y ago
  > 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.
  - Someone 11y ago
    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 11y ago
    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?
  - pcwalton 11y ago
    The compiler problem here was in explicit scheduling, not counting outgoing registers. Modern C compilers for x86 architectures already do the latter.
    - acallan 11y ago
      I recall learning that the important part of the optimization phase for Itanium was based on runtime performance analysis, not just static optimizations.
  - nickpsecurity 11y ago
    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. ;)
pcwalton 11y ago
> 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 https://en.wikipedia.org/wiki/Register_window
- simula67 11y ago
  > SPARC did this too. I thought this experiment was a failure since most operating systems do multitasking : http://ieng9.ucsd.edu/~cs30x/sparcstack.html http://ieng9.ucsd.edu/~cs30x/sparcstack.html