Am 25.06.21 um 21:01 schrieb Basil Hussain: > What is the motivation and benefits for changing the calling convention? > I was sure I remembered you posting before sometime on one of the > mailing lists about changing the STM8 calling convention with some > reasons, but I can't find anything now. > > Personally, my comments are that I think the proposed new calling > convention will make life difficult when writing assembly code that is > to be called by C code. In my opinion, the current STM8 calling > convention suits that scenario just fine. > > Currently, where all arguments are on the stack, this gives more > flexibility to use A/X/Y registers however one wants, and the function > arguments are always there when you need them, without worrying about > overwriting or preserving them. With the new convention, one typically > would have to push A/X onto the stack immediately, and then use the > values from there. If the aim is to reduce stack usage, then it would > seem to be counter-productive in this respect. > > I can see a little benefit of having the first 8/16-bit argument passed > in A/X, as you may want to immediately operate on the argument value > anyway (a lot of my assembly immediately does "ld a, (3,sp)" or "ldw x, > (3,sp)" - you'd save that operation), but it's troublesome in that if > you want to refer again to the argument value later, you would have > needed to have saved it yourself. Any benefit will probably only be for > the most trivial of single-argument functions.
Register arguments have been requested by users commonly (as has been callee-cleanup of stack parameters), but I didn't want to make this big API-breaking change without having some data. For nearly every aspect of the calling convention, one can come up with cases where one is better vs. the other. So I created the callingconvention branch, designed to make it easy to test various calling conventions; I wrote a small program that creates a large number of patches for various different calling conventions. For those, I compiled sdcc, and 4 benchmarks, then looked at the code size (and to some degree also at benchmark scores). Looking at the data this approach to register aguments is among the best for all 4 benchmarks, both in code size and scores. So I think the results are clear here. Similarly, our current way of handling return values also was among the best for all 4 benchmarks, so keeping that one is a clear result,t oo. Details can be found in the corresponding feature request ticket: https://sourceforge.net/p/sdcc/feature-requests/732/ > >> SDCC 4.1.0 will likely use a different calling convention from the >> current one for stm8. > > Did you mean 4.2.0? Obviously, 4.1.0 is already out. :) 4.2.0. > >> This aspect is similar to Raisonance, and to some degree IAR. > > Is this a goal, to have some kind of binary compatibility with those > compilers? 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. > >> For the medium memory model, stack cleanup for stack parameters is >> done by the calle for some cases > > Typo obscures understanding here: is that supposed to be "caller" or > "callee"? > 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. So I ran tests with over a thousand different ways of deciding caller vs callee depending on return value and first argument. The picture that emerged is that for small return values, callee-cleanup tends to be better, for big ones caller-cleanup, with the notable exception of float functions. For the latter, I see a big code size advantage for callee-cleanup. Still, I might do more experiments about this aspect (my timeline is to next look into z80 / r3ka calling conventions, and then come back to stm8). Philipp _______________________________________________ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
