Changeset 9459c01 for doc/papers

Timestamp:

Jul 4, 2018, 12:35:13 PM (6 years ago)

Author:

Peter A. Buhr <pabuhr@…>

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

Message:

final production copy

Location:

doc/papers

Files:

• AMA/AMA-stix/ama/WileyNJD-v2.cls (modified) (1 diff)
• general/Makefile (modified) (1 diff)
• general/Paper.tex (modified) (7 diffs)
• general/fig.tex (added)

doc/papers/AMA/AMA-stix/ama/WileyNJD-v2.cls

@@ -3406 +3406 @@
 \hskip-\parindentvalue\fbox{\vbox{\noindent\@jnlcitation}}}%
 
-\AtEndDocument{\ifappendixsec\else\printjnlcitation\fi}%
+%\AtEndDocument{\ifappendixsec\else\printjnlcitation\fi}%
 
 %% Misc math macros %%

doc/papers/general/Makefile

@@ -46 +46 @@
 
 Paper.zip :
-        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
+        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 \
+                -x general/mail -x general/response -x general/test.c -x general/Paper.ps -x general/"*build*" -r Paper.zip general pl.bib
 
 evaluation.zip :
-        zip -x evaluation/.gitignore  -x evaluation/timing.xlsx -x evaluation/timing.dat -r evaluation.zip evaluation
+        zip -x evaluation/.gitignore -x evaluation/timing.xlsx -x evaluation/timing.dat -r evaluation.zip evaluation
 
 # File Dependencies #

doc/papers/general/Paper.tex

@@ -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.
 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.
-Finally, experimental results are presented to validate several of the new features.
+Experimental results are presented to validate several of the new features.
 }%
 
@@ -255 +255 @@
 Not discussed in this paper are the integrated concurrency-constructs and user-level threading-library~\cite{Delisle18}.
 \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).
-Ultimately, a compiler is necessary for advanced features and optimal performance.
 % @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 
 % -------------------------------------------------------------------------------
@@ -271 +270 @@
 % -------------------------------------------------------------------------------
 The \CFA translator is 200+ files and 46,000+ lines of code written in C/\CC.
-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.
-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.
-At the heart of the translator is the type resolver, which handles the polymorphic function/type overload-resolution.
+A translator versus a compiler makes it easier and faster to generate and debug C object-code rather than intermediate, assembler or machine code;
+ultimately, a compiler is necessary for advanced features and optimal performance.
+% 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.
+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.
+Details of these components are available in Bilson~\cite{Bilson03} Chapters 2 and 3, and form the base for the current \CFA translator.
 % @plg2[8]% cd cfa-cc/src; cloc libcfa
 % -------------------------------------------------------------------------------
@@ -305 +306 @@
 % SUM:                           290          13175           3400          27776
 % -------------------------------------------------------------------------------
-The \CFA tests are 290+ files and 27,000+ lines of code.
-The tests illustrate syntactic and semantic features in \CFA, plus a growing number of runtime benchmarks.
-The tests check for correctness and are used for daily regression testing of 3800+ commits.
-
-Finally, it is impossible to describe a programming language without usages before definitions.
-Therefore, syntax and semantics appear before explanations, and related work (Section~\ref{s:RelatedWork}) is deferred until \CFA is presented;
-hence, patience is necessary until details are discussed.
+% The \CFA tests are 290+ files and 27,000+ lines of code.
+% The tests illustrate syntactic and semantic features in \CFA, plus a growing number of runtime benchmarks.
+% The tests check for correctness and are used for daily regression testing of 3800+ commits.
+
+Finally, it is impossible to describe a programming language without usage before definition.
+Therefore, syntax and semantics appear before explanations;
+hence, patience is necessary until sufficient details are presented and discussed.
+Similarly, a detailed comparison with other programming languages is postponed until Section~\ref{s:RelatedWork}.
 
 
@@ -1872 +1874 @@
 \begin{itemize}
 \item
-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).
-        
+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).
 \item
-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).
+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).
 \end{itemize}
 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.
 
-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.
+While all examples in the paper compile and run, there are ongoing efforts to reduce compilation time, provide better debugging, and add more libraries;
+when this work is complete in early 2019, a public beta release will be available at \url{https://github.com/cforall/cforall}.
 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.
 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.
 Hence it may be beneficial to provide a mechanism for performance-sensitive code.
 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).
-These approaches are not mutually exclusive and allow performance optimizations to be applied only when necessary, without suffering global code-bloat.
+ These approaches are not mutually exclusive and allow performance optimizations to be applied only when necessary, without suffering global code-bloat.
 In general, we believe separate compilation, producing smaller code, works well with loaded hardware-caches, which may offset the benefit of larger inlined-code.
 
@@ -2850 +2852 @@
 {%
 \fontsize{9bp}{12bp}\selectfont%
+\vspace*{-3pt}
 \bibliography{pl}
 }%