Copyright 2004 by M. Uli Kusterer Fri, 29 Nov -1901 11:06:32 GMT Comments on article blog-stack-backwards-head-hurts at blog-stack-backwards-head-hurts Comments witness_dot_of_dot_teachtext_at_gmx_dot_net (M. Uli Kusterer) witness_dot_of_dot_teachtext_at_gmx_dot_net (M. Uli Kusterer) en-us Comment 2 by Uli Kusterer Uli Kusterer writes:
@Jeff: Yeah. I was quite happy to find out that, since on OS X the *caller* cleans up the stack, you could easily add new parameters to a function which older versions would quietly ignore.

And 9-bit bytes: I'd heard that stuff like that existed, but so far I've never used a computer that had such an odd (from today's viewpoint) set-up. At least, not knowingly ;-)
Comment 1 by Jeff Interestingly (at least from a historic perspective), the stack growing backwards is the reason that the order C evaluates arguments to a function is undefined. See specifically the section titled "Effects on the Language" for words from the language designer himself.

Consider varargs functions, those with an indeterminate number of arguments. Consider printf() - it can be quite sure that its first argument is at SP-4 irrespective of how many args were passed.

Many years back, I worked on a PRIME minicomputer which did not have a contiguous stack - instead, each function was responsible for allocating a block of "scratch memory" which it had to pass in to any function it called - this made it perfect for doing "stack crawlbacks" but a nightmare for compiler writers since the compiler had to determine (and record) the amount of temporary stack space a function would need, and to CALL a function, you needed to look at its declared requirement. Little surprise that the natural language on a PRIME was Fortran - to implement C, they actually had to code knowledge of printf()s behaviour into the compiler.

Still, that was better than GCOS with its 9 bit bytes. :-)