Mercurial > pub > dyncall > dyncall

comparison doc/manual/callconvs/callconv_mips64.tex @ 499:fc614cb865c6

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
- 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 75c19f11b86a
children
comparison
equal deleted inserted replaced
498:fd9ba3a6d348 499:fc614cb865c6
82 \item float arguments passed in the variable part of a vararg call are passed like integers, meaning float registers don't ever need to be saved that way, so only \$a0-\$a7 are need to be spilled 82 \item float arguments passed in the variable part of a vararg call are passed like integers, meaning float registers don't ever need to be saved that way, so only \$a0-\$a7 are need to be spilled
83 \item quad precision float arguments are passed in even-odd register pairs, skipping one register if needed 83 \item quad precision float arguments are passed in even-odd register pairs, skipping one register if needed
84 \item integer parameters \textless\ 64 bit are right-justified (meaning occupy higher-address bytes) in their 8-byte slot on the stack, requiring extra-care for big-endian targets 84 \item integer parameters \textless\ 64 bit are right-justified (meaning occupy higher-address bytes) in their 8-byte slot on the stack, requiring extra-care for big-endian targets
85 \item single precision float parameters (32 bit) are left-justified in their 8-byte slot on the stack, but are right justified in fp-registers on big endian targets, as they aren't promoted (actually, official docs says "undecided", but real world implementations seem to use what is described here) 85 \item single precision float parameters (32 bit) are left-justified in their 8-byte slot on the stack, but are right justified in fp-registers on big endian targets, as they aren't promoted (actually, official docs says "undecided", but real world implementations seem to use what is described here)
86 \item aggregates (struct, union) are passed as a sequence of dwords in (integer registers and the stack), with the following particularities: 86 \item aggregates (struct, union) are passed as a sequence of dwords in (integer registers and the stack), with the following particularities:
87 \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
87 \begin{itemize} 88 \begin{itemize}
88 \item if a dword happens to be a double precision floating point struct field, it is passed in a floating point register 89 \item if a dword happens to be a double precision floating point struct field, it is passed in a floating point register
89 \item array and union fields are always passed like integers (even if their type is float or double) 90 \item array and union fields are always passed like integers (even if their type is float or double)
90 \item splitting an argument across registers and the stack is fine 91 \item splitting an argument across registers and the stack is fine
91 \end{itemize} 92 \end{itemize}
121 122
122 \begin{itemize} 123 \begin{itemize}
123 \item results are returned in \$v0, and for a second one \$v1 is used 124 \item results are returned in \$v0, and for a second one \$v1 is used
124 \item only on hard-float targets: floating point results are returned in \$f0 (and \$f2 if needed) 125 \item only on hard-float targets: floating point results are returned in \$f0 (and \$f2 if needed)
125 \item only on hard-float targets: structs with only one or two floating point fields are returned in \$f0 (and \$f2 if necessary), field-by-field 126 \item only on hard-float targets: structs with only one or two floating point fields are returned in \$f0 (and \$f2 if necessary), field-by-field
127 \item for {\it non-trivial} C++ aggregates, the caller allocates space, passes pointer to it to the callee as a hidden first param
128 (meaning in \%a0), and callee writes return value to this space; the ptr to the aggregate is returned in \%v0
126 \item any other aggregates (struct, union) \textless= 16 bytes are returned via registers \$v0 (and \$v1 if necessary), dword-by-dword 129 \item any other aggregates (struct, union) \textless= 16 bytes are returned via registers \$v0 (and \$v1 if necessary), dword-by-dword
127 \item all other aggregates (struct, union) \textgreater 16 bytes are returned in a space allocated by the caller, with a pointer to it 130 \item all other aggregates (struct, union) \textgreater 16 bytes are returned in a space allocated by the caller, with a pointer to it
128 passed as first parameter to the function called (meaning in \%a0) 131 passed as first parameter to the function called (meaning in \%a0); the ptr to the aggregate is returned in \%v0
129 %spec; 132 %spec;
130 %Composite results (struct, union, or array) are returned in 133 %Composite results (struct, union, or array) are returned in
131 %$2/$f0 and $3/$f2 according to the following rules: 134 %$2/$f0 and $3/$f2 according to the following rules:
132 %- A struct with only one or two floating point fields is returned in $f0 (and $f2 if 135 %- A struct with only one or two floating point fields is returned in $f0 (and $f2 if
133 %necessary). This is a generalization of the Fortran COMPLEX case. 136 %necessary). This is a generalization of the Fortran COMPLEX case.