Changeset 6a86a0a for doc/generic_types


Ignore:
Timestamp:
Mar 29, 2017, 5:41:51 PM (7 years ago)
Author:
Rob Schluntz <rschlunt@…>
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
Message:

fix some minor typos in generic types paper

File:
1 edited

Legend:

Unmodified
Added
Removed
  • doc/generic_types/generic_types.tex

    r95448f1e r6a86a0a  
    148148\label{sec:poly-fns}
    149149
    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):
    151151\begin{lstlisting}
    152152forall(otype T)
     
    174174forall(otype S | { S ?+?(S, S); })
    175175S 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}
     177This 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@.
    178178The 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@.}.
    179179
     
    196196forall(otype M | has_magnitude(M))
    197197M max_magnitude( M a, M b ) {
    198     return abs(a) < abs(b) ? b : a; 
     198    return abs(a) < abs(b) ? b : a;
    199199}
    200200\end{lstlisting}
     
    213213Given 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):
    214214\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), 
     215void 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),
    220220                void* m, void* _rtn ) {  // polymorphic parameter and return passed as void*
    221221        // M zero = { 0 };
     
    223223        _ctor_M_zero(zero, 0);  // initialize using zero_t constructor
    224224        // return m < zero ? -m : m;
    225         void *_tmp = alloca(_sizeof_M)
     225        void *_tmp = alloca(_sizeof_M);
    226226        _copy_M( _rtn,  // copy-initialize return value
    227227                _lt_M( m, zero ) ?  // check condition
     
    323323In 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@.
    324324% \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,
    326326%               size_t _szeof_R, size_t _alignof_R, size_t _szeof_S, size_t _alignof_S) {
    327327%     *_szeof_pair = 0; // default values
     
    332332%     *_szeof_pair += _szeof_R;
    333333%     if ( *_alignof_pair < _alignof_R ) *_alignof_pair = _alignof_R;
    334        
     334
    335335%       // padding, offset, size, and alignment of second field
    336336%     if ( *_szeof_pair & (_alignof_S - 1) )
     
    754754f(x.field_0, (_tuple2){ x.field_1, 'z' });
    755755\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@, a 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.
     756Note 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.
    757757
    758758Expressions 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:
     
    774774);
    775775\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 true 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.
     776Since 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.
    777777
    778778Currently, 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.