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.
Many of the accounts that I've read indicated the largest issue with Itanium was building effective compilers.
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
I thought this experiment was a failure since most operating systems do multitasking : http://ieng9.ucsd.edu/~cs30x/sparcstack.html
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.