Changeset 9459c01
- Timestamp:
- Jul 4, 2018, 12:35:13 PM (6 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, no_list, persistent-indexer, pthread-emulation, qualifiedEnum
- Children:
- 6c0c52f
- Parents:
- bbe1a87
- Location:
- doc/papers
- Files:
-
- 1 added
- 3 edited
Legend:
- Unmodified
- Added
- Removed
-
doc/papers/AMA/AMA-stix/ama/WileyNJD-v2.cls
rbbe1a87 r9459c01 3406 3406 \hskip-\parindentvalue\fbox{\vbox{\noindent\@jnlcitation}}}% 3407 3407 3408 \AtEndDocument{\ifappendixsec\else\printjnlcitation\fi}%3408 %\AtEndDocument{\ifappendixsec\else\printjnlcitation\fi}% 3409 3409 3410 3410 %% Misc math macros %% -
doc/papers/general/Makefile
rbbe1a87 r9459c01 46 46 47 47 Paper.zip : 48 zip -x general/.gitignore -x general/"*AMA*" -x general/Paper.out.ps -x general/Paper.tex.plain -x general/evaluation.zip -x general/mail -x general/response -x general/test.c -x general/evaluation.zip -x general/Paper.tex.plain -x general/Paper.ps -x general/Paper.pdf -x general/"*build*" -x general/evaluation/.gitignore -x general/evaluation/timing.xlsx -r Paper.zip general 48 zip -x general/.gitignore -x general/Paper.out.ps -x general/Paper.tex.plain -x -x general/WileyNJD-AMA.bst general/"*evaluation*" -x general/evaluation.zip \ 49 -x general/mail -x general/response -x general/test.c -x general/Paper.ps -x general/"*build*" -r Paper.zip general pl.bib 49 50 50 51 evaluation.zip : 51 zip -x evaluation/.gitignore 52 zip -x evaluation/.gitignore -x evaluation/timing.xlsx -x evaluation/timing.dat -r evaluation.zip evaluation 52 53 53 54 # File Dependencies # -
doc/papers/general/Paper.tex
rbbe1a87 r9459c01 210 210 Specifically, \CFA is designed to have an orthogonal feature-set based closely on the C programming paradigm, so that \CFA features can be added \emph{incrementally} to existing C code-bases, and C programmers can learn \CFA extensions on an as-needed basis, preserving investment in existing code and programmers. 211 211 This paper presents a quick tour of \CFA features showing how their design avoids shortcomings of similar features in C and other C-like languages. 212 Finally, experimental results are presented to validate several of the new features.212 Experimental results are presented to validate several of the new features. 213 213 }% 214 214 … … 255 255 Not discussed in this paper are the integrated concurrency-constructs and user-level threading-library~\cite{Delisle18}. 256 256 \CFA is an \emph{open-source} project implemented as a source-to-source translator from \CFA to the gcc-dialect of C~\cite{GCCExtensions}, allowing it to leverage the portability and code optimizations provided by gcc, meeting goals (1)--(3). 257 Ultimately, a compiler is necessary for advanced features and optimal performance.258 257 % @plg2[9]% cd cfa-cc/src; cloc ArgTweak CodeGen CodeTools Common Concurrency ControlStruct Designators GenPoly InitTweak MakeLibCfa.cc MakeLibCfa.h Parser ResolvExpr SymTab SynTree Tuples driver prelude main.cc 259 258 % ------------------------------------------------------------------------------- … … 271 270 % ------------------------------------------------------------------------------- 272 271 The \CFA translator is 200+ files and 46,000+ lines of code written in C/\CC. 273 Starting with a translator versus a compiler makes it easier and faster to generate and debug C object-code rather than intermediate, assembler or machine code. 274 The translator design is based on the \emph{visitor pattern}, allowing multiple passes over the abstract code-tree, which works well for incrementally adding new feature through additional visitor passes. 275 At the heart of the translator is the type resolver, which handles the polymorphic function/type overload-resolution. 272 A translator versus a compiler makes it easier and faster to generate and debug C object-code rather than intermediate, assembler or machine code; 273 ultimately, a compiler is necessary for advanced features and optimal performance. 274 % The translator design is based on the \emph{visitor pattern}, allowing multiple passes over the abstract code-tree, which works well for incrementally adding new feature through additional visitor passes. 275 Two key translator components are expression analysis, determining expression validity and what operations are required for its implementation, and code generation, dealing with multiple forms of overloading, polymorphism, and multiple return values by converting them into C code for a C compiler that supports none of these features. 276 Details of these components are available in Bilson~\cite{Bilson03} Chapters 2 and 3, and form the base for the current \CFA translator. 276 277 % @plg2[8]% cd cfa-cc/src; cloc libcfa 277 278 % ------------------------------------------------------------------------------- … … 305 306 % SUM: 290 13175 3400 27776 306 307 % ------------------------------------------------------------------------------- 307 The \CFA tests are 290+ files and 27,000+ lines of code. 308 The tests illustrate syntactic and semantic features in \CFA, plus a growing number of runtime benchmarks. 309 The tests check for correctness and are used for daily regression testing of 3800+ commits. 310 311 Finally, it is impossible to describe a programming language without usages before definitions. 312 Therefore, syntax and semantics appear before explanations, and related work (Section~\ref{s:RelatedWork}) is deferred until \CFA is presented; 313 hence, patience is necessary until details are discussed. 308 % The \CFA tests are 290+ files and 27,000+ lines of code. 309 % The tests illustrate syntactic and semantic features in \CFA, plus a growing number of runtime benchmarks. 310 % The tests check for correctness and are used for daily regression testing of 3800+ commits. 311 312 Finally, it is impossible to describe a programming language without usage before definition. 313 Therefore, syntax and semantics appear before explanations; 314 hence, patience is necessary until sufficient details are presented and discussed. 315 Similarly, a detailed comparison with other programming languages is postponed until Section~\ref{s:RelatedWork}. 314 316 315 317 … … 1872 1874 \begin{itemize} 1873 1875 \item 1874 if @R@ is an rvalue of type {@T &@$_1 \cdots$@ &@$_r$} where $r \ge 1$ references (@&@ symbols) then @&R@ has type {@T `*`&@$_{\color{red}2} \cdots$@ &@$_{\color{red}r}$}, \\ \ie @T@ pointer with $r-1$ references (@&@ symbols). 1875 1876 if @R@ is an rvalue of type @T &@$_1\cdots$ @&@$_r$, where $r \ge 1$ references (@&@ symbols), than @&R@ has type @T `*`&@$_{\color{red}2}\cdots$ @&@$_{\color{red}r}$, \ie @T@ pointer with $r-1$ references (@&@ symbols). 1876 1877 \item 1877 if @L@ is an lvalue of type {@T &@$_1 \cdots$@ &@$_l$} where $l \ge 0$ references (@&@ symbols) then @&L@ has type {@T `*`&@$_{\color{red}1} \cdots$@ &@$_{\color{red}l}$}, \\\ie @T@ pointer with $l$ references (@&@ symbols).1878 if @L@ is an lvalue of type @T &@$_1\cdots$ @&@$_l$, where $l \ge 0$ references (@&@ symbols), than @&L@ has type @T `*`&@$_{\color{red}1}\cdots$ @&@$_{\color{red}l}$, \ie @T@ pointer with $l$ references (@&@ symbols). 1878 1879 \end{itemize} 1879 1880 Since pointers and references share the same internal representation, code using either is equally performant; in fact the \CFA compiler converts references to pointers internally, and the choice between them is made solely on convenience, \eg many pointer or value accesses. … … 2834 2835 Finally, we demonstrate that \CFA performance for some idiomatic cases is better than C and close to \CC, showing the design is practically applicable. 2835 2836 2836 While all examples in the paper compile and run, a public beta-release of \CFA will take 6--8 months to reduce compilation time, provide better debugging, and add a few more libraries. 2837 While all examples in the paper compile and run, there are ongoing efforts to reduce compilation time, provide better debugging, and add more libraries; 2838 when this work is complete in early 2019, a public beta release will be available at \url{https://github.com/cforall/cforall}. 2837 2839 There is also new work on a number of \CFA features, including arrays with size, runtime type-information, virtual functions, user-defined conversions, and modules. 2838 2840 While \CFA polymorphic functions use dynamic virtual-dispatch with low runtime overhead (see Section~\ref{sec:eval}), it is not as low as \CC template-inlining. 2839 2841 Hence it may be beneficial to provide a mechanism for performance-sensitive code. 2840 2842 Two promising approaches are an @inline@ annotation at polymorphic function call sites to create a template-specialization of the function (provided the code is visible) or placing an @inline@ annotation on polymorphic function-definitions to instantiate a specialized version for some set of types (\CC template specialization). 2841 These approaches are not mutually exclusive and allow performance optimizations to be applied only when necessary, without suffering global code-bloat.2843 These approaches are not mutually exclusive and allow performance optimizations to be applied only when necessary, without suffering global code-bloat. 2842 2844 In general, we believe separate compilation, producing smaller code, works well with loaded hardware-caches, which may offset the benefit of larger inlined-code. 2843 2845 … … 2850 2852 {% 2851 2853 \fontsize{9bp}{12bp}\selectfont% 2854 \vspace*{-3pt} 2852 2855 \bibliography{pl} 2853 2856 }%
Note: See TracChangeset
for help on using the changeset viewer.