Philipp Klaus Krause schreef op 2025-11-23 16:02:
Currently, SDCC omits integer promotion of explictly typecast
arguments passed as variable arguments. This is done only when the
selected standard dialect is an SDCC variant, and the target is not a
pdk port (see section 3.5.15 of the manual).
The feature allows to save a byte of stack space (and some code size /
speed if pushing an 8-bit value is simpler than pushing a 16-bit one)
when passing a char, bool or _BitInt as variable argument.
I'd like to remove support for this langauge extension from the stm8
port, f8 port, the z80-related ports, hc08 and s08.
Rationale:
* The main benefit of the feature is saving a little bit of stack
space. But stm8, f8, the z80-related ports, hc08, s08, and mcs51 (for
the large and huge memory model) have a large stack (with the
exception of some stm8 devices, the whole RAM can be used as stack).
I would not qualify the stack as large for the mcs51 large & huge
memory models. Medium, large and huge do not place every variable in
the <= 248 bytes data memory, but still use it for itemps. So stack
space (= unallocated idata) remains very limited.
And when using --xstack the stack still is limited to 256 bytes pdata.
There is no stack implementation in xdata.
* Omitting the integer promotion violates the C standard, and could
thus result in surprising behavior for the user. After all that cast
is not necessarily explicitly written with intent to omit the
promotion, the cast might come e.g. from a macro expansion.
* The omission makes code compiled with the SDCC dialect incompatible
with code compiled without the dialect. This results in silent
breakage when there are calls between such code that pass explicitly
cast variable arguments (AFAIK even if that happens within the same
file, and there is a #pragma std_sdccXX / #pragma std_cXX in between).
* stm8, f8, the z80-related ports, hc08, s08 do have instructions to
efficiently push a 16-bit value onto the stack, so there is not much
benefit in code size and speed.
* For the z80-related ports, we do not have instructions to
efficiently put a single 8-bit value on the stack, we instead need to
push a 16-bit register or value, then adjust the stack pointer, so
there typically is no or even a negative benenefit in code size and
speed.
Philipp
So my recommendation is to keep this behaviour for all targets with a
stack space of 256 bytes or less.
Maarten
_______________________________________________
Sdcc-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sdcc-user
