- Timestamp:
- Apr 3, 2017, 12:00:58 PM (8 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:
- 7444113
- Parents:
- 1d29d46
- Location:
- doc
- Files:
-
- 3 edited
Legend:
- Unmodified
- Added
- Removed
-
doc/bibliography/cfa.bib
r1d29d46 r5995116 860 860 } 861 861 862 @manual{C11, 862 @techreport{C11, 863 type = {International Standard}, 863 864 keywords = {ISO/IEC C 11}, 864 865 contributer = {pabuhr@plg}, 865 key = { C11},866 key = {{ISO/IEC} 9889-2011}, 866 867 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}, 869 869 address = {http://www.iso.org}, 870 870 year = 2012, 871 871 } 872 872 873 @manual{C++Concepts, 873 @techreport{C++Concepts, 874 type = {International Standard}, 874 875 keywords = {ISO/IEC TS 19217:2015}, 875 876 contributer = {a3moss@uwaterloo.ca}, 876 key = { C++ Concepts},877 key = {{ISO/IEC} {TS} 19217}, 877 878 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}, 880 880 address = {http://www.iso.org}, 881 881 year = 2015 -
doc/generic_types/.gitignore
r1d29d46 r5995116 16 16 *.lot 17 17 *.synctex.gz 18 comment.cut -
doc/generic_types/generic_types.tex
r1d29d46 r5995116 29 29 \newcommand{\CCtwenty}{\rm C\kern-.1em\hbox{+\kern-.25em+}20\xspace} % C++20 symbolic name 30 30 31 \newcommand{\TODO}{\textbf{TODO}} 31 \newcommand{\TODO}[1]{\textbf{TODO}: #1} % TODO included 32 %\newcommand{\TODO}[1]{} % TODO elided 32 33 \newcommand{\eg}{\textit{e}.\textit{g}.,\xspace} 33 34 \newcommand{\ie}{\textit{i}.\textit{e}.,\xspace} … … 280 281 }; 281 282 \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:283 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}: 283 284 \begin{lstlisting} 284 285 void abs( size_t _sizeof_M, size_t _alignof_M, … … 629 630 [int, [int, int], int] g(); 630 631 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)}$ 636 637 \end{lstlisting} 637 638 … … 766 767 In 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)@. 767 768 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).} 769 770 770 771 \subsection{Implementation} … … 849 850 The 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. 850 851 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 851 856 \section{Related Work} 852 857 … … 855 860 Cyclone 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. 856 861 857 Go and Rustare 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.862 Go \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. 858 863 859 864 \section{Conclusion \& Future Work} … … 862 867 863 868 \begin{acks} 869 The authors would like to thank Magnus Madsen for valuable editorial feedback. 870 864 871 This 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. 865 872 \end{acks}
Note: See TracChangeset
for help on using the changeset viewer.