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
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.
92 \subsection{The C type root class} \label{sec:clang.c-types.root}
94 \begin{describe}{cls}{c-type ()}
95 The class @|c-type| marks the root of the built-in C type hierarchy.
97 Users may define subclasses of @|c-type|. All non-abstract subclasses must
98 have a primary method defined on @|pprint-c-type|; unless instances of the
99 subclass are interned, a method on @|c-type-equal-p| is also required.
101 The class @|c-type| is abstract.
105 \subsection{C type S-expression notation} \label{sec:clang.c-types.sexp}
107 The S-expression representation of a type is described syntactically as a
108 type specifier. Type specifiers fit into two syntactic categories.
110 \item A \emph{symbolic type specifier} consists of a symbol. It has a
111 single, fixed meaning: if @<name> is a symbolic type specifier, then each
112 use of @<name> in a type specifier evaluates to the same (@|eq|) type
113 object, until the @<name> is redefined.
114 \item A \emph{type operator} is a symbol; the corresponding specifier is a
115 list whose @|car| is the operator. The remaining items in the list are
116 arguments to the type operator.
119 \begin{describe}{mac}{c-type @<type-spec> @> @<c-type>}
120 Evaluates to a C type object, as described by the type specifier
124 \begin{describe}{mac}
125 {defctype @{ @<name> @! (@<name> @<nickname>^*) @} @<type-spec>
127 Defines a new symbolic type specifier @<name>; if a list of @<name>s is
128 given, then all are defined in the same way. The type constructed by using
129 any of the @<name>s is as described by the type specifier @<type-spec>.
131 The resulting type object is constructed once, at the time that the macro
132 expansion is evaluated; the same (@|eq|) value is used each time any
133 @<name> is used in a type specifier.
136 \begin{describe}{mac}{c-type-alias @<original> @<alias>^* @> @<aliases>}
137 Defines each @<alias> as being a type operator identical in behaviour to
138 @<original>. If @<original> is later redefined then the behaviour of the
139 @<alias>es changes too.
142 \begin{describe}{mac}
143 {define-c-type-syntax @<name> @<lambda-list> \\ \ind
144 @[[ @<declaration>^* @! @<doc-string> @]] \\
147 Defines the symbol @<name> as a new type operator. When a list of the form
148 @|(@<name> @<argument>^*)| is used as a type specifier, the @<argument>s
149 are bound to fresh variables according to @<lambda-list> (a destructuring
150 lambda-list) and the @<form>s evaluated in order in the resulting lexical
151 environment as an implicit @|progn|. The value should be a Lisp form which
152 will evaluate to the type specified by the arguments.
154 The @<form>s may call @|expand-c-type-spec| in order to recursively expand
155 type specifiers among its arguments.
158 \begin{describe}{fun}{expand-c-type-spec @<type-spec> @> @<form>}
159 Returns the Lisp form that @|(c-type @<type-spec>)| would expand into.
163 {print-c-type @<stream> @<type> \&optional @<colon> @<atsign>}
164 Print the C type object @<type> to @<stream> in S-expression form. The
165 @<colon> and @<atsign> arguments may be interpreted in any way which seems
166 appropriate: they are provided so that @|print-c-type| may be called via
167 @|format|'s @|\char`\~/\dots/| command; they are not set when
168 @|print-c-type| is called by Sod functions.
170 There should be a method defined for every C type class; there is no
175 \subsection{Comparing C types} \label{sec:clang.c-types.cmp}
177 It is necessary to compare C types for equality, for example when checking
178 argument lists for methods. This is done by @|c-type-equal-p|.
181 {c-type-equal-p @<c-type>_1 @<c-type>_2 @> @<generalized-boolean>}
182 The generic function @|c-type-equal-p| compares two C types @<c-type>_1 and
183 @<c-type>_2 for equality; it returns true if the two types are equal and
184 false if they are not.
186 Two types are equal if they are structurally similar, where this property
187 is defined by methods for each individual class; see the descriptions of
188 the classes for the details.
190 The generic function @|c-type-equal-p| uses the @|and| method combination.
192 \begin{describe}{meth}{c-type-equal-p @<c-type>_1 @<c-type>_2}
193 A default primary method for @|c-type-equal-p| is defined. It simply
194 returns @|nil|. This way, methods can specialize on both arguments
195 without fear that a call will fail because no methods are applicable.
197 \begin{describe}{ar-meth}{c-type-equal-p @<c-type>_1 @<c-type>_2}
198 A default around-method for @|c-type-equal-p| is defined. It returns
199 true if @<c-type>_1 and @<c-type>_2 are @|eql|; otherwise it delegates to
200 the primary methods. Since several common kinds of C types are interned,
201 this is a common case worth optimizing.
206 \subsection{Outputting C types} \label{sec:clang.c-types.output}
208 \begin{describe}{gf}{pprint-c-type @<c-type> @<stream> @<kernel>}
209 The generic function @|pprint-c-type| pretty-prints to @<stream> a C-syntax
210 declaration of an object or function of type @<c-type>. The result is
211 written to @<stream>.
213 A C declaration has two parts: a sequence of \emph{declaration specifiers}
214 and a \emph{declarator}. The declarator syntax involves parentheses and
215 operators, in order to reflect the operators applicable to the declared
216 variable. For example, the name of a pointer variable is preceded by @`*';
217 the name of an array is followed by dimensions enclosed in @`['\dots @`]'.
219 The @<kernel> argument must be a function designator (though see the
220 standard around-method); it is invoked as
221 \begin{quote} \codeface
222 (funcall @<kernel> @<stream> @<priority> @<spacep>)
224 It should write to @<stream> -- which may not be the same stream originally
225 passed into the generic function -- the `kernel' of the declarator, i.e.,
226 the part to which prefix and/or postfix operators are attached to form the
229 The methods on @|pprint-c-type| specialized for compound types work by
230 recursively calling @|pprint-c-type| on the subtype, passing down a closure
231 which prints the necessary additional declarator operators before calling
232 the original @<kernel> function. The additional arguments @<priority> and
233 @<spacep> support this implementation technique.
235 The @<priority> argument describes the surrounding operator context. It is
236 zero if no type operators are directly attached to the kernel (i.e., there
237 are no operators at all, or the kernel is enclosed in parentheses), one if
238 a prefix operator is directly attached, or two if a postfix operator is
239 directly attached. If the @<kernel> function intends to provide its own
240 additional declarator operators, it should check the @<priority> in order
241 to determine whether parentheses are necessary. See also the
242 @|maybe-in-parens| macro (page~\pageref{mac:maybe-in-parens}).
244 The @<spacep> argument indicates whether a space needs to be printed in
245 order to separate the declarator from the declaration specifiers. A kernel
246 which contains an identifier should insert a space before the identifier
247 when @<spacep> is non-nil. An `empty' kernel, as found in an abstract
248 declarator (one that specifies no name), looks more pleasing without a
249 trailing space. See also the @|c-type-space| function
250 (page~\pageref{fun:c-type-space}).
252 Every concrete subclass of @|c-type| is expected to provide a primary
253 method on this function. There is no default primary method.
255 \begin{describe}{ar-meth}{pprint-c-type @<c-type> @<stream> @<kernel>}
256 A default around method is defined on @|pprint-c-type| which `canonifies'
257 non-function @<kernel> arguments. In particular:
259 \item if @<kernel> is nil, then @|pprint-c-type| is called recursively
260 with a @<kernel> function that does nothing; and
261 \item if @<kernel> is any other kind of object, then @|pprint-c-type| is
262 called recursively with a @<kernel> function that prints the object as
263 if by @|princ|, preceded if necessary by space using @|c-type-space|.
268 \begin{describe}{fun}{c-type-space @<stream>}
269 Writes a space and other pretty-printing instructions to @<stream> in order
270 visually to separate a declarator from the preceding declaration
271 specifiers. The precise details are subject to change.
274 \begin{describe}{mac}
275 {maybe-in-parens (@<stream-var> @<guard-form>)
278 The @<guard-form> is evaluated, and then the @<form>s are evaluated in
279 sequence within a pretty-printer logical block writing to the stream named
280 by the symbol @<stream-var>. If the @<guard-form> evaluates to nil, then
281 the logical block has empty prefix and suffix strings; if it evaluates to a
282 non-nil value, then the logical block has prefix and suffix @`(' and @`)'
285 Note that this may cause @<stream> to be bound to a different stream object
290 \subsection{Type qualifiers and qualifiable types}
291 \label{sec:clang.ctypes.qual}
293 \begin{describe}{cls}{qualifiable-c-type (c-type) \&key :qualifiers}
294 The class @|qualifiable-c-type| describes C types which can bear
295 `qualifiers' (\Cplusplus\ calls them `cv-qualifiers'): @|const|,
296 @|restrict| and @|volatile|.
298 The @<qualifiers> are a list of keyword symbols @|:const|, @|:restrict| and
299 @|:volatile|. There is no built-in limitation to these particular
300 qualifiers; others keywords may be used, though this isn't recommended.
302 Two qualifiable types are equal only if they have \emph{matching
303 qualifiers}: i.e., every qualifier attached to one is also attached to the
304 other: order is not significant, and neither is multiplicity.
306 The class @|qualifiable-c-type| is abstract.
309 \begin{describe}{gf}{c-type-qualifiers @<c-type> @> @<list>}
310 Returns the qualifiers of the @|qualifiable-c-type| instance @<c-type> as
314 \begin{describe}{fun}{qualify-type @<c-type> @<qualifiers> @> @<c-type>}
315 The argument @<c-type> must be an instance of @|qualifiable-c-type|,
316 currently bearing no qualifiers, and @<qualifiers> a list of qualifier
317 keywords. The result is a C type object like @<c-type> except that it
318 bears the given @<qualifiers>.
320 The @<c-type> is not modified. If @<c-type> is interned, then the returned
321 type will be interned.
324 \begin{describe}{fun}{format-qualifiers @<qualifiers>}
325 Returns a string containing the qualifiers listed in @<qualifiers> in C
326 syntax, with a space after each. In particular, if @<qualifiers> is
327 non-null then the final character of the returned string will be a space.
331 \subsection{Leaf types} \label{sec:clang.c-types.leaf}
333 A \emph{leaf type} is a type which is not defined in terms of another type.
334 In Sod, the leaf types are
336 \item \emph{simple types}, including builtin types like @|int| and @|char|,
337 as well as type names introduced by @|typename|, because Sod isn't
338 interested in what the type name means, merely that it names a type; and
339 \item \emph{tagged types}, i.e., enum, struct and union types which are named
340 by a keyword identifying the kind of type, and a \emph{tag}.
343 \begin{describe}{cls}{simple-c-type (qualifiable-c-type)
344 \&key :qualifiers :name}
345 The class of `simple types'; an instance denotes the type @<qualifiers>
348 A simple type object maintains a \emph{name}, which is a string whose
349 contents are the C name for the type. The initarg @|:name| may be used to
350 provide this name when calling @|make-instance|.
352 Two simple type objects are equal if and only if they have @|string=| names
353 and matching qualifiers.
355 A number of symbolic type specifiers for builtin types are predefined as
356 shown in \xref{tab:codegen.c-types.simple}. These are all defined as if by
357 @|define-simple-c-type|, so can be used to construct qualified types.
361 \begin{tabular}[C]{ll} \hlx*{hv}
362 \thd{C type} & \thd{Specifiers} \\ \hlx{vhv}
363 @|void| & @|void| \\ \hlx{v}
364 @|_Bool| & @|bool| \\ \hlx{v}
365 @|char| & @|char| \\ \hlx{}
366 @|wchar_t| & @|wchar-t| \\ \hlx{v}
367 @|signed char| & @|signed-char|, @|schar| \\ \hlx{}
368 @|unsigned char| & @|unsigned-char|, @|uchar| \\ \hlx{v}
369 @|short| & @|short|, @|signed-short|, @|short-int|,
370 @|signed-short-int| @|sshort| \\ \hlx{}
371 @|unsigned short| & @|unsigned-short|, @|unsigned-short-int|,
373 @|int| & @|int|, @|signed|, @|signed-int|,
375 @|unsigned int| & @|unsigned|, @|unsigned-int|, @|uint| \\ \hlx{v}
376 @|long| & @|long|, @|signed-long|, @|long-int|,
377 @|signed-long-int|, @|slong| \\ \hlx{}
378 @|unsigned long| & @|unsigned-long|, @|unsigned-long-int|,
380 @|long long| & @|long-long|, @|signed-long-long|,
381 @|long-long-int|, \\ \hlx{}
382 & \qquad @|signed-long-long-int|,
383 @|llong|, @|sllong| \\ \hlx{v}
384 @|unsigned long long|
385 & @|unsigned-long-long|, @|unsigned-long-long-int|,
387 @|size_t| & @|size-t| \\ \hlx{}
388 @|ptrdiff_t| & @|ptrdiff-t| \\ \hlx{v}
389 @|float| & @|float| \\ \hlx{}
390 @|double| & @|double| \\ \hlx{}
391 @|long double| & @|long-double| \\ \hlx{v}
392 @|float _Imaginary| & @|float-imaginary| \\ \hlx{}
393 @|double _Imaginary|& @|double-imaginary| \\ \hlx{}
394 @|long double _Imaginary|
395 & @|long-double-imaginary| \\ \hlx{v}
396 @|float _Complex| & @|float-complex| \\ \hlx{}
397 @|double _Complex| & @|double-complex| \\ \hlx{}
398 @|long double _Complex|
399 & @|long-double-complex| \\ \hlx{v}
400 @|va_list| & @|va-list| \\ \hlx*{vh}
402 \caption{Builtin symbolic type specifiers for simple C types}
403 \label{tab:codegen.c-types.simple}
406 \begin{describe}{fun}
407 {make-simple-type @<name> \&optional @<qualifiers> @> @<c-type>}
408 Return the (unique interned) simple C type object for the C type whose name
409 is @<name> (a string) and which has the given @<qualifiers> (a list of
413 \begin{describe}{gf}{c-type-name @<c-type> @> @<string>}
414 Returns the name of a @|simple-c-type| instance @<c-type> as an immutable
418 \begin{describe}{mac}
419 {define-simple-c-type @{ @<name> @! (@<name>^*) @} @<string> @> @<name>}
420 Define type specifiers for a new simple C type. Each symbol @<name> is
421 defined as a symbolic type specifier for the (unique interned) simple C
422 type whose name is the value of @<string>. Further, each @<name> is
423 defined to be a type operator: the type specifier @|(@<name>
424 @<qualifier>^*)| evaluates to the (unique interned) simple C type whose
425 name is @<string> and which has the @<qualifiers> (which are evaluated).
428 \begin{describe}{cls}{tagged-c-type (qualifiable-c-type)
429 \&key :qualifiers :tag}
430 Provides common behaviour for C tagged types. A @<tag> is a string
431 containing a C identifier.
433 Two tagged types are equal if and only if they have the same class, their
434 @<tag>s are @|string=|, and they have matching qualifiers. (User-defined
435 subclasses may have additional methods on @|c-type-equal-p| which impose
436 further restrictions.)
439 Sod maintains distinct namespaces for the three kinds of tagged types. In
440 C, there is only one namespace for tags which is shared between enums,
444 \begin{describe}{gf}{c-tagged-type-kind @<c-type> @> @<keyword>}
445 Returns a keyword classifying the tagged @<c-type>: one of @|:enum|,
446 @|:struct| or @|:union|. User-defined subclasses of @|tagged-c-type|
447 should return their own classification symbols. It is intended that
448 @|(string-downcase (c-tagged-type-kind @<c-type>))| be valid C
450 Alas, C doesn't provide a syntactic category for these keywords;
451 \Cplusplus\ calls them a @<class-key>.} %
452 There is a method defined for each of the built-in tagged type classes
453 @|c-struct-type|, @|c-union-type| and @|c-enum-type|.
456 \begin{describe}{gf}{kind-c-tagged-type @<keyword> @> @<symbol>}
457 This is not quite the inverse of @|c-tagged-type-kind|. Given a keyword
458 naming a kind of tagged type, return the name of the corresponding C
459 type class as a symbol.
462 \begin{describe}{cls}{c-enum-type (tagged-c-type) \&key :qualifiers :tag}
463 Represents a C enumerated type. An instance denotes the C type @|enum|
464 @<tag>. See the direct superclass @|tagged-c-type| for details.
466 The type specifier @|(enum @<tag> @<qualifier>^*)| returns the (unique
467 interned) enumerated type with the given @<tag> and @<qualifier>s (all
470 \begin{describe}{fun}
471 {make-enum-type @<tag> \&optional @<qualifiers> @> @<c-enum-type>}
472 Return the (unique interned) C type object for the enumerated C type whose
473 tag is @<tag> (a string) and which has the given @<qualifiers> (a list of
477 \begin{describe}{cls}{c-struct-type (tagged-c-type) \&key :qualifiers :tag}
478 Represents a C structured type. An instance denotes the C type @|struct|
479 @<tag>. See the direct superclass @|tagged-c-type| for details.
481 The type specifier @|(struct @<tag> @<qualifier>^*)| returns the (unique
482 interned) structured type with the given @<tag> and @<qualifier>s (all
485 \begin{describe}{fun}
486 {make-struct-type @<tag> \&optional @<qualifiers> @> @<c-struct-type>}
487 Return the (unique interned) C type object for the structured C type whose
488 tag is @<tag> (a string) and which has the given @<qualifiers> (a list of
492 \begin{describe}{cls}{c-union-type (tagged-c-type) \&key :qualifiers :tag}
493 Represents a C union type. An instance denotes the C type @|union|
494 @<tag>. See the direct superclass @|tagged-c-type|
497 The type specifier @|(union @<tag> @<qualifier>^*)| returns the (unique
498 interned) union type with the given @<tag> and @<qualifier>s (all
501 \begin{describe}{fun}
502 {make-union-type @<tag> \&optional @<qualifiers> @> @<c-union-type>}
503 Return the (unique interned) C type object for the union C type whose tag
504 is @<tag> (a string) and which has the given @<qualifiers> (a list of
509 \subsection{Compound C types} \label{sec:code.c-types.compound}
511 Some C types are \emph{compound types}: they're defined in terms of existing
512 types. The classes which represent compound types implement a common
515 \begin{describe}{gf}{c-type-subtype @<c-type> @> @<subtype>}
516 Returns the underlying type of a compound type @<c-type>. Precisely what
517 this means depends on the class of @<c-type>.
521 \subsection{Pointer types} \label{sec:clang.c-types.pointer}
523 Pointers compound types. The subtype of a pointer type is the type it points
526 \begin{describe}{cls}
527 {c-pointer-type (qualifiable-c-type) \&key :qualifiers :subtype}
528 Represents a C pointer type. An instance denotes the C type @<subtype>
531 The @<subtype> may be any C type. Two pointer types are equal if and only
532 if their subtypes are equal and they have matching qualifiers.
534 The type specifier @|(* @<type-spec> @<qualifier>^*)| returns a type
535 qualified pointer-to-@<subtype>, where @<subtype> is the type specified by
536 @<type-spec> and the @<qualifier>s are qualifier keywords (which are
537 evaluated). The synonyms @|ptr| and @|pointer| may be used in place of the
540 The symbol @|string| is a type specifier for the type pointer to
541 characters; the symbol @|const-string| is a type specifier for the type
542 pointer to constant characters.
545 \begin{describe}{fun}
546 {make-pointer-type @<c-type> \&optional @<qualifiers>
547 @> @<c-pointer-type>}
548 Return an object describing the type qualified pointer to @<subtype>.
549 If @<subtype> is interned, then the returned pointer type object is
554 \subsection{Array types} \label{sec:clang.c-types.array}
556 Arrays implement the compound-type protocol. The subtype of an array type is
557 the array element type.
559 \begin{describe}{cls}{c-array-type (c-type) \&key :subtype :dimensions}
560 Represents a multidimensional C array type. The @<dimensions> are a list
561 of dimension specifiers $d_0$, $d_1$, \ldots, $d_{n-1}$; an instance then
562 denotes the C type @<subtype> @|[$d_0$][$d_1$]$\ldots$[$d_{n-1}$]|. An
563 individual dimension specifier is either a string containing a C integral
564 constant expression, or nil which is equivalent to an empty string. Only
565 the first (outermost) dimension $d_0$ should be empty.
567 C doesn't actually have multidimensional arrays as a primitive notion;
568 rather, it permits an array (with known extent) to be the element type of
569 an array, which achieves an equivalent effect. C arrays are stored in
570 row-major order: i.e., if we write down the indices of the elements of an
571 array in order of ascending address, the rightmost index varies fastest;
572 hence, the type constructed is more accurately an array of $d_0$ arrays of
573 $d_1$ of \ldots\ arrays of $d_{n-1}$ elements of type @<subtype>. We shall
574 continue to abuse terminology and refer to multidimensional arrays.
576 The type specifier @|([] @<type-spec> @<dimension>^*)| constructs a
577 multidimensional array with the given @<dimension>s whose elements have the
578 type specified by @<type-spec>. If no dimensions are given then a
579 single-dimensional array with unspecified extent. The synonyms @|array|
580 and @|vector| may be used in place of the brackets @`[]'.
583 \begin{describe}{fun}
584 {make-array-type @<subtype> @<dimensions> @> @<c-array-type>}
585 Return an object describing the type of arrays with given @<dimensions> and
586 with element type @<subtype> (an instance of @|c-type|). The @<dimensions>
587 argument is a list whose elements are strings or nil; see the description
588 of the class @|c-array-type| above for details.
591 \begin{describe}{gf}{c-array-dimensions @<c-type> @> @<list>}
592 Returns the dimensions of @<c-type>, an array type, as an immutable list.
596 \subsection{Function types} \label{sec:clang.c-types.fun}
598 Function types implement the compound-type protocol. The subtype of a
599 function type is the type of the function's return value.
601 \begin{describe}{cls}{argument}
602 Represents an ordinary function argument.
605 \begin{describe}{fun}{argumentp @<value> @> @<generalized-boolean>}
606 Decide whether @<value> is an @<argument> object: if so, return non-nil; if
610 \begin{describe}{fun}{make-argument @<name> @<c-type> @> @<argument>}
611 Construct and a return a new @<argument> object. The argument has type
612 @<c-type>, which must be a @|c-type| object, and is named @<name>.
614 The @<name> may be nil to indicate that the argument has no name: in this
615 case the argument will be formatted as an abstract declarator, which is not
616 suitable for function definitions. If @<name> is not nil, then the
617 @<name>'s print representation, with @|*print-escape*| nil, is used as the
622 {\dhead{fun}{argument-name @<argument> @> @<name>}
623 \dhead{fun}{argument-type @<argument> @> @<c-type>}}
624 Accessor functions for @|argument| objects. They return the name (for
625 @|argument-name|) or type (for @|argument-type|) from the object, as passed
630 {commentify-argument-name @<name> @> @<commentified-name>}
631 Convert the argument name @<name> so that it's suitable to declare the
632 function in a header file.
634 Robust header files shouldn't include literal argument names in
635 declarations of functions or function types, since this restricts the
636 including file from defining such names as macros. This generic function
637 is used to convert names into a safe form.
639 \begin{describe}{meth}{commentify-argument-name (@<name> null) @> nil}
640 Returns nil: if the argument name is already omitted, it's safe for use
643 \begin{describe}{meth}{commentify-argument-name (@<name> t) @> @<string>}
644 Returns the print form of @<name> wrapped in a C comment, as
649 \begin{describe}{fun}
650 {commentify-argument-names @<arguments> @> @<commentified-arguments>}
651 Convert the @<arguments> list so that it's suitable for use in a header
654 The @<arguments> list should be a list whose items are @|argument| objects
655 or the keyword @|:ellipsis|. The return value is a list constructed as
656 follows. For each @|argument| object in the input list, there is a
657 corresponding @|argument| object in the returned list, with the same type,
658 and whose name is the result of @|commentify-argument-name| applied to the
659 input argument name; an @|:ellipsis| in the input list is passed through
663 \begin{describe}{cls}{c-function-type (c-type) \&key :subtype :arguments}
664 Represents C function types. An instance denotes the type of a C
665 function which accepts the @<arguments> and returns @<subtype>.
667 The @<arguments> are a possibly empty list. All but the last element of
668 the list must be @|argument| objects; the final element may instead be the
669 keyword @|:ellipsis|, which denotes a variable argument list.
671 An @<arguments> list consisting of a single argument with type @|void| is
672 converted into an empty list. On output as C code, an empty argument list
673 is written as @|void|. It is not possible to represent a pre-ANSI C
674 function without prototypes.
676 Two function types are considered to be the same if their return types are
677 the same, and their argument lists consist of arguments with the same type,
678 in the same order, and either both or neither argument list ends with
679 @|:ellipsis|; argument names are not compared.
681 The type specifier @|(fun @<return-type> @{ (@<arg-name> @<arg-type>) @}^*
682 @[:ellipsis @! . @<form> @])| constructs a function type. The function has
683 the subtype @<return-type>. The remaining items in the type-specifier list
684 are used to construct the argument list. The argument items are a possibly
685 improper list, beginning with zero or more \emph{explicit arguments}:
686 two-item @<arg-name>/@<arg-type> lists. For each such list, an @|argument|
687 object is constructed with the given name (evaluated) and type. Following
688 the explicit arguments, there may be
690 \item nothing, in which case the function's argument list consists only of
691 the explicit arguments;
692 \item the keyword @|:ellipsis|, as the final item in the type-specifier
693 list, indicating a variable argument list may follow the explicit
695 \item a possibly-improper list tail, beginning with an atom either as a
696 list item or as the final list cdr, indicating that the entire list tail
697 is Lisp expression which is to be evaluated to compute the remaining
700 A tail expression may return a list of @|argument| objects, optionally
701 followed by an @|:ellipsis|.
705 (c-type (fun \=(lisp (c-type-subtype other-func)) \+ \\
706 ("first" int) . (c-function-arguments other-func))
708 evaluates to a function type like @|other-func|, only with an additional
709 argument of type @|int| added to the front of its argument list. This
710 could also have been written
712 (let (\=(args (c-function-arguments other-func)) \+ \\
713 (ret (c-type-subtype other-func))) \- \\ \ind
714 (c-type (fun \=(lisp ret) ("first" int) . args)
718 \begin{describe}{fun}
719 {make-function-type @<subtype> @<arguments> @> @<c-function-type>}
720 Construct and return a new function type, returning @<subtype> and
721 accepting the @<arguments>.
725 {c-function-arguments @<c-function-type> @> @<arguments>}
726 Return the arguments list of the @<c-function-type>.
729 \begin{describe}{fun}
730 {commentify-function-type @<c-function-type> @> @<commentified-c-type>}
731 Return a commentified version of the @<c-function-type>.
733 The returned type has the same subtype as the given type, and the argument
734 list of the returned type is the result of applying
735 @|commentify-argument-names| to the argument list of the given type.
739 \subsection{Parsing C types} \label{sec:clang.c-types.parsing}
741 \begin{describe}{fun}
742 {parse-c-type @<scanner>
743 @> @<result> @<success-flag> @<consumed-flag>}
746 \begin{describe}{fun}
747 {parse-declarator @<scanner> @<base-type> \&key :kernel :abstractp
748 \nlret @<result> @<success-flag> @<consumed-flag>}
752 \subsection{Class types} \label{sec:clang.c-types.class}
754 \begin{describe}{cls}
755 {c-class-type (simple-c-type) \&key :class :tag :qualifiers :name}
759 {\dhead{gf}{c-type-class @<class-type> @> @<class>}
760 \dhead{gf}{setf (c-type-class @<class-type>) @<class>}}
763 \begin{describe}{fun}{find-class-type @<name> @> @<class-type-or-nil>}
766 \begin{describe}{fun}
767 {make-class-type @<name> \&optional @<qualifiers> @> @<class-type>}
770 \begin{describe}{fun}
771 {make-class-type @<name> \&optional @<qualifiers> @> @<class-type>}
774 \begin{describe}{fun}{find-sod-class @<name> @> @<class>}
777 \begin{describe}{fun}{record-sod-class @<class>}
780 %%%--------------------------------------------------------------------------
781 \section{Generating C code} \label{sec:clang.codegen}
783 This section deals with Sod's facilities for constructing and manipulating C
784 expressions, declarations, instructions and definitions.
787 \subsection{Temporary names} \label{sec:clang.codegen.temporaries}
789 Many C-level objects, especially ones with external linkage or inclusion in a
790 header file, are assigned names which are simple strings, perhaps fixed ones,
791 perhaps constructed. Other objects don't need meaningful names, and
792 suitably unique constructed names would be tedious and most likely rather
793 opaque. Therefore Sod has an ability to construct \emph{temporary names}.
795 These aren't temporary in the sense that they name C objects which have
796 limited lifetimes at runtime. Rather, the idea is that the names be
797 significant only to small pieces of Lisp code, which will soon forget about
800 \subsubsection{The temporary name protocol}
801 Temporary names are represented by objects which implement a simple protocol.
803 \begin{describe}{gf}{format-temporary-name @<var> @<stream>}
807 {\dhead{gf}{var-in-use-p @<var> @> @<generalized-boolean>}
808 \dhead[setf var-in-use-p]
809 {gf}{setf (var-in-use-p @<var>) @<generalized-boolean>}}
812 \subsubsection{Temporary name objects}
814 \begin{describe}{cls}{temporary-name () \&key :tag}
815 A temporary name object. This is the root of a small collection of
816 subclasses, but is also usable on its own.
819 \begin{describe}{meth}
820 {commentify-argument-name (@<name> temporary-name) @> nil}
824 \begin{tabular}[C]{*2{>{\codeface}l}} \hlx*{hv}
825 \thd{\textbf{Class}} & \thd{\textbf{Name format}} \\ \hlx{vhv}
826 temporary-name & @<tag> \\
827 temporary-argument & sod__a@<tag> \\
828 temporary-function & sod__f@<tag> \\
829 temporary-variable & sod__v@<tag> \\ \hlx*{vh}
831 \caption{Temporary name formats}
832 \label{tab:codegen.codegen.temps-format}
835 \begin{describe}{cls}{temporary-argument (temporary-name) \&key :tag}
838 \begin{describe}{cls}{temporary-function (temporary-name) \&key :tag}
841 \begin{describe}{fun}{temporary-function @> @<name>}
844 \begin{describe}{cls}
845 {temporary-variable (temporary-name) \&key :tag :in-use-p}
848 \subsubsection{Well-known `temporary' names}
851 \begin{tabular}[C]{*2{>{\codeface}l}} \hlx*{hv}
852 \thd{\textbf{Variable}} & \thd{\textbf{Name format}} \\ \hlx{vhv}
853 {}*sod-ap* & sod__ap \\
854 {}*sod-master-ap* & sod__master_ap \\
855 {}*sod-tmp-ap* & sod__tmp_ap \\ \hlx*{vh}
857 \caption{Well-known temporary names}
858 \label{tab:codegen.codegen.well-known-temps}
862 \subsection{Instructions} \label{sec:clang.codegen.insts}
864 \begin{describe}{cls}{inst () \&key}
867 \begin{describe}{gf}{inst-metric @<inst>}
870 \begin{describe}{mac}
871 {definst @<code> (@<streamvar> \&key @<export>) (@<arg>^*) \\ \ind
872 @[[ @<declaration>^* @! @<doc-string> @]] \\
877 \begin{describe}{mac}
878 {format-compound-statement
879 (@<stream> @<child> \&optional @<morep>) \\ \ind
885 \begin{tabular}[C]{ll>{\codeface}l} \hlx*{hv}
888 \thd{Output format} \\ \hlx{vhv}
889 @|var| & @<name> @<type> @<init> & @<type> @<name> @[= @<init>@];
891 @|set| & @<var> @<expr> & @<var> = @<expr>; \\ \hlx{v}
892 @|update| & @<var> @<op> @<expr> & @<var> @<op>= @<expr>;
894 @|return| & @<expr> & return @[@<expr>@];
896 @|break| & --- & break; \\ \hlx{v}
897 @|continue| & --- & continue; \\ \hlx{v}
898 @|expr| & @<expr> & @<expr>; \\ \hlx{v}
899 @|call| & @<func> @<args> & @<func>(@<arg>_1,
902 @|va-start| & @<ap> @<arg> & va_start(@<ap>, @<arg>);
904 @|va-copy| & @<to> @<from> & va_copy(@<to>, @<from>);
906 @|va-end| & @<ap> & va_end(@<ap>); \\ \hlx{vhv}
907 @|block| & @<decls> @<body> & \{ @[@<decls>@] @<body> \}
909 @|if| & @<cond> @<conseq> @<alt> & if (@<cond>) @<conseq>
910 @[else @<alt>@] \\ \hlx{v}
911 @|while| & @<cond> @<body> & while (@<cond>) @<body>
913 @|do-while| & @<body> @<cond> & do @<body> while (@<cond>);
915 @|function| & @<name> @<type> @<body> &
916 @<type>_0 @<name>(@<type>_1 @<arg>_1, $\ldots$,
917 @<type>_n @<arg>_n @[, \dots@])
920 \caption{Instruction classes}
921 \label{tab:codegen.codegen.insts}
925 \subsection{Code generation} \label{sec:clang.codegen.codegen}
927 \begin{describe}{gf}{codegen-functions @<codegen> @> @<list>}
931 {ensure-var @<codegen> @<name> @<type> \&optional @<init>}
934 \begin{describe}{gf}{emit-inst @<codegen> @<inst>}
937 \begin{describe}{gf}{emit-insts @<codegen> @<insts>}
940 \begin{describe}{gf}{emit-decl @<codegen> @<decl>}
943 \begin{describe}{gf}{emit-declss @<codegen> @<decls>}
946 \begin{describe}{gf}{codegen-push @<codegen>}
949 \begin{describe}{gf}{codegen-pop @<codegen> @> @<decls> @<insts>}
952 \begin{describe}{gf}{codegen-pop-block @<codegen> @> @<block-inst>}
956 {codegen-pop-function @<codegen> @<name> @<type> @> @<name>}
959 \begin{describe}{gf}{codegen-add-function @<codegen> @<function>}
962 \begin{describe}{fun}
963 {codegen-build-function @<codegen> @<name> @<type> @<vars> @<insts>
967 \begin{describe}{gf}{temporary-var @<codegen> @<type> @> @<name>}
970 \begin{describe}{mac}
971 {with-temporary-var (@<codegen> @<var> @<type>) \\ \ind
977 \begin{describe}{fun}{deliver-expr @<codegen> @<target> @<expr>}
980 \begin{describe}{fun}{convert-stmts @<codegen> @<target> @<type> @<func>}
983 \begin{describe}{cls}{codegen () \&key :vars :insts (:temp-index 0)}
986 %%%--------------------------------------------------------------------------
987 \section{Literal C code fragments} \label{sec:clang.fragment}
989 \begin{describe}{cls}{c-fragment () \&key :location :text}
992 \begin{describe}{gf}{c-fragment-text @<fragment> @> @<string>}
995 \begin{describe}{fun}
996 {scan-c-fragment @<scanner> @<end-chars>
997 @> @<result> @<success-flag> @<consumed-flag>}
1000 \begin{describe}{fun}
1001 {parse-delimited-fragment @<scanner> @<begin> @<end> \&key :keep-end
1002 \nlret @<result> @<success-flag> @<consumed-flag>}
1005 %%%----- That's all, folks --------------------------------------------------
1007 %%% Local variables:
1009 %%% TeX-master: "sod.tex"