Mercurial > pub > dyncall > dyncall
comparison doc/manual/callconvs/callconv_mips32.tex @ 499:fc614cb865c6
- doc and disasexample additions specific to non-trivial C++ aggregates as return values (incl. fixes to doc and additional LSB specific PPC32 section)
| author | Tassilo Philipp |
|---|---|
| date | Mon, 04 Apr 2022 15:50:52 +0200 |
| parents | a55506bf924e |
| children |
comparison
equal
deleted
inserted
replaced
| 498:fd9ba3a6d348 | 499:fc614cb865c6 |
|---|---|
| 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 | 91 \item aggregates (struct, union) \textless=\ 32bit are passed like an integer |
| 92 \item {\it non-trivial} C++ aggregates (as defined by the language) of any size, are passed indirectly via a pointer to a copy of the aggregate | |
| 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 | 93 \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 |
| 93 \end{itemize} | 94 \end{itemize} |
| 94 | 95 |
| 95 \paragraph{Return values} | 96 \paragraph{Return values} |
| 96 | 97 |
| 97 \begin{itemize} | 98 \begin{itemize} |
| 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 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) |
| 100 \item for {\it non-trivial} C++ aggregates, the caller allocates space, passes pointer to it to the callee as a hidden first param | |
| 101 (meaning in \%a0), and callee writes return value to this space; the ptr to the aggregate is returned in \%v0 | |
| 99 \item aggregates (struct, union) \textless=\ 64bit are returned like an integer (aligned within the register according to endianness) | 102 \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 | 103 \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) | 104 passed as first parameter to the function called (meaning in \%a0); the ptr to the aggregate is returned in \%v0 |
| 102 \end{itemize} | 105 \end{itemize} |
| 103 | 106 |
| 104 \paragraph{Stack layout} | 107 \paragraph{Stack layout} |
| 105 | 108 |
| 106 % verified/amended: TP nov 2019 (see also doc/disas_examples/mips.eabi.disas) | 109 % verified/amended: TP nov 2019 (see also doc/disas_examples/mips.eabi.disas) |
| 178 \item only on hard-float targets: if the very first call argument is a float, up to 2 floats or doubles can be passed via \$f12 and \$f14, respectively, for first and second argument | 181 \item only on hard-float targets: if the very first call argument is a float, up to 2 floats or doubles can be passed via \$f12 and \$f14, respectively, for first and second argument |
| 179 \item only on hard-float targets: if any arguments are passed via float registers, skip \$a0-\$a3 for subsequent arguments as if the values were passed via them | 182 \item only on hard-float targets: if any arguments are passed via float registers, skip \$a0-\$a3 for subsequent arguments as if the values were passed via them |
| 180 \item only on hard-float targets: note that if the first argument is not a float, but the second, it'll get passed via the \$a? registers | 183 \item only on hard-float targets: note that if the first argument is not a float, but the second, it'll get passed via the \$a? registers |
| 181 \item single precision float parameters (32 bit) are right-justified in their 8-byte slot on the stack on big endian targets, as they aren't promoted % @@@ verify | 184 \item single precision float parameters (32 bit) are right-justified in their 8-byte slot on the stack on big endian targets, as they aren't promoted % @@@ verify |
| 182 \item aggregates (struct, union) are passed as a sequence of words like integers, no matter the fields or if hard-float target (splitting across registers and stack is allowed) | 185 \item aggregates (struct, union) are passed as a sequence of words like integers, no matter the fields or if hard-float target (splitting across registers and stack is allowed) |
| 186 \item {\it non-trivial} C++ aggregates (as defined by the language) of any size, are passed indirectly via a pointer to a copy of the aggregate | |
| 183 \end{itemize} | 187 \end{itemize} |
| 184 | 188 |
| 185 \paragraph{Return values} | 189 \paragraph{Return values} |
| 186 | 190 |
| 187 \begin{itemize} | 191 \begin{itemize} |
| 188 \item results are returned in \$v0 and \$v1, with \$v0 for all values \textless\ 64bit (only integer on hard-float targets) | 192 \item results are returned in \$v0 and \$v1, with \$v0 for all values \textless\ 64bit (only integer on hard-float targets) |
| 189 \item only on hard-float targets: floating point results are returned in \$f0 (32-bit float), or \$f0 and \$f3 (64bit float) | 193 \item only on hard-float targets: floating point results are returned in \$f0 (32-bit float), or \$f0 and \$f3 (64bit float) |
| 190 \item aggregates (struct, union) of any size are returned in a space allocated by the caller, with a pointer to it | 194 \item aggregates (struct, union) are returned in a space allocated by the caller, with a pointer to it |
| 191 passed as first parameter to the function called (meaning in \%a0) | 195 passed as first parameter to the function called (meaning in \%a0); the ptr to the aggregate is returned in \%v0 |
| 192 \end{itemize} | 196 \end{itemize} |
| 193 | 197 |
| 194 \paragraph{Stack layout} | 198 \paragraph{Stack layout} |
| 195 | 199 |
| 196 % verified/amended: TP nov 2019 (see also doc/disas_examples/mips.o32.disas) | 200 % verified/amended: TP nov 2019 (see also doc/disas_examples/mips.o32.disas) |