Changeset 6a86a0a
- Timestamp:
- Mar 29, 2017, 5:41:51 PM (8 years ago)
- Branches:
- ADT, aaron-thesis, arm-eh, ast-experimental, cleanup-dtors, deferred_resn, demangler, enum, forall-pointer-decay, jacob/cs343-translation, jenkins-sandbox, master, new-ast, new-ast-unique-expr, new-env, no_list, persistent-indexer, pthread-emulation, qualifiedEnum, resolv-new, with_gc
- Children:
- 89ae7f4
- Parents:
- 95448f1e
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
TabularUnified doc/generic_types/generic_types.tex ¶
r95448f1e r6a86a0a 148 148 \label{sec:poly-fns} 149 149 150 \CFA{}'s polymorphism was originally formalized by \citet{Ditchfield92}, and first implemented by \citet{Bilson03}. The signature feature of \CFA{} is parametric-polymorphic functions; such functions are written using a @forall@ clause (which gives the language its name): 150 \CFA{}'s polymorphism was originally formalized by \citet{Ditchfield92}, and first implemented by \citet{Bilson03}. The signature feature of \CFA{} is parametric-polymorphic functions; such functions are written using a @forall@ clause (which gives the language its name): 151 151 \begin{lstlisting} 152 152 forall(otype T) … … 174 174 forall(otype S | { S ?+?(S, S); }) 175 175 S twice(S x) { return x + x; } // (2) 176 \end{lstlisting} 177 This version of @twice@ works for any type @S@ that has an addition operator defined for it, and it could have been used to satisfy the type assertion on @four_times@. 176 \end{lstlisting} 177 This version of @twice@ works for any type @S@ that has an addition operator defined for it, and it could have been used to satisfy the type assertion on @four_times@. 178 178 The translator accomplishes this polymorphism by creating a wrapper function calling @twice // (2)@ with @S@ bound to @double@, then providing this wrapper function to @four_times@\footnote{\lstinline@twice // (2)@ could also have had a type parameter named \lstinline@T@; \CFA{} specifies renaming of the type parameters, which would avoid the name conflict with the type variable \lstinline@T@ of \lstinline@four_times@.}. 179 179 … … 196 196 forall(otype M | has_magnitude(M)) 197 197 M max_magnitude( M a, M b ) { 198 return abs(a) < abs(b) ? b : a; 198 return abs(a) < abs(b) ? b : a; 199 199 } 200 200 \end{lstlisting} … … 213 213 Given the information provided for an @otype@, variables of polymorphic type can be treated as if they were a complete struct type -- they can be stack-allocated using the @alloca@ compiler builtin, default or copy-initialized, assigned, and deleted. As an example, the @abs@ function above produces generated code something like the following (simplified for clarity and brevity): 214 214 \begin{lstlisting} 215 void abs( size_t _sizeof_M, size_t _alignof_M, 216 void (*_ctor_M)(void*), void (*_copy_M)(void*, void*), 217 void (*_assign_M)(void*, void*), void (*_dtor_M)(void*), 218 bool (*_lt_M)(void*, void*), void (*_neg_M)(void*, void*), 219 void (*_ctor_M_zero)(void*, int), 215 void abs( size_t _sizeof_M, size_t _alignof_M, 216 void (*_ctor_M)(void*), void (*_copy_M)(void*, void*), 217 void (*_assign_M)(void*, void*), void (*_dtor_M)(void*), 218 bool (*_lt_M)(void*, void*), void (*_neg_M)(void*, void*), 219 void (*_ctor_M_zero)(void*, int), 220 220 void* m, void* _rtn ) { // polymorphic parameter and return passed as void* 221 221 // M zero = { 0 }; … … 223 223 _ctor_M_zero(zero, 0); // initialize using zero_t constructor 224 224 // return m < zero ? -m : m; 225 void *_tmp = alloca(_sizeof_M) 225 void *_tmp = alloca(_sizeof_M); 226 226 _copy_M( _rtn, // copy-initialize return value 227 227 _lt_M( m, zero ) ? // check condition … … 323 323 In some cases the offset arrays cannot be statically generated. For instance, modularity is generally provided in C by including an opaque forward-declaration of a struct and associated accessor and mutator routines in a header file, with the actual implementations in a separately-compiled \texttt{.c} file. \CFA{} supports this pattern for generic types, and in this instance the caller does not know the actual layout or size of the dynamic generic type, and only holds it by pointer. The \CFA{} translator automatically generates \emph{layout functions} for cases where the size, alignment, and offset array of a generic struct cannot be passed in to a function from that function's caller. These layout functions take as arguments pointers to size and alignment variables and a caller-allocated array of member offsets, as well as the size and alignment of all @sized@ parameters to the generic struct (un-@sized@ parameters are forbidden from the language from being used in a context that affects layout). Results of these layout functions are cached so that they are only computed once per type per function.%, as in the example below for @pair@. 324 324 % \begin{lstlisting} 325 % static inline void _layoutof_pair(size_t* _szeof_pair, size_t* _alignof_pair, size_t* _offsetof_pair, 325 % static inline void _layoutof_pair(size_t* _szeof_pair, size_t* _alignof_pair, size_t* _offsetof_pair, 326 326 % size_t _szeof_R, size_t _alignof_R, size_t _szeof_S, size_t _alignof_S) { 327 327 % *_szeof_pair = 0; // default values … … 332 332 % *_szeof_pair += _szeof_R; 333 333 % if ( *_alignof_pair < _alignof_R ) *_alignof_pair = _alignof_R; 334 334 335 335 % // padding, offset, size, and alignment of second field 336 336 % if ( *_szeof_pair & (_alignof_S - 1) ) … … 754 754 f(x.field_0, (_tuple2){ x.field_1, 'z' }); 755 755 \end{lstlisting} 756 Note that due to flattening, @x@ used in the argument position is converted into the list of its fields. In the call to @f@, athe second and third argument components are structured into a tuple argument. Similarly, tuple member expressions are recursively expanded into a list of member access expressions.756 Note that due to flattening, @x@ used in the argument position is converted into the list of its fields. In the call to @f@, the second and third argument components are structured into a tuple argument. Similarly, tuple member expressions are recursively expanded into a list of member access expressions. 757 757 758 758 Expressions that may contain side effects are made into \emph{unique expressions} before being expanded by the flattening conversion. Each unique expression is assigned an identifier and is guaranteed to be executed exactly once: … … 774 774 ); 775 775 \end{lstlisting} 776 Since argument evaluation order is not specified by the C programming language, this scheme is built to work regardless of evaluation order. The first time a unique expression is executed, the actual expression is evaluated and the accompanying boolean is trueto true. Every subsequent evaluation of the unique expression then results in an access to the stored result of the actual expression. Tuple member expressions also take advantage of unique expressions in the case of possible impurity.776 Since argument evaluation order is not specified by the C programming language, this scheme is built to work regardless of evaluation order. The first time a unique expression is executed, the actual expression is evaluated and the accompanying boolean is set to true. Every subsequent evaluation of the unique expression then results in an access to the stored result of the actual expression. Tuple member expressions also take advantage of unique expressions in the case of possible impurity. 777 777 778 778 Currently, the \CFA{} translator has a very broad, imprecise definition of impurity, where any function call is assumed to be impure. This notion could be made more precise for certain intrinsic, auto-generated, and builtin functions, and could analyze function bodies when they are available to recursively detect impurity, to eliminate some unique expressions.
Note: See TracChangeset
for help on using the changeset viewer.