#388 Extended stack access for stm8


Currently, the stm8 port accesses local variables using sp-relative addressing mode (except for aggregates and unions). While this is the fastest way to access local variables, it limits their total size to baout 240 bytes; functions that use more local variables fail to compile with error message "Unimplemented extended stack access".

It would be good if the stm8 port was able to use more local variables in functions, so we need to come up with a way to handle the extended stack. One option would be to use a frame pointer, similar to what the z80 port does (for ordinary stack access, since the z80 doesn't have sp-relative addressing): Save sp into y on function entry, and use the y-relative addressing mode for extended stack access. This would mean that on functions using more than 240 bytes of local variables, y would be reserved for that and could not be used for temporaries. Also, the current calling convention uses y for return values, and y is a calle-saved register, so we would have to save and restore y over very function call from functions that use more than 240 bytes of lcoal variables. An alternaitve would be to create a pointer to variables on the extended stack onyl as-needed. The latter solution would be cheaper for functions that do many functions calls, but do not access variables on the extended stack often, but more expensive otherwise.

I guess using a frame pointer in y would be the easiest way to go for now. Since this affects register allocation, we need to make a safe guess on weather a function might use the extened stack before register allocation, make register allocation reserve y in such functions, setup the frame pointer, and use it in code generation.

In case --fno-omit-frame-pointer is specified, we would always reserve y, and setup a frame pointer, in case --fomit-frame-pointer is specified, we would try to do without one, and then give an error message, if we can't (just replace the current "Unimplemented extended stack access" with something more informative).



  • Philipp Klaus Krause

    • assigned_to: Philipp Klaus Krause
    • Group: -->
  • Philipp Klaus Krause

    • status: open --> closed-fixed
  • Philipp Klaus Krause

    This got even more complicated: Unlike the z80, the sdcc only supports unsigned offsets in pointer access, so we cannot use y as a frame pointer, but have to use it more like a second stack pointer.
    Still thh basic functionality should now be there in revision #8685.



Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks