One aspect of the ABI is if stack parameters are cleaned up by the caller vs. the callee.
Caller-cleanup pseudocode for call: push arg call func add sp, #argsize Callee-cleanup pseudocode for call: push arg call func Callee-cleanup saves code size and cycles in the caller, at the cost of adding code size and cycles in the callee. Where there is a free 16-bit register (i.e. return value of at most 16 bits), using callee-cleanup is usually worth it. But for larger return values, the lack of a free register in the callee at the end of the function results in substantial overhead for callee-cleanup. For functions that are called often, we still benefit from callee-cleanup in code size, but suffer in cycles. This becomes particularly interesting for float functions. Soft-float helper functions (e.g. floating-point addition, etc) are called often, so programs that use a lot of float benefit in code size, and suffer in speed. Example: Whetstone compiled for different calling conventions (using a variant of SDCC where all asm-implemented library functions are replaced by C code): * New ABI, variant where caller cleans up the stack for float functions vs. old ABI: Whetstone code size reduced by 1.2%, score increased by 0.5%. * New ABI, variant where callee cleans up the stack for float functions vs. old ABI: Whetstone code size reduced by 3.4%, score reduced by 0.9%. Are there any opinions from SDCC users on how we should proceed here? At this point is looks to me like this is the only remaining unclear aspect of the future default calling convention for stm8. Philipp P.S.: In reality, i.e. with asm-implemented lib functions the impact of the question is even a bit bigger. For the new (callee cleans up stack parameters variant) vs. the old ABI, I see Whetstone cose size reduced by 3.8%, score reduced by 1.8%. _______________________________________________ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
