Changeset 6dba9f99 for doc/papers/general

Timestamp:

Mar 7, 2018, 2:15:00 PM (7 years ago)

Author:

Aaron Moss <a3moss@…>

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:

7b0dfa4, f1f8e55

Parents:

14a3dad2

Message:

Update dynamic generic type examples

File:

• doc/papers/general/Paper.tex (modified) (3 diffs)

doc/papers/general/Paper.tex

@@ -451 +451 @@
 };
 forall( otype T ) T value( pair( const char *, T ) p ) { return p.second; } $\C{// dynamic}$
-forall( dtype F, otype T ) T value( pair( F *, T * ) p ) { return *p.second; } $\C{// concrete}$
-
-pair( const char *, int ) p = { "magic", 42 }; $\C{// dynamic}$
+forall( dtype F, otype T ) T value( pair( F *, T * ) p ) { return *p.second; } $\C{// dtype-static (concrete)}$
+
+pair( const char *, int ) p = { "magic", 42 }; $\C{// concrete}$
 int i = value( p );
 pair( void *, int * ) q = { 0, &p.second }; $\C{// concrete}$
@@ -464 +464 @@
 \CFA classifies generic types as either \newterm{concrete} or \newterm{dynamic}.
 Concrete types have a fixed memory layout regardless of type parameters, while dynamic types vary in memory layout depending on their type parameters.
-A type may have polymorphic parameters but still be concrete, called \newterm{dtype-static}.
-Polymorphic pointers are an example of dtype-static, \eg @forall(dtype T) T *@ is a polymorphic type, but for any @T@, @T *@  is a fixed-sized pointer, and therefore, can be represented by a @void *@ in code generation.
+A \newterm{dtype-static} type has polymorphic parameters but is still concrete.
+Polymorphic pointers are an example of dtype-static types, \eg @forall(dtype T) T *@ is a polymorphic type, but for any @T@, @T *@  is a fixed-sized pointer, and therefore, can be represented by a @void *@ in code generation.
 
 \CFA generic types also allow checked argument-constraints.
@@ -507 +507 @@
 The offset arrays are statically generated where possible.
 If a dynamic generic-type is declared to be passed or returned by value from a polymorphic function, the translator can safely assume the generic type is complete (\ie has a known layout) at any call-site, and the offset array is passed from the caller;
-if the generic type is concrete at the call site, the elements of this offset array can even be statically generated using the C @offsetof@ macro.
-As an example, @p.second@ in the @value@ function above is implemented as @*(p + _offsetof_pair[1])@, where @p@ is a @void *@, and @_offsetof_pair@ is the offset array passed into @value@ for @pair( const char *, T )@.
-The offset array @_offsetof_pair@ is generated at the call site as @size_t _offsetof_pair[] = { offsetof(_pair_conc0, first), offsetof(_pair_conc0, second) }@.
+if the generic type is concrete at the call site, the elements of this offset array can even be statically generated using the C @offsetof@ macro. 
+As an example, the body of the second @value@ function is implemented like this:
+\begin{cfa}
+_assign_T(_retval, p + _offsetof_pair[1]); $\C{// return *p.second}$
+\end{cfa}
+@_assign_T@ is passed in as an implicit parameter from @otype T@, and takes two @T*@ (@void*@ in the generated code), a destination and a source; @_retval@ is the pointer to a caller-allocated buffer for the return value, the usual \CFA method to handle dynamically-sized return types.
+@_offsetof_pair@ is the offset array passed into @value@; this array is generated at the call site as:
+\begin{cfa}
+size_t _offsetof_pair[] = { offsetof(_pair_conc0, first), offsetof(_pair_conc0, second) }
+\end{cfa}
 
 In some cases the offset arrays cannot be statically generated.