3 %%% C language utilities
5 %%% (c) 2015 Straylight/Edgeware
8 %%%----- Licensing notice ---------------------------------------------------
10 %%% This file is part of the Sensble 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
49 @|c-pointer-type| \- \\
53 \caption{Classes representing C types}
54 \label{fig:codegen.c-types.classes}
57 C type objects are immutable unless otherwise specified.
59 \subsubsection{Constructing C type objects}
60 There is a constructor function for each non-abstract class of C type object.
61 Note, however, that constructor functions need not generate a fresh type
62 object if a previously existing type object is suitable. In this case, we
63 say that the objects are \emph{interned}. Some constructor functions are
64 specified to return interned objects: programs may rely on receiving the same
65 (@|eq|) type object for similar (possibly merely @|equal|) arguments. Where
66 not specified, clients may still not rely on receiving fresh objects.
68 A convenient S-expression notation is provided by the @|c-type| macro. Use
69 of this macro is merely an abbreviation for corresponding use of the various
70 constructor functions, and therefore interns type objects in the same manner.
71 The syntax accepted by the macro can be extended in order to support new
72 classes: see @|defctype|, @|c-type-alias| and @|define-c-type-syntax|.
74 The descriptions of each of the various classes include descriptions of the
75 initargs which may be passed to @|make-instance| when constructing a new
76 instance of the class. However, the constructor functions and S-expression
77 syntax are strongly recommended over direct use of @|make-instance|.
79 \subsubsection{Printing}
80 There are two protocols for printing C types. Unfortunately they have
83 \item The @|print-c-type| function prints a C type value using the
84 S-expression notation. It is mainly useful for diagnostic purposes.
85 \item The @|pprint-c-type| function prints a C type as a C-syntax
88 Neither generic function defines a default primary method; subclasses of
89 @|c-type| must define their own methods in order to print correctly.
91 \subsection{The C type root class} \label{sec:clang.c-types.root}
93 \begin{describe}{cls}{c-type ()}
94 The class @|c-type| marks the root of the built-in C type hierarchy.
96 Users may define subclasses of @|c-type|. All non-abstract subclasses must
97 have a primary method defined on @|pprint-c-type|; unless instances of the
98 subclass are interned, a method on @|c-type-equal-p| is also required.
100 The class @|c-type| is abstract.
103 \subsection{C type S-expression notation} \label{sec:clang.c-types.sexp}
105 The S-expression representation of a type is described syntactically as a
106 type specifier. Type specifiers fit into two syntactic categories.
108 \item A \emph{symbolic type specifier} consists of a symbol. It has a
109 single, fixed meaning: if @<name> is a symbolic type specifier, then each
110 use of @<name> in a type specifier evaluates to the same (@|eq|) type
111 object, until the @<name> is redefined.
112 \item A \emph{type operator} is a symbol; the corresponding specifier is a
113 list whose @|car| is the operator. The remaining items in the list are
114 arguments to the type operator.
117 \begin{describe}{mac}{c-type @<type-spec> @> @<c-type>}
118 Evaluates to a C type object, as described by the type specifier
122 \begin{describe}{mac}
123 {defctype @{ @<name> @! (@<name> @<nickname>^*) @} @<type-spec>
125 Defines a new symbolic type specifier @<name>; if a list of @<name>s is
126 given, then all are defined in the same way. The type constructed by using
127 any of the @<name>s is as described by the type specifier @<type-spec>.
129 The resulting type object is constructed once, at the time that the macro
130 expansion is evaluated; the same (@|eq|) value is used each time any
131 @<name> is used in a type specifier.
134 \begin{describe}{mac}{c-type-alias @<original> @<alias>^* @> @<aliases>}
135 Defines each @<alias> as being a type operator identical in behaviour to
136 @<original>. If @<original> is later redefined then the behaviour of the
137 @<alias>es changes too.
140 \begin{describe}{mac}
141 {define-c-type-syntax @<name> @<lambda-list> \\ \ind
142 @[[ @<declaration>^* @! @<doc-string> @]] \\
145 Defines the symbol @<name> as a new type operator. When a list of the form
146 @|(@<name> @<argument>^*)| is used as a type specifier, the @<argument>s
147 are bound to fresh variables according to @<lambda-list> (a destructuring
148 lambda-list) and the @<form>s evaluated in order in the resulting lexical
149 environment as an implicit @|progn|. The value should be a Lisp form which
150 will evaluate to the type specified by the arguments.
152 The @<form>s may call @|expand-c-type-spec| in order to recursively expand
153 type specifiers among its arguments.
156 \begin{describe}{fun}{expand-c-type-spec @<type-spec> @> @<form>}
157 Returns the Lisp form that @|(c-type @<type-spec>)| would expand into.
161 {print-c-type @<stream> @<type> \&optional @<colon> @<atsign>}
162 Print the C type object @<type> to @<stream> in S-expression form. The
163 @<colon> and @<atsign> arguments may be interpreted in any way which seems
164 appropriate: they are provided so that @|print-c-type| may be called via
165 @|format|'s @|\char`\~/\dots/| command; they are not set when
166 @|print-c-type| is called by Sod functions.
168 There should be a method defined for every C type class; there is no
172 \subsection{Comparing C types} \label{sec:clang.c-types.cmp}
174 It is necessary to compare C types for equality, for example when checking
175 argument lists for methods. This is done by @|c-type-equal-p|.
178 {c-type-equal-p @<c-type>_1 @<c-type>_2 @> @<generalized-boolean>}
179 The generic function @|c-type-equal-p| compares two C types @<c-type>_1 and
180 @<c-type>_2 for equality; it returns true if the two types are equal and
181 false if they are not.
183 Two types are equal if they are structurally similar, where this property
184 is defined by methods for each individual class; see the descriptions of
185 the classes for the details.
187 The generic function @|c-type-equal-p| uses the @|and| method combination.
189 \begin{describe}{meth}{c-type-equal-p @<c-type>_1 @<c-type>_2}
190 A default primary method for @|c-type-equal-p| is defined. It simply
191 returns @|nil|. This way, methods can specialize on both arguments
192 without fear that a call will fail because no methods are applicable.
194 \begin{describe}{ar-meth}{c-type-equal-p @<c-type>_1 @<c-type>_2}
195 A default around-method for @|c-type-equal-p| is defined. It returns
196 true if @<c-type>_1 and @<c-type>_2 are @|eql|; otherwise it delegates to
197 the primary methods. Since several common kinds of C types are interned,
198 this is a common case worth optimizing.
202 \subsection{Outputting C types} \label{sec:clang.c-types.output}
204 \begin{describe}{gf}{pprint-c-type @<c-type> @<stream> @<kernel>}
205 The generic function @|pprint-c-type| pretty-prints to @<stream> a C-syntax
206 declaration of an object or function of type @<c-type>. The result is
207 written to @<stream>.
209 A C declaration has two parts: a sequence of \emph{declaration specifiers}
210 and a \emph{declarator}. The declarator syntax involves parentheses and
211 operators, in order to reflect the operators applicable to the declared
212 variable. For example, the name of a pointer variable is preceded by @`*';
213 the name of an array is followed by dimensions enclosed in @`['\dots @`]'.
215 The @<kernel> argument must be a function designator (though see the
216 standard around-method); it is invoked as
217 \begin{quote} \codeface
218 (funcall @<kernel> @<stream> @<priority> @<spacep>)
220 It should write to @<stream> -- which may not be the same stream originally
221 passed into the generic function -- the `kernel' of the declarator, i.e.,
222 the part to which prefix and/or postfix operators are attached to form the
225 The methods on @|pprint-c-type| specialized for compound types work by
226 recursively calling @|pprint-c-type| on the subtype, passing down a closure
227 which prints the necessary additional declarator operators before calling
228 the original @<kernel> function. The additional arguments @<priority> and
229 @<spacep> support this implementation technique.
231 The @<priority> argument describes the surrounding operator context. It is
232 zero if no type operators are directly attached to the kernel (i.e., there
233 are no operators at all, or the kernel is enclosed in parentheses), one if
234 a prefix operator is directly attached, or two if a postfix operator is
235 directly attached. If the @<kernel> function intends to provide its own
236 additional declarator operators, it should check the @<priority> in order
237 to determine whether parentheses are necessary. See also the
238 @|maybe-in-parens| macro (page~\pageref{mac:maybe-in-parens}).
240 The @<spacep> argument indicates whether a space needs to be printed in
241 order to separate the declarator from the declaration specifiers. A kernel
242 which contains an identifier should insert a space before the identifier
243 when @<spacep> is non-nil. An `empty' kernel, as found in an abstract
244 declarator (one that specifies no name), looks more pleasing without a
245 trailing space. See also the @|c-type-space| function
246 (page~\pageref{fun:c-type-space}).
248 Every concrete subclass of @|c-type| is expected to provide a primary
249 method on this function. There is no default primary method.
251 \begin{describe}{ar-meth}{pprint-c-type @<c-type> @<stream> @<kernel>}
252 A default around method is defined on @|pprint-c-type| which `canonifies'
253 non-function @<kernel> arguments. In particular:
255 \item if @<kernel> is nil, then @|pprint-c-type| is called recursively
256 with a @<kernel> function that does nothing; and
257 \item if @<kernel> is any other kind of object, then @|pprint-c-type| is
258 called recursively with a @<kernel> function that prints the object as
259 if by @|princ|, preceded if necessary by space using @|c-type-space|.
264 \begin{describe}{fun}{c-type-space @<stream>}
265 Writes a space and other pretty-printing instructions to @<stream> in order
266 visually to separate a declarator from the preceding declaration
267 specifiers. The precise details are subject to change.
270 \begin{describe}{mac}
271 {maybe-in-parens (@<stream-var> @<guard-form>)
274 The @<guard-form> is evaluated, and then the @<form>s are evaluated in
275 sequence within a pretty-printer logical block writing to the stream named
276 by the symbol @<stream-var>. If the @<guard-form> evaluates to nil, then
277 the logical block has empty prefix and suffix strings; if it evaluates to a
278 non-nil value, then the logical block has prefix and suffix @`(' and @`)'
281 Note that this may cause @<stream> to be bound to a different stream object
285 \subsection{Type qualifiers and qualifiable types}
286 \label{sec:clang.ctypes.qual}
288 \begin{describe}{cls}{qualifiable-c-type (c-type) \&key :qualifiers}
289 The class @|qualifiable-c-type| describes C types which can bear
290 `qualifiers' (\Cplusplus\ calls them `cv-qualifiers'): @|const|,
291 @|restrict| and @|volatile|.
293 The @<qualifiers> are a list of keyword symbols @|:const|, @|:restrict| and
294 @|:volatile|. There is no built-in limitation to these particular
295 qualifiers; others keywords may be used, though this isn't recommended.
297 Two qualifiable types are equal only if they have \emph{matching
298 qualifiers}: i.e., every qualifier attached to one is also attached to
299 the other: order is not significant, and neither is multiplicity.
301 The class @|qualifiable-c-type| is abstract.
304 \begin{describe}{gf}{c-type-qualifiers @<c-type> @> @<list>}
305 Returns the qualifiers of the @|qualifiable-c-type| instance @<c-type> as
309 \begin{describe}{fun}{qualify-type @<c-type> @<qualifiers> @> @<c-type>}
310 The argument @<c-type> must be an instance of @|qualifiable-c-type|,
311 currently bearing no qualifiers, and @<qualifiers> a list of qualifier
312 keywords. The result is a C type object like @<c-type> except that it
313 bears the given @<qualifiers>.
315 The @<c-type> is not modified. If @<c-type> is interned, then the returned
316 type will be interned.
319 \begin{describe}{fun}{format-qualifiers @<qualifiers>}
320 Returns a string containing the qualifiers listed in @<qualifiers> in C
321 syntax, with a space after each. In particular, if @<qualifiers> is
322 non-null then the final character of the returned string will be a space.
325 \subsection{Leaf types} \label{sec:clang.c-types.leaf}
327 A \emph{leaf type} is a type which is not defined in terms of another type.
328 In Sod, the leaf types are
330 \item \emph{simple types}, including builtin types like @|int| and @|char|,
331 as well as type names introduced by @|typename|, because Sod isn't
332 interested in what the type name means, merely that it names a type; and
333 \item \emph{tagged types}, i.e., enum, struct and union types which are named
334 by a keyword identifying the kind of type, and a \emph{tag}.
337 \begin{describe}{cls}{simple-c-type (qualifiable-c-type)
338 \&key :qualifiers :name}
339 The class of `simple types'; an instance denotes the type @<qualifiers>
342 A simple type object maintains a \emph{name}, which is a string whose
343 contents are the C name for the type. The initarg @|:name| may be used to
344 provide this name when calling @|make-instance|.
346 Two simple type objects are equal if and only if they have @|string=| names
347 and matching qualifiers.
349 A number of symbolic type specifiers for builtin types are predefined as
350 shown in \xref{tab:codegen.c-types.simple}. These are all defined as if by
351 @|define-simple-c-type|, so can be used to construct qualified types.
355 \begin{tabular}[C]{ll} \hlx*{hv}
356 \thd{C type} & \thd{Specifiers} \\ \hlx{vhv}
357 @|void| & @|void| \\ \hlx{v}
358 @|char| & @|char| \\ \hlx{v}
359 @|unsigned char| & @|unsigned-char|, @|uchar| \\ \hlx{}
360 @|signed char| & @|signed-char|, @|schar| \\ \hlx{v}
361 @|short| & @|short|, @|signed-short|, @|short-int|,
362 @|signed-short-int| @|sshort| \\ \hlx{}
363 @|unsigned short| & @|unsigned-short|, @|unsigned-short-int|,
365 @|int| & @|int|, @|signed|, @|signed-int|,
367 @|unsigned int| & @|unsigned|, @|unsigned-int|, @|uint| \\ \hlx{v}
368 @|long| & @|long|, @|signed-long|, @|long-int|,
369 @|signed-long-int|, @|slong| \\ \hlx{}
370 @|unsigned long| & @|unsigned-long|, @|unsigned-long-int|,
372 @|long long| & @|long-long|, @|signed-long-long|,
374 & \qquad @|signed-long-long-int|,
375 @|llong|, @|sllong| \\ \hlx{v}
376 @|unsigned long long|
377 & @|unsigned-long-long|, @|unsigned-long-long-int|,
379 @|float| & @|float| \\ \hlx{}
380 @|double| & @|double| \\ \hlx{v}
381 @|va_list| & @|va-list| \\ \hlx{v}
382 @|size_t| & @|size-t| \\ \hlx{v}
383 @|ptrdiff_t| & @|ptrdiff-t| \\ \hlx*{vh}
385 \caption{Builtin symbolic type specifiers for simple C types}
386 \label{tab:codegen.c-types.simple}
389 \begin{describe}{fun}
390 {make-simple-type @<name> \&optional @<qualifiers> @> @<c-type>}
391 Return the (unique interned) simple C type object for the C type whose name
392 is @<name> (a string) and which has the given @<qualifiers> (a list of
396 \begin{describe}{gf}{c-type-name @<c-type> @> @<string>}
397 Returns the name of a @|simple-c-type| instance @<c-type> as an immutable
401 \begin{describe}{mac}
402 {define-simple-c-type @{ @<name> @! (@<name>^*) @} @<string> @> @<name>}
403 Define type specifiers for a new simple C type. Each symbol @<name> is
404 defined as a symbolic type specifier for the (unique interned) simple C
405 type whose name is the value of @<string>. Further, each @<name> is
406 defined to be a type operator: the type specifier @|(@<name>
407 @<qualifier>^*)| evaluates to the (unique interned) simple C type whose
408 name is @<string> and which has the @<qualifiers> (which are evaluated).
411 \begin{describe}{cls}{tagged-c-type (qualifiable-c-type)
412 \&key :qualifiers :tag}
413 Provides common behaviour for C tagged types. A @<tag> is a string
414 containing a C identifier.
416 Two tagged types are equal if and only if they have the same class, their
417 @<tag>s are @|string=|, and they have matching qualifiers. (User-defined
418 subclasses may have additional methods on @|c-type-equal-p| which impose
419 further restrictions.)
422 Sod maintains distinct namespaces for the three kinds of tagged types. In
423 C, there is only one namespace for tags which is shared between enums,
427 \begin{describe}{gf}{c-tagged-type-kind @<c-type> @> @<keyword>}
428 Returns a keyword classifying the tagged @<c-type>: one of @|:enum|,
429 @|:struct| or @|:union|. User-defined subclasses of @|tagged-c-type|
430 should return their own classification symbols. It is intended that
431 @|(string-downcase (c-tagged-type-kind @<c-type>))| be valid C
433 Alas, C doesn't provide a syntactic category for these keywords;
434 \Cplusplus\ calls them a @<class-key>.} %
435 There is a method defined for each of the built-in tagged type classes
436 @|c-struct-type|, @|c-union-type| and @|c-enum-type|.
439 \begin{describe}{gf}{kind-c-tagged-type @<keyword> @> @<symbol>}
440 This is not quite the inverse of @|c-tagged-type-kind|. Given a keyword
441 naming a kind of tagged type, return the name of the corresponding C
442 type class as a symbol.
445 \begin{describe}{cls}{c-enum-type (tagged-c-type) \&key :qualifiers :tag}
446 Represents a C enumerated type. An instance denotes the C type @|enum|
447 @<tag>. See the direct superclass @|tagged-c-type| for details.
449 The type specifier @|(enum @<tag> @<qualifier>^*)| returns the (unique
450 interned) enumerated type with the given @<tag> and @<qualifier>s (all
453 \begin{describe}{fun}
454 {make-enum-type @<tag> \&optional @<qualifiers> @> @<c-enum-type>}
455 Return the (unique interned) C type object for the enumerated C type whose
456 tag is @<tag> (a string) and which has the given @<qualifiers> (a list of
460 \begin{describe}{cls}{c-struct-type (tagged-c-type) \&key :qualifiers :tag}
461 Represents a C structured type. An instance denotes the C type @|struct|
462 @<tag>. See the direct superclass @|tagged-c-type| for details.
464 The type specifier @|(struct @<tag> @<qualifier>^*)| returns the (unique
465 interned) structured type with the given @<tag> and @<qualifier>s (all
468 \begin{describe}{fun}
469 {make-struct-type @<tag> \&optional @<qualifiers> @> @<c-struct-type>}
470 Return the (unique interned) C type object for the structured C type whose
471 tag is @<tag> (a string) and which has the given @<qualifiers> (a list of
475 \begin{describe}{cls}{c-union-type (tagged-c-type) \&key :qualifiers :tag}
476 Represents a C union type. An instance denotes the C type @|union|
477 @<tag>. See the direct superclass @|tagged-c-type|
480 The type specifier @|(union @<tag> @<qualifier>^*)| returns the (unique
481 interned) union type with the given @<tag> and @<qualifier>s (all
484 \begin{describe}{fun}
485 {make-union-type @<tag> \&optional @<qualifiers> @> @<c-union-type>}
486 Return the (unique interned) C type object for the union C type whose tag
487 is @<tag> (a string) and which has the given @<qualifiers> (a list of
491 \subsection{Compound C types} \label{sec:code.c-types.compound}
493 Some C types are \emph{compound types}: they're defined in terms of existing
494 types. The classes which represent compound types implement a common
497 \begin{describe}{gf}{c-type-subtype @<c-type> @> @<subtype>}
498 Returns the underlying type of a compound type @<c-type>. Precisely what
499 this means depends on the class of @<c-type>.
502 \subsection{Pointer types} \label{sec:clang.c-types.pointer}
504 Pointers compound types. The subtype of a pointer type is the type it points
507 \begin{describe}{cls}
508 {c-pointer-type (qualifiable-c-type) \&key :qualifiers :subtype}
509 Represents a C pointer type. An instance denotes the C type @<subtype>
512 The @<subtype> may be any C type. Two pointer types are equal if and only
513 if their subtypes are equal and they have matching qualifiers.
515 The type specifier @|(* @<type-spec> @<qualifier>^*)| returns a type
516 qualified pointer-to-@<subtype>, where @<subtype> is the type specified by
517 @<type-spec> and the @<qualifier>s are qualifier keywords (which are
518 evaluated). The synonyms @|ptr| and @|pointer| may be used in place of the
521 The symbol @|string| is a type specifier for the type pointer to
522 characters; the symbol @|const-string| is a type specifier for the type
523 pointer to constant characters.
526 \begin{describe}{fun}
527 {make-pointer-type @<c-type> \&optional @<qualifiers>
528 @> @<c-pointer-type>}
529 Return an object describing the type qualified pointer to @<subtype>.
530 If @<subtype> is interned, then the returned pointer type object is
534 \subsection{Array types} \label{sec:clang.c-types.array}
536 Arrays implement the compound-type protocol. The subtype of an array type is
537 the array element type.
539 \begin{describe}{cls}{c-array-type (c-type) \&key :subtype :dimensions}
540 Represents a multidimensional C array type. The @<dimensions> are a list
541 of dimension specifiers $d_0$, $d_1$, \ldots, $d_{n-1}$; an instance then
542 denotes the C type @<subtype> @|[$d_0$][$d_1$]$\ldots$[$d_{n-1}$]|. An
543 individual dimension specifier is either a string containing a C integral
544 constant expression, or nil which is equivalent to an empty string. Only
545 the first (outermost) dimension $d_0$ should be empty.
547 C doesn't actually have multidimensional arrays as a primitive notion;
548 rather, it permits an array (with known extent) to be the element type of
549 an array, which achieves an equivalent effect. C arrays are stored in
550 row-major order: i.e., if we write down the indices of the elements of an
551 array in order of ascending address, the rightmost index varies fastest;
552 hence, the type constructed is more accurately an array of $d_0$ arrays of
553 $d_1$ of \ldots\ arrays of $d_{n-1}$ elements of type @<subtype>. We shall
554 continue to abuse terminology and refer to multidimensional arrays.
556 The type specifier @|([] @<type-spec> @<dimension>^*)| constructs a
557 multidimensional array with the given @<dimension>s whose elements have the
558 type specified by @<type-spec>. If no dimensions are given then a
559 single-dimensional array with unspecified extent. The synonyms @|array|
560 and @|vector| may be used in place of the brackets @`[]'.
563 \begin{describe}{fun}
564 {make-array-type @<subtype> @<dimensions> @> @<c-array-type>}
565 Return an object describing the type of arrays with given @<dimensions> and
566 with element type @<subtype> (an instance of @|c-type|). The @<dimensions>
567 argument is a list whose elements are strings or nil; see the description
568 of the class @|c-array-type| above for details.
571 \begin{describe}{gf}{c-array-dimensions @<c-type> @> @<list>}
572 Returns the dimensions of @<c-type>, an array type, as an immutable list.
575 \subsection{Function types} \label{sec:clang.c-types.fun}
577 Function types implement the compound-type protocol. The subtype of a
578 function type is the type of the function's return value.
580 \begin{describe}{cls}{argument}
581 Represents an ordinary function argument.
584 \begin{describe}{fun}{argumentp @<value> @> @<generalized-boolean>}
585 Decide whether @<value> is an @<argument> object: if so, return non-nil; if
589 \begin{describe}{fun}{make-argument @<name> @<c-type> @> @<argument>}
590 Construct and a return a new @<argument> object. The argument has type
591 @<c-type>, which must be a @|c-type| object, and is named @<name>.
593 The @<name> may be nil to indicate that the argument has no name: in this
594 case the argument will be formatted as an abstract declarator, which is not
595 suitable for function definitions. If @<name> is not nil, then the
596 @<name>'s print representation, with @|*print-escape*| nil, is used as the
600 \begin{describe}{fun}{argument-name @<argument> @> @<name>}
601 Return the name of the @<argument>, as it was supplied to @|make-argument|.
604 \begin{describe}{fun}{argument-type @<argument> @> @<c-type>}
605 Return the type of the @<argument>, as it was supplied to @|make-argument|.
609 {commentify-argument-name @<name> @> @<commentified-name>}
610 Convert the argument name @<name> so that it's suitable to declare the
611 function in a header file.
613 Robust header files shouldn't include literal argument names in
614 declarations of functions or function types, since this restricts the
615 including file from defining such names as macros. This generic function
616 is used to convert names into a safe form.
618 \begin{describe}{meth}{commentify-argument-name (@<name> null) @> nil}
619 Returns nil: if the argument name is already omitted, it's safe for use
622 \begin{describe}{meth}{commentify-argument-name (@<name> t) @> @<string>}
623 Returns the print form of @<name> wrapped in a C comment, as
628 \begin{describe}{fun}
629 {commentify-argument-names @<arguments> @> @<commentified-arguments>}
630 Convert the @<arguments> list so that it's suitable for use in a header
633 The @<arguments> list should be a list whose items are @|argument| objects
634 or the keyword @|:ellipsis|. The return value is a list constructed as
635 follows. For each @|argument| object in the input list, there is a
636 corresponding @|argument| object in the returned list, with the same type,
637 and whose name is the result of @|commentify-argument-name| applied to the
638 input argument name; an @|:ellipsis| in the input list is passed through
642 \begin{describe}{cls}{c-function-type (c-type) \&key :subtype :arguments}
643 Represents C function types. An instance denotes the type of a C
644 function which accepts the @<arguments> and returns @<subtype>.
646 The @<arguments> are a possibly empty list. All but the last element of
647 the list must be @|argument| objects; the final element may instead be the
648 keyword @|:ellipsis|, which denotes a variable argument list.
650 An @<arguments> list consisting of a single argument with type @|void| is
651 converted into an empty list. On output as C code, an empty argument list
652 is written as @|void|. It is not possible to represent a pre-ANSI C
653 function without prototypes.
655 Two function types are considered to be the same if their return types are
656 the same, and their argument lists consist of arguments with the same type,
657 in the same order, and either both or neither argument list ends with
658 @|:ellipsis|; argument names are not compared.
660 The type specifier @|(fun @<return-type> @{ (@<arg-name> @<arg-type>) @}^*
661 @[:ellipsis @! . @<form> @])| constructs a function type. The function has
662 the subtype @<return-type>. The remaining items in the type-specifier list
663 are used to construct the argument list. The argument items are a possibly
664 improper list, beginning with zero or more \emph{explicit arguments}:
665 two-item @<arg-name>/@<arg-type> lists. For each such list, an @|argument|
666 object is constructed with the given name (evaluated) and type. Following
667 the explicit arguments, there may be
669 \item nothing, in which case the function's argument list consists only of
670 the explicit arguments;
671 \item the keyword @|:ellipsis|, as the final item in the type-specifier
672 list, indicating a variable argument list may follow the explicit
674 \item a possibly-improper list tail, beginning with an atom either as a
675 list item or as the final list cdr, indicating that the entire list tail
676 is Lisp expression which is to be evaluated to compute the remaining
679 A tail expression may return a list of @|argument| objects, optionally
680 followed by an @|:ellipsis|.
684 (c-type (fun \=(lisp (c-type-subtype other-func)) \+ \\
685 ("first" int) . (c-function-arguments other-func))
687 evaluates to a function type like @|other-func|, only with an additional
688 argument of type @|int| added to the front of its argument list. This
689 could also have been written
691 (let (\=(args (c-function-arguments other-func)) \+ \\
692 (ret (c-type-subtype other-func))) \- \\ \ind
693 (c-type (fun \=(lisp ret) ("first" int) . args)
697 \begin{describe}{fun}
698 {make-function-type @<subtype> @<arguments> @> @<c-function-type>}
699 Construct and return a new function type, returning @<subtype> and
700 accepting the @<arguments>.
704 {c-function-arguments @<c-function-type> @> @<arguments>}
705 Return the arguments list of the @<c-function-type>.
708 \begin{describe}{fun}
709 {commentify-function-type @<c-function-type> @> @<commentified-c-type>}
710 Return a commentified version of the @<c-function-type>.
712 The returned type has the same subtype as the given type, and the argument
713 list of the returned type is the result of applying
714 @|commentify-argument-names| to the argument list of the given type.
717 \subsection{Parsing C types} \label{sec:clang.c-types.parsing}
719 %%%--------------------------------------------------------------------------
720 \section{Generating C code} \label{sec:clang.codegen}
722 This section deals with Sod's facilities for constructing and manipulating C
723 expressions, declarations, instructions and definitions.
725 \subsection{Temporary names} \label{sec:clang.codegen.temporaries}
727 Many C-level objects, especially ones with external linkage or inclusion in a
728 header file, are assigned names which are simple strings, perhaps fixed ones,
729 perhaps constructed. Other objects don't need meaningful names, and
730 suitably unique constructed names would be tedious and most likely rather
731 opaque. Therefore Sod has an ability to construct \emph{temporary names}.
733 These aren't temporary in the sense that they name C objects which have
734 limited lifetimes at runtime. Rather, the idea is that the names be
735 significant only to small pieces of Lisp code, which will soon forget about
738 \subsubsection{The temporary name protocol}
739 Temporary names are represented by objects which implement a simple protocol.
741 \begin{describe}{gf}{format-temporary-name @<var> @<stream>}
745 {\dhead{gf}{var-in-use-p @<var> @> @<generalized-boolean>}
746 \dhead[setf var-in-use-p]
747 {gf}{setf (var-in-use-p @<var>) @<generalized-boolean>}}
750 \subsubsection{Temporary name objects}
752 \begin{describe}{cls}{temporary-name () \&key :tag}
753 A temporary name object. This is the root of a small collection of
754 subclasses, but is also usable on its own.
757 \begin{describe}{meth}
758 {commentify-argument-name (@<name> temporary-name) @> nil}
762 \begin{tabular}[C]{*2{>{\codeface}l}} \hlx*{hv}
763 \thd{\textbf{Class}} & \thd{\textbf{Name format}} \\ \hlx{vhv}
764 temporary-name & @<tag> \\
765 temporary-argument & sod__a@<tag> \\
766 temporary-function & sod__f@<tag> \\
767 temporary-variable & sod__v@<tag> \\ \hlx*{vh}
769 \caption{Temporary name formats}
770 \label{tab:codegen.codegen.temps-format}
773 \begin{describe}{cls}{temporary-argument (temporary-name) \&key :tag}
776 \begin{describe}{cls}{temporary-function (temporary-name) \&key :tag}
779 \begin{describe}{fun}{temporary-function @> @<name>}
782 \begin{describe}{cls}
783 {temporary-variable (temporary-name) \&key :tag :in-use-p}
786 \subsubsection{Well-known `temporary' names}
789 \begin{tabular}[C]{*2{>{\codeface}l}} \hlx*{hv}
790 \thd{\textbf{Variable}} & \thd{\textbf{Name format}} \\ \hlx{vhv}
791 {}*sod-ap* & sod__ap \\
792 {}*sod-master-ap* & sod__master_ap \\
793 {}*sod-tmp-ap* & sod__tmp_ap \\ \hlx*{vh}
795 \caption{Well-known temporary names}
796 \label{tab:codegen.codegen.well-known-temps}
799 \subsection{Instructions} \label{sec:clang.codegen.insts}
801 \begin{describe}{cls}{inst () \&key}
804 \begin{describe}{gf}{inst-metric @<inst>}
807 \begin{describe}{mac}
808 {definst @<code> (@<streamvar> \&key @<export>) (@<arg>^*) \\ \ind
809 @[[ @<declaration>^* @! @<doc-string> @]] \\
814 \begin{describe}{mac}
815 {format-compound-statement
816 (@<stream> @<child> \&optional @<morep>) \\ \ind
822 \begin{tabular}[C]{ll>{\codeface}l} \hlx*{hv}
825 \thd{Output format} \\ \hlx{vhv}
826 @|var| & @<name> @<type> @<init> & @<type> @<name> @[= @<init>@];
828 @|set| & @<var> @<expr> & @<var> = @<expr>; \\ \hlx{v}
829 @|update| & @<var> @<op> @<expr> & @<var> @<op>= @<expr>;
831 @|return| & @<expr> & return @[@<expr>@];
833 @|break| & --- & break; \\ \hlx{v}
834 @|continue| & --- & continue; \\ \hlx{v}
835 @|expr| & @<expr> & @<expr>; \\ \hlx{v}
836 @|call| & @<func> @<args> & @<func>(@<arg>_1,
839 @|va-start| & @<ap> @<arg> & va_start(@<ap>, @<arg>);
841 @|va-copy| & @<to> @<from> & va_copy(@<to>, @<from>);
843 @|va-end| & @<ap> & va_end(@<ap>); \\ \hlx{vhv}
844 @|block| & @<decls> @<body> & \{ @[@<decls>@] @<body> \}
846 @|if| & @<cond> @<conseq> @<alt> & if (@<cond>) @<conseq>
847 @[else @<alt>@] \\ \hlx{v}
848 @|while| & @<cond> @<body> & while (@<cond>) @<body>
850 @|do-while| & @<body> @<cond> & do @<body> while (@<cond>);
852 @|function| & @<name> @<type> @<body> &
853 @<type>_0 @<name>(@<type>_1 @<arg>_1, $\ldots$,
854 @<type>_n @<arg>_n @[, \dots@])
857 \caption{Instruction classes}
858 \label{tab:codegen.codegen.insts}
861 \subsection{Code generation} \label{sec:clang.codegen.codegen}
863 \begin{describe}{gf}{codegen-functions @<codegen> @> @<list>}
867 {ensure-var @<codegen> @<name> @<type> \&optional @<init>}
870 \begin{describe}{gf}{emit-inst @<codegen> @<inst>}
873 \begin{describe}{gf}{emit-insts @<codegen> @<insts>}
876 \begin{describe}{gf}{emit-decl @<codegen> @<decl>}
879 \begin{describe}{gf}{emit-declss @<codegen> @<decls>}
882 \begin{describe}{gf}{codegen-push @<codegen>}
885 \begin{describe}{gf}{codegen-pop @<codegen> @> @<decls> @<insts>}
888 \begin{describe}{gf}{codegen-pop-block @<codegen> @> @<block-inst>}
892 {codegen-pop-function @<codegen> @<name> @<type> @> @<name>}
895 \begin{describe}{gf}{codegen-add-function @<codegen> @<function>}
898 \begin{describe}{fun}
899 {codegen-build-function @<codegen> @<name> @<type> @<vars> @<insts>
903 \begin{describe}{gf}{temporary-var @<codegen> @<type> @> @<name>}
906 \begin{describe}{mac}
907 {with-temporary-var (@<codegen> @<var> @<type>) \\ \ind
913 \begin{describe}{fun}{deliver-expr @<codegen> @<target> @<expr>}
916 \begin{describe}{fun}{convert-stmts @<codegen> @<target> @<type> @<func>}
919 \begin{describe}{cls}{codegen () \&key :vars :insts (:temp-index 0)}
922 %%%--------------------------------------------------------------------------
923 \section{Literal C code fragments} \label{sec:clang.fragment}
925 \begin{describe}{cls}{c-fragment () \&key :location :text}
928 \begin{describe}{gf}{c-fragment-text @<fragment> @> @<string>}
931 \begin{describe}{fun}
932 {scan-c-fragment @<scanner> @<end-chars>
933 @> @<result> @<success-flag> @<consumed-flag>}
936 \begin{describe}{fun}
937 {parse-delimited-fragment @<scanner> @<begin> @<end> \&key :keep-end
938 \nlret @<result> @<success-flag> @<consumed-flag>}
941 %%%----- That's all, folks --------------------------------------------------
945 %%% TeX-master: "sod.tex"