http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51002
--- Comment #8 from Claus-Justus Heine <hims...@claus-justus-heine.de> 2012-03-18 20:30:06 UTC --- (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, which is the case for many devices, but of course one has to check this individually. > As there is code in libgcc that has to set the frame pointer, it has to load > the high byte of FP, too. libgcc (just as gcc) assumes that SP.H is always > zero. Yes. Exactly this is the problem: when artificially restricting the stack-space to 256 bytes, then nevertheless the frame pointer high-byte should be initialized with the high-byte of the stack-pointer. > Otherwise, the multilibs had to be split even further, i.e. not only on basis > of SP size but also on basis of RAM size. No. When -mtiny-stack just restricts the stack usage to 256 bytes, then there is no need for additional multi-lib targets. The ABI is not affected. Prerequisites are: - the application really does not need more than 256 bytes stack space - stack-top is aligned to 256 bytes Then: during stack updates no carry will occur from SP_L to SP_H. I can be wrong but I think in the beginning -mtiny-stack was just meant for this kind of optimization. There is also a related commit, which breaks the distinction between 8-bit hardware and -mtiny-stack-8-bit-restricted-stack-space, this was http://gcc.gnu.org/viewcvs?view=revision&revision=150801 However, can be that I'm the only fool which uses -mtiny-stack this way. So what. Still I think originally -mtiny-stack was just introduced for this: reduce the prologue size if one knows that stack usage stays below 256 bytes (and the stack-top is aligned properly). Best, cH
