The stack is a great huge implementation detail, and doesn't necessarily work the way you want it to. With porting an operating system across processors or whe

The stack is a great huge implementation detail, and doesn't necessarily work the way you want it to. With porting an operating system across processors or when performing significant changes and upgrades to an operating system and its interfaces, the details of the data and call stack and the thread stacks and register-passing and register spillage and all the other related ugliness can be (and often is) exceedingly platform-specific. Adding applications dependencies on these details means your code can be somewhere between faster and less portable, or faster and non-portable. Or your applications can pin the vendor in a corner by depending on a design statement that the vendor might now regret having made. Whether that might provide or prevent a thread stack, or changes to the call frames, or stack randomization or otherwise. I'm working in several areas where the vendors spend far, far, far too much time describing the internal details of their implementations. Which is bad on several levels. It can pin the vendor to the design; into choosing compatibility or choosing to break applications. And it tends to obscure the information presented to application programmers with details that are less than relevant. There's more here than strictly performance; there's also compatibility and maintainability, and stability and sustainability, and extensibility. Absent specific reasons and whenever in doubt, the decision should be to present an opaque interface. "The stack is an implementation detail."