3 %%% C language utilities
5 %%% (c) 2015 Straylight/Edgeware
8 %%%----- Licensing notice ---------------------------------------------------
10 %%% This file is part of the Sensible Object Design, an object system for C.
12 %%% SOD is free software; you can redistribute it and/or modify
13 %%% it under the terms of the GNU General Public License as published by
14 %%% the Free Software Foundation; either version 2 of the License, or
15 %%% (at your option) any later version.
17 %%% SOD is distributed in the hope that it will be useful,
18 %%% but WITHOUT ANY WARRANTY; without even the implied warranty of
19 %%% MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
20 %%% GNU General Public License for more details.
22 %%% You should have received a copy of the GNU General Public License
23 %%% along with SOD; if not, write to the Free Software Foundation,
24 %%% Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
26 \chapter{C language utilities
} \label{ch:clang
}
28 %%%--------------------------------------------------------------------------
29 \section{C type representation
} \label{sec:clang.c-types
}
31 \subsection{Overview
} \label{sec:clang.c-types.over
}
33 The Sod translator represents C types in a fairly simple and direct way.
34 However, because it spends a fair amount of its time dealing with C types, it
35 provides a number of useful operations and macros.
37 The class hierarchy is shown in~
\xref{fig:codegen.c-types.classes
}.
39 \begin{figure
} \centering
40 \parbox{10pt
}{\begin{tabbing}
42 @|qualifiable-c-type| \\
\ind
43 @|simple-c-type| \\
\ind
45 @|tagged-c-type| \\
\ind
50 @|c-pointer-type| \-\\
52 @|c-function-type| \\
\ind
53 @|c-keyword-function-type| \-
55 \caption{Classes representing C types
}
56 \label{fig:codegen.c-types.classes
}
59 C type objects are immutable unless otherwise specified.
61 \subsubsection{Constructing C type objects
}
62 There is a constructor function for each non-abstract class of C type object.
63 Note, however, that constructor functions need not generate a fresh type
64 object if a previously existing type object is suitable. In this case, we
65 say that the objects are
\emph{interned
}. Some constructor functions are
66 specified to return interned objects: programs may rely on receiving the same
67 (@|eq|) type object for similar (possibly merely @|equal|) arguments. Where
68 not specified, clients may still not rely on receiving fresh objects.
70 A convenient S-expression notation is provided by the
71 \descref{c-type
}[macro
]{mac
}. Use of this macro is merely an abbreviation
72 for corresponding use of the various constructor functions, and therefore
73 interns type objects in the same manner. The syntax accepted by the macro
74 can be extended in order to support new classes: see
\descref{defctype
}{mac
},
75 \descref{c-type-alias
}{mac
} and
\descref{define-c-type-syntax
}{mac
}.
77 The descriptions of each of the various classes include descriptions of the
78 initargs which may be passed to @|make-instance| when constructing a new
79 instance of the class. However, the constructor functions and S-expression
80 syntax are strongly recommended over direct use of @|make-instance|.
82 \subsubsection{Printing
}
83 There are two protocols for printing C types. Unfortunately they have
86 \item The
\descref{print-c-type
}[function
]{gf
} prints a C type value using
87 the S-expression notation. It is mainly useful for diagnostic purposes.
88 \item The
\descref{pprint-c-type
}[function
]{gf
} prints a C type as a
91 Neither generic function defines a default primary method; subclasses of
92 @|c-type| must define their own methods in order to print correctly.
95 \subsection{The C type root class
} \label{sec:clang.c-types.root
}
97 \begin{describe
}{cls
}{c-type ()
}
98 The class @|c-type| marks the root of the built-in C type hierarchy.
100 Users may define subclasses of @|c-type|. All non-abstract subclasses must
101 have a primary method defined on @|pprint-c-type|; unless instances of the
102 subclass are interned, a method on @|c-type-equal-p| is also required.
104 The class @|c-type| is abstract.
108 \subsection{C type S-expression notation
} \label{sec:clang.c-types.sexp
}
110 The S-expression representation of a type is described syntactically as a
111 type specifier. Type specifiers fit into two syntactic categories.
113 \item A
\emph{symbolic type specifier
} consists of a symbol. It has a
114 single, fixed meaning: if @<name> is a symbolic type specifier, then each
115 use of @<name> in a type specifier evaluates to the same (@|eq|) type
116 object, until the @<name> is redefined.
117 \item A
\emph{type operator
} is a symbol; the corresponding specifier is a
118 list whose @|car| is the operator. The remaining items in the list are
119 arguments to the type operator.
122 \begin{describe
}{mac
}{c-type @<type-spec> @> @<c-type>
}
123 Evaluates to a C type object, as described by the type specifier
127 \begin{describe
}{mac
}
128 {defctype \=@
{ @<name> @! (@<name>^+) @
} @<type-spec> \+\\
129 @
[[ @|:export| @<export-flag> @
]]^*
131 Defines a new symbolic type specifier @<name>; if a list of @<name>s is
132 given, then all are defined in the same way. The type constructed by using
133 any of the @<name>s is as described by the type specifier @<type-spec>.
135 The resulting type object is constructed once, at the time that the macro
136 expansion is evaluated; the same (@|eq|) value is used each time any
137 @<name> is used in a type specifier.
139 A variable named @|c-type-@<name>|, for the first @<name> only, is defined
140 and initialized to contain the C type object so constructed. Altering or
141 binding this name is discouraged.
143 If @<export-flag> is true, then the variable name, and all of the @<name>s,
144 are exported from the current package.
147 \begin{describe
}{mac
}{c-type-alias @<original> @<alias>^* @> @<aliases>
}
148 Defines each @<alias> as being a type operator identical in behaviour to
149 @<original>. If @<original> is later redefined then the behaviour of the
150 @<alias>es changes too.
153 \begin{describe
}{mac
}
154 {define-c-type-syntax @<name> @<lambda-list> \\
\ind
155 @
[[ @<declaration>^* @! @<doc-string> @
]] \\
158 Defines the symbol @<name> as a new type operator. When a list of the form
159 @|(@<name> @<argument>^*)| is used as a type specifier, the @<argument>s
160 are bound to fresh variables according to @<lambda-list> (a destructuring
161 lambda-list) and the @<form>s evaluated in order in the resulting lexical
162 environment as an implicit @|progn|. The value should be a Lisp form which
163 will evaluate to the type specified by the arguments.
165 The @<form>s may call @|expand-c-type-spec| in order to recursively expand
166 type specifiers among its arguments.
169 \begin{describe
}{gf
}{expand-c-type-spec @<type-spec> @> @<form>
}
170 Returns the Lisp form that @|(c-type @<type-spec>)| would expand into.
172 If @<type-spec> is a list, then
\descref{expand-c-type-form
}{fun
} is
176 \begin{describe
}{gf
}{expand-c-type-form @<head> @<tail> @> @<form>
}
177 Returns the Lisp form that @|(c-type (@<head> . @<tail>)| would expand
182 {print-c-type @<stream> @<type> \&optional @<colon> @<atsign>
}
183 Print the C type object @<type> to @<stream> in S-expression form. The
184 @<colon> and @<atsign> arguments may be interpreted in any way which seems
185 appropriate: they are provided so that @|print-c-type| may be called via
186 @|format|'s @|
\char`\~/
\dots/| command; they are not set when
187 @|print-c-type| is called by Sod functions.
189 There should be a method defined for every C type class; there is no
194 \subsection{Comparing C types
} \label{sec:clang.c-types.cmp
}
196 It is necessary to compare C types for equality, for example when checking
197 argument lists for methods. This is done by @|c-type-equal-p|.
200 {c-type-equal-p @<c-type>_1 @<c-type>_2 @> @<generalized-boolean>
}
201 The generic function @|c-type-equal-p| compares two C types @<c-type>_1 and
202 @<c-type>_2 for equality; it returns true if the two types are equal and
203 false if they are not.
205 Two types are equal if they are structurally similar, where this property
206 is defined by methods for each individual class; see the descriptions of
207 the classes for the details.
209 The generic function @|c-type-equal-p| uses the @|and| method combination.
211 \begin{describe
}{meth
}{c-type-equal-p @<c-type>_1 @<c-type>_2
}
212 A default primary method for @|c-type-equal-p| is defined. It simply
213 returns @|nil|. This way, methods can specialize on both arguments
214 without fear that a call will fail because no methods are applicable.
216 \begin{describe
}{ar-meth
}{c-type-equal-p @<c-type>_1 @<c-type>_2
}
217 A default around-method for @|c-type-equal-p| is defined. It returns
218 true if @<c-type>_1 and @<c-type>_2 are @|eql|; otherwise it delegates to
219 the primary methods. Since several common kinds of C types are interned,
220 this is a common case worth optimizing.
225 \subsection{Outputting C types
} \label{sec:clang.c-types.output
}
227 \begin{describe
}{gf
}{pprint-c-type @<c-type> @<stream> @<kernel>
}
228 The generic function @|pprint-c-type| pretty-prints to @<stream> a C-syntax
229 declaration of an object or function of type @<c-type>. The result is
230 written to @<stream>.
232 A C declaration has two parts: a sequence of
\emph{declaration specifiers
}
233 and a
\emph{declarator
}. The declarator syntax involves parentheses and
234 operators, in order to reflect the operators applicable to the declared
235 variable. For example, the name of a pointer variable is preceded by @`*';
236 the name of an array is followed by dimensions enclosed in @`
['
\dots @`
]'.
238 The @<kernel> argument must be a function designator (though see the
239 standard around-method); it is invoked as
240 \begin{quote
} \codeface
241 (funcall @<kernel> @<stream> @<priority> @<spacep>)
243 It should write to @<stream> -- which may not be the same stream originally
244 passed into the generic function -- the `kernel' of the declarator, i.e.,
245 the part to which prefix and/or postfix operators are attached to form the
248 The methods on @|pprint-c-type| specialized for compound types work by
249 recursively calling @|pprint-c-type| on the subtype, passing down a closure
250 which prints the necessary additional declarator operators before calling
251 the original @<kernel> function. The additional arguments @<priority> and
252 @<spacep> support this implementation technique.
254 The @<priority> argument describes the surrounding operator context. It is
255 zero if no type operators are directly attached to the kernel (i.e., there
256 are no operators at all, or the kernel is enclosed in parentheses), one if
257 a prefix operator is directly attached, or two if a postfix operator is
258 directly attached. If the @<kernel> function intends to provide its own
259 additional declarator operators, it should check the @<priority> in order
260 to determine whether parentheses are necessary. See also the
261 \descref{maybe-in-parens
}[macro
]{mac
}.
263 The @<spacep> argument indicates whether a space needs to be printed in
264 order to separate the declarator from the declaration specifiers. A kernel
265 which contains an identifier should insert a space before the identifier
266 when @<spacep> is non-nil. An `empty' kernel, as found in an abstract
267 declarator (one that specifies no name), looks more pleasing without a
268 trailing space. See also the
\descref{c-type-space
}[function
]{fun
}.
270 Every concrete subclass of @|c-type| is expected to provide a primary
271 method on this function. There is no default primary method.
273 \begin{describe
}{ar-meth
}{pprint-c-type @<c-type> @<stream> @<kernel>
}
274 A default around method is defined on @|pprint-c-type| which `canonifies'
275 non-function @<kernel> arguments. In particular:
277 \item if @<kernel> is nil, then @|pprint-c-type| is called recursively
278 with a @<kernel> function that does nothing; and
279 \item if @<kernel> is any other kind of object, then @|pprint-c-type| is
280 called recursively with a @<kernel> function that prints the object as
281 if by @|princ|, preceded if necessary by space using @|c-type-space|.
286 \begin{describe
}{fun
}{c-type-space @<stream>
}
287 Writes a space and other pretty-printing instructions to @<stream> in order
288 visually to separate a declarator from the preceding declaration
289 specifiers. The precise details are subject to change.
292 \begin{describe
}{mac
}
293 {maybe-in-parens (@<stream-var> @<guard-form>)
296 The @<guard-form> is evaluated, and then the @<form>s are evaluated in
297 sequence within a pretty-printer logical block writing to the stream named
298 by the symbol @<stream-var>. If the @<guard-form> evaluates to nil, then
299 the logical block has empty prefix and suffix strings; if it evaluates to a
300 non-nil value, then the logical block has prefix and suffix @`(' and @`)'
303 Note that this may cause @<stream> to be bound to a different stream object
308 \subsection{Type qualifiers and qualifiable types
}
309 \label{sec:clang.ctypes.qual
}
311 Qualifiers -- @|const|, @|volatile|, and so on -- are represented as lists of
312 keywords attached to types. Not all C types can carry qualifiers: notably,
313 function and array types cannot be qualified.
315 For the most part, the C qualifier keywords correspond to like-named Lisp
316 keywords, only the Lisp keyword names are in uppercase. The correspondence
317 is shown in
\xref{tab:clang.ctypes.qual
}.
320 \begin{tabular
}[C
]{*
2{>
{\codeface}l
}l
} \hlx*
{hv
}
321 \thd{\textbf{C name
}} &
\thd{\textbf{Lisp name
}} \\
\hlx{vhv
}
324 restrict & :restrict \\
325 volatile & :volatile \\
\hlx*
{vh
}
327 \caption{C and Lisp qualifier names
} \label{tab:clang.ctypes.qual
}
330 The default behaviour, on output, is to convert keywords to lowercase and
331 hope for the best: special cases can be dealt with by adding appropriate
332 methods to
\descref{c-qualifier-keyword
}{gf
}.
334 \begin{describe
}{cls
}{qualifiable-c-type (c-type) \&key :qualifiers
}
335 The class @|qualifiable-c-type| describes C types which can bear
336 `qualifiers' (
\Cplusplus\ calls them `cv-qualifiers'): @|const|,
337 @|restrict| and @|volatile|.
339 The @<qualifiers> are a list of keyword symbols @|:const|, @|:restrict| and
340 @|:volatile|. There is no built-in limitation to these particular
341 qualifiers; others keywords may be used, though this isn't recommended.
343 Two qualifiable types are equal only if they have
\emph{matching
344 qualifiers
}: i.e., every qualifier attached to one is also attached to the
345 other: order is not significant, and neither is multiplicity.
347 The class @|qualifiable-c-type| is abstract.
350 \begin{describe
}{gf
}{c-type-qualifiers @<c-type> @> @<list>
}
351 Returns the qualifiers of the @|qualifiable-c-type| instance @<c-type> as
355 \begin{describe
}{fun
}{qualify-type @<c-type> @<qualifiers> @> @<c-type>
}
356 The argument @<c-type> must be an instance of @|qualifiable-c-type|,
357 currently bearing no qualifiers, and @<qualifiers> a list of qualifier
358 keywords. The result is a C type object like @<c-type> except that it
359 bears the given @<qualifiers>.
361 The @<c-type> is not modified. If @<c-type> is interned, then the returned
362 type will be interned.
365 \begin{describe
}{fun
}{format-qualifiers @<qualifiers> @> @<string>
}
366 Returns a string containing the qualifiers listed in @<qualifiers> in C
367 syntax, with a space after each. In particular, if @<qualifiers> is
368 non-null then the final character of the returned string will be a space.
371 \begin{describe
}{gf
}{c-qualifier-keyword @<qualifier> @> @<string>
}
372 Return, as a string, the C keyword corresponding to the Lisp @<qualifier>.
374 There is a standard method, which deals with many qualifiers. Additional
375 methods exist for qualifier keywords which need special handling, such as
376 @|:atomic|; they are not listed here explicitly.
378 \begin{describe
}{meth
}{c-qualifier-keyword @<keyword> @> @<string>
}
379 Returns the @<keyword>'s print-name, in lower case. This is sufficient
380 for the standard qualifiers @|:const|, @|:restrict|, and @|:volatile|.
384 \begin{describe
}{fun
}{c-type-qualifier-keywords @<c-type> @> @<list>
}
385 Return the @<c-type>'s qualifiers, as a list of C keyword names.
389 \subsection{Storage specifiers
} \label{sec:clang.ctypes.specs
}
391 Some declaration specifiers, mostly to do with how to store the specific
392 object in question, are determinedly `top level', and, unlike qualifiers,
393 don't stay attached to the base type when acted on by declarator operators.
394 Sod calls these `storage specifiers', though no such category exists in the C
395 standard. They have their own protocol, which is similar in many ways to
398 Every Lisp keyword is potentially a storage specifier, which simply maps to
399 its lower-case print name in C; but other storage specifiers may be more
402 \begin{describe
}{cls
}
403 {c-storage-specifiers-type (c-type) \&key :subtype :specifiers
}
404 A type which carries storage specifiers. The @<subtype> is the actual
405 type, and may be any C type; the @<specifiers> are a list of
406 storage-specifier objects.
408 The type specifier @|(specs @<subtype> @<specifier>^*)| wraps the
409 @<subtype> in a @|c-storage-specifiers-type|, carrying the @<specifier>s,
410 which are a list of storage specifiers in S-expression notation.
413 \begin{describe
}{fun
}{c-type-specifiers @<type> @> @<list>
}
414 Returns the list of type specifiers attached to the @<type> object, which
415 must be a @|c-storage-specifiers-type|.
418 \begin{describe
}{mac
}
419 {define-c-storage-specifier-syntax @<name> @<lambda-list> \\
\ind
420 @
[[ @<declaration>^* @! @<doc-string> @
]] \\
424 Defines the symbol @<name> as a new storage-specifier operator. When a
425 list of the form @|(@<name> @<argument>^*)| is used as a storage specifier,
426 the @<argument>s are bound to fresh variables according to the
427 @<lambda-list> (a destructuring lambda-list) and the @<form>s evaluated in
428 order in the resulting lexical environment as an implicit @<progn>. The
429 value should be a Lisp form which will evaluate to the storage-specifier
430 object described by the arguments.
432 The @<form>s may call @|expand-c-storage-specifier| in order to recursively
433 expand storage specifiers among its arguments.
436 \begin{describe
}{gf
}{expand-c-storage-specifier @<spec> @> @<form>
}
437 Returns the Lisp form that @<spec> expands to within @|(c-type (specs
438 @<subtype> @<spec>))|.
440 If @<spec> is a list, then
\descref{expand-c-storage-specifier-form
} is
444 \begin{describe
}{gf
}{expand-c-storage-specifier-form @<spec> @> @<form>
}
445 Returns the Lisp form that @|(@<head> . @<tail>)| expands to within
446 @|(c-type (specs @<subtype> (@<head> . @<tail>)))|.
449 \begin{describe
}{gf
}{pprint-c-storage-specifier @<spec> @<stream>
}
453 {print-c-storage-specifier @<stream> @<spec>
454 \&optional @<colon> @<atsign>
}
457 \begin{describe
}{fun
}{wrap-c-type @<func> @<base-type> @> @<c-type>
}
458 Apply @<func> to the underlying C type of @<base-type> to create a new
459 `wrapped' type, and attach the storage specifiers of @<base-type> to the
462 If @<base-type> is
\emph{not
} a @|c-storage-specifiers-type|, then return
463 @|(funcall @<func> @<base-type>)|. Otherwise, return a new
464 @|c-storage-specifiers-type|, with the same specifiers, but whose subtype
465 is the result of applying @<func> to the subtype of the original
469 \begin{describe
}{cls
}{alignas-storage-specifier () \&key :alignment
}
470 The class of @|_Alignas| storage specifiers; an instance denotes the
471 specifier @|_Alignas(@<alignment>)|. The @<alignment> parameter may be any
472 printable object, but is usually a string or C fragment.
474 The storage specifier form @|(alignas @<alignment>)| returns a storage
475 specifier @|_Alignas(@<alignment>)|, where @<alignment> is evaluated.
479 \subsection{Leaf types
} \label{sec:clang.c-types.leaf
}
481 A
\emph{leaf type
} is a type which is not defined in terms of another type.
482 In Sod, the leaf types are
484 \item \emph{simple types
}, including builtin types like @|int| and @|char|,
485 as well as type names introduced by @|typename|, because Sod isn't
486 interested in what the type name means, merely that it names a type; and
487 \item \emph{tagged types
}, i.e., enum, struct and union types which are named
488 by a keyword identifying the kind of type, and a
\emph{tag
}.
491 \begin{describe
}{cls
}{simple-c-type (qualifiable-c-type)
492 \&key :qualifiers :name
}
493 The class of `simple types'; an instance denotes the type @<qualifiers>
496 A simple type object maintains a
\emph{name
}, which is a string whose
497 contents are the C name for the type. The initarg @|:name| may be used to
498 provide this name when calling @|make-instance|.
500 Two simple type objects are equal if and only if they have @|string=| names
501 and matching qualifiers.
503 A number of symbolic type specifiers for builtin types are predefined as
504 shown in
\xref{tab:codegen.c-types.simple
}. These are all defined as if by
505 @|define-simple-c-type|, so can be used to construct qualified types.
509 \begin{tabular
}[C
]{ll
} \hlx*
{hv
}
510 \thd{C type
} &
\thd{Specifiers
} \\
\hlx{vhv
}
511 @|void| & @|void| \\
\hlx{v
}
512 @|_Bool| & @|bool| \\
\hlx{v
}
513 @|char| & @|char| \\
\hlx{}
514 @|wchar_t| & @|wchar-t| \\
\hlx{v
}
515 @|signed char| & @|signed-char|, @|schar| \\
\hlx{}
516 @|unsigned char| & @|unsigned-char|, @|uchar| \\
\hlx{v
}
517 @|short| & @|short|, @|signed-short|, @|short-int|,
518 @|signed-short-int| @|sshort| \\
\hlx{}
519 @|unsigned short| & @|unsigned-short|, @|unsigned-short-int|,
521 @|int| & @|int|, @|signed|, @|signed-int|,
523 @|unsigned int| & @|unsigned|, @|unsigned-int|, @|uint| \\
\hlx{v
}
524 @|long| & @|long|, @|signed-long|, @|long-int|,
525 @|signed-long-int|, @|slong| \\
\hlx{}
526 @|unsigned long| & @|unsigned-long|, @|unsigned-long-int|,
528 @|long long| & @|long-long|, @|signed-long-long|,
529 @|long-long-int|, \\
\hlx{}
530 &
\qquad @|signed-long-long-int|,
531 @|llong|, @|sllong| \\
\hlx{v
}
532 @|unsigned long long|
533 & @|unsigned-long-long|, @|unsigned-long-long-int|,
535 @|size_t| & @|size-t| \\
\hlx{}
536 @|ptrdiff_t| & @|ptrdiff-t| \\
\hlx{v
}
537 @|float| & @|float| \\
\hlx{}
538 @|double| & @|double| \\
\hlx{}
539 @|long double| & @|long-double| \\
\hlx{v
}
540 @|float _Imaginary| & @|float-imaginary| \\
\hlx{}
541 @|double _Imaginary|& @|double-imaginary| \\
\hlx{}
542 @|long double _Imaginary|
543 & @|long-double-imaginary| \\
\hlx{v
}
544 @|float _Complex| & @|float-complex| \\
\hlx{}
545 @|double _Complex| & @|double-complex| \\
\hlx{}
546 @|long double _Complex|
547 & @|long-double-complex| \\
\hlx{v
}
548 @|va_list| & @|va-list| \\
\hlx*
{vh
}
550 \caption{Builtin symbolic type specifiers for simple C types
}
551 \label{tab:codegen.c-types.simple
}
554 \begin{describe
}{fun
}
555 {make-simple-type @<name> \&optional @<qualifiers> @> @<c-type>
}
556 Return the (unique interned) simple C type object for the C type whose name
557 is @<name> (a string) and which has the given @<qualifiers> (a list of
561 \begin{describe
}{gf
}{c-type-name @<c-type> @> @<string>
}
562 Returns the name of a @|simple-c-type| instance @<c-type> as an immutable
566 \begin{describe
}{mac
}
567 {define-simple-c-type
568 \=@
{ @<name> @! (@<name>^+) @
} @<string> \+\\
569 @
[[ @|:export| @<export-flag> @
]]
571 Define type specifiers for a new simple C type. Each symbol @<name> is
572 defined as a symbolic type specifier for the (unique interned) simple C
573 type whose name is the value of @<string>. Further, each @<name> is
574 defined to be a type operator: the type specifier @|(@<name>
575 @<qualifier>^*)| evaluates to the (unique interned) simple C type whose
576 name is @<string> and which has the @<qualifiers> (which are evaluated).
578 Furthermore, a variable @|c-type-@<name>| is defined, for the first @<name>
579 only, and initialized with the newly constructed C type object.
581 If @<export-flag> is true, then the @|c-type-@<name>| variable name, and
582 all of the @<name>s, are exported from the current package.
585 \begin{describe
}{cls
}{tagged-c-type (qualifiable-c-type)
586 \&key :qualifiers :tag
}
587 Provides common behaviour for C tagged types. A @<tag> is a string
588 containing a C identifier.
590 Two tagged types are equal if and only if they have the same class, their
591 @<tag>s are @|string=|, and they have matching qualifiers. (User-defined
592 subclasses may have additional methods on @|c-type-equal-p| which impose
593 further restrictions.)
596 Sod maintains distinct namespaces for the three kinds of tagged types. In
597 C, there is only one namespace for tags which is shared between enums,
601 \begin{describe
}{gf
}{c-tagged-type-kind @<c-type> @> @<keyword>
}
602 Returns a keyword classifying the tagged @<c-type>: one of @|:enum|,
603 @|:struct| or @|:union|. User-defined subclasses of @|tagged-c-type|
604 should return their own classification symbols. It is intended that
605 @|(string-downcase (c-tagged-type-kind @<c-type>))| be valid C
607 Alas, C doesn't provide a syntactic category for these keywords;
608 \Cplusplus\ calls them a @<class-key>.
} %
609 There is a method defined for each of the built-in tagged type classes
610 @|c-struct-type|, @|c-union-type| and @|c-enum-type|.
613 \begin{describe
}{gf
}{kind-c-tagged-type @<keyword> @> @<symbol>
}
614 This is not quite the inverse of @|c-tagged-type-kind|. Given a keyword
615 naming a kind of tagged type, return the name of the corresponding C
616 type class as a symbol.
619 \begin{describe
}{cls
}{c-enum-type (tagged-c-type) \&key :qualifiers :tag
}
620 Represents a C enumerated type. An instance denotes the C type @|enum|
621 @<tag>. See the direct superclass @|tagged-c-type| for details.
623 The type specifier @|(enum @<tag> @<qualifier>^*)| returns the (unique
624 interned) enumerated type with the given @<tag> and @<qualifier>s (all
627 \begin{describe
}{fun
}
628 {make-enum-type @<tag> \&optional @<qualifiers> @> @<c-enum-type>
}
629 Return the (unique interned) C type object for the enumerated C type whose
630 tag is @<tag> (a string) and which has the given @<qualifiers> (a list of
634 \begin{describe
}{cls
}{c-struct-type (tagged-c-type) \&key :qualifiers :tag
}
635 Represents a C structured type. An instance denotes the C type @|struct|
636 @<tag>. See the direct superclass @|tagged-c-type| for details.
638 The type specifier @|(struct @<tag> @<qualifier>^*)| returns the (unique
639 interned) structured type with the given @<tag> and @<qualifier>s (all
642 \begin{describe
}{fun
}
643 {make-struct-type @<tag> \&optional @<qualifiers> @> @<c-struct-type>
}
644 Return the (unique interned) C type object for the structured C type whose
645 tag is @<tag> (a string) and which has the given @<qualifiers> (a list of
649 \begin{describe
}{cls
}{c-union-type (tagged-c-type) \&key :qualifiers :tag
}
650 Represents a C union type. An instance denotes the C type @|union|
651 @<tag>. See the direct superclass @|tagged-c-type|
654 The type specifier @|(union @<tag> @<qualifier>^*)| returns the (unique
655 interned) union type with the given @<tag> and @<qualifier>s (all
658 \begin{describe
}{fun
}
659 {make-union-type @<tag> \&optional @<qualifiers> @> @<c-union-type>
}
660 Return the (unique interned) C type object for the union C type whose tag
661 is @<tag> (a string) and which has the given @<qualifiers> (a list of
666 \subsection{Compound C types
} \label{sec:code.c-types.compound
}
668 Some C types are
\emph{compound types
}: they're defined in terms of existing
669 types. The classes which represent compound types implement a common
672 \begin{describe
}{gf
}{c-type-subtype @<c-type> @> @<subtype>
}
673 Returns the underlying type of a compound type @<c-type>. Precisely what
674 this means depends on the class of @<c-type>.
678 \subsection{Atomic types
} \label{sec:clang.c-types.atomic
}
680 Atomic types are compound types. The subtype of an atomic type is simply the
681 underlying type of the object. Note that, as far as Sod is concerned, atomic
682 types are not the same as atomic-qualified types: you must be consistent
685 \begin{describe
}{cls
}
686 {c-atomic-type (qualifiable-c-type) \&key :qualifiers :subtype
}
687 Represents an atomic type. An instance denotes the C type
688 @|_Atomic(@<subtype>)|.
690 The @<subtype> may be any C type.
\footnote{%
691 C does not permit atomic function or array types.
} %
692 Two atomic types are equal if and only if their subtypes are equal and they
693 have matching qualifiers. It is possible, though probably not useful, to
694 have an atomic-qualified atomic type.
696 The type specifier @|(atomic @<type-spec> @<qualifier>^*)| returns a type
697 qualified atomic @<subtype>, where @<subtype> is the type specified by
698 @<type-spec> and the @<qualifier>s are qualifier keywords (which are
702 \begin{describe
}{fun
}
703 {make-atomic-type @<c-type> \&optional @<qualifiers> @> @<c-atomic-type>
}
704 Return an object describing the type qualified atomic @<subtype>. If
705 @<subtype> is interned, then the returned atomic type object is interned
710 \subsection{Pointer types
} \label{sec:clang.c-types.pointer
}
712 Pointers are compound types. The subtype of a pointer type is the type it
715 \begin{describe
}{cls
}
716 {c-pointer-type (qualifiable-c-type) \&key :qualifiers :subtype
}
717 Represents a C pointer type. An instance denotes the C type @<subtype>
720 The @<subtype> may be any C type. Two pointer types are equal if and only
721 if their subtypes are equal and they have matching qualifiers.
723 The type specifier @|
(* @<type-spec> @<qualifier>^*)| returns a type
724 qualified pointer-to-@<subtype>, where @<subtype> is the type specified by
725 @<type-spec> and the @<qualifier>s are qualifier keywords (which are
726 evaluated). The synonyms @|ptr| and @|pointer| may be used in place of the
729 The symbol @|string| is a type specifier for the type pointer to
730 characters; the symbol @|const-string| is a type specifier for the type
731 pointer to constant characters.
734 \begin{describe
}{fun
}
735 {make-pointer-type @<c-type> \&optional @<qualifiers>
736 @> @<c-pointer-type>
}
737 Return an object describing the type qualified pointer to @<subtype>.
738 If @<subtype> is interned, then the returned pointer type object is
743 \subsection{Array types
} \label{sec:clang.c-types.array
}
745 Arrays implement the compound-type protocol. The subtype of an array type is
746 the array element type.
748 \begin{describe
}{cls
}{c-array-type (c-type) \&key :subtype :dimensions
}
749 Represents a multidimensional C array type. The @<dimensions> are a list
750 of dimension specifiers $d_0$, $d_1$,
\ldots, $d_
{n-
1}$; an instance then
751 denotes the C type @<subtype> @|
[$d_0$
][$d_1$
]$
\ldots$
[$d_
{n-
1}$
]|. An
752 individual dimension specifier is either a string containing a C integral
753 constant expression, or nil which is equivalent to an empty string. Only
754 the first (outermost) dimension $d_0$ should be empty.
756 C doesn't actually have multidimensional arrays as a primitive notion;
757 rather, it permits an array (with known extent) to be the element type of
758 an array, which achieves an equivalent effect. C arrays are stored in
759 row-major order: i.e., if we write down the indices of the elements of an
760 array in order of ascending address, the rightmost index varies fastest;
761 hence, the type constructed is more accurately an array of $d_0$ arrays of
762 $d_1$ of
\ldots\ arrays of $d_
{n-
1}$ elements of type @<subtype>. We shall
763 continue to abuse terminology and refer to multidimensional arrays.
765 The type specifier @|(
[] @<type-spec> @<dimension>^*)| constructs a
766 multidimensional array with the given @<dimension>s whose elements have the
767 type specified by @<type-spec>. If no dimensions are given then a
768 single-dimensional array with unspecified extent. The synonyms @|array|
769 and @|vector| may be used in place of the brackets @`
[]'.
772 \begin{describe
}{fun
}
773 {make-array-type @<subtype> @<dimensions> @> @<c-array-type>
}
774 Return an object describing the type of arrays with given @<dimensions> and
775 with element type @<subtype> (an instance of @|c-type|). The @<dimensions>
776 argument is a list whose elements are strings or nil; see the description
777 of the class @|c-array-type| above for details.
780 \begin{describe
}{gf
}{c-array-dimensions @<c-type> @> @<list>
}
781 Returns the dimensions of @<c-type>, an array type, as an immutable list.
785 \subsection{Function types
} \label{sec:clang.c-types.fun
}
787 Function types implement the compound-type protocol. The subtype of a
788 function type is the type of the function's return value.
790 \begin{describe
}{cls
}{argument
}
791 Represents an ordinary function argument.
794 \begin{describe
}{fun
}{argumentp @<value> @> @<generalized-boolean>
}
795 Decide whether @<value> is an @<argument> object: if so, return non-nil; if
799 \begin{describe
}{fun
}
800 {make-argument @<name> @<c-type> \&optional @<default> @> @<argument>
}
801 Construct and a return a new @<argument> object. The argument has type
802 @<c-type>, which must be a @|c-type| object, and is named @<name>.
804 The @<name> may be nil to indicate that the argument has no name: in this
805 case the argument will be formatted as an abstract declarator, which is not
806 suitable for function definitions. If @<name> is not nil, then the
807 @<name>'s print representation, with @|*print-escape*| nil, is used as the
810 A @<default> may be supplied. If the argument is used in a
811 keyword-argument list (e.g., in a
\descref{c-keyword-function-type
}
812 [object
]{cls
}), and the @<default> value is provided and non-nil, then its
813 (unescaped) printed representation is used to provide a default value if
814 the keyword argument is not supplied by the caller.
818 {\dhead{fun
}{argument-name @<argument> @> @<name>
}
819 \dhead{fun
}{argument-type @<argument> @> @<c-type>
}
820 \dhead{fun
}{argument-default @<argument> @> @<default>
}}
821 Accessor functions for @|argument| objects. They return the appropriate
822 component of the object, as set by to @|make-argument|. The @<default> is
823 nil if no default was provided to @|make-argument|.
827 {commentify-argument-name @<name> @> @<commentified-name>
}
828 Convert the argument name @<name> so that it's suitable to declare the
829 function in a header file.
831 Robust header files shouldn't include literal argument names in
832 declarations of functions or function types, since this restricts the
833 including file from defining such names as macros. This generic function
834 is used to convert names into a safe form.
836 \begin{describe
}{meth
}{commentify-argument-name (@<name> null) @> nil
}
837 Returns nil: if the argument name is already omitted, it's safe for use
840 \begin{describe
}{meth
}{commentify-argument-name (@<name> t) @> @<string>
}
841 Returns the print form of @<name> wrapped in a C comment, as
846 \begin{describe
}{fun
}
847 {commentify-argument-names @<arguments> @> @<commentified-arguments>
}
848 Convert the @<arguments> list so that it's suitable for use in a header
851 The @<arguments> list should be a list whose items are @|argument| objects
852 or the keyword @|:ellipsis|. The return value is a list constructed as
853 follows. For each @|argument| object in the input list, there is a
854 corresponding @|argument| object in the returned list, with the same type,
855 and whose name is the result of @|commentify-argument-name| applied to the
856 input argument name; an @|:ellipsis| in the input list is passed through
860 \begin{describe
}{cls
}{c-function-type (c-type) \&key :subtype :arguments
}
861 Represents C function types. An instance denotes the type of a C
862 function which accepts the @<arguments> and returns @<subtype>.
864 The @<arguments> are a possibly empty list. All but the last element of
865 the list must be @|argument| objects; the final element may instead be the
866 keyword @|:ellipsis|, which denotes a variable argument list.
868 An @<arguments> list consisting of a single argument with type @|void| is
869 converted into an empty list. On output as C code, an empty argument list
870 is written as @|void|. It is not possible to represent a pre-ANSI C
871 function without prototypes.
873 Two function types are considered to be the same if their return types are
874 the same, and their argument lists consist of arguments with the same type,
875 in the same order, and either both or neither argument list ends with
876 @|:ellipsis|; argument names are not compared.
881 @
{ (@<arg-name> @<arg-type>) @
}^*
882 @
[:ellipsis @! . @<form>@
])
884 constructs a function type. The function has the subtype @<return-type>.
885 The remaining items in the type-specifier list are used to construct the
886 argument list. The argument items are a possibly improper list, beginning
887 with zero or more
\emph{explicit arguments
}: two-item
888 @<arg-name>/@<arg-type> lists. For each such list, an @|argument| object
889 is constructed with the given name (evaluated) and type. Following the
890 explicit arguments, there may be
892 \item nothing, in which case the function's argument list consists only of
893 the explicit arguments;
894 \item the keyword @|:ellipsis|, as the final item in the type-specifier
895 list, indicating a variable argument list may follow the explicit
897 \item a possibly-improper list tail, beginning with an atom either as a
898 list item or as the final list cdr, indicating that the entire list tail
899 is Lisp expression which is to be evaluated to compute the remaining
902 A tail expression may return a list of @|argument| objects, optionally
903 followed by an @|:ellipsis|.
907 (c-type (fun \=(lisp (c-type-subtype other-func)) \+\\
908 ("first" int) . (c-function-arguments other-func))
910 evaluates to a function type like @|other-func|, only with an additional
911 argument of type @|int| added to the front of its argument list. This
912 could also have been written
914 (let (\=(args (c-function-arguments other-func)) \+\\
915 (ret (c-type-subtype other-func))) \-\\
\ind
916 (c-type (fun \=(lisp ret) ("first" int) . args)
920 \begin{describe
}{cls
}
921 {c-keyword-function-type (c-function-type)
922 \&key :subtype :arguments :keywords
}
923 Represents `functions' which accept keyword arguments. Of course, actual C
924 functions can't accept keyword arguments directly, but this type is useful
925 for describing messages and methods which deal with keyword arguments.
927 An instance denotes the type of C function which accepts the position
928 argument list @<arguments>, and keyword arguments from the @<keywords>
929 list, and returns @<subtype>. Either or both of the @<arguments> and
930 @<keywords> lists may be empty. (It is important to note the distinction
931 between a function which doesn't accept keyword arguments, and one which
932 does but for which no keyword arguments are defined. In particular, the
933 latter function can be changed later to accept a keyword argument without
934 breaking compatibility with old code.) The @<arguments> and @<keywords>
935 lists must
\emph{not
} contain @|:ellipsis| markers: a function can accept
936 keywords, or a variable-length argument tail, but not both.
938 Keyword arguments may (but need not) have a
\emph{default value
} which is
939 supplied to the function body if the keyword is omitted.
941 Keyword functions are never considered to be the same as ordinary
942 functions. Two keyword function types are considered to be the same if
943 their return types are the same, and their positional argument lists consist of
944 arguments with the same type, in the same order: the keyword arguments
945 accepted by the functions is not significant.
947 Keyword functions are constructed using an extended version of the @|fun|
948 specifier used for ordinary C function types. The extended syntax is as
951 (fun \=@<return-type>
952 @
{ (@<arg-name> @<arg-type>) @
}^* \+\\
953 @
{ \=:keys @
{ (@<kw-name> @<kw-type> @
[@<kw-default>@
]) @
}^*
954 @
[. @<form>@
] @! \+\\
957 where either the symbol @|:keys| appears literally in the specifier, or the
958 @<form> evaluates to a list containing the symbol @|:keys|. (If neither of
959 these circumstances obtains, then the specifier constructs an ordinary
962 See the description of
\descref{c-function-type
}{cls
} for how a trailing
965 The list of @<arg-name>s and @<arg-type>s describes the positional
966 arguments. The list of @<kw-name>s, @<kw-type>s and @<kw-defaults>s
967 describes the keyword arguments.
970 \begin{describe
}{fun
}
971 {make-function-type @<subtype> @<arguments> @> @<c-function-type>
}
972 Construct and return a new function type, returning @<subtype> and
973 accepting the @<arguments>.
975 If the @<arguments> list contains a @|:keys| marker, then a
976 \descref{c-keyword-function-type
}[object
]{cls
} is returned: those arguments
977 preceding the @|:keys| marker form the positional argument list, and those
978 following the marker form the list of keyword arguments.
981 \begin{describe
}{fun
}
982 {make-keyword-function-type @<subtype> @<arguments> @<keywords>
983 \nlret @<c-keyword-function-type>
}
984 Construct and return a new keyword-function type, returning @<subtype> and
985 accepting the @<arguments> and @<keywords>.
989 {c-function-arguments @<c-function-type> @> @<arguments>
}
990 Return the arguments list of the @<c-function-type>.
993 \begin{describe
}{fun
}
994 {commentify-function-type @<c-function-type> @> @<commentified-c-type>
}
995 Return a commentified version of the @<c-function-type>.
997 The returned type has the same subtype as the given type, and the argument
998 list of the returned type is the result of applying
999 @|commentify-argument-names| to the argument list of the given type.
1002 \begin{describe
}{fun
}{reify-variable-argument-tail @<arguments> @> @<list>
}
1003 If the @<argument> list contains an @|:ellipsis| marker, then replace it
1004 with a @|va_list|. The name for the new argument, if any, is taken from
1005 the
\descref{*sod-ap*
}[variable
]{var
}. The new list is returned; the
1006 original list is not modified, but may share structure with the new list.
1009 \begin{describe
}{fun
}{merge-keyword-lists @<lists> @> @<list>
}
1010 Merge a number of keyword-argument lists together and return the result.
1012 The @<lists> parameter is a list consisting of a number of @|(@<args>
1013 . @<origin>)| pairs: in each pair, @<args> is a list of
1014 \descref{argument
}{cls
} objects, and @<origin> is either nil or an object
1015 whose printed representation describes the origin of the corresponding
1016 @<args> list, suitable for inclusion in an error message.
1018 The resulting list contains exactly one argument for each distinct argument
1019 name appearing in the input @<lists>; this argument will contain the
1020 default value from the earliest occurrence in the input @<lists> of an
1021 argument with that name.
1023 If the same name appears multiple times with different types, an error is
1024 signalled quoting the name, conflicting types, and (if non-nil) the origins
1025 of the offending argument objects.
1028 \begin{describe
}{fun
}
1029 {pprint-c-function-type @<return-type> @<stream>
1030 @<print-args> @<print-kernel>
}
1031 Provides the top-level structure for printing C function types.
1033 Output is written to @<stream> to describe a function type returning
1034 @<return-type>, whose declarator kernel (containing the name, and any
1035 further type operands) will be printed by @<print-kernel>, and whose
1036 arguments, if any, will be printed by @<print-args>.
1038 The @<print-kernel> function is a standard kernel-printing function
1039 following the
\descref{pprint-c-type
}[protocol
]{gf
}.
1041 The @<print-args> function is given a single argument, which is the
1042 @<stream> to print on. It should not print the surrounding parentheses.
1044 The output written to @<stream> looks approximately like
1046 @<return-type> @<kernel>(@<args>)
1050 \begin{describe
}{fun
}{pprint-argument-list @<args> @<stream> @> @<flag>
}
1051 Print an argument list to @<stream>.
1053 The @<args> is a list of
\descref{argument
}[objects
]{cls
}, optionally
1054 containing an @|:ellipsis| marker. The function returns true if any
1055 arguments were actually printed.
1059 \subsection{Parsing C types
} \label{sec:clang.c-types.parsing
}
1061 \begin{describe
}{fun
}
1062 {parse-c-type @<scanner>
1063 @> @<result> @<success-flag> @<consumed-flag>
}
1066 \begin{describe
}{fun
}
1067 {parse-declarator @<scanner> @<base-type> \&key :kernel :abstractp
1068 \nlret @<result> @<success-flag> @<consumed-flag>
}
1072 \subsection{Class types
} \label{sec:clang.c-types.class
}
1074 \begin{describe
}{cls
}
1075 {c-class-type (simple-c-type) \&key :class :tag :qualifiers :name
}
1079 {\dhead{gf
}{c-type-class @<class-type> @> @<class>
}
1080 \dhead{gf
}{setf (c-type-class @<class-type>) @<class>
}}
1083 \begin{describe
}{fun
}{find-class-type @<name> @> @<class-type-or-nil>
}
1086 \begin{describe
}{fun
}
1087 {make-class-type @<name> \&optional @<qualifiers> @> @<class-type>
}
1090 \begin{describe
}{fun
}
1091 {make-class-type @<name> \&optional @<qualifiers> @> @<class-type>
}
1094 \begin{describe
}{fun
}{find-sod-class @<name> @> @<class>
}
1097 \begin{describe
}{fun
}{record-sod-class @<class>
}
1100 %%%--------------------------------------------------------------------------
1101 \section{Generating C code
} \label{sec:clang.codegen
}
1103 This section deals with Sod's facilities for constructing and manipulating C
1104 expressions, declarations, instructions and definitions.
1107 \subsection{Temporary names
} \label{sec:clang.codegen.temporaries
}
1109 Many C-level objects, especially ones with external linkage or inclusion in a
1110 header file, are assigned names which are simple strings, perhaps fixed ones,
1111 perhaps constructed. Other objects don't need meaningful names, and
1112 suitably unique constructed names would be tedious and most likely rather
1113 opaque. Therefore Sod has an ability to construct
\emph{temporary names
}.
1115 These aren't temporary in the sense that they name C objects which have
1116 limited lifetimes at runtime. Rather, the idea is that the names be
1117 significant only to small pieces of Lisp code, which will soon forget about
1120 \subsubsection{The temporary name protocol
}
1121 Temporary names are represented by objects which implement a simple protocol.
1123 \begin{describe
}{gf
}{format-temporary-name @<var> @<stream>
}
1127 {\dhead{gf
}{var-in-use-p @<var> @> @<generalized-boolean>
}
1128 \dhead[setf var-in-use-p
]
1129 {gf
}{setf (var-in-use-p @<var>) @<generalized-boolean>
}}
1132 \subsubsection{Temporary name objects
}
1134 \begin{describe
}{cls
}{temporary-name () \&key :tag
}
1135 A temporary name object. This is the root of a small collection of
1136 subclasses, but is also usable on its own.
1139 \begin{describe
}{meth
}
1140 {commentify-argument-name (@<name> temporary-name) @> nil
}
1144 \begin{tabular
}[C
]{*
2{>
{\codeface}l
}} \hlx*
{hv
}
1145 \thd{\textbf{Class
}} &
\thd{\textbf{Name format
}} \\
\hlx{vhv
}
1146 temporary-name & @<tag> \\
1147 temporary-argument & sod__a@<tag> \\
1148 temporary-function & sod__f@<tag> \\
1149 temporary-variable & sod__v@<tag> \\
\hlx*
{vh
}
1151 \caption{Temporary name formats
}
1152 \label{tab:codegen.codegen.temps-format
}
1155 \begin{describe
}{cls
}{temporary-argument (temporary-name) \&key :tag
}
1158 \begin{describe
}{cls
}{temporary-function (temporary-name) \&key :tag
}
1161 \begin{describe
}{fun
}{temporary-function @> @<name>
}
1164 \begin{describe
}{cls
}
1165 {temporary-variable (temporary-name) \&key :tag :in-use-p
}
1168 \subsubsection{Well-known `temporary' names
}
1171 \begin{tabular
}[C
]{*
2{>
{\codeface}l
}} \hlx*
{hv
}
1172 \thd{\textbf{Variable
}} &
\thd{\textbf{Name format
}} \\
\hlx{vhv
}
1173 {}*sod-ap* & sod__ap \\
1174 {}*sod-master-ap* & sod__master_ap \\
1175 {}*null-pointer* & NULL \\
\hlx*
{vh
}
1177 \caption{Well-known temporary names
}
1178 \label{tab:codegen.codegen.well-known-temps
}
1182 \subsection{Instructions
} \label{sec:clang.codegen.insts
}
1184 \begin{describe
}{cls
}{inst () \&key
}
1187 \begin{describe
}{gf
}{inst-metric @<inst>
}
1190 \begin{describe
}{mac
}
1191 {definst @<code> (@<streamvar> \&key @<export>) (@<arg>^*) \\
\ind
1192 @
[[ @<declaration>^* @! @<doc-string> @
]] \\
1197 \begin{describe
}{mac
}
1198 {format-compound-statement
1199 (@<stream> @<child> \&optional @<morep>) \\
\ind
1204 \begin{describe
}{fun
}
1205 {format-banner-comment @<stream> @<control> \&rest @<args>
}
1209 \begin{tabular
}[C
]{ll>
{\codeface}l
} \hlx*
{hv
}
1212 \thd{Output format
} \\
\hlx{vhv
}
1213 @|var| & @<name> @<type> @|\&optional| @<init>
1214 & @<type> @<name> @
[= @<init>@
];
1216 @|set| & @<var> @<expr> & @<var> = @<expr>; \\
\hlx{v
}
1217 @|update| & @<var> @<op> @<expr> & @<var> @<op>= @<expr>;
1219 @|cond| & @<cond> @<conseq> @<alt> & @<cond> ? @<conseq> : @<alt>
1221 @|return| & @<expr> & return @
[@<expr>@
];
1223 @|break| & --- & break; \\
\hlx{v
}
1224 @|continue| & --- & continue; \\
\hlx{v
}
1225 @|expr| & @<expr> & @<expr>; \\
\hlx{v
}
1226 @|call| & @<func> @|\&rest| @<args>
1229 @<arg>_n) \\
\hlx{v
}
1230 @|banner| & @<control> @|\&rest| @<args>
1231 & /* @<banner> */ \\
\hlx{vhv
}
1232 @|block| & @<decls> @<body> & \
{ @
[@<decls>@
] @<body> \
}
1234 @|if| & @<cond> @<conseq> @|\&optional| @<alt>
1235 & if (@<cond>) @<conseq>
1236 @
[else @<alt>@
] \\
\hlx{v
}
1237 @|for| & @<init> @<cond> @<update> @<body> &
1238 for (@<init>; @<cond>; @<update>) @<body> \\
\hlx{v
}
1239 @|while| & @<cond> @<body> & while (@<cond>) @<body>
1241 @|do-while| & @<body> @<cond> & do @<body> while (@<cond>);
1244 \vtop{\hbox{\strut @<name> @<type> @<body>
}
1245 \hbox{\strut \quad @|\&optional @<banner>|
}
1246 \hbox{\strut \quad @|\&rest| @<banner-args>
}} &
1247 \vtop{\hbox{\strut @
[/* @<banner> */@
]}
1248 \hbox{\strut @<type>_0 @<name>(@<type>_1 @<arg>_1, $
\ldots$,
1249 @<type>_n @<arg>_n @
[,
\dots@
])
}
1250 \hbox{\strut \quad @<body>
}} \\
\hlx*
{vh
}
1252 \caption{Instruction classes
}
1253 \label{tab:codegen.codegen.insts
}
1257 \subsection{Code generation
} \label{sec:clang.codegen.codegen
}
1259 \begin{describe
}{gf
}{codegen-functions @<codegen> @> @<list>
}
1262 \begin{describe
}{gf
}
1263 {ensure-var @<codegen> @<name> @<type> \&optional @<init>
}
1266 \begin{describe
}{gf
}{emit-inst @<codegen> @<inst>
}
1269 \begin{describe
}{gf
}{emit-insts @<codegen> @<insts>
}
1272 \begin{describe
}{gf
}{emit-decl @<codegen> @<decl>
}
1275 \begin{describe
}{gf
}{emit-decls @<codegen> @<decls>
}
1278 \begin{describe
}{fun
}{emit-banner @<codegen> @<control> \&rest @<args>
}
1281 \begin{describe
}{gf
}{codegen-push @<codegen>
}
1284 \begin{describe
}{gf
}{codegen-pop @<codegen> @> @<decls> @<insts>
}
1287 \begin{describe
}{gf
}{codegen-pop-block @<codegen> @> @<block-inst>
}
1290 \begin{describe
}{gf
}
1291 {codegen-pop-function @<codegen> @<name> @<type> @> @<name>
}
1294 \begin{describe
}{gf
}{codegen-add-function @<codegen> @<function>
}
1297 \begin{describe
}{fun
}
1298 {codegen-build-function @<codegen> @<name> @<type> @<vars> @<insts>
1302 \begin{describe
}{gf
}{temporary-var @<codegen> @<type> @> @<name>
}
1305 \begin{describe
}{mac
}
1306 {with-temporary-var (@<codegen> @<var> @<type>) \\
\ind
1309 \-
\nlret @<value>^*
}
1312 \begin{describe
}{fun
}{deliver-expr @<codegen> @<target> @<expr>
}
1315 \begin{describe
}{fun
}
1316 {deliver-call @<codegen> @<target> @<func> \&rest @<args>
}
1319 \begin{describe
}{fun
}{convert-stmts @<codegen> @<target> @<type> @<func>
}
1322 \begin{describe
}{cls
}{codegen () \&key :vars :insts (:temp-index
0)
}
1325 %%%--------------------------------------------------------------------------
1326 \section{Literal C code fragments
} \label{sec:clang.fragment
}
1328 \begin{describe
}{cls
}{c-fragment () \&key :location :text
}
1331 \begin{describe
}{gf
}{c-fragment-text @<fragment> @> @<string>
}
1334 \begin{describe
}{fun
}
1335 {scan-c-fragment @<scanner> @<end-chars>
1336 @> @<result> @<success-flag> @<consumed-flag>
}
1339 \begin{describe
}{fun
}
1340 {parse-delimited-fragment @<scanner> @<begin> @<end> \&key :keep-end
1341 \nlret @<result> @<success-flag> @<consumed-flag>
}
1344 %%%----- That's all, folks --------------------------------------------------
1346 %%% Local variables:
1348 %%% TeX-master: "sod.tex"