Changes in doc/user/user.tex [9724df0:45576af9]

File:

• doc/user/user.tex (modified) (12 diffs)

doc/user/user.tex

@@ -11 +11 @@
 %% Created On       : Wed Apr  6 14:53:29 2016
 %% Last Modified By : Peter A. Buhr
-%% Last Modified On : Mon Jun 20 10:47:22 2016
-%% Update Count     : 575
+%% Last Modified On : Fri Jun 10 16:38:22 2016
+%% Update Count     : 394
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 
@@ -21 +21 @@
 % blue highlighting ß...ß (sharp s symbol) emacs: C-q M-_
 % green highlighting ¢...¢ (cent symbol) emacs: C-q M-"
-% LaTex escape §...§ (section symbol) emacs: C-q M-'
+% Latex escape §...§ (section symbol) emacs: C-q M-'
 % keyword escape ¶...¶ (pilcrow symbol) emacs: C-q M-^
 % math escape $...$ (dollar symbol)
 
 \documentclass[twoside,11pt]{article}
-
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 
@@ -35 +34 @@
 \usepackage{fullpage,times,comment}
 \usepackage{epic,eepic}
-\usepackage{upquote}                                                                    % switch curled `'" to straight
+\usepackage{upquote}                                                                    % switch curled `'" to straight `'"
 \usepackage{xspace}
 \usepackage{varioref}                                                                   % extended references
@@ -50 +49 @@
 \renewcommand{\UrlFont}{\small\sf}
 
-\makeatletter
-\renewcommand{\pagestyle}[1]{
-  \@ifundefined{ps@#1}%
-    \undefinedpagestyle
-    {\def\@tempa{#1}\def\@tempb{headings}\def\@tempc{myheadings}%
-     \ifx\@tempa\@tempb\setlength{\topmargin}{-0.25in}\setlength{\headsep}{0.25in}%
-     \else\ifx\@tempa\@tempc\setlength{\topmargin}{-0.25in}\setlength{\headsep}{0.25in}\fi\fi%
-     \@nameuse{ps@#1}}}% pagestyle
-\makeatother
-
-
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-
 % Names used in the document.
 
@@ -74 +60 @@
 \newcommand{\G}[1]{{\Textbf[OliveGreen]{#1}}}
 
-\newsavebox{\LstBox}
-
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 
@@ -83 +67 @@
 
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+\begin{document}
+\pagestyle{headings}
+\linenumbers                                            % comment out to turn off line numbering
 
 \title{\Huge
@@ -89 +77 @@
 Version 1.0                                                     \\
 \vspace*{0.25in}
-\huge``describe not prescribe''
+\huge``describe not prescribe''         \\
 \vspace*{1in}
 }% title
-
 \author{\huge
-Peter A. Buhr and ...
+Peter A. Buhr and ...                           \\
 }% author
-
 \date{
-DRAFT \\ \today
+DRAFT \\
+\today
 }% date
 
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-
-\begin{document}
-\pagestyle{headings}
 \pagenumbering{roman}
-\linenumbers                                            % comment out to turn off line numbering
+\pagestyle{plain}
 
 \maketitle
@@ -124 +107 @@
 
 \clearpage
-\markright{\CFA User Manual}
 \pagenumbering{arabic}
 
@@ -489 +471 @@
 \end{quote2}
 
-Unsupported are K\&R C declarations where the base type defaults to ©int©, if no type is specified,\footnote{
-At least one type specifier shall be given in the declaration specifiers in each declaration, and in the specifier-qualifier list in each structure declaration and type name~\cite[\S~6.7.2(2)]{C11}}
+Unsupported are K\&R C declarations where the base type defaults to ©int©, if no type is specified\footnote{
+At least one type specifier shall be given in the declaration specifiers in each declaration, and in the specifier-qualifier list in each structure declaration and type name~\cite[\S~6.7.2(2)]{C11}},
 e.g.:
 \begin{lstlisting}
@@ -503 +485 @@
 Clearly, both styles need to be supported for some time due to existing C-style header-files, particularly for UNIX systems.
 
-
-\section{Reference Pointers}
-
-Program variables are implicit pointers to memory locations generated by the compiler and automatically dereferenced, as in:
-\begin{quote2}
-\begin{tabular}{@{}l|l@{}}
-\multicolumn{1}{c|}{Variables} & \multicolumn{1}{c}{Compiler generated addresses (100, 104) and dereferencing} \\
-\hline
-\begin{lstlisting}
-int x, y;
-x = 3;
-y = x;
-\end{lstlisting}
-&
-\begin{lstlisting}
-int * const x = (int *)100, * const y = (int *)104;
-*x = 3;         // implicit dereference
-*y = *x;
-\end{lstlisting}
-\end{tabular}
-\end{quote2}
-A variable name only points to one location during its lifetime, i.e., it is a \Index{non-mutable} pointer.
-For example, the variables ©x© and ©y© are constant pointers.
-Variable addresses are usually not stored in memory and loaded before dereferencing;
-instead, variable addresses are stored in instructions, so an instruction fetch implicitly gets the variable's address.
-\begin{quote2}
-\begin{tabular}{@{}l|l@{}}
-\begin{lstlisting}
-x = x + 1
-&x = *(&x) + 1
-(100) = *(100) + 1
-\end{lstlisting}
-&
-\begin{lstlisting}
-ld              r1,(100)                        // address of x
-add             r1,1
-st              r1,(100)                        // address of x
-\end{lstlisting}
-\end{tabular}
-\end{quote2}
-Finally, the non-mutable nature of variables and the fact that there is no storage for a variable address means pointer assignment is impossible.
-Therefore, the expression ©x = y© only has one meaning, ©*x = *y©, i.e., copy the variable values, so explicitly writing the dereferences is unnecessary even though it occurs implicitly as part of instruction decoding.
-
-A variable name is generalized by a \newterm{pointer}, which is a mutable pointer variable that can point to more than one memory location during its life-time (like an integer variable versus a literal).
-Hence, a pointer occupies memory to store its current address, and the pointer's value is loaded by dereferencing, e.g.:
-\begin{lstlisting}
-int x, y, z, ®*® p1, ®*® p2;
-p1 = ®&®x;                                      // p1 points to x
-p2 = p1;                                        // p2 also points to x
-p1 = ®&®y;                                      // p1 points to y
-p2 = p1 + 1;                            // p2 points to z, pointer arithmetic
-\end{lstlisting}
-In many cases, a pointer name is anonymous (dynamically computed), so it cannot be stored directly in an instruction like a variable name.
-
-Pointers have a duality: an address in memory or the value at that address.
-In many cases, the compiler can infer which of these operations are needed:
-\begin{lstlisting}
-p2 = p1 + x;                            // compiler infers *p2 = *p1 + x;
-\end{lstlisting}
-because adding the integer value of ©x© to the address of ©p1© and storing the resulting address into ©p2© is an unlikely operation.
-Algol68~\cite{Algol68} inferences pointer dereferencing to select the best meaning for each pointer usage.
-However, there are ambiguous cases, especially when pointer arithmetic is possible, as in C:
-\begin{lstlisting}
-p1 = p2;                                        // p1 = p2 or *p1 = *p2
-p1 = p1 + 1;                            // p1 = p1 + 1 or *p1 = *p1 + 1
-\end{lstlisting}
-
-Most programming languages pick a default operation and supply an explicit operation to resolve the pointer-duality ambiguity.
-In C, the default operation for pointers is manipulate the pointer value and the pointed-to value is explicitly accessed by dereferencing ©*©.
-\begin{lstlisting}
-p1 = p2;                                        // pointer value assignment
-*p1 = *p1 + 1;                          // pointed-to value assignment/operation
-\end{lstlisting}
-which works well for low-level memory management, such as ©malloc©/©free©, where manipulation of addresses in the primary operation, and data is only occasionally accessed.
-
-However, in the majority of pointer usages, the pointed-to value is required rather than the pointer address.
-\begin{lstlisting}
-*p2 = ((*p1 + *p2) * (*p2 - *p1)) / (*p1 - *p2);
-\end{lstlisting}
-And, it is tedious and error prone to explicitly write the dereferencing, especially when pointer arithmetic with integer values is allowed.
-It is better to have the compiler generate the dereferencing:
-\begin{lstlisting}
-p2 = ((p1 + p2) * (p2 - p1)) / (p1 - p2);
-\end{lstlisting}
-
-To provide this capability, it is necessary to switch the default operation to resolve the pointer-duality ambiguity, which requires a new kind of pointer called a \newterm{reference} pointer.
-\begin{lstlisting}
-int x, y, z, ®&® r1, ®&® r2;    // & denotes reference pointer
-r1 ®:=® &x;                                     // r1 points to x
-r2 ®:=® &r1;                                    // r2 also points to x
-r1 ®:=® &y;                                     // r1 points to y
-r2 ®:=® &r1 + 1;                                // r2 points to z
-r2 = ((r1 + r2) * (r2 - r1)) / (r1 - r2); // implicit dereferencing
-\end{lstlisting}
-Hence, a reference pointer behaves like a variable name for the current variable it is pointing-to, so dereferencing a reference pointer returns the address of its pointed-to value, i.e., the address in the reference pointer.
-Notice, the explicit operator ©:=© to denote pointer assignment to a reference pointer to support both aspects of pointer duality.
-Note, \CC deals with the pointer duality by making a reference pointer a constant (©const©), like a plain variable, so there is no reference assignment.
-
-Like pointers, it is possible to use ©const© qualifiers with a reference:
-\begin{lstlisting}
-const int cx = 5;                       // cannot change cx;
-const int & r3 = &cx;           // cannot change what r3 is pointing to
-r3 ®:=® &cx;                                    // can change r3
-r3 = 7;                                         // error, cannot change cx
-int & const r4 = &x;            // must be initialized, §\CC§ reference
-r4 ®:=® &x;                                     // error, cannot change r4
-const int & const r5 = &cx;     // must be initialized, §\CC§ reference
-r5 = 7;                                         // error, cannot change cx
-r5 ®:=® &cx;                                    // error, cannot change r5
-\end{lstlisting}
-Note, for type ©& const©, there is no pointer assignment, so ©r4 := &x© is disallowed, and the pointer value cannot be ©0©.
-Since there is only one meaning for ©r4 = x©, which is to change the value of the variable pointed to by ©r4©, therefore:
-\begin{itemize}
-\item
-it in impossible to take the address of ©r4© as it always means the address of what ©r4© is pointing to.
-\item
-the dereference at initialization is optional because there can only be one
-\begin{lrbox}{\LstBox}%
-\footnotesize%
-\begin{lstlisting}%
-void f( int p ) {...}
-void (*fp)( int ) = &f;         // equivalent initialization
-void (*fp)( int ) = f;          // missing dereference allowed
-\end{lstlisting}%
-\end{lrbox}%
-meaning.\footnote{
-This case is similar to initializing a routine pointer, where the routine constant should be dereferenced.
-\newline
-\usebox{\LstBox}
-}% footnote
-\begin{lstlisting}
-int & const r4 = &x;            // equivalent initialization
-int & const r4 = x;                     // missing dereference allowed
-\end{lstlisting}
-\end{itemize}
-Similarly, when a ©const© reference is used for a parameters type, the call-site argument does not require a reference.
-\begin{lstlisting}
-void f( int & ri, int & const cri );
-f( &x, x );                                     // reference not required for second argument
-\end{lstlisting}
-Within routine ©f©, it is possible to change an argument by changing the corresponding parameter, and parameter ©ri© can be locally reassigned within ©f©.
-
-Finally, when a reference parameter has a ©const© value, it is possible to pass literals and expressions.
-\begin{lstlisting}
-void g( const int & ri, const int & const cri );
-f( &3, 3 );
-f( &(x + y), x + y );
-\end{lstlisting}
-At the call site, the compiler implicitly creates the necessary temporary that is subsequently pointed to by the reference parameter.
-Hence, changing the parameter only changes the temporary at the call site.
-For the non-©const© parameter, requiring the reference on the literal or expression makes it clear that nothing is changing at the call site and allows the call to proceed, where other languages require the programmer to explicitly create the temporary for the argument.
 
 \section{Type Operators}
@@ -977 +808 @@
 \subsection{Type Nesting}
 
-\CFA allows \Index{type nesting}, and type qualification of the nested types (see \VRef[Figure]{f:TypeNestingQualification}), where as C hoists\index{type hoisting} (refactors) nested types into the enclosing scope and has no type qualification.
-\begin{figure}
+\CFA allows \Index{type nesting}, and type qualification of the nested types, where as C hoists\index{type hoisting} (refactors) nested types into the enclosing scope and has no type qualification.
+\begin{quote2}
 \begin{tabular}{@{}l@{\hspace{3em}}l|l@{}}
 \multicolumn{1}{c@{\hspace{3em}}}{\textbf{C Type Nesting}}      & \multicolumn{1}{c}{\textbf{C Implicit Hoisting}}      & \multicolumn{1}{|c}{\textbf{\CFA}}    \\
@@ -1039 +870 @@
 \end{lstlisting}
 \end{tabular}
-\caption{Type Nesting / Qualification}
-\label{f:TypeNestingQualification}
-\end{figure}
+\end{quote2}
 In the left example in C, types ©C©, ©U© and ©T© are implicitly hoisted outside of type ©S© into the containing block scope.
 In the right example in \CFA, the types are not hoisted and accessed using the field-selection operator ``©.©'' for type qualification, as does Java, rather than the \CC type-selection operator ``©::©''.