Am 12.01.24 um 22:58 schrieb Basil Hussain:
On 12/01/2024 19:27, Philipp Klaus Krause wrote:
Currently, the calling convention does not pass arguments in
registers. They are either passed at those names you mentioned, or on
the stack. The latter is done for __reentrant functions and when
--stack-auto is used.
I am trying to understand the stack arguments scheme. I don't understand
what is going on with the assembly code SDCC generates when accessing a
single 8-bit argument on the stack:
mov.io a, sp
add a, #0xfc
mov p, a
idxm a, p
What is the addition operation for? It's subtracting 4? Why? But if idxm
instruction needs a word address, why not divide by two (with a shift
right)?
idxm a, M reads a byte from an adress; that address does not need to be
a word address. It is a byte address, and both even and odd addresses
work. However, that address itself needs to be located at a word address
(i.e. here p needs to be at an even address, which is true, since p is
always at address 0, but p might hold an odd value, also the upper byte
of that word (i.e. here the byte at address 1) needs to be 0 for pdk13,
pdk14 and pdk15).
sp points to the unused byte just above the stack.
sp-1 and sp-2 point to the bytes of the return address for the current
function.
sp-3 point to the padding byte that we need to ensure that sp is always
even, sp-4 points to the data byte of the argument.
In more complex functions, there might be additional data (local
variables) above the return address, so the return address and argument
byte might be further from where sp points to.
P is an 8-bit pseudoregister, and the byte following P is always 0x00.
Ah, I assumed P was 16-bits. Given that P is allocated two bytes
(presumably then only for reason of alignment of subsequent data), is it
okay to use the upper byte of P for arbitrary purposes, so long as that
byte is always reset back to zero afterwards?
You mean using that byte at adress 1 in some assembler code? That could
work, but you'd have to reset it back to zero before it is used by any
SDCC-generated code. So you'd have to disable interrupts before using
the byte (and then reeenable them again after zeroing the byte).
Philipp
_______________________________________________
Sdcc-user mailing list
Sdcc-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sdcc-user
