It was not a goal for the new calling convention. However, for those that want binary / asm compability, I introduced the __raisonance, __comsic, __iar keywords, to explicitly use the calling convention of a compiler for an individual function.
If you are adding these attribute keywords, would it then be possible to have one to dictate, per function, the use of the old purely-stack-based calling convention? I think this would be a good idea for the sake of backwards compatibility, so that existing inline assembly code does not have to be rewritten just to compile under the new version.
For instance, I have some STM8 assembly libraries (https://github.com/basilhussain/stm8-crc, https://github.com/basilhussain/stm8-utils) that would need a lot of minor changes to their code in order to work under the new calling convention.
callee. In the current convention, the cleanup is always done by the caller. The caller vs callee-cleanup is the aspect that I am still a bit unsure of. While this makes a differnce, the pciture was not that clear initally.
Can I clarify my understanding here? Callee-cleanup will have the called function rewind the stack pointer for any arguments that were passed on the stack. So, the caller will still push args onto the stack as before, but the callee will be responsible for clearing them off the stack? And the caller will not need to do anything after the called function returns. Am I correct?
I have a tangential question: does any of this work make it easier to implement the callee-saves option/pragma for STM8? I was disappointed that this option doesn't work on the STM8 platform when working on the open-source STM8 bootloader erase/write routines with Georg Icking-Konert earlier this year. The ROM bootloader does not save register contents before calling erase/write RAM functions, so flagging these functions as callee-saves would have been ideal. But because it could not be used, I had to do the extra work of inspecting the ROM code disassembly in detail to ensure nothing bad would happen when registers were not in their original state when returning to ROM code.
Regards, Basil Hussain _______________________________________________ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
