Changeset 9724df0 for doc/user

Jun 20, 2016, 10:52:40 AM (5 years ago)
Peter A. Buhr <pabuhr@…>
aaron-thesis, arm-eh, cleanup-dtors, ctor, deferred_resn, demangler, gc_noraii, jacob/cs343-translation, jenkins-sandbox, master, memory, new-ast, new-ast-unique-expr, new-env, no_list, persistent-indexer, resolv-new, with_gc
1f17e07, a0dcd2e, f6d4204

update latex macros, and user and refrat manuals

2 edited


  • doc/user/Makefile

    r1da317b r9724df0  
    11## Define the appropriate configuration variables.
    3 TeXLIB = .:../bibliography/:../LaTeXmacros/:
     3TeXLIB = .:../LaTeXmacros:../LaTeXmacros/listings:../LaTeXmacros/enumitem:../bibliography/:
    44LaTeX  = TEXINPUTS=${TeXLIB} && export TEXINPUTS && latex
    55BibTeX = BIBINPUTS=${TeXLIB} && export BIBINPUTS && bibtex
  • 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
    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)
    36 \usepackage{upquote}                                                                    % switch curled `'" to straight `'"
     37\usepackage{upquote}                                                                    % switch curled `'" to straight
    3839\usepackage{varioref}                                                                   % extended references
     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
    5165% Names used in the document.
    70 \begin{document}
    71 \pagestyle{headings}
    72 \linenumbers                                            % comment out to turn off line numbering
    7789Version 1.0                                                     \\
    79 \huge``describe not prescribe''         \\
     91\huge``describe not prescribe''
    8193}% title
    83 Peter A. Buhr and ...                           \\
     96Peter A. Buhr and ...
    8497}% author
    86 DRAFT \\
    87 \today
     100DRAFT \\ \today
    88101}% date
    91 \pagestyle{plain}
     108\linenumbers                                            % comment out to turn off line numbering
     126\markright{\CFA User Manual}
    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}}
    485503Clearly, both styles need to be supported for some time due to existing C-style header-files, particularly for UNIX systems.
     506\section{Reference Pointers}
     508Program variables are implicit pointers to memory locations generated by the compiler and automatically dereferenced, as in:
     511\multicolumn{1}{c|}{Variables} & \multicolumn{1}{c}{Compiler generated addresses (100, 104) and dereferencing} \\
     514int x, y;
     515x = 3;
     516y = x;
     520int * const x = (int *)100, * const y = (int *)104;
     521*x = 3;         // implicit dereference
     522*y = *x;
     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.
     533x = x + 1
     534&x = *(&x) + 1
     535(100) = *(100) + 1
     539ld              r1,(100)                        // address of x
     540add             r1,1
     541st              r1,(100)                        // address of x
     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.
     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.:
     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
     557In many cases, a pointer name is anonymous (dynamically computed), so it cannot be stored directly in an instruction like a variable name.
     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:
     562p2 = p1 + x;                            // compiler infers *p2 = *p1 + x;
     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:
     568p1 = p2;                                        // p1 = p2 or *p1 = *p2
     569p1 = p1 + 1;                            // p1 = p1 + 1 or *p1 = *p1 + 1
     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 ©*©.
     575p1 = p2;                                        // pointer value assignment
     576*p1 = *p1 + 1;                          // pointed-to value assignment/operation
     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.
     580However, in the majority of pointer usages, the pointed-to value is required rather than the pointer address.
     582*p2 = ((*p1 + *p2) * (*p2 - *p1)) / (*p1 - *p2);
     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:
     587p2 = ((p1 + p2) * (p2 - p1)) / (p1 - p2);
     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.
     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
     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.
     603Like pointers, it is possible to use ©const© qualifiers with a reference:
     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
     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:
     619it in impossible to take the address of ©r4© as it always means the address of what ©r4© is pointing to.
     621the dereference at initialization is optional because there can only be one
     625void f( int p ) {...}
     626void (*fp)( int ) = &f;         // equivalent initialization
     627void (*fp)( int ) = f;          // missing dereference allowed
     631This case is similar to initializing a routine pointer, where the routine constant should be dereferenced.
     634}% footnote
     636int & const r4 = &x;            // equivalent initialization
     637int & const r4 = x;                     // missing dereference allowed
     640Similarly, when a ©const© reference is used for a parameters type, the call-site argument does not require a reference.
     642void f( int & ri, int & const cri );
     643f( &x, x );                                     // reference not required for second argument
     645Within routine ©f©, it is possible to change an argument by changing the corresponding parameter, and parameter ©ri© can be locally reassigned within ©f©.
     647Finally, when a reference parameter has a ©const© value, it is possible to pass literals and expressions.
     649void g( const int & ri, const int & const cri );
     650f( &3, 3 );
     651f( &(x + y), x + y );
     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.
    488657\section{Type Operators}
    808977\subsection{Type Nesting}
    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.
    813982\multicolumn{1}{c@{\hspace{3em}}}{\textbf{C Type Nesting}}      & \multicolumn{1}{c}{\textbf{C Implicit Hoisting}}      & \multicolumn{1}{|c}{\textbf{\CFA}}    \\
    872 \end{quote2}
     1041\caption{Type Nesting / Qualification}
    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.