Changeset 9724df0 for doc/user/user.tex


Ignore:
Timestamp:
Jun 20, 2016, 10:52:40 AM (8 years ago)
Author:
Peter A. Buhr <pabuhr@…>
Branches:
ADT, aaron-thesis, arm-eh, ast-experimental, cleanup-dtors, ctor, deferred_resn, demangler, enum, forall-pointer-decay, gc_noraii, jacob/cs343-translation, jenkins-sandbox, master, memory, new-ast, new-ast-unique-expr, new-env, no_list, persistent-indexer, pthread-emulation, qualifiedEnum, resolv-new, with_gc
Children:
1f17e07, a0dcd2e, f6d4204
Parents:
1da317b
Message:

update latex macros, and user and refrat manuals

File:
1 edited

Legend:

Unmodified
Added
Removed
  • doc/user/user.tex

    r1da317b r9724df0  
    1111%% Created On       : Wed Apr  6 14:53:29 2016
    1212%% Last Modified By : Peter A. Buhr
    13 %% Last Modified On : Fri Jun 10 16:38:22 2016
    14 %% Update Count     : 394
     13%% Last Modified On : Mon Jun 20 10:47:22 2016
     14%% Update Count     : 575
    1515%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
    1616
     
    2121% blue highlighting ß...ß (sharp s symbol) emacs: C-q M-_
    2222% green highlighting ¢...¢ (cent symbol) emacs: C-q M-"
    23 % Latex escape §...§ (section symbol) emacs: C-q M-'
     23% LaTex escape §...§ (section symbol) emacs: C-q M-'
    2424% keyword escape ¶...¶ (pilcrow symbol) emacs: C-q M-^
    2525% math escape $...$ (dollar symbol)
    2626
    2727\documentclass[twoside,11pt]{article}
     28
    2829%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
    2930
     
    3435\usepackage{fullpage,times,comment}
    3536\usepackage{epic,eepic}
    36 \usepackage{upquote}                                                                    % switch curled `'" to straight `'"
     37\usepackage{upquote}                                                                    % switch curled `'" to straight
    3738\usepackage{xspace}
    3839\usepackage{varioref}                                                                   % extended references
     
    4950\renewcommand{\UrlFont}{\small\sf}
    5051
     52\makeatletter
     53\renewcommand{\pagestyle}[1]{
     54  \@ifundefined{ps@#1}%
     55    \undefinedpagestyle
     56    {\def\@tempa{#1}\def\@tempb{headings}\def\@tempc{myheadings}%
     57     \ifx\@tempa\@tempb\setlength{\topmargin}{-0.25in}\setlength{\headsep}{0.25in}%
     58     \else\ifx\@tempa\@tempc\setlength{\topmargin}{-0.25in}\setlength{\headsep}{0.25in}\fi\fi%
     59     \@nameuse{ps@#1}}}% pagestyle
     60\makeatother
     61
     62
     63%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
     64
    5165% Names used in the document.
    5266
     
    6074\newcommand{\G}[1]{{\Textbf[OliveGreen]{#1}}}
    6175
     76\newsavebox{\LstBox}
     77
    6278%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
    6379
     
    6783
    6884%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
    69 
    70 \begin{document}
    71 \pagestyle{headings}
    72 \linenumbers                                            % comment out to turn off line numbering
    7385
    7486\title{\Huge
     
    7789Version 1.0                                                     \\
    7890\vspace*{0.25in}
    79 \huge``describe not prescribe''         \\
     91\huge``describe not prescribe''
    8092\vspace*{1in}
    8193}% title
     94
    8295\author{\huge
    83 Peter A. Buhr and ...                           \\
     96Peter A. Buhr and ...
    8497}% author
     98
    8599\date{
    86 DRAFT \\
    87 \today
     100DRAFT \\ \today
    88101}% date
    89102
     103%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
     104
     105\begin{document}
     106\pagestyle{headings}
    90107\pagenumbering{roman}
    91 \pagestyle{plain}
     108\linenumbers                                            % comment out to turn off line numbering
    92109
    93110\maketitle
     
    107124
    108125\clearpage
     126\markright{\CFA User Manual}
    109127\pagenumbering{arabic}
    110128
     
    471489\end{quote2}
    472490
    473 Unsupported are K\&R C declarations where the base type defaults to ©int©, if no type is specified\footnote{
    474 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}},
     491Unsupported are K\&R C declarations where the base type defaults to ©int©, if no type is specified,\footnote{
     492At 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}}
    475493e.g.:
    476494\begin{lstlisting}
     
    485503Clearly, both styles need to be supported for some time due to existing C-style header-files, particularly for UNIX systems.
    486504
     505
     506\section{Reference Pointers}
     507
     508Program variables are implicit pointers to memory locations generated by the compiler and automatically dereferenced, as in:
     509\begin{quote2}
     510\begin{tabular}{@{}l|l@{}}
     511\multicolumn{1}{c|}{Variables} & \multicolumn{1}{c}{Compiler generated addresses (100, 104) and dereferencing} \\
     512\hline
     513\begin{lstlisting}
     514int x, y;
     515x = 3;
     516y = x;
     517\end{lstlisting}
     518&
     519\begin{lstlisting}
     520int * const x = (int *)100, * const y = (int *)104;
     521*x = 3;         // implicit dereference
     522*y = *x;
     523\end{lstlisting}
     524\end{tabular}
     525\end{quote2}
     526A variable name only points to one location during its lifetime, i.e., it is a \Index{non-mutable} pointer.
     527For example, the variables ©x© and ©y© are constant pointers.
     528Variable addresses are usually not stored in memory and loaded before dereferencing;
     529instead, variable addresses are stored in instructions, so an instruction fetch implicitly gets the variable's address.
     530\begin{quote2}
     531\begin{tabular}{@{}l|l@{}}
     532\begin{lstlisting}
     533x = x + 1
     534&x = *(&x) + 1
     535(100) = *(100) + 1
     536\end{lstlisting}
     537&
     538\begin{lstlisting}
     539ld              r1,(100)                        // address of x
     540add             r1,1
     541st              r1,(100)                        // address of x
     542\end{lstlisting}
     543\end{tabular}
     544\end{quote2}
     545Finally, the non-mutable nature of variables and the fact that there is no storage for a variable address means pointer assignment is impossible.
     546Therefore, 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.
     547
     548A 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).
     549Hence, a pointer occupies memory to store its current address, and the pointer's value is loaded by dereferencing, e.g.:
     550\begin{lstlisting}
     551int x, y, z, ®*® p1, ®*® p2;
     552p1 = ®&®x;                                      // p1 points to x
     553p2 = p1;                                        // p2 also points to x
     554p1 = ®&®y;                                      // p1 points to y
     555p2 = p1 + 1;                            // p2 points to z, pointer arithmetic
     556\end{lstlisting}
     557In many cases, a pointer name is anonymous (dynamically computed), so it cannot be stored directly in an instruction like a variable name.
     558
     559Pointers have a duality: an address in memory or the value at that address.
     560In many cases, the compiler can infer which of these operations are needed:
     561\begin{lstlisting}
     562p2 = p1 + x;                            // compiler infers *p2 = *p1 + x;
     563\end{lstlisting}
     564because adding the integer value of ©x© to the address of ©p1© and storing the resulting address into ©p2© is an unlikely operation.
     565Algol68~\cite{Algol68} inferences pointer dereferencing to select the best meaning for each pointer usage.
     566However, there are ambiguous cases, especially when pointer arithmetic is possible, as in C:
     567\begin{lstlisting}
     568p1 = p2;                                        // p1 = p2 or *p1 = *p2
     569p1 = p1 + 1;                            // p1 = p1 + 1 or *p1 = *p1 + 1
     570\end{lstlisting}
     571
     572Most programming languages pick a default operation and supply an explicit operation to resolve the pointer-duality ambiguity.
     573In C, the default operation for pointers is manipulate the pointer value and the pointed-to value is explicitly accessed by dereferencing ©*©.
     574\begin{lstlisting}
     575p1 = p2;                                        // pointer value assignment
     576*p1 = *p1 + 1;                          // pointed-to value assignment/operation
     577\end{lstlisting}
     578which 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.
     579
     580However, in the majority of pointer usages, the pointed-to value is required rather than the pointer address.
     581\begin{lstlisting}
     582*p2 = ((*p1 + *p2) * (*p2 - *p1)) / (*p1 - *p2);
     583\end{lstlisting}
     584And, it is tedious and error prone to explicitly write the dereferencing, especially when pointer arithmetic with integer values is allowed.
     585It is better to have the compiler generate the dereferencing:
     586\begin{lstlisting}
     587p2 = ((p1 + p2) * (p2 - p1)) / (p1 - p2);
     588\end{lstlisting}
     589
     590To 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.
     591\begin{lstlisting}
     592int x, y, z, ®&® r1, ®&® r2;    // & denotes reference pointer
     593r1 ®:=® &x;                                     // r1 points to x
     594r2 ®:=® &r1;                                    // r2 also points to x
     595r1 ®:=® &y;                                     // r1 points to y
     596r2 ®:=® &r1 + 1;                                // r2 points to z
     597r2 = ((r1 + r2) * (r2 - r1)) / (r1 - r2); // implicit dereferencing
     598\end{lstlisting}
     599Hence, 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.
     600Notice, the explicit operator ©:=© to denote pointer assignment to a reference pointer to support both aspects of pointer duality.
     601Note, \CC deals with the pointer duality by making a reference pointer a constant (©const©), like a plain variable, so there is no reference assignment.
     602
     603Like pointers, it is possible to use ©const© qualifiers with a reference:
     604\begin{lstlisting}
     605const int cx = 5;                       // cannot change cx;
     606const int & r3 = &cx;           // cannot change what r3 is pointing to
     607r3 ®:=® &cx;                                    // can change r3
     608r3 = 7;                                         // error, cannot change cx
     609int & const r4 = &x;            // must be initialized, §\CC§ reference
     610r4 ®:=® &x;                                     // error, cannot change r4
     611const int & const r5 = &cx;     // must be initialized, §\CC§ reference
     612r5 = 7;                                         // error, cannot change cx
     613r5 ®:=® &cx;                                    // error, cannot change r5
     614\end{lstlisting}
     615Note, for type ©& const©, there is no pointer assignment, so ©r4 := &x© is disallowed, and the pointer value cannot be ©0©.
     616Since there is only one meaning for ©r4 = x©, which is to change the value of the variable pointed to by ©r4©, therefore:
     617\begin{itemize}
     618\item
     619it in impossible to take the address of ©r4© as it always means the address of what ©r4© is pointing to.
     620\item
     621the dereference at initialization is optional because there can only be one
     622\begin{lrbox}{\LstBox}%
     623\footnotesize%
     624\begin{lstlisting}%
     625void f( int p ) {...}
     626void (*fp)( int ) = &f;         // equivalent initialization
     627void (*fp)( int ) = f;          // missing dereference allowed
     628\end{lstlisting}%
     629\end{lrbox}%
     630meaning.\footnote{
     631This case is similar to initializing a routine pointer, where the routine constant should be dereferenced.
     632\newline
     633\usebox{\LstBox}
     634}% footnote
     635\begin{lstlisting}
     636int & const r4 = &x;            // equivalent initialization
     637int & const r4 = x;                     // missing dereference allowed
     638\end{lstlisting}
     639\end{itemize}
     640Similarly, when a ©const© reference is used for a parameters type, the call-site argument does not require a reference.
     641\begin{lstlisting}
     642void f( int & ri, int & const cri );
     643f( &x, x );                                     // reference not required for second argument
     644\end{lstlisting}
     645Within routine ©f©, it is possible to change an argument by changing the corresponding parameter, and parameter ©ri© can be locally reassigned within ©f©.
     646
     647Finally, when a reference parameter has a ©const© value, it is possible to pass literals and expressions.
     648\begin{lstlisting}
     649void g( const int & ri, const int & const cri );
     650f( &3, 3 );
     651f( &(x + y), x + y );
     652\end{lstlisting}
     653At the call site, the compiler implicitly creates the necessary temporary that is subsequently pointed to by the reference parameter.
     654Hence, changing the parameter only changes the temporary at the call site.
     655For 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.
    487656
    488657\section{Type Operators}
     
    808977\subsection{Type Nesting}
    809978
    810 \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.
    811 \begin{quote2}
     979\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.
     980\begin{figure}
    812981\begin{tabular}{@{}l@{\hspace{3em}}l|l@{}}
    813982\multicolumn{1}{c@{\hspace{3em}}}{\textbf{C Type Nesting}}      & \multicolumn{1}{c}{\textbf{C Implicit Hoisting}}      & \multicolumn{1}{|c}{\textbf{\CFA}}    \\
     
    8701039\end{lstlisting}
    8711040\end{tabular}
    872 \end{quote2}
     1041\caption{Type Nesting / Qualification}
     1042\label{f:TypeNestingQualification}
     1043\end{figure}
    8731044In the left example in C, types ©C©, ©U© and ©T© are implicitly hoisted outside of type ©S© into the containing block scope.
    8741045In 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 ``©::©''.
Note: See TracChangeset for help on using the changeset viewer.