Mercurial > pub > dyncall > dyncall
comparison doc/manual/callconvs/callconv_mips32.tex @ 479:a55506bf924e
- mips32/eabi doc: adding info about aggregates
| author | Tassilo Philipp |
|---|---|
| date | Tue, 01 Mar 2022 09:29:21 +0100 |
| parents | 6c72cb768099 |
| children | fc614cb865c6 |
comparison
equal
deleted
inserted
replaced
| 478:6c72cb768099 | 479:a55506bf924e |
|---|---|
| 86 \item 64-bit stack arguments are always aligned to 8 bytes | 86 \item 64-bit stack arguments are always aligned to 8 bytes |
| 87 \item 64-bit integers or double precision floats are passed in two general purpose registers starting at an even register number, skipping one odd register | 87 \item 64-bit integers or double precision floats are passed in two general purpose registers starting at an even register number, skipping one odd register |
| 88 \item if either integer or float registers are used up, the stack is used | 88 \item if either integer or float registers are used up, the stack is used |
| 89 \item if the callee takes the address of one of the parameters and uses it to address other unnamed parameters (e.g. varargs) it has to copy - in its prolog - the the argument registers to a reserved stack area adjacent to the other parameters on the stack (only the unnamed integer parameters require saving, though) % @@@ seems to *ONLY* spill with varargs, never for any other reason | 89 \item if the callee takes the address of one of the parameters and uses it to address other unnamed parameters (e.g. varargs) it has to copy - in its prolog - the the argument registers to a reserved stack area adjacent to the other parameters on the stack (only the unnamed integer parameters require saving, though) % @@@ seems to *ONLY* spill with varargs, never for any other reason |
| 90 \item float registers don't seem to ever need to be saved that way, because floats passed to an ellipsis function are promoted to doubles, which in turn are passed in a? register pairs, so only \$a0-\$a7 are need to be spilled | 90 \item float registers don't seem to ever need to be saved that way, because floats passed to an ellipsis function are promoted to doubles, which in turn are passed in a? register pairs, so only \$a0-\$a7 are need to be spilled |
| 91 \item aggregates (struct, union) \textless=\ 32bit are passed like an integer | |
| 92 \item all other aggregates (struct, union) are passed indirectly, as a pointer to a copy (if needed, and for vararg arguments required to be copied by the caller) of the struct | |
| 91 \end{itemize} | 93 \end{itemize} |
| 92 | 94 |
| 93 \paragraph{Return values} | 95 \paragraph{Return values} |
| 94 | 96 |
| 95 \begin{itemize} | 97 \begin{itemize} |
| 96 \item results are returned in \$v0 (32-bit), \$v0 and \$v1 (64-bit), \$f0 or \$f0 and \$f2 (2 $\times$ 32 bit float e.g. complex) | 98 \item results are returned in \$v0 (32-bit), \$v0 and \$v1 (64-bit), \$f0 or \$f0 and \$f2 (2 $\times$ 32 bit float e.g. complex) |
| 99 \item aggregates (struct, union) \textless=\ 64bit are returned like an integer (aligned within the register according to endianness) | |
| 100 \item all other aggregates (struct, union) are returned in a space allocated by the caller, with a pointer to it | |
| 101 passed as first parameter to the function called (meaning in \%a0) | |
| 97 \end{itemize} | 102 \end{itemize} |
| 98 | 103 |
| 99 \paragraph{Stack layout} | 104 \paragraph{Stack layout} |
| 100 | 105 |
| 101 % verified/amended: TP nov 2019 (see also doc/disas_examples/mips.eabi.disas) | 106 % verified/amended: TP nov 2019 (see also doc/disas_examples/mips.eabi.disas) |