http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51002
--- Comment #10 from Claus-Justus Heine <hims...@claus-justus-heine.de> 2012-03-18 21:56:35 UTC --- (In reply to comment #9) > (In reply to comment #8) > > (In reply to comment #7) > > > (In reply to comment #6) > > > > Jut a comment: at least I was using -mtiny-stack on targets with 16-bit > > > > stack to reduce the size of the prologue/epilogue of a function. > > > > This worked quite well, of course only if the actual stack usage > > > > really stayed below 256 bytes. > > > I don't think that works reliably, even if the stack usage is below > > > 256 bytes. Crucial point is the crossing of a 256-byte boundary, i.e. > > > changing SP.H, for example while crossing the 0xff/0x100 border. > > > > It should work reliably if the stack-top is aligned to a 256 bytes, > > No, that's not sufficient. The reason is that gcc does not only change > SP. In some situations the cmopiler has to set up a frame pointer and > build a 16-bit pointer. If the stack pointer in only 8 bits wide, there > is no other sensible value than 0. Sorry, but my comments are just about this: loading the frame pointer with the complete 16bit value of the stack pointer. I will stop the discussion at this point, because I have the impression talk at cross-purposes. I never suggested to tweak the stack pointer, but just realized that recent gcc versions stopped to load the frame pointer with the complete stack pointer value in the presence of -mtiny-stack. I still think that the origin of the "problem" was to "unify" the -mtiny-stack switch with the architectural hardware-constraint of having only an 8 bit stack pointer.
