Ignore:
Timestamp:
May 13, 2025, 1:17:50 PM (10 months ago)
Author:
Mike Brooks <mlbrooks@…>
Branches:
master, stuck-waitfor-destruct
Children:
0528d79
Parents:
7d02d35 (diff), 2410424 (diff)
Note: this is a merge changeset, the changes displayed below correspond to the merge itself.
Use the (diff) links above to see all the changes relative to each parent.
Message:

Merge branch 'master' of plg.uwaterloo.ca:software/cfa/cfa-cc

File:
1 edited

Legend:

Unmodified
Added
Removed
  • doc/theses/fangren_yu_MMath/features.tex

    r7d02d35 rbd72f517  
    1313Here, manipulating the pointer address is the primary operation, while dereferencing the pointer to its value is the secondary operation.
    1414For example, \emph{within} a data structure, \eg stack or queue, all operations involve pointer addresses and the pointer may never be dereferenced because the referenced object is opaque.
    15 Alternatively, use a reference when its primary purpose is to alias a value, \eg a function parameter that does not copy the argument (performance reason).
     15Alternatively, use a reference when its primary purpose is to alias a value, \eg a function parameter that does not copy the argument, for performance reasons.
    1616Here, manipulating the value is the primary operation, while changing the pointer address is the secondary operation.
    1717Succinctly, if the address changes often, use a pointer;
     
    2323\CFA adopts a uniform policy between pointers and references where mutability is a separate property made at the declaration.
    2424
    25 The following examples shows how pointers and references are treated uniformly in \CFA.
     25The following examples show how pointers and references are treated uniformly in \CFA.
    2626\begin{cfa}[numbers=left,numberblanklines=false]
    2727int x = 1, y = 2, z = 3;$\label{p:refexamples}$
     
    3636@&@r3 = @&@y; @&&@r3 = @&&@r4;                          $\C{// change r1, r2}$
    3737\end{cfa}
    38 Like pointers, reference can be cascaded, \ie a reference to a reference, \eg @&& r2@.\footnote{
     38Like pointers, references can be cascaded, \ie a reference to a reference, \eg @&& r2@.\footnote{
    3939\CC uses \lstinline{&&} for rvalue reference, a feature for move semantics and handling the \lstinline{const} Hell problem.}
    4040Usage of a reference variable automatically performs the same number of dereferences as the number of references in its declaration, \eg @r2@ becomes @**r2@.
     
    6464The call applies an implicit dereference once to @x@ so the call is typed @f( int & )@ with @T = int@, rather than with @T = int &@.
    6565
    66 As for a pointer type, a reference type may have qualifiers, where @const@ is most common.
     66As with a pointer type, a reference type may have qualifiers, where @const@ is most common.
    6767\begin{cfa}
    6868int x = 3; $\C{// mutable}$
     
    101101Interestingly, C does not give a warning/error if a @const@ pointer is not initialized, while \CC does.
    102102Hence, type @& const@ is similar to a \CC reference, but \CFA does not preclude initialization with a non-variable address.
    103 For example, in system's programming, there are cases where an immutable address is initialized to a specific memory location.
     103For example, in systems programming, there are cases where an immutable address is initialized to a specific memory location.
    104104\begin{cfa}
    105105int & const mem_map = *0xe45bbc67@p@; $\C{// hardware mapped registers ('p' for pointer)}$
     
    122122\end{cfa}
    123123the call to @foo@ must pass @x@ by value, implying auto-dereference, while the call to @bar@ must pass @x@ by reference, implying no auto-dereference.
    124 Without any restrictions, this ambiguity limits the behaviour of reference types in \CFA polymorphic functions, where a type @T@ can bind to a reference or non-reference type.
     124
     125\PAB{My analysis shows} without any restrictions, this ambiguity limits the behaviour of reference types in \CFA polymorphic functions, where a type @T@ can bind to a reference or non-reference type.
    125126This ambiguity prevents the type system treating reference types the same way as other types, even if type variables could be bound to reference types.
    126127The reason is that \CFA uses a common \emph{object trait}\label{p:objecttrait} (constructor, destructor and assignment operators) to handle passing dynamic concrete type arguments into polymorphic functions, and the reference types are handled differently in these contexts so they do not satisfy this common interface.
     
    157158\end{cfa}
    158159While it is possible to write a reference type as the argument to a generic type, it is disallowed in assertion checking, if the generic type requires the object trait \see{\VPageref{p:objecttrait}} for the type argument, a fairly common use case.
    159 Even if the object trait can be made optional, the current type system often misbehaves by adding undesirable auto-dereference on the referenced-to value rather than the reference variable itself, as intended.
     160Even if the object trait can be made optional, the current compiler implementation often misbehaves by adding undesirable auto-dereference on the referenced-to value rather than the reference variable itself, as intended.
    160161Some tweaks are necessary to accommodate reference types in polymorphic contexts and it is unclear what can or cannot be achieved.
    161162Currently, there are contexts where the \CFA programmer is forced to use a pointer type, giving up the benefits of auto-dereference operations and better syntax with reference types.
     
    188189@[x, y, z]@ = foo( 3, 4 );  // return 3 values into a tuple
    189190\end{cfa}
    190 Along with making returning multiple values a first-class feature, tuples were extended to simplify a number of other common context that normally require multiple statements and/or additional declarations, all of which reduces coding time and errors.
     191Along with making returning multiple values a first-class feature, tuples were extended to simplify a number of other common contexts that normally require multiple statements and/or additional declarations.
    191192\begin{cfa}
    192193[x, y, z] = 3; $\C[2in]{// x = 3; y = 3; z = 3, where types may be different}$
     
    205206Only when returning a tuple from a function is there the notion of a tuple value.
    206207
    207 Overloading in the \CFA type-system must support complex composition of tuples and C type conversions using a costing scheme giving lower cost to widening conversions that do not truncate a value.
     208Overloading in the \CFA type-system must support complex composition of tuples and C type conversions using a conversion cost scheme giving lower cost to widening conversions that do not truncate a value.
    208209\begin{cfa}
    209210[ int, int ] foo$\(_1\)$( int );                        $\C{// overloaded foo functions}$
     
    213214\end{cfa}
    214215The type resolver only has the tuple return types to resolve the call to @bar@ as the @foo@ parameters are identical.
    215 The resultion involves unifying the flattened @foo@ return values with @bar@'s parameter list.
     216The resulution involves unifying the flattened @foo@ return values with @bar@'s parameter list.
    216217However, no combination of @foo@s is an exact match with @bar@'s parameters;
    217218thus, the resolver applies C conversions to obtain a best match.
     
    223224bar( foo( 3 ) ) // only one tuple returning call
    224225\end{lstlisting}
    225 Hence, programers cannot take advantage of the full power of tuples but type match is straightforward.
     226Hence, programmers cannot take advantage of the full power of tuples but type match is straightforward.
    226227
    227228K-W C also supported tuple variables, but with a strong distinction between tuples and tuple values/variables.
     
    286287\end{figure}
    287288
    288 The primary issues for tuples in the \CFA type system are polymorphism and conversions.
     289\PAB{I identified} the primary issues for tuples in the \CFA type system are polymorphism and conversions.
    289290Specifically, does it make sense to have a generic (polymorphic) tuple type, as is possible for a structure?
    290291\begin{cfa}
     
    303304\section{Tuple Implementation}
    304305
    305 As noted, tradition languages manipulate multiple values by in/out parameters and/or structures.
     306As noted, traditional languages manipulate multiple values by in/out parameters and/or structures.
    306307K-W C adopted the structure for tuple values or variables, and as needed, the fields are extracted by field access operations.
    307308As well, for the tuple-assignment implementation, the left-hand tuple expression is expanded into assignments of each component, creating temporary variables to avoid unexpected side effects.
     
    356357\end{figure}
    357358
    358 Interestingly, in the third implementation of \CFA tuples by Robert Schluntz~\cite[\S~3]{Schluntz17}, the MVR functions revert back to structure based, where it remains in the current version of \CFA.
     359Interestingly, in the third implementation of \CFA tuples by Robert Schluntz~\cite[\S~3]{Schluntz17}, the MVR functions revert back to structure based, and this remains in the current version of \CFA.
    359360The reason for the reversion is a uniform approach for tuple values/variables making tuples first-class types in \CFA, \ie allow tuples with corresponding tuple variables.
    360361This reversion was possible, because in parallel with Schluntz's work, generic types were added independently by Moss~\cite{Moss19}, and the tuple variables leveraged the same implementation techniques as for generic variables~\cite[\S~3.7]{Schluntz17}.
     
    384385Scala, like \CC, provides tuple types through a library using this structural expansion, \eg Scala provides tuple sizes 1 through 22 via hand-coded generic data-structures.
    385386
    386 However, after experience gained building the \CFA runtime system, making tuple-types first-class seems to add little benefit.
     387However, after experience gained building the \CFA runtime system, \PAB{I convinced them} making tuple-types first-class seems to add little benefit.
    387388The main reason is that tuples usages are largely unstructured,
    388389\begin{cfa}
     
    512513looping is used to traverse the argument pack from left to right.
    513514The @va_list@ interface is walking up the stack (by address) looking at the arguments pushed by the caller.
    514 (Magic knowledge is needed for arguments pushed using registers.)
     515(Compiler-specific ABI knowledge is needed for arguments pushed using registers.)
    515516
    516517\begin{figure}
     
    571572
    572573Currently in \CFA, variadic polymorphic functions are the only place tuple types are used.
    573 And because \CFA compiles polymorphic functions versus template expansion, many wrapper functions are generated to implement both user-defined generic-types and polymorphism with variadics.
     574\PAB{My analysis showed} many wrapper functions are generated to implement both user-defined generic-types and polymorphism with variadics, because \CFA compiles polymorphic functions versus template expansion.
    574575Fortunately, the only permitted operations on polymorphic function parameters are given by the list of assertion (trait) functions.
    575576Nevertheless, this small set of functions eventually needs to be called with flattened tuple arguments.
    576577Unfortunately, packing the variadic arguments into a rigid @struct@ type and generating all the required wrapper functions is significant work and largely wasted because most are never called.
    577578Interested readers can refer to pages 77-80 of Robert Schluntz's thesis to see how verbose the translator output is to implement a simple variadic call with 3 arguments.
    578 As the number of arguments increases, \eg a call with 5 arguments, the translator generates a concrete @struct@ types for a 4-tuple and a 3-tuple along with all the polymorphic type data for them.
     579As the number of arguments increases, \eg a call with 5 arguments, the translator generates concrete @struct@ types for a 4-tuple and a 3-tuple along with all the polymorphic type data for them.
    579580An alternative approach is to put the variadic arguments into an array, along with an offset array to retrieve each individual argument.
    580581This method is similar to how the C @va_list@ object is used (and how \CFA accesses polymorphic fields in a generic type), but the \CFA variadics generate the required type information to guarantee type safety (like the @printf@ format string).
     
    683684
    684685Nested \emph{named} aggregates are allowed in C but there is no qualification operator, like the \CC type operator `@::@', to access an inner type.
    685 \emph{To compensate for the missing type operator, all named nested aggregates are hoisted to global scope, regardless of the nesting depth, and type usages within the nested type are replaced with global type name.}
     686To compensate for the missing type operator, all named nested aggregates are hoisted to global scope, regardless of the nesting depth, and type usages within the nested type are replaced with global type name.
    686687Hoisting nested types can result in name collisions among types at the global level, which defeats the purpose of nesting the type.
    687688\VRef[Figure]{f:NestedNamedAggregate} shows the nested type @T@ is hoisted to the global scope and the declaration rewrites within structure @S@.
     
    729730\end{figure}
    730731
    731 For good reasons, \CC chose to change this semantics:
     732\CC chose to change this semantics:
    732733\begin{cquote}
    733734\begin{description}[leftmargin=*,topsep=0pt,itemsep=0pt,parsep=0pt]
     
    769770Like an anonymous nested type, a named Plan-9 nested type has its field names hoisted into @struct S@, so there is direct access, \eg @s.x@ and @s.i@.
    770771Hence, the field names must be unique, unlike \CC nested types, but the type names are at a nested scope level, unlike type nesting in C.
    771 In addition, a pointer to a structure is automatically converted to a pointer to an anonymous field for assignments and function calls, providing containment inheritance with implicit subtyping, \ie @U@ $\subset$ @S@ and @W@ $\subset$ @S@, \eg:
     772In addition, a pointer to a structure is automatically converted to a pointer to an anonymous field for assignments and function calls, providing containment inheritance with implicit subtyping, \ie @U@ $<:$ @S@ and @W@ $<:$ @S@, \eg:
    772773\begin{cfa}
    773774void f( union U * u );
     
    781782Note, there is no value assignment, such as, @w = s@, to copy the @W@ field from @S@.
    782783
    783 Unfortunately, the Plan-9 designers did not lookahead to other useful features, specifically nested types.
     784Unfortunately, the Plan-9 designers did not look ahead to other useful features, specifically nested types.
    784785This nested type compiles in \CC and \CFA.
    785786\begin{cfa}
     
    808809In addition, a semi-non-compatible change is made so that Plan-9 syntax means a forward declaration in a nested type.
    809810Since the Plan-9 extension is not part of C and rarely used, this change has minimal impact.
    810 Hence, all Plan-9 semantics are denoted by the @inline@ qualifier, which is good ``eye-candy'' when reading a structure definition to spot Plan-9 definitions.
     811Hence, all Plan-9 semantics are denoted by the @inline@ qualifier, which clearly indicates the usage of Plan-9 definitions.
    811812Finally, the following code shows the value and pointer polymorphism.
    812813\begin{cfa}
     
    821822
    822823In general, non-standard C features (@gcc@) do not need any special treatment, as they are directly passed through to the C compiler.
    823 However, the Plan-9 semantics allow implicit conversions from the outer type to the inner type, which means the \CFA type resolver must take this information into account.
     824However, \PAB{I found} the Plan-9 semantics allow implicit conversions from the outer type to the inner type, which means the \CFA type resolver must take this information into account.
    824825Therefore, the \CFA resolver must implement the Plan-9 features and insert necessary type conversions into the translated code output.
    825826In the current version of \CFA, this is the only kind of implicit type conversion other than the standard C arithmetic conversions.
     
    847848\end{c++}
    848849and again the expression @d.x@ is ambiguous.
    849 While \CC has no direct syntax to disambiguate @x@, \ie @d.B.x@ or @d.C.x@, it is possible with casts, @((B)d).x@ or @((C)d).x@.
     850While \CC has no direct syntax to disambiguate @x@, \eg @d.B.x@ or @d.C.x@, it is possible with casts, @((B)d).x@ or @((C)d).x@.
    850851Like \CC, \CFA compiles the Plan-9 version and provides direct qualification and casts to disambiguate @x@.
    851 While ambiguous definitions are allowed, duplicate field names is poor practice and should be avoided if possible.
     852While ambiguous definitions are allowed, duplicate field names are poor practice and should be avoided if possible.
    852853However, when a programmer does not control all code, this problem can occur and a naming workaround must exist.
Note: See TracChangeset for help on using the changeset viewer.