Changeset a6af031


Ignore:
Timestamp:
Apr 3, 2017, 12:26:38 PM (5 years ago)
Author:
Thierry Delisle <tdelisle@…>
Branches:
aaron-thesis, arm-eh, cleanup-dtors, deferred_resn, demangler, jacob/cs343-translation, jenkins-sandbox, master, new-ast, new-ast-unique-expr, new-env, no_list, persistent-indexer, resolv-new, with_gc
Children:
221c2de
Parents:
727cf70 (diff), 7444113 (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

Files:
4 edited

Legend:

Unmodified
Added
Removed
  • doc/bibliography/cfa.bib

    r727cf70 ra6af031  
    860860}
    861861
    862 @manual{C11,
     862@techreport{C11,
     863    type = {International Standard},
    863864    keywords    = {ISO/IEC C 11},
    864865    contributer = {pabuhr@plg},
    865     key         = {C11},
     866    key         = {{ISO/IEC} 9889-2011},
    866867    title       = {American National Standard Information technology -- Programming Languages -- {C}},
    867     organization= {International Standard ISO/IEC 9899-2011[2012]},
    868     publisher   = {International Standard Organization},
     868    institution = {International Standard Organization},
    869869    address     = {http://www.iso.org},
    870870    year        = 2012,
    871871}
    872872
    873 @manual{C++Concepts,
     873@techreport{C++Concepts,
     874    type = {International Standard},
    874875    keywords    = {ISO/IEC TS 19217:2015},
    875876    contributer = {a3moss@uwaterloo.ca},
    876     key         = {C++ Concepts},
     877    key         = {{ISO/IEC} {TS} 19217},
    877878    title       = {Information technology -- Programming languages -- {C}{\kern-.1em\hbox{\large\texttt{+\kern-.25em+}}} Extensions for concepts},
    878     organization= {International Standard ISO/IEC TS 19217:2015},
    879     publisher   = {International Standard Organization},
     879    institution = {International Standard Organization},
    880880    address     = {http://www.iso.org},
    881881    year        = 2015
  • doc/generic_types/.gitignore

    r727cf70 ra6af031  
    1616*.lot
    1717*.synctex.gz
     18comment.cut
  • doc/generic_types/generic_types.tex

    r727cf70 ra6af031  
    2929\newcommand{\CCtwenty}{\rm C\kern-.1em\hbox{+\kern-.25em+}20\xspace} % C++20 symbolic name
    3030
    31 \newcommand{\TODO}{\textbf{TODO}}
     31\newcommand{\TODO}[1]{\textbf{TODO}: #1} % TODO included
     32%\newcommand{\TODO}[1]{} % TODO elided
    3233\newcommand{\eg}{\textit{e}.\textit{g}.,\xspace}
    3334\newcommand{\ie}{\textit{i}.\textit{e}.,\xspace}
     
    280281};
    281282\end{lstlisting}
    282 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 @sum@ function produces generated code something like the following (simplified for clarity and brevity) \TODO{} fix example, maybe elide, it's likely too long with the more complicated function:
     283Given 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 @sum@ function produces generated code something like the following (simplified for clarity and brevity)\TODO{fix example, maybe elide, it's likely too long with the more complicated function}:
    283284\begin{lstlisting}
    284285void abs( size_t _sizeof_M, size_t _alignof_M,
     
    629630  [int, [int, int], int] g();
    630631
    631   ([int, double])f();           // (1)
    632   ([int, int, int])g();         // (2)
    633   ([void, [int, int]])g();      // (3)
    634   ([int, int, int, int])g();    // (4)
    635   ([int, [int, int, int]])g();  // (5)
     632  ([int, double])f();           $\C{// (1)}$
     633  ([int, int, int])g();         $\C{// (2)}$
     634  ([void, [int, int]])g();      $\C{// (3)}$
     635  ([int, int, int, int])g();    $\C{// (4)}$
     636  ([int, [int, int, int]])g();  $\C{// (5)}$
    636637\end{lstlisting}
    637638
     
    766767In the call to @new@, @Pair(double, char)@ is selected to match @T@, and @Params@ is expanded to match @[double, char]@. The constructor (1) may be specialized to  satisfy the assertion for a constructor with an interface compatible with @void ?{}(Pair(int, char) *, int, char)@.
    767768
    768 \TODO{} Check if we actually can use ttype parameters on generic types (if they set the complete flag, it should work, or nearly so).
     769\TODO{Check if we actually can use ttype parameters on generic types (if they set the complete flag, it should work, or nearly so).}
    769770
    770771\subsection{Implementation}
     
    849850The various kinds of tuple assignment, constructors, and destructors generate GNU C statement expressions. A variable is generated to store the value produced by a statement expression, since its fields may need to be constructed with a non-trivial constructor and it may need to be referred to multiple time, \eg in a unique expression. The use of statement expressions allows the translator to arbitrarily generate additional temporary variables as needed, but binds the implementation to a non-standard extension of the C language. However, there are other places where the \CFA translator makes use of GNU C extensions, such as its use of nested functions, so this restriction is not new.
    850851
     852\section{Evaluation}
     853
     854\TODO{Magnus suggests we need some graphs, it's kind of a done thing that the reviewers will be looking for. Also, we've made some unsubstantiated claims about the runtime performance of \CFA, which some micro-benchmarks could help with. I'm thinking a simple stack push and pop, with an idiomatic \lstinline@void*@, \CFA, \CC template and \CC virtual inheritance versions (the void* and virtual inheritance versions likely need to be linked lists, or clumsy in their API -- possibly both versions) to test generics, and variadic print to test tuples. We measure SLOC, runtime performance, executable size (making sure to include benchmarks for multiple types in the executable), and possibly manually count the number of places where the programmer must provide un-type-checked type information. Appendices don't count against our page limit, so we might want to include the source code for the benchmarks (or at least the relevant implementation details) in one.}
     855
    851856\section{Related Work}
    852857
     
    855860Cyclone also provides capabilities for polymorphic functions and existential types~\citep{Grossman06}, similar in concept to \CFA's @forall@ functions and generic types. Cyclone existential types can include function pointers in a construct similar to a virtual function table, but these pointers must be explicitly initialized at some point in the code, a tedious and potentially error-prone process. Furthermore, Cyclone's polymorphic functions and types are restricted in that they may only abstract over types with the same layout and calling convention as @void*@, in practice only pointer types and @int@ - in \CFA terms, all Cyclone polymorphism must be dtype-static. This design provides the efficiency benefits discussed in Section~\ref{sec:generic-apps} for dtype-static polymorphism, but is more restrictive than \CFA's more general model.
    856861
    857 Go and Rust are both modern, compiled languages with abstraction features similar to \CFA traits, \emph{interfaces} in Go and \emph{traits} in Rust. However, both languages represent dramatic departures from C in terms of language model, and neither has the same level of compatibility with C as \CFA. Go is a garbage-collected language, imposing the associated runtime overhead, and complicating foreign-function calls with the necessity of accounting for data transfer between the managed Go runtime and the unmanaged C runtime. Furthermore, while generic types and functions are available in Go, they are limited to a small fixed set provided by the compiler, with no language facility to define more. Rust is not garbage-collected, and thus has a lighter-weight runtime that is more easily interoperable with C. It also possesses much more powerful abstraction capabilities for writing generic code than Go. On the other hand, Rust's borrow-checker, while it does provide strong safety guarantees, is complex and difficult to learn, and imposes a distinctly idiomatic programming style on Rust. \CFA, with its more modest safety features, is significantly easier to port C code to, while maintaining the idiomatic style of the original source.
     862Go \citep{Go} and Rust \citep{Rust} are both modern, compiled languages with abstraction features similar to \CFA traits, \emph{interfaces} in Go and \emph{traits} in Rust. However, both languages represent dramatic departures from C in terms of language model, and neither has the same level of compatibility with C as \CFA. Go is a garbage-collected language, imposing the associated runtime overhead, and complicating foreign-function calls with the necessity of accounting for data transfer between the managed Go runtime and the unmanaged C runtime. Furthermore, while generic types and functions are available in Go, they are limited to a small fixed set provided by the compiler, with no language facility to define more. Rust is not garbage-collected, and thus has a lighter-weight runtime that is more easily interoperable with C. It also possesses much more powerful abstraction capabilities for writing generic code than Go. On the other hand, Rust's borrow-checker, while it does provide strong safety guarantees, is complex and difficult to learn, and imposes a distinctly idiomatic programming style on Rust. \CFA, with its more modest safety features, is significantly easier to port C code to, while maintaining the idiomatic style of the original source.
    858863
    859864\section{Conclusion \& Future Work}
     
    862867
    863868\begin{acks}
     869The authors would like to thank Magnus Madsen for valuable editorial feedback.
     870
    864871This work is supported in part by a corporate partnership with \grantsponsor{Huawei}{Huawei Ltd.}{http://www.huawei.com}\ and the first author's \grantsponsor{NSERC-PGS}{NSERC PGS D}{http://www.nserc-crsng.gc.ca/Students-Etudiants/PG-CS/BellandPostgrad-BelletSuperieures_eng.asp} scholarship.
    865872\end{acks}
  • src/libcfa/startup.h

    r727cf70 ra6af031  
    1818#define STARTUP_H
    1919
     20#if GCC_VERSION > 50000
    2021extern "C" {
    2122        enum {
     
    2627        };
    2728}
     29#else
     30#define STARTUP_PRIORITY_CORE       101
     31#define STARTUP_PRIORITY_KERNEL     102
     32#define STARTUP_PRIORITY_MEMORY     103
     33#define STARTUP_PRIORITY_IOSTREAM   104
     34#endif
    2835
    2936#endif //STARTUP_H
Note: See TracChangeset for help on using the changeset viewer.