It would just perhaps be an indicator that something went wrong, but you'd only know that the cookie got eaten and not who ate it; and also it might be too late to check...

I learned from a colleague of mine to put a stack checking routine into the interrupt of the highest priority (which happened to hold some 20-30% of the whole programs functionality - I know you'd say phooey but you also certainly know I am not afraid to do unusual things if I have a good reason); and make a stack dump if overflow occurs (provided that there is good place to store the dump into or to transmit it or to display it), but I would not say it's perfect either (it caught a case or two but never out in the wild only on my desk, so I would catch them most probably without this, too - but this is perhaps given by the nature of the tasks I am usually solving and the method might be more useful generally).

Certainly the best thing is to have a rock bottom (which in '51 happens to be at the top... :-) ) of the stack - so if some routine chews it all up, it chokes on the next bite... Yes, I mean real hardware. It does not require any sophisticated and complicated memory management unit, as the stack is guaranteed to be accessed linearly (until some idiot starts to play with SP, of course), so a single-address access breakpoint throwing an interrupt (or, if you want an another fancy term, exception) will suffice. Such hardware is I suspect present in those '51s which have hardware support for debugging (SiLabs, Ramtron/exGoal Versa, ADuC???), but I am afraid that the manufacturers jealously
withhold these information from the public...

JW