Several RISC architectures are neutral about stack growth direction, because they don't "microcodedly" push registers into RAM; they switch to alternate register sets during exceptions, for example, and instead of having a "call" instruction that pushes a return address, they have a "branch and link" instruction that saves the return address in a link register. PA-RISC is an example where the stack often (always?) grows up, e.g. in the canonical HP-UX. ARM and PowerPC can also use stacks that grow up, down or sideways according to the developer's particular fetish.
Well, this is a semantic question; what, exactly, is "significant"? There are relatively few architectures that have a hardware-enforced "directionness" that makes the stack grow up. The RISC architectures I mentioned are neutral, _BUT_ there are ABI definitions, generally adhered to by compilers, that might "encourage" one direction rather than another. Your life will become consummately interesting if you defy this without modifying the compiler, operating system and libraries with which you intend to interoperate.
This issue has been dealt with extensively by the porters of Linux to eldritch architectures.
I can't think of a useful example off the top of my head, but I've got a vague memory tickling the back of my mind.
"On the 8096BH, the address is calculated based on the un-updated version of the stack pointer. The 80C196KB uses the updated version. The offset for POP[SP] and POP nn[SP] instructions may need to be changed by a count of 2."
I am currently working with the 8096 and need to treat the stack pointer as post-decremented.
The context is the following: I am developing the small RTOS keeping in mind the portability to the popular architectures. The RTOS is seen as a library module with the minimum dependencies from the tool chain and the target. So, the question is if it can be assumed that the stacks are always from high to low address, pre-decremented, or it should be defined as the configuration or build option.
I can't recall any except x51, that's why I am addressing the question to the club.
Then you have a logical inconsistency highlighted by merely asking your original question, viz: if you are targeting "popular" architectures, why are you worrying about obscure, rare, alien architectures not known to the majority of engineers or programmers?
And the answer - which you didn't really need to ask in order to know
- is that it is most flexible if you make it configurable, but most people will be satisfied with the assumption of a downgrowing stack.
Are you asking a question? Well, on ARM, it's normally down, PA-RISC it's up, MIPS it's down, PowerPC it's down, but you can implement it the other way on any of those architectures.
Solutions have been found for processors capable of running Linux. The MCS51 etc obviously do not qualify.
For your application, it's non-obvious why you need to know; your RTOS and libraries would presumably conceal most of this information from the caller (e.g. if your caller needs to start a thread and provide stack space, he passes a pointer to the start of the block, and a size parameter, and your OS handles any required arithmetic and housekeeping).