Changeset 6dba9f99
- Timestamp:
- Mar 7, 2018, 2:15:00 PM (7 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:
- 7b0dfa4, f1f8e55
- Parents:
- 14a3dad2
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
doc/papers/general/Paper.tex
r14a3dad2 r6dba9f99 451 451 }; 452 452 forall( otype T ) T value( pair( const char *, T ) p ) { return p.second; } $\C{// dynamic}$ 453 forall( dtype F, otype T ) T value( pair( F *, T * ) p ) { return *p.second; } $\C{// concrete}$454 455 pair( const char *, int ) p = { "magic", 42 }; $\C{// dynamic}$453 forall( dtype F, otype T ) T value( pair( F *, T * ) p ) { return *p.second; } $\C{// dtype-static (concrete)}$ 454 455 pair( const char *, int ) p = { "magic", 42 }; $\C{// concrete}$ 456 456 int i = value( p ); 457 457 pair( void *, int * ) q = { 0, &p.second }; $\C{// concrete}$ … … 464 464 \CFA classifies generic types as either \newterm{concrete} or \newterm{dynamic}. 465 465 Concrete types have a fixed memory layout regardless of type parameters, while dynamic types vary in memory layout depending on their type parameters. 466 A type may have polymorphic parameters but still be concrete, called \newterm{dtype-static}.467 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.466 A \newterm{dtype-static} type has polymorphic parameters but is still concrete. 467 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. 468 468 469 469 \CFA generic types also allow checked argument-constraints. … … 507 507 The offset arrays are statically generated where possible. 508 508 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; 509 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. 510 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 )@. 511 The offset array @_offsetof_pair@ is generated at the call site as @size_t _offsetof_pair[] = { offsetof(_pair_conc0, first), offsetof(_pair_conc0, second) }@. 509 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. 510 As an example, the body of the second @value@ function is implemented like this: 511 \begin{cfa} 512 _assign_T(_retval, p + _offsetof_pair[1]); $\C{// return *p.second}$ 513 \end{cfa} 514 @_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. 515 @_offsetof_pair@ is the offset array passed into @value@; this array is generated at the call site as: 516 \begin{cfa} 517 size_t _offsetof_pair[] = { offsetof(_pair_conc0, first), offsetof(_pair_conc0, second) } 518 \end{cfa} 512 519 513 520 In some cases the offset arrays cannot be statically generated.
Note: See TracChangeset
for help on using the changeset viewer.