Changeset b680198


Ignore:
Timestamp:
Jun 23, 2021, 2:06:12 PM (3 years ago)
Author:
Thierry Delisle <tdelisle@…>
Branches:
ADT, ast-experimental, enum, forall-pointer-decay, jacob/cs343-translation, master, new-ast-unique-expr, pthread-emulation, qualifiedEnum
Children:
68b52b0
Parents:
6ba6846 (diff), 929d925 (diff)
Note: this is a merge changeset, the changes displayed below correspond to the merge itself.
Use the (diff) links above to see all the changes relative to each parent.
Message:

Merge branch 'master' of plg.uwaterloo.ca:software/cfa/cfa-cc

Location:
doc/theses/andrew_beach_MMath
Files:
6 edited

Legend:

Unmodified
Added
Removed

  • doc/theses/andrew_beach_MMath/existing.tex

    r6ba6846 rb680198  
    1 \chapter{\CFA Existing Features}
     1\chapter{\CFA{} Existing Features}
    22\label{c:existing}
    33
    … …  
    99existing C code-base allowing programmers to learn \CFA on an as-needed basis.
    1010
    11 Only those \CFA features pertaining to this thesis are discussed.  Many of the
    12 \CFA syntactic and semantic features used in the thesis should be fairly
    13 obvious to the reader.
     11Only those \CFA features pertaining to this thesis are discussed.
     12Also, only new features of \CFA will be discussed, a familiarity with
     13C or C-like languages is assumed.
    1414
    1515\section{Overloading and \lstinline{extern}}
    … …  
    2929// name mangling on by default
    3030int i; // _X1ii_1
    31 @extern "C"@ {  // disables name mangling
     31extern "C" {  // disables name mangling
    3232        int j; // j
    33         @extern "Cforall"@ {  // enables name mangling
     33        extern "Cforall" {  // enables name mangling
    3434                int k; // _X1ki_1
    3535        }
    … …  
    4747Reference-types are written the same way as a pointer-type but each
    4848asterisk (@*@) is replaced with a ampersand (@&@);
    49 this includes cv-qualifiers and multiple levels of reference, \eg:
    50 
     49this includes cv-qualifiers and multiple levels of reference.
     50
     51Generally, references act like pointers with an implicate dereferencing
     52operation added to each use of the variable.
     53These automatic dereferences may be disabled with the address-of operator
     54(@&@).
     55
     56% Check to see if these are generating errors.
    5157\begin{minipage}{0,5\textwidth}
    5258With references:
    … …  
    5662int && rri = ri;
    5763rri = 3;
    58 &ri = &j; // reference assignment
     64&ri = &j;
    5965ri = 5;
    6066\end{cfa}
    … …  
    6773int ** ppi = &pi;
    6874**ppi = 3;
    69 pi = &j; // pointer assignment
     75pi = &j;
    7076*pi = 5;
    7177\end{cfa}
    7278\end{minipage}
    7379
    74 References are intended for cases where you would want to use pointers but would
     80References are intended to be used when you would use pointers but would
    7581be dereferencing them (almost) every usage.
    76 In most cases a reference can just be thought of as a pointer that
    77 automatically puts a dereference in front of each of its uses (per-level of
    78 reference).
    79 The address-of operator (@&@) acts as an escape and removes one of the
    80 automatic dereference operations.
    81 Mutable references may be assigned by converting them to a pointer
    82 with a @&@ and then assigning a pointer to them, as in @&ri = &j;@ above.
     82Mutable references may be assigned to by converting them to a pointer
     83with a @&@ and then assigning a pointer to them, as in @&ri = &j;@ above
    8384
    8485\section{Operators}
    8586
    86 In general, operator names in \CFA are constructed by bracketing an operator
    87 token with @?@, which indicates the position of the arguments. For example,
     87\CFA implements operator overloading by providing special names.
     88Operator uses are translated into function calls using these names.
     89These names are created by taking the operator symbols and joining them with
     90@?@s to show where the arguments go.
     91For example,
    8892infixed multiplication is @?*?@ while prefix dereference is @*?@.
    8993This syntax make it easy to tell the difference between prefix operations
    9094(such as @++?@) and post-fix operations (@?++@).
    9195
    92 An operator name may describe any function signature (it is just a name) but
    93 only certain signatures may be called in operator form.
    94 \begin{cfa}
    95 int ?+?( int i, int j, int k ) { return i + j + k; }
    96 {
    97         sout | ?+?( 3, 4, 5 ); // no infix form
    98 }
    99 \end{cfa}
    100 Some ``near-misses" for unary/binary operator prototypes generate warnings.
     96\begin{cfa}
     97point ?+?(point a, point b) { return point{a.x + b.x, a.y + b.y}; }
     98bool ?==?(point a, point b) { return a.x == b.x && a.y == b.y; }
     99{
     100        assert(point{1, 2} + point{3, 4} == point{4, 6});
     101}
     102\end{cfa}
     103Note that these special names are not limited to just being used for these
     104operator functions, and may be used name other declarations.
     105Some ``near misses", that will not match an operator form but looks like
     106it may have been supposed to, will generate wantings but otherwise they are
     107left alone.
     108
     109%\subsection{Constructors and Destructors}
    101110
    102111Both constructors and destructors are operators, which means they are
    103112functions with special operator names rather than type names in \Cpp. The
    104 special operator names may be used to call the functions explicitly (not
    105 allowed in \Cpp for constructors).
    106 
    107 The special name for a constructor is @?{}@, where the name @{}@ comes from the
    108 initialization syntax in C, \eg @Structure s = {...}@.
    109 % That initialization syntax is also the operator form.
    110 \CFA generates a constructor call each time a variable is declared,
    111 passing the initialization arguments to the constructor.
    112 \begin{cfa}
    113 struct Structure { ... };
    114 void ?{}(Structure & this) { ... }
    115 {
    116         Structure a;
    117         Structure b = {};
    118 }
    119 void ?{}(Structure & this, char first, int num) { ... }
    120 {
    121         Structure c = {'a', 2};
    122 }
    123 \end{cfa}
    124 Both @a@ and @b@ are initialized with the first constructor,
    125 while @c@ is initialized with the second.
    126 Currently, there is no general way to skip initialization.
     113special operator names may be used to call the functions explicitly.
     114% Placement new means that this is actually equivant to C++.
     115
     116The special name for a constructor is @?{}@, which comes from the
     117initialization syntax in C, \eg @Example e = { ... }@.
     118\CFA will generate a constructor call each time a variable is declared,
     119passing the initialization arguments to the constructort.
     120\begin{cfa}
     121struct Example { ... };
     122void ?{}(Example & this) { ... }
     123{
     124        Example a;
     125        Example b = {};
     126}
     127void ?{}(Example & this, char first, int num) { ... }
     128{
     129        Example c = {'a', 2};
     130}
     131\end{cfa}
     132Both @a@ and @b@ will be initalized with the first constructor,
     133while @c@ will be initalized with the second.
     134Currently, there is no general way to skip initialation.
    127135
    128136% I don't like the \^{} symbol but $^\wedge$ isn't better.
    129 Similarly, destructors use the special name @^?{}@ (the @^@ has no special
    130 meaning).  Normally, they are implicitly called on a variable when it goes out
    131 of scope but they can be called explicitly as well.
    132 \begin{cfa}
    133 void ^?{}(Structure & this) { ... }
    134 {
    135         Structure d;
     137Similarly destructors use the special name @^?{}@ (the @^@ has no special
     138meaning).
     139These are a normally called implicitly called on a variable when it goes out
     140of scope. They can be called explicitly as well.
     141\begin{cfa}
     142void ^?{}(Example & this) { ... }
     143{
     144        Example d;
    136145} // <- implicit destructor call
    137146\end{cfa}
    138147
    139 Whenever a type is defined, \CFA creates a default zero-argument
     148Whenever a type is defined, \CFA will create a default zero-argument
    140149constructor, a copy constructor, a series of argument-per-field constructors
    141150and a destructor. All user constructors are defined after this.
    … …  
    198207void do_once(double y) { ... }
    199208int quadruple(int x) {
    200         void do_once(int y) { y = y * 2; } // replace global do_once
    201         do_twice(x); // use local do_once
    202         do_twice(x + 1.5); // use global do_once
     209        void do_once(int & y) { y = y * 2; }
     210        do_twice(x);
    203211        return x;
    204212}
    205213\end{cfa}
    206214Specifically, the complier deduces that @do_twice@'s T is an integer from the
    207 argument @x@. It then looks for the most \emph{specific} definition matching the
     215argument @x@. It then looks for the most specific definition matching the
    208216assertion, which is the nested integral @do_once@ defined within the
    209217function. The matched assertion function is then passed as a function pointer
    210 to @do_twice@ and called within it.  The global definition of @do_once@ is used
    211 for the second call because the float-point argument is a better match.
     218to @do_twice@ and called within it.
     219The global definition of @do_once@ is ignored, however if quadruple took a
     220@double@ argument then the global definition would be used instead as it
     221would be a better match.
     222% Aaron's thesis might be a good reference here.
    212223
    213224To avoid typing long lists of assertions, constraints can be collect into
    … …  
    279290Each coroutine has a @main@ function, which takes a reference to a coroutine
    280291object and returns @void@.
    281 \begin{cfa}[numbers=left]
     292%[numbers=left] Why numbers on this one?
     293\begin{cfa}
    282294void main(CountUp & this) {
    283295        for (unsigned int next = 0 ; true ; ++next) {

  • doc/theses/andrew_beach_MMath/features.tex

    r6ba6846 rb680198  
    22\label{c:features}
    33
    4 This chapter covers the design and user interface of the \CFA
    5 EHM, % or exception system.
     4This chapter covers the design and user interface of the \CFA EHM
    65and begins with a general overview of EHMs. It is not a strict
    76definition of all EHMs nor an exhaustive list of all possible features.
    8 However it does cover the most common structures and features found in them.
    9 
     7However it does cover the most common structure and features found in them.
     8
     9\section{Overview of EHMs}
    1010% We should cover what is an exception handling mechanism and what is an
    1111% exception before this. Probably in the introduction. Some of this could
    1212% move there.
    13 \section{Raise / Handle}
     13\subsection{Raise / Handle}
    1414An exception operation has two main parts: raise and handle.
    15 These terms are sometimes also known as throw and catch but this work uses
     15These terms are sometimes known as throw and catch but this work uses
    1616throw/catch as a particular kind of raise/handle.
    1717These are the two parts that the user writes and may
    … …  
    2424
    2525Some well known examples include the @throw@ statements of \Cpp and Java and
    26 the \code{Python}{raise} statement from Python. A raise may
    27 perform some other work (such as memory management) but for the
     26the \code{Python}{raise} statement from Python. In real systems a raise may
     27preform some other work (such as memory management) but for the
    2828purposes of this overview that can be ignored.
    2929
    … …  
    3333
    3434A handler has three common features: the previously mentioned user code, a
    35 region of code they guard, and an exception label/condition that matches
     35region of code they guard and an exception label/condition that matches
    3636certain exceptions.
    3737Only raises inside the guarded region and raising exceptions that match the
    3838label can be handled by a given handler.
    39 Different EHMs have different rules to pick a handler,
    40 if multiple handlers could be used, such as ``best match" or ``first found".
     39If multiple handlers could can handle an exception,
     40EHMs will define a rule to pick one, such as ``best match" or ``first found".
    4141
    4242The @try@ statements of \Cpp, Java and Python are common examples. All three
    … …  
    4444region.
    4545
    46 \section{Propagation}
     46\subsection{Propagation}
    4747After an exception is raised comes what is usually the biggest step for the
    4848EHM: finding and setting up the handler. The propagation from raise to
    4949handler can be broken up into three different tasks: searching for a handler,
    50 matching against the handler, and installing the handler.
     50matching against the handler and installing the handler.
    5151
    5252\paragraph{Searching}
    … …  
    5555thrown as it looks for handlers that have the raise site in their guarded
    5656region.
    57 This search includes handlers in the current function, as well as any in callers
    58 on the stack that have the function call in their guarded region.
     57The search includes handlers in the current function, as well as any in
     58callers on the stack that have the function call in their guarded region.
    5959
    6060\paragraph{Matching}
    6161Each handler found has to be matched with the raised exception. The exception
    62 label defines a condition that is used with the exception to decide if
     62label defines a condition that is used with exception and decides if
    6363there is a match or not.
    6464
    6565In languages where the first match is used, this step is intertwined with
    66 searching: a match check is performed immediately after the search finds
     66searching; a match check is preformed immediately after the search finds
    6767a possible handler.
    6868
    69 \section{Installing}
     69\paragraph{Installing}
    7070After a handler is chosen it must be made ready to run.
    7171The implementation can vary widely to fit with the rest of the
    … …  
    7474case when stack unwinding is involved.
    7575
    76 If a matching handler is not guarantied to be found, the EHM needs a
     76If a matching handler is not guaranteed to be found, the EHM needs a
    7777different course of action for the case where no handler matches.
    7878This situation only occurs with unchecked exceptions as checked exceptions
    7979(such as in Java) can make the guarantee.
    80 This unhandled action can abort the program or install a very general handler.
     80This unhandled action is usually very general, such as aborting the program.
    8181
    8282\paragraph{Hierarchy}
    8383A common way to organize exceptions is in a hierarchical structure.
    84 This organization is often used in object-orientated languages where the
     84This pattern comes from object-orientated languages where the
    8585exception hierarchy is a natural extension of the object hierarchy.
    8686
    … …  
    9090\end{center}
    9191
    92 A handler labelled with any given exception can handle exceptions of that
     92A handler labeled with any given exception can handle exceptions of that
    9393type or any child type of that exception. The root of the exception hierarchy
    9494(here \code{C}{exception}) acts as a catch-all, leaf types catch single types
    … …  
    104104% Could I cite the rational for the Python IO exception rework?
    105105
    106 \paragraph{Completion}
    107 After the handler has finished the entire exception operation has to complete
     106\subsection{Completion}
     107After the handler has finished, the entire exception operation has to complete
    108108and continue executing somewhere else. This step is usually simple,
    109109both logically and in its implementation, as the installation of the handler
    … …  
    111111
    112112The EHM can return control to many different places,
    113 the most common are after the handler definition (termination) and after the raise (resumption).
    114 
    115 \paragraph{Communication}
     113the most common are after the handler definition (termination)
     114and after the raise (resumption).
     115
     116\subsection{Communication}
    116117For effective exception handling, additional information is often passed
    117118from the raise to the handler and back again.
    118119So far only communication of the exceptions' identity has been covered.
    119 A common communication method is putting fields into the exception instance and giving the
    120 handler access to them. References in the exception instance can push data back to the raise.
     120A common communication method is putting fields into the exception instance
     121and giving the handler access to them.
     122Passing the exception by reference instead of by value can allow data to be
     123passed in both directions.
    121124
    122125\section{Virtuals}
    123126Virtual types and casts are not part of \CFA's EHM nor are they required for
    124127any EHM.
    125 However, one of the best ways to support an exception hierarchy is via a virtual system
    126 among exceptions and used for exception matching.
     128However, it is one of the best ways to support an exception hierarchy
     129is via a virtual hierarchy and dispatch system.
    127130
    128131Ideally, the virtual system would have been part of \CFA before the work
    129132on exception handling began, but unfortunately it was not.
    130 Therefore, only the features and framework needed for the EHM were
     133Hence, only the features and framework needed for the EHM were
    131134designed and implemented. Other features were considered to ensure that
    132 the structure could accommodate other desirable features in the future but they were not
    133 implemented.
    134 The rest of this section discusses the implemented subset of the
    135 virtual-system design.
     135the structure could accommodate other desirable features in the future
     136but they were not implemented.
     137The rest of this section will only discuss the implemented subset of the
     138virtual system design.
    136139
    137140The virtual system supports multiple ``trees" of types. Each tree is
    … …  
    143146% A type's ancestors are its parent and its parent's ancestors.
    144147% The root type has no ancestors.
    145 % A type's decedents are its children and its children's decedents.
     148% A type's descendants are its children and its children's descendants.
    146149
    147150Every virtual type also has a list of virtual members. Children inherit
    … …  
    150153of object-orientated programming, and can be of any type.
    151154
    152 \PAB{I do not understand these sentences. Can you add an example? $\Rightarrow$
    153155\CFA still supports virtual methods as a special case of virtual members.
    154156Function pointers that take a pointer to the virtual type are modified
    155157with each level of inheritance so that refers to the new type.
    156158This means an object can always be passed to a function in its virtual table
    157 as if it were a method.}
     159as if it were a method.
     160\todo{Clarify (with an example) virtual methods.}
    158161
    159162Each virtual type has a unique id.
    … …  
    161164into a virtual table type. Each virtual type has a pointer to a virtual table
    162165as a hidden field.
    163 
    164 \PAB{God forbid, maybe you need a UML diagram to relate these entities.}
     166\todo{Might need a diagram for virtual structure.}
    165167
    166168Up until this point the virtual system is similar to ones found in
    … …  
    173175types can begin to satisfy a trait, stop satisfying a trait or satisfy the same
    174176trait in a different way at any lexical location in the program.
    175 In this sense, they are ``open" as they can change at any time. This capability means it
    176 is impossible to pick a single set of functions that represent the type's
    177 implementation across the program.
     177In this sense, they are ``open" as they can change at any time.
     178This capability means it is impossible to pick a single set of functions
     179that represent the type's implementation across the program.
    178180
    179181\CFA side-steps this issue by not having a single virtual table for each
    180182type. A user can define virtual tables that are filled in at their
    181 declaration and given a name. Anywhere that name is visible, even if
     183declaration and given a name. Anywhere that name is visible, even if it is
    182184defined locally inside a function (although that means it does not have a
    183185static lifetime), it can be used.
    … …  
    186188through the object.
    187189
    188 \PAB{The above explanation is very good!}
    189 
    190190While much of the virtual infrastructure is created, it is currently only used
    191191internally for exception handling. The only user-level feature is the virtual
    192 cast
     192cast, which is the same as the \Cpp \code{C++}{dynamic_cast}.
    193193\label{p:VirtualCast}
    194194\begin{cfa}
    195195(virtual TYPE)EXPRESSION
    196196\end{cfa}
    197 which is the same as the \Cpp \code{C++}{dynamic_cast}.
    198197Note, the syntax and semantics matches a C-cast, rather than the function-like
    199198\Cpp syntax for special casts. Both the type of @EXPRESSION@ and @TYPE@ must be
    … …  
    218217The trait is defined over two types, the exception type and the virtual table
    219218type. Each exception type should have a single virtual table type.
    220 There are no actual assertions in this trait because currently the trait system
    221 cannot express them (adding such assertions would be part of
     219There are no actual assertions in this trait because the trait system
     220cannot express them yet (adding such assertions would be part of
    222221completing the virtual system). The imaginary assertions would probably come
    223222from a trait defined by the virtual system, and state that the exception type
    224 is a virtual type, is a descendent of @exception_t@ (the base exception type)
     223is a virtual type, is a descendant of @exception_t@ (the base exception type)
    225224and note its virtual table type.
    226225
    … …  
    241240};
    242241\end{cfa}
    243 Both traits ensure a pair of types are an exception type and its virtual table,
     242Both traits ensure a pair of types are an exception type, its virtual table
     243type
    244244and defines one of the two default handlers. The default handlers are used
    245245as fallbacks and are discussed in detail in \vref{s:ExceptionHandling}.
    … …  
    269269\section{Exception Handling}
    270270\label{s:ExceptionHandling}
    271 As stated, \CFA provides two kinds of exception handling: termination and resumption.
     271As stated,
     272\CFA provides two kinds of exception handling: termination and resumption.
    272273These twin operations are the core of \CFA's exception handling mechanism.
    273 This section covers the general patterns shared by the two operations and
    274 then go on to cover the details of each individual operation.
     274This section will cover the general patterns shared by the two operations and
     275then go on to cover the details each individual operation.
    275276
    276277Both operations follow the same set of steps.
    277 Both start with the user performing a raise on an exception.
     278Both start with the user preforming a raise on an exception.
    278279Then the exception propagates up the stack.
    279280If a handler is found the exception is caught and the handler is run.
    280 After that control returns to a point specific to the kind of exception.
    281 If the search fails a default handler is run, and if it returns, control
    282 continues after the raise. Note, the default handler may further change control flow rather than return.
     281After that control continues at a raise-dependent location.
     282If the search fails a default handler is run and, if it returns, then control
     283continues after the raise.
    283284
    284285This general description covers what the two kinds have in common.
    285 Differences include how propagation is performed, where exception continues
     286Differences include how propagation is preformed, where exception continues
    286287after an exception is caught and handled and which default handler is run.
    287288
    288289\subsection{Termination}
    289290\label{s:Termination}
    290 
    291291Termination handling is the familiar kind and used in most programming
    292292languages with exception handling.
    … …  
    313313
    314314The throw copies the provided exception into managed memory to ensure
    315 the exception is not destroyed when the stack is unwound.
     315the exception is not destroyed if the stack is unwound.
    316316It is the user's responsibility to ensure the original exception is cleaned
    317317up whether the stack is unwound or not. Allocating it on the stack is
    318318usually sufficient.
    319319
    320 Then propagation starts the search. \CFA uses a ``first match" rule so
    321 matching is performed with the copied exception as the search continues.
    322 It starts from the throwing function and proceeds towards the base of the stack,
     320% How to say propagation starts, its first sub-step is the search.
     321Then propagation starts with the search. \CFA uses a ``first match" rule so
     322matching is preformed with the copied exception as the search continues.
     323It starts from the throwing function and proceeds towards base of the stack,
    323324from callee to caller.
    324325At each stack frame, a check is made for resumption handlers defined by the
    … …  
    334335\end{cfa}
    335336When viewed on its own, a try statement simply executes the statements
    336 in \snake{GUARDED_BLOCK} and when those are finished, the try statement finishes.
     337in \snake{GUARDED_BLOCK} and when those are finished,
     338the try statement finishes.
    337339
    338340However, while the guarded statements are being executed, including any
    339 invoked functions, all the handlers in these statements are included on the search
    340 path. Hence, if a termination exception is raised, the search includes the added handlers associated with the guarded block and those further up the
    341 stack from the guarded block.
     341invoked functions, all the handlers in these statements are included in the
     342search path.
     343Hence, if a termination exception is raised these handlers may be matched
     344against the exception and may handle it.
    342345
    343346Exception matching checks the handler in each catch clause in the order
    344347they appear, top to bottom. If the representation of the raised exception type
    345348is the same or a descendant of @EXCEPTION_TYPE@$_i$ then @NAME@$_i$
    346 (if provided) is bound to a pointer to the exception and the statements in
    347 @HANDLER_BLOCK@$_i$ are executed.
    348 If control reaches the end of the handler, the exception is
     349(if provided) is
     350bound to a pointer to the exception and the statements in @HANDLER_BLOCK@$_i$
     351are executed. If control reaches the end of the handler, the exception is
    349352freed and control continues after the try statement.
    350353
    351 If no termination handler is found during the search, the default handler
    352 (\defaultTerminationHandler) visible at the raise statement is called.
    353 Through \CFA's trait system, the best match at the raise sight is used.
    354 This function is run and is passed the copied exception. If the default
    355 handler returns, control continues after the throw statement.
     354If no termination handler is found during the search then the default handler
     355(\defaultTerminationHandler) visible at the raise statement is run.
     356Through \CFA's trait system the best match at the raise statement will be used.
     357This function is run and is passed the copied exception.
     358If the default handler is run control continues after the raise statement.
    356359
    357360There is a global @defaultTerminationHandler@ that is polymorphic over all
    358 termination exception types. Since it is so general, a more specific handler can be
     361termination exception types.
     362Since it is so general a more specific handler can be
    359363defined and is used for those types, effectively overriding the handler
    360364for a particular exception type.
    … …  
    370374matched a closure is taken from up the stack and executed,
    371375after which the raising function continues executing.
    372 These are most often used when a potentially repairable error occurs, some handler is found on the stack to fix it, and
    373 the raising function can continue with the correction.
    374 Another common usage is dynamic event analysis, \eg logging, without disrupting control flow.
    375 Note, if an event is raised and there is no interest, control continues normally.
    376 
    377 \PAB{We also have \lstinline{report} instead of \lstinline{throwResume}, \lstinline{recover} instead of \lstinline{catch}, and \lstinline{fixup} instead of \lstinline{catchResume}.
    378 You may or may not want to mention it. You can still stick with \lstinline{catch} and \lstinline{throw/catchResume} in the thesis.}
     376The common uses for resumption exceptions include
     377potentially repairable errors, where execution can continue in the same
     378function once the error is corrected, and
     379ignorable events, such as logging where nothing needs to happen and control
     380should always continue from the same place.
    379381
    380382A resumption raise is started with the @throwResume@ statement:
    … …  
    382384throwResume EXPRESSION;
    383385\end{cfa}
     386\todo{Decide on a final set of keywords and use them everywhere.}
    384387It works much the same way as the termination throw.
    385388The expression must return a reference to a resumption exception,
    … …  
    387390@is_resumption_exception@ at the call site.
    388391The assertions from this trait are available to
    389 the exception system, while handling the exception.
    390 
    391 Resumption does not need to copy the raised exception, as the stack is not unwound.
    392 The exception and
    393 any values on the stack remain in scope, while the resumption is handled.
    394 
    395 The EHM then begins propogation. The search starts from the raise in the
    396 resuming function and proceeds towards the base of the stack, from callee to caller.
     392the exception system while handling the exception.
     393
     394At run-time, no exception copy is made.
     395Resumption does not unwind the stack nor otherwise remove values from the
     396current scope, so there is no need to manage memory to keep things in scope.
     397
     398The EHM then begins propagation. The search starts from the raise in the
     399resuming function and proceeds towards the base of the stack,
     400from callee to caller.
    397401At each stack frame, a check is made for resumption handlers defined by the
    398402@catchResume@ clauses of a @try@ statement.
    … …  
    412416kind of raise.
    413417When a try statement is executed, it simply executes the statements in the
    414 @GUARDED_BLOCK@ and then returns.
     418@GUARDED_BLOCK@ and then finishes.
    415419
    416420However, while the guarded statements are being executed, including any
    417 invoked functions, all the handlers in these statements are included on the search
    418 path. Hence, if a resumption exception is raised the search includes the added handlers associated with the guarded block and those further up the
    419 stack from the guarded block.
     421invoked functions, all the handlers in these statements are included in the
     422search path.
     423Hence, if a resumption exception is raised these handlers may be matched
     424against the exception and may handle it.
    420425
    421426Exception matching checks the handler in each catch clause in the order
    … …  
    427432the raise statement that raised the handled exception.
    428433
    429 Like termination, if no resumption handler is found during the search, the default handler
    430 (\defaultResumptionHandler) visible at the raise statement is called.
    431 It uses the best match at the
    432 raise sight according to \CFA's overloading rules. The default handler is
    433 passed the exception given to the throw. When the default handler finishes
     434Like termination, if no resumption handler is found during the search,
     435the default handler (\defaultResumptionHandler) visible at the raise
     436statement is called. It will use the best match at the raise sight according
     437to \CFA's overloading rules. The default handler is
     438passed the exception given to the raise. When the default handler finishes
    434439execution continues after the raise statement.
    435440
    436 There is a global \defaultResumptionHandler{} that is polymorphic over all
    437 resumption exception types and preforms a termination throw on the exception.
    438 The \defaultTerminationHandler{} can be
    439 customized by introducing a new or better match as well.
     441There is a global \defaultResumptionHandler{} is polymorphic over all
     442resumption exceptions and preforms a termination throw on the exception.
     443The \defaultTerminationHandler{} can be overridden by providing a new
     444function that is a better match.
    440445
    441446\subsubsection{Resumption Marking}
    442447\label{s:ResumptionMarking}
    443 
    444448A key difference between resumption and termination is that resumption does
    445449not unwind the stack. A side effect that is that when a handler is matched
    446 and run, its try block (the guarded statements) and every try statement
    447 searched before it are still on the stack. Their existence can lead to the recursive
    448 resumption problem.
     450and run it's try block (the guarded statements) and every try statement
     451searched before it are still on the stack. There presence can lead to
     452the recursive resumption problem.
    449453
    450454The recursive resumption problem is any situation where a resumption handler
    … …  
    459463\end{cfa}
    460464When this code is executed, the guarded @throwResume@ starts a
    461 search and matchs the handler in the @catchResume@ clause. This
    462 call is placed on the top of stack above the try-block. The second throw
    463 searchs the same try block and puts call another instance of the
    464 same handler on the stack leading to an infinite recursion.
     465search and matches the handler in the @catchResume@ clause. This
     466call is placed on the stack above the try-block. The second raise then
     467searches the same try block and puts another instance of the
     468same handler on the stack leading to infinite recursion.
    465469
    466470While this situation is trivial and easy to avoid, much more complex cycles
    467471can form with multiple handlers and different exception types.
    468472
    469 To prevent all of these cases, the exception search marks the try statements it visits.
    470 A try statement is marked when a match check is preformed with it and an
    471 exception. The statement is unmarked when the handling of that exception
    472 is completed or the search completes without finding a handler.
    473 While a try statement is marked, its handlers are never matched, effectify
    474 skipping over them to the next try statement.
     473To prevent all of these cases, a each try statement is ``marked" from the
     474time the exception search reaches it to either when the exception is being
     475handled completes the matching handler or when the search reaches the base
     476of the stack.
     477While a try statement is marked, its handlers are never matched, effectively
     478skipping over it to the next try statement.
    475479
    476480\begin{center}
    … …  
    478482\end{center}
    479483
    480 These rules mirror what happens with termination.
    481 When a termination throw happens in a handler, the search does not look at
    482 any handlers from the original throw to the original catch because that
    483 part of the stack is unwound.
    484 A resumption raise in the same situation wants to search the entire stack,
    485 but with marking, the search does match exceptions for try statements at equivalent sections
    486 that would have been unwound by termination.
    487 
    488 The symmetry between resumption termination is why this pattern is picked.
    489 Other patterns, such as marking just the handlers that caught the exception, also work but
    490 lack the symmetry, meaning there are more rules to remember.
     484There are other sets of marking rules that could be used,
     485for instance, marking just the handlers that caught the exception,
     486would also prevent recursive resumption.
     487However, these rules mirror what happens with termination.
     488
     489The try statements that are marked are the ones that would be removed from
     490the stack if this was a termination exception, that is those on the stack
     491between the handler and the raise statement.
     492This symmetry applies to the default handler as well, as both kinds of
     493default handlers are run at the raise statement, rather than (physically
     494or logically) at the bottom of the stack.
     495% In early development having the default handler happen after
     496% unmarking was just more useful. We assume that will continue.
    491497
    492498\section{Conditional Catch}
    493 
    494499Both termination and resumption handler clauses can be given an additional
    495500condition to further control which exceptions they handle:
    … …  
    504509did not match.
    505510
    506 The condition matching allows finer matching to check
     511The condition matching allows finer matching by checking
    507512more kinds of information than just the exception type.
    508513\begin{cfa}
    … …  
    519524// Can't handle a failure relating to f2 here.
    520525\end{cfa}
    521 In this example, the file that experianced the IO error is used to decide
     526In this example the file that experienced the IO error is used to decide
    522527which handler should be run, if any at all.
    523528
    … …  
    548553
    549554\subsection{Comparison with Reraising}
    550 
    551555A more popular way to allow handlers to match in more detail is to reraise
    552556the exception after it has been caught, if it could not be handled here.
    553 On the surface these two features seem interchangable.
    554 
    555 If @throw@ is used to start a termination reraise then these two statements
    556 have the same behaviour:
     557On the surface these two features seem interchangeable.
     558
     559If @throw;@ (no argument) starts a termination reraise,
     560which is the same as a raise but reuses the last caught exception,
     561then these two statements have the same behaviour:
    557562\begin{cfa}
    558563try {
    … …  
    574579}
    575580\end{cfa}
    576 However, if there are further handlers after this handler only the first is
    577 check. For multiple handlers on a single try block that could handle the
    578 same exception, the equivalent translations to conditional catch becomes more complex, resulting is multiple nested try blocks for all possible reraises.
    579 So while catch-with-reraise is logically equivilant to conditional catch, there is a lexical explosion for the former.
    580 
    581 \PAB{I think the following discussion makes an incorrect assumption.
    582 A conditional catch CAN happen with the stack unwound.
    583 Roy talked about this issue in Section 2.3.3 here: \newline
    584 \url{http://plg.uwaterloo.ca/theses/KrischerThesis.pdf}}
    585 
    586 Specifically for termination handling, a
    587 conditional catch happens before the stack is unwound, but a reraise happens
    588 afterwards. Normally this might only cause you to loose some debug
    589 information you could get from a stack trace (and that can be side stepped
    590 entirely by collecting information during the unwind). But for \CFA there is
    591 another issue, if the exception is not handled the default handler should be
    592 run at the site of the original raise.
    593 
    594 There are two problems with this: the site of the original raise does not
    595 exist anymore and the default handler might not exist anymore. The site is
    596 always removed as part of the unwinding, often with the entirety of the
    597 function it was in. The default handler could be a stack allocated nested
    598 function removed during the unwind.
    599 
    600 This means actually trying to pretend the catch didn't happening, continuing
    601 the original raise instead of starting a new one, is infeasible.
    602 That is the expected behaviour for most languages and we can't replicate
    603 that behaviour.
     581That is, they will have the same behaviour in isolation.
     582Two things can expose differences between these cases.
     583
     584One is the existence of multiple handlers on a single try statement.
     585A reraise skips all later handlers on this try statement but a conditional
     586catch does not.
     587Hence, if an earlier handler contains a reraise later handlers are
     588implicitly skipped, with a conditional catch they are not.
     589Still, they are equivalently powerful,
     590both can be used two mimic the behaviour of the other,
     591as reraise can pack arbitrary code in the handler and conditional catches
     592can put arbitrary code in the predicate.
     593% I was struggling with a long explanation about some simple solutions,
     594% like repeating a condition on later handlers, and the general solution of
     595% merging everything together. I don't think it is useful though unless its
     596% for a proof.
     597% https://en.cppreference.com/w/cpp/language/throw
     598
     599The question then becomes ``Which is a better default?"
     600We believe that not skipping possibly useful handlers is a better default.
     601If a handler can handle an exception it should and if the handler can not
     602handle the exception then it is probably safer to have that explicitly
     603described in the handler itself instead of implicitly described by its
     604ordering with other handlers.
     605% Or you could just alter the semantics of the throw statement. The handler
     606% index is in the exception so you could use it to know where to start
     607% searching from in the current try statement.
     608% No place for the `goto else;` metaphor.
     609
     610The other issue is all of the discussion above assumes that the only
     611way to tell apart two raises is the exception being raised and the remaining
     612search path.
     613This is not true generally, the current state of the stack can matter in
     614a number of cases, even only for a stack trace after an program abort.
     615But \CFA has a much more significant need of the rest of the stack, the
     616default handlers for both termination and resumption.
     617
     618% For resumption it turns out it is possible continue a raise after the
     619% exception has been caught, as if it hadn't been caught in the first place.
     620This becomes a problem combined with the stack unwinding used in termination
     621exception handling.
     622The stack is unwound before the handler is installed, and hence before any
     623reraises can run. So if a reraise happens the previous stack is gone,
     624the place on the stack where the default handler was supposed to run is gone,
     625if the default handler was a local function it may have been unwound too.
     626There is no reasonable way to restore that information, so the reraise has
     627to be considered as a new raise.
     628This is the strongest advantage conditional catches have over reraising,
     629they happen before stack unwinding and avoid this problem.
     630
     631% The one possible disadvantage of conditional catch is that it runs user
     632% code during the exception search. While this is a new place that user code
     633% can be run destructors and finally clauses are already run during the stack
     634% unwinding.
     635%
     636% https://www.cplusplus.com/reference/exception/current_exception/
     637%   `exception_ptr current_exception() noexcept;`
     638% https://www.python.org/dev/peps/pep-0343/
    604639
    605640\section{Finally Clauses}
    606641\label{s:FinallyClauses}
    607 
    608642Finally clauses are used to preform unconditional clean-up when leaving a
    609643scope and are placed at the end of a try statement after any handler clauses:
    … …  
    618652The @FINALLY_BLOCK@ is executed when the try statement is removed from the
    619653stack, including when the @GUARDED_BLOCK@ finishes, any termination handler
    620 finishes, or during an unwind.
     654finishes or during an unwind.
    621655The only time the block is not executed is if the program is exited before
    622656the stack is unwound.
    … …  
    634668
    635669Not all languages with unwinding have finally clauses. Notably \Cpp does
    636 without it as destructors with RAII serve a similar role. Although destructors and
    637 finally clauses have overlapping usage cases, they have their own
    638 specializations, like top-level functions and lambda functions with closures.
    639 Destructors take more work if a number of unrelated, local variables without destructors or dynamically allocated variables must be passed for de-intialization.
    640 Maintaining this destructor during local-block modification is a source of errors.
    641 A finally clause places local de-intialization inline with direct access to all local variables.
     670without it as descructors, and the RAII design pattern, serve a similar role.
     671Although destructors and finally clauses can be used in the same cases,
     672they have their own strengths, similar to top-level function and lambda
     673functions with closures.
     674Destructors take more work for their first use, but if there is clean-up code
     675that needs to be run every time a type is used they soon become much easier
     676to set-up.
     677On the other hand finally clauses capture the local context, so is easy to
     678use when the clean-up is not dependent on the type of a variable or requires
     679information from multiple variables.
     680% To Peter: I think these are the main points you were going for.
    642681
    643682\section{Cancellation}
    … …  
    652691raise, this exception is not used in matching only to pass information about
    653692the cause of the cancellation.
    654 (This restriction also means matching cannot fail so there is no default handler.)
     693(This also means matching cannot fail so there is no default handler.)
    655694
    656695After @cancel_stack@ is called the exception is copied into the EHM's memory
    657 and the current stack is
    658 unwound.
    659 The result of a cancellation depends on the kind of stack that is being unwound.
     696and the current stack is unwound.
     697The behaviour after that depends on the kind of stack being cancelled.
    660698
    661699\paragraph{Main Stack}
    … …  
    664702After the main stack is unwound there is a program-level abort.
    665703
    666 There are two reasons for this semantics. The first is that it obviously had to do the abort
     704There are two reasons for these semantics.
     705The first is that it had to do this abort.
    667706in a sequential program as there is nothing else to notify and the simplicity
    668707of keeping the same behaviour in sequential and concurrent programs is good.
    669 \PAB{I do not understand this sentence. $\Rightarrow$ Also, even in concurrent programs, there is no stack that an innate connection
    670 to, so it would have be explicitly managed.}
     708Also, even in concurrent programs there may not currently be any other stacks
     709and even if other stacks do exist, main has no way to know where they are.
    671710
    672711\paragraph{Thread Stack}
    … …  
    680719and an implicit join (from a destructor call). The explicit join takes the
    681720default handler (@defaultResumptionHandler@) from its calling context while
    682 the implicit join provides its own, which does a program abort if the
     721the implicit join provides its own; which does a program abort if the
    683722@ThreadCancelled@ exception cannot be handled.
    684723
    685 \PAB{Communication can occur during the lifetime of a thread using shared variable and \lstinline{waitfor} statements.
    686 Are you sure you mean communication here? Maybe you mean synchronization (rendezvous) point. $\Rightarrow$ Communication is done at join because a thread only has two points of
    687 communication with other threads: start and join.}
     724The communication and synchronization are done here because threads only have
     725two structural points (not dependent on user-code) where
     726communication/synchronization happens: start and join.
    688727Since a thread must be running to perform a cancellation (and cannot be
    689728cancelled from another stack), the cancellation must be after start and
    690 before the join, so join is use.
     729before the join, so join is used.
    691730
    692731% TODO: Find somewhere to discuss unwind collisions.
    … …  
    695734a destructor and prevents cascading the error across multiple threads if
    696735the user is not equipped to deal with it.
    697 Also you can always add an explicit join if that is the desired behaviour.
     736It is always possible to add an explicit join if that is the desired behaviour.
     737
     738With explicit join and a default handler that triggers a cancellation, it is
     739possible to cascade an error across any number of threads, cleaning up each
     740in turn, until the error is handled or the main thread is reached.
    698741
    699742\paragraph{Coroutine Stack}
    … …  
    701744satisfies the @is_coroutine@ trait.
    702745After a coroutine stack is unwound, control returns to the @resume@ function
    703 that most recently resumed it. The resume reports a
    704 @CoroutineCancelled@ exception, which contains references to the cancelled
     746that most recently resumed it. @resume@ reports a
     747@CoroutineCancelled@ exception, which contains a references to the cancelled
    705748coroutine and the exception used to cancel it.
    706749The @resume@ function also takes the \defaultResumptionHandler{} from the
    707 caller's context and passes it to the internal cancellation.
     750caller's context and passes it to the internal report.
    708751
    709752A coroutine knows of two other coroutines, its starter and its last resumer.
    … …  
    711754(in terms of coroutine state) called resume on this coroutine, so the message
    712755is passed to the latter.
     756
     757With a default handler that triggers a cancellation, it is possible to
     758cascade an error across any number of coroutines, cleaning up each in turn,
     759until the error is handled or a thread stack is reached.

  • doc/theses/andrew_beach_MMath/future.tex

    r6ba6846 rb680198  
    33
    44\section{Language Improvements}
     5\todo{Future/Language Improvements seems to have gotten mixed up. It is
     6presented as ``waiting on language improvements" but really its more
     7non-research based impovements.}
    58\CFA is a developing programming language. As such, there are partially or
    69unimplemented features of the language (including several broken components)
    … …  
    1114\item
    1215The implementation of termination is not portable because it includes
    13 hand-crafted assembly statements. These sections must be ported by hand to
     16hand-crafted assembly statements.
     17The existing compilers cannot translate that for other platforms and those
     18sections must be ported by hand to
    1419support more hardware architectures, such as the ARM processor.
    15 \PAB{I think this is a straw-man problem because the hand-coded assembler code
    16 has to be generated somewhere, and that somewhere is hand-coded.}
    1720\item
    1821Due to a type-system problem, the catch clause cannot bind the exception to a
    … …  
    3033There is no detection of colliding unwinds. It is possible for clean-up code
    3134run during an unwind to trigger another unwind that escapes the clean-up code
    32 itself, \eg, a termination exception caught further down the stack or a
    33 cancellation. There do exist ways to handle this issue, but currently they are not
    34 even detected and the first unwind is simply dropped, often leaving
    35 it in a bad state. \Cpp terminates the program in this case, and Java picks the ...
     35itself; such as a termination exception caught further down the stack or a
     36cancellation. There do exist ways to handle this but currently they are not
     37even detected and the first unwind will simply be forgotten, often leaving
     38it in a bad state.
    3639\item
    3740Also the exception system did not have a lot of time to be tried and tested.
    … …  
    6972bad software engineering.
    7073
    71 Non-local/concurrent raise requires more coordination between the concurrency system
     74Non-local/concurrent raise requires more
     75coordination between the concurrency system
    7276and the exception system. Many of the interesting design decisions centre
    7377around masking, \ie controlling which exceptions may be thrown at a stack. It
    … …  
    9498passed on.
    9599
    96 However checked exceptions were never seriously considered for this project because
    97 they have significant usability and reuse trade-offs in
     100However checked exceptions were never seriously considered for this project
     101because they have significant trade-offs in usablity and code reuse in
    98102exchange for the increased safety.
    99103These trade-offs are most problematic when trying to pass exceptions through
    … …  
    103107over safety design) so additional research is needed.
    104108
    105 Follow-up work might find a compromise design for checked exceptions in \CFA, possibly using
    106 polymorphic exception signatures, a form of tunneling\cite{Zhang19}, or
     109Follow-up work might add some form of checked exceptions to \CFA,
     110possibly using polymorphic exception signatures,
     111a form of tunneling\cite{Zhang19} or
    107112checked and unchecked raises.
    108113
    … …  
    148153For instance, resumption could be extended to cover this use by allowing local
    149154control flow out of it. This approach would require an unwind as part of the
    150 transition as there are stack frames that have to be removed back to the resumption handler.  This approach
    151 means no special statement is required in the handler to continue after it.
    152 Currently, \CFA allows a termination exception to be thrown from within any resumption handler so
    153 there is already a way to partially mimic signal exceptions.
     155transition as there are stack frames that have to be removed between where
     156the resumption handler is installed and where it is defined.
     157This approach would not require, but might benefit from, a special statement
     158to leave the handler.
     159Currently, mimicking this behaviour in \CFA is possible by throwing a
     160termination inside a resumption handler.
    154161
    155162% Maybe talk about the escape; and escape CONTROL_STMT; statements or how

  • doc/theses/andrew_beach_MMath/implement.tex

    r6ba6846 rb680198  
    1717pointer to the virtual table, which is called the \emph{virtual-table pointer}.
    1818Internally, the field is called \snake{virtual_table}.
    19 The field is fixed after construction and is the first field in the
     19The field is fixed after construction. It is always the first field in the
    2020structure so that its location is always known.
    2121\todo{Talk about constructors for virtual types (after they are working).}
    2222
    23 The virtual-table pointer is what binds an instance of a virtual type to its virtual table. This
    24 pointer is used as an identity check, and to access the
     23The virtual table pointer binds an instance of a virtual type
     24to a virtual table.
     25The pointer is also the table's id and how the system accesses the
    2526virtual table and the virtual members there.
    2627
    2728\subsection{Type Id}
    2829Every virtual type has a unique id.
    29 Type ids can be compared for equality (\ie the types represented are the same)
     30Type ids can be compared for equality,
     31which checks if the types reperented are the same,
    3032or used to access the type's type information.
    3133The type information currently is only the parent's type id or, if the
    32 type has no parent, @0p@.
     34type has no parent, the null pointer.
    3335
    3436The id's are implemented as pointers to the type's type information instance.
    3537Dereferencing the pointer gets the type information.
    36 The ancestors of a virtual type are found by traversing the type id through
     38The ancestors of a virtual type are found by traversing type ids through
    3739the type information.
    38 An id also pushes the issue of creating a unique value (for
     40The information pushes the issue of creating a unique value (for
    3941the type id) to the problem of creating a unique instance (for type
    4042information), which the linker can solve.
    4143
    42 Advanced linker support is required because there is no place that appears
    43 only once to attach the type information to. There should be one structure
    44 definition but it is included in multiple translation units because of separate compilation. Each virtual
    45 table definition should be unique but there are an arbitrary number of these,
    46 so the special section prefix \texttt{.gnu.linkonce} is used.
    47 With a generated unique suffix (making the entire section name unique) the linker
    48 removes multiple definition ensuring only one version exists after linking.
    49 Then it is just a matter of making sure there is a unique name for each type.
    50 
    51 These steps are done in three phases.
     44The advanced linker support is used here to avoid having to create
     45a new declaration to attach this data to.
     46With C/\CFA's header/implementation file divide for something to appear
     47exactly once it must come from a declaration that appears in exactly one
     48implementation file; the declarations in header files may exist only once
     49they can be included in many different translation units.
     50Therefore, structure's declaration will not work.
     51Neither will attaching the type information to the virtual table -- although
     52a vtable declarations are in implemention files they are not unique, see
     53\autoref{ss:VirtualTable}.
     54Instead the same type information is generated multiple times and then
     55the new attribute \snake{cfa_linkone} is used to removed duplicates.
     56
     57Type information is constructed as follows:
    5258\begin{enumerate}
    5359\item
    54 The first phase is to generate a new structure definition to store the type
     60Use the type's name to generate a name for the type information structure.
     61This is saved so it may be reused.
     62\item
     63Generate a new structure definition to store the type
    5564information. The layout is the same in each case, just the parent's type id,
    56 but the types are changed.
    57 The structure's name is change, it is based off the virtual type's name, and
    58 the type of the parent's type id.
    59 If the virtual type is polymorphic, then the type information structure is
     65but the types used change from instance to instance.
     66The generated name is used for both this structure and, if relivant, the
     67parent pointer.
     68If the virtual type is polymorphic then the type information structure is
    6069polymorphic as well, with the same polymorphic arguments.
    6170\item
    62 The second phase is to generate an instance of the type information with a
    63 almost unique name, generated by mangling the virtual type name.
     71A seperate name for instances is generated from the type's name.
    6472\item
    65 The third phase is implicit with \CFA's overloading scheme. \CFA mangles
    66 names with type information so that all of the symbols exported to the linker
    67 are unique even if in the \CFA code they are the same. Having two declarations
    68 with the same name and same type is forbidden because it is impossible for
    69 overload resolution to pick between them. This is the reason why a unique type is
    70 generated for each virtual type.
    71 Polymorphic information is included in this mangling so polymorphic
    72 types have separate instances for each set of polymorphic arguments.
     73The definition is generated and initialised.
     74The parent id is set to the null pointer or to the address of the parent's
     75type information instance. Name resolution handles the rest.
     76\item
     77\CFA's name mangler does its regular name mangling encoding the type of
     78the declaration into the instance name. This gives a completely unique name
     79including different instances of the same polymorphic type.
    7380\end{enumerate}
    74 The following example shows the components for a generated virtual type.
    75 \begin{cfa}
    76 struct TYPE_ID_TYPE {
    77         PARENT_ID_TYPE const * parent;
     81\todo{The list is making me realise, some of this isn't ordered.}
     82
     83Writing that code manually, with helper macros for the early name mangling,
     84would look like this:
     85\begin{cfa}
     86struct INFO_TYPE(TYPE) {
     87        INFO_TYPE(PARENT) const * parent;
    7888};
    7989
    8090__attribute__((cfa_linkonce))
    81 TYPE_ID_TYPE const TYPE_ID_NAME = {
    82         &PARENT_ID_NAME,
     91INFO_TYPE(TYPE) const INFO_NAME(TYPE) = {
     92        &INFO_NAME(PARENT),
    8393};
    8494\end{cfa}
    8595
    86 \subsubsection{\lstinline{cfa_linkonce} Attribute}
     96\subsubsection{\lstinline{cfa\_linkonce} Attribute}
     97% I just realised: This is an extension of the inline keyword.
     98% An extension of C's at least, it is very similar to C++'s.
    8799Another feature added to \CFA is a new attribute: \texttt{cfa\_linkonce}.
    88100This attribute is attached to an object or function definition
    89101(any global declaration with a name and a type)
    90102allowing it to be defined multiple times.
    91 All matching definitions must have the link-once attribute on them and should
    92 be identical.
    93 This attributed prototype is placed in a header file with other
    94 forward declaration.
    95 
    96 This technique is used for type-id instances, as there is no unique location
    97 associated with a type, except for the type definition in a header.
    98 The result is the unique type-id object generated by the linker.
     103All matching definitions mush have the link-once attribute
     104and their implementations should be identical as well.
     105
     106A single definition with the attribute can be included in a header
     107file as if it was a forward declaration, except no definition is required.
     108
     109This technique is used for type-id instances. A link-once definition is
     110generated each time the structure is seen. This will result in multiple
     111copies but the link-once attribute ensures all but one are removed for a
     112unique instance.
    99113
    100114Internally, @cfa_linkonce@ is replaced with
    101115@section(".gnu.linkonce.NAME")@ where \texttt{NAME} is replaced by the
    102116mangled name of the object.
    103 Any other @section@ attributes are also removed from the declaration.
     117Any other @section@ attributes are removed from the declaration.
    104118The prefix \texttt{.gnu.linkonce} in section names is recognized by the
    105 linker. If two of these sections appear with the same name, including everything
    106 that comes after the special prefix, then only one is used and the other
    107 discarded.
     119linker. If two of these sections appear with the same name, including
     120everything that comes after the special prefix, then only one is used
     121and the other is discarded.
    108122
    109123\subsection{Virtual Table}
     124\label{ss:VirtualTable}
    110125Each virtual type has a virtual table type that stores its type id and
    111126virtual members.
    … …  
    115130below.
    116131
    117 Figure~\ref{f:VirtualTableLayout} shows the layout is in three parts.
    118 \PAB{Number the parts in the figure.}
    119 \begin{enumerate}
    120 \item
     132The layout always comes in three parts.
     133\todo{Add labels to the virtual table layout figure.}
    121134The first section is just the type id at the head of the table. It is always
    122 there to ensure that \PAB{... missing text to end this sentence}
    123 \item
     135there to ensure that it can be found even when the accessing code does not
     136know which virtual type it has.
    124137The second section are all the virtual members of the parent, in the same
    125138order as they appear in the parent's virtual table. Note that the type may
    126 change slightly as references to the @this@ change. This structure is limited to
     139change slightly as references to the ``this" will change. This is limited to
    127140inside pointers/references and via function pointers so that the size (and
    128141hence the offsets) are the same.
    129 \item
    130142The third section is similar to the second except that it is the new virtual
    131143members introduced at this level in the hierarchy.
    132 \end{enumerate}
    133144
    134145\begin{figure}
    … …  
    142153prefix that has the same layout and types as its parent virtual table.
    143154This, combined with the fixed offset to the virtual table pointer, means that
    144 for any virtual type, it or any of its
    145 descendants can be accessed through
    146 the virtual table pointer.
    147 From there, it is safe to check the type id to identify the exact type of the
    148 underlying object, access any of the virtual members, and pass the object to
     155for any virtual type, it is always safe to access its virtual table and,
     156from there, it is safe to check the type id to identify the exact type of the
     157underlying object, access any of the virtual members and pass the object to
    149158any of the method-like virtual members.
    150159
    … …  
    153162the context of the declaration.
    154163
    155 The type id is always fixed with each virtual table type having
     164The type id is always fixed; with each virtual table type having
    156165exactly one possible type id.
    157 The virtual members are usually filled in during type resolution. The best match for
    158 a given name and type at the declaration site is used.
    159 There are two exceptions to that rule: the @size@ field is the type's size
    160 set using a @sizeof@ expression, and the @align@ field is the
    161 type's alignment set using an @alignof@ expression.
     166The virtual members are usually filled in by type resolution.
     167The best match for a given name and type at the declaration site is used.
     168There are two exceptions to that rule: the @size@ field, the type's size,
     169is set using a @sizeof@ expression and the @align@ field, the
     170type's alignment, is set using an @alignof@ expression.
    162171
    163172\subsubsection{Concurrency Integration}
    … …  
    168177at the definition of the main function.
    169178
    170 Figure~\ref{f:ConcurrencyTransformations} shows ...
    171 \todo{Improve Concurrency Transformations figure.}
     179This is showned through code re-writing in
     180\autoref{f:ConcurrencyTransformations}.
    172181
    173182\begin{figure}
    … …  
    206215\label{f:ConcurrencyTransformations}
    207216\end{figure}
     217\todo{Improve Concurrency Transformations figure.}
    208218
    209219\subsection{Virtual Cast}
    … …  
    222232the cast target is passed in as @child@.
    223233
    224 The generated C code wraps both arguments and the result with type casts.
     234For generated C code wraps both arguments and the result with type casts.
    225235There is also an internal check inside the compiler to make sure that the
    226236target type is a virtual type.
    227237% It also checks for conflicting definitions.
    228238
    229 The virtual cast either returns the original pointer as a new type or 0p.
    230 So the function just does the parent check and returns the appropriate value.
     239The virtual cast either returns the original pointer or the null pointer
     240as the new type.
     241So the function does the parent check and returns the appropriate value.
    231242The parent check is a simple linear search of child's ancestors using the
    232243type information.
    … …  
    257268Allocating/deallocating stack space is usually an $O(1)$ operation achieved by
    258269bumping the hardware stack-pointer up or down as needed.
    259 In fact, constructing/destructing values within a stack frame is of similar complexity but often takes longer.
     270Constructing/destructing values within a stack frame has
     271a similar complexity but can add additional work and take longer.
    260272
    261273Unwinding across multiple stack frames is more complex because that
    262274information is no longer contained within the current function.
    263 With separate compilation a function has no way of knowing what its callers
    264 so it can not know how large those frames are.
    265 Without altering the main code path, it is also hard to pass that work off
     275With seperate compilation a function has no way of knowing what its callers
     276are so it can't know how large those frames are.
     277Without altering the main code path it is also hard to pass that work off
    266278to the caller.
    267279
    … …  
    272284stack. It is up to the programmer to ensure the snap-shot is valid when it is
    273285reset and that all required clean-up from the unwound stacks is performed.
    274 This approach is fragile and forces extra work in the surrounding code.
    275 
    276 With respect to the extra work in the surrounding code,
     286This approach is fragile and requires extra work in the surrounding code.
     287
     288With respect to the extra work in the surounding code,
    277289many languages define clean-up actions that must be taken when certain
    278290sections of the stack are removed. Such as when the storage for a variable
    279 is removed from the stack or when a @try@ statement with a finally clause is
     291is removed from the stack or when a try statement with a finally clause is
    280292(conceptually) popped from the stack.
    281 None of these should be handled explicitly by the user --- that would contradict the
     293None of these should be handled by the user --- that would contradict the
    282294intention of these features --- so they need to be handled automatically.
    283295
    … …  
    308320instruction pointer is within a region's start/end, then execution is currently
    309321executing in that region. Regions are used to mark out the scopes of objects
    310 with destructors and @try@ blocks.
     322with destructors and try blocks.
    311323
    312324% Libunwind actually does very little, it simply moves down the stack from
    … …  
    326338The attribute is used on a variable and specifies a function,
    327339in this case @clean_up@, run when the variable goes out of scope.
    328 This capability is enough to mimic destructors, but not @try@ statements which can effect
     340This feature is enough to mimic destructors,
     341but not try statements which can effect
    329342the unwinding.
    330343
    331 To get full unwinding support, all of these components must done directly with
    332 assembly and assembler directives, particularly the cfi directives
    333 \snake{.cfi_Leda} and \snake{.cfi_personality}.
     344To get full unwinding support, all of these features must be handled directly
     345in assembly and assembler directives; partiularly the cfi directives
     346\snake{.cfi_lsda} and \snake{.cfi_personality}.
    334347
    335348\subsection{Personality Functions}
    … …  
    375388The @exception_class@ argument is a copy of the
    376389\code{C}{exception}'s @exception_class@ field,
    377 which is a number that identifies the exception handling mechanism that created
    378 the \PAB{... missing text to end this sentence}
     390which is a number that identifies the exception handling mechanism
     391that created the exception.
    379392
    380393The \code{C}{exception} argument is a pointer to a user
    … …  
    392405messages for special cases (some of which should never be used by the
    393406personality function) and error codes. However, unless otherwise noted, the
    394 personality function always return @_URC_CONTINUE_UNWIND@.
     407personality function always returns @_URC_CONTINUE_UNWIND@.
    395408
    396409\subsection{Raise Exception}
    397 Raising an exception is the central function of libunwind and it performs the
     410Raising an exception is the central function of libunwind and it performs
    398411two-staged unwinding.
    399412\begin{cfa}
    … …  
    485498\Cpp exceptions closely. The main complication for \CFA is that the
    486499compiler generates C code, making it very difficult to generate the assembly to
    487 form the LSDA for @try@ blocks or destructors.
     500form the LSDA for try blocks or destructors.
    488501
    489502\subsection{Memory Management}
    … …  
    500513\label{f:ExceptionLayout}
    501514\end{figure}
    502 \todo*{Convert the exception layout to an actual diagram.}
    503 
    504 Exceptions are stored in variable-sized blocks (see Figure~\vref{f:ExceptionLayout}).
     515
     516Exceptions are stored in variable-sized blocks
     517(see \autoref{f:ExceptionLayout}).
    505518The first component is a fixed-sized data structure that contains the
    506519information for libunwind and the exception system. The second component is an
    … …  
    517530high enough), which must be allocated. The previous exceptions may not be
    518531freed because the handler/catch clause has not been run.
    519 Therefore, the EHM must keep all of these exceptions alive while it allocates exceptions for new throws.
     532Therefore, the EHM must keep all unhandled exceptions alive
     533while it allocates exceptions for new throws.
    520534
    521535\begin{figure}
    … …  
    584598exception into managed memory. After the exception is handled, the free
    585599function is used to clean up the exception and then the entire node is
    586 passed to free so the memory is returned to the heap.
     600passed to free, returning the memory back to the heap.
    587601
    588602\subsection{Try Statements and Catch Clauses}
    589 The @try@ statement with termination handlers is complex because it must
    590 compensate for the C code-generation versus assembly-code generation from \CFA. Libunwind
     603The try statement with termination handlers is complex because it must
     604compensate for the C code-generation versus
     605assembly-code generated from \CFA. Libunwind
    591606requires an LSDA and personality function for control to unwind across a
    592607function. The LSDA in particular is hard to mimic in generated C code.
    593608
    594609The workaround is a function called @__cfaehm_try_terminate@ in the standard
    595 library. The contents of a @try@ block and the termination handlers are converted
     610library. The contents of a try block and the termination handlers are converted
    596611into functions. These are then passed to the try terminate function and it
    597612calls them.
    598613Because this function is known and fixed (and not an arbitrary function that
    599 happens to contain a @try@ statement), the LSDA can be generated ahead
     614happens to contain a try statement), the LSDA can be generated ahead
    600615of time.
    601616
    … …  
    603618embedded assembly. This assembly code is handcrafted using C @asm@ statements
    604619and contains
    605 enough information for a single @try@ statement the function represents.
     620enough information for a single try statement the function repersents.
    606621
    607622The three functions passed to try terminate are:
    608623\begin{description}
    609 \item[try function:] This function is the @try@ block, where all the code inside the
    610 @try@ block is wrapped inside the function. It takes no parameters and has no
     624\item[try function:] This function is the try block, it is where all the code
     625from inside the try block is placed. It takes no parameters and has no
    611626return value. This function is called during regular execution to run the try
    612627block.
    … …  
    620635handler that matches the exception.
    621636
    622 \item[handler function:] This function handles the exception, where the code inside
    623 is constructed by stitching together the bodies of
    624 each handler of a @try@ statement and dispatches to the selected handler.
     637\item[handler function:] This function handles the exception, and contains
     638all the code from the handlers in the try statement, joined with a switch
     639statement on the handler's id.
    625640It takes a
    626641pointer to the exception and the handler's id and returns nothing. It is called
    … …  
    628643\end{description}
    629644All three functions are created with GCC nested functions. GCC nested functions
    630 can be used to create closures, \ie functions that can refer to the state of other
     645can be used to create closures,
     646in other words functions that can refer to the state of other
    631647functions on the stack. This approach allows the functions to refer to all the
    632648variables in scope for the function containing the @try@ statement. These
    … …  
    636652Using this pattern, \CFA implements destructors with the cleanup attribute.
    637653
    638 Figure~\ref{f:TerminationTransformation} shows an example transformation for a \CFA @try@
    639 statement with  @catch@ clauses into corresponding C functions. \PAB{Walk the reader through the example code.}
     654\autoref{f:TerminationTransformation} shows the pattern used to transform
     655a \CFA try statement with catch clauses into the approprate C functions.
     656\todo{Explain the Termination Transformation figure.}
    640657
    641658\begin{figure}
    … …  
    653670\hrule
    654671\medskip
     672\todo*{Termination Transformation divider feels too strong.}
    655673
    656674\begin{cfa}
    … …  
    707725Instead of storing the data in a special area using assembly,
    708726there is just a linked list of possible handlers for each stack,
    709 with each list node representing a @try@ statement on the stack.
     727with each node on the list reperenting a try statement on the stack.
    710728
    711729The head of the list is stored in the exception context.
    712 The nodes are stored in order, with the more recent @try@ statements closer
     730The nodes are stored in order, with the more recent try statements closer
    713731to the head of the list.
    714732Instead of traversing the stack, resumption handling traverses the list.
    715 At each node, the EHM checks to see if the @try@ statement it represents
     733At each node, the EHM checks to see if the try statement the node repersents
    716734can handle the exception. If it can, then the exception is handled and
    717735the operation finishes, otherwise the search continues to the next node.
    718 If the search reaches the end of the list without finding a @try@ statement
     736If the search reaches the end of the list without finding a try statement
    719737that can handle the exception, the default handler is executed and the
    720738operation finishes.
    … …  
    724742if the exception is handled and false otherwise.
    725743
    726 For each @catchResume@ clause, the handler function:
    727 \begin{itemize}
    728 \item
    729 checks to see if the raised exception is a descendant type of the declared
    730 exception type,
    731 \item
    732 if it is and there is a conditional expression then it
    733 runs the test,
    734 \item
    735 if both checks pass the handling code for the clause is run and the function returns true,
    736 \item
    737 otherwise it moves onto the next clause.
    738 \end{itemize}
    739 If this is the last @catchResume@ clause then instead of moving onto
    740 the next clause the function returns false as no handler could be found.
    741 
    742 Figure~\ref{f:ResumptionTransformation} shows an example transformation for a \CFA @try@
    743 statement with @catchResume@ clauses into corresponding C functions. \PAB{Walk the reader through the example code.}
     744The handler function checks each of its internal handlers in order,
     745top-to-bottom, until it funds a match. If a match is found that handler is
     746run, after which the function returns true, ignoring all remaining handlers.
     747If no match is found the function returns false.
     748The match is performed in two steps, first a virtual cast is used to see
     749if the thrown exception is an instance of the declared exception or one of
     750its descendant type, then check to see if passes the custom predicate if one
     751is defined. This ordering gives the type guarantee used in the predicate.
     752
     753\autoref{f:ResumptionTransformation} shows the pattern used to transform
     754a \CFA try statement with catch clauses into the approprate C functions.
     755\todo{Explain the Resumption Transformation figure.}
    744756
    745757\begin{figure}
    … …  
    753765}
    754766\end{cfa}
     767
     768\medskip
     769\hrule
     770\medskip
     771\todo*{Resumption Transformation divider feels too strong.}
    755772
    756773\begin{cfa}
    … …  
    784801
    785802% Recursive Resumption Stuff:
    786 Figure~\ref{f:ResumptionMarking} shows the search skipping (see \vpageref{s:ResumptionMarking}), which ignores parts of
     803\autoref{f:ResumptionMarking} shows search skipping
     804(see \vpageref{s:ResumptionMarking}), which ignores parts of
    787805the stack
    788806already examined, is accomplished by updating the front of the list as the
    … …  
    790808is updated to the next node of the current node. After the search is complete,
    791809successful or not, the head of the list is reset.
     810% No paragraph?
    792811This mechanism means the current handler and every handler that has already
    793812been checked are not on the list while a handler is run. If a resumption is
    794813thrown during the handling of another resumption, the active handlers and all
    795814the other handler checked up to this point are not checked again.
     815% No paragraph?
    796816This structure also supports new handlers added while the resumption is being
    797817handled. These are added to the front of the list, pointing back along the
    798 stack -- the first one points over all the checked handlers -- and the ordering
    799 is maintained.
    800 \PAB{Maybe number the figure and use the numbers in the description to help the reader follow.}
     818stack --- the first one points over all the checked handlers ---
     819and the ordering is maintained.
    801820
    802821\begin{figure}
    … …  
    804823\caption{Resumption Marking}
    805824\label{f:ResumptionMarking}
    806 \todo*{Convert Resumption Marking into a line figure.}
     825\todo*{Label Resumption Marking to aid clarity.}
    807826\end{figure}
    808827
    809828\label{p:zero-cost}
    810 Finally, the resumption implementation has a cost for entering/exiting a @try@
    811 statement with @catchResume@ clauses, whereas a @try@ statement with @catch@
     829Finally, the resumption implementation has a cost for entering/exiting a try
     830statement with @catchResume@ clauses, whereas a try statement with @catch@
    812831clauses has zero-cost entry/exit. While resumption does not need the stack
    813832unwinding and cleanup provided by libunwind, it could use the search phase to
    … …  
    828847around the context of the associated @try@ statement.
    829848
    830 The rest is handled by GCC. The @try@ block and all handlers are inside this
     849The rest is handled by GCC. The try block and all handlers are inside this
    831850block. At completion, control exits the block and the empty object is cleaned
    832851up, which runs the function that contains the finally code.
    … …  
    840859
    841860The first step of cancellation is to find the cancelled stack and its type:
    842 coroutine or thread. Fortunately, the thread library stores the main thread
    843 pointer and the current thread pointer, and every thread stores a pointer to
    844 its coroutine and the coroutine it is currently executing.
     861coroutine, thread or main thread.
     862In \CFA, a thread (the construct the user works with) is a user-level thread
     863(point of execution) paired with a coroutine, the thread's main coroutine.
     864The thread library also stores pointers to the main thread and the current
     865thread.
    845866If the current thread's main and current coroutines are the same then the
    846867current stack is a thread stack, otherwise it is a coroutine stack.
    847 Note, the runtime considers a thread as a coroutine with an associated user-level thread;
    848 hence, for many operations a thread and coroutine are treated uniformly.
    849 %\todo*{Consider adding a description of how threads are coroutines.}
    850 
    851 % Furthermore it is easy to compare the
    852 % current thread to the main thread to see if they are the same. And if this
    853 % is not a thread stack then it must be a coroutine stack.
     868If the current stack is a thread stack, it is also the main thread stack
     869if and only if the main and current threads are the same.
    854870
    855871However, if the threading library is not linked, the sequential execution is on
    … …  
    861877passed to the forced-unwind function. The general pattern of all three stop
    862878functions is the same: continue unwinding until the end of stack and
    863 then perform the appropriate transfer.
     879then preform the appropriate transfer.
    864880
    865881For main stack cancellation, the transfer is just a program abort.
    … …  
    872888cancelled exception. It is then resumed as a regular exception with the default
    873889handler coming from the context of the resumption call.
    874 This semantics allows a cancellation to cascade through an arbitrary set of resumed
    875 coroutines back to the thread's coroutine, performing cleanup along the way.
    876890
    877891For thread cancellation, the exception is stored on the thread's main stack and
    … …  
    883897null (as it is for the auto-generated joins on destructor call), the default is
    884898used, which is a program abort.
    885 This semantics allows a cancellation to cascade through an arbitrary set of joining
    886 threads back to the program's main, performing cleanup along the way.
    887899%; which gives the required handling on implicate join.

  • doc/theses/andrew_beach_MMath/intro.tex

    r6ba6846 rb680198  
    11\chapter{Introduction}
    22
    3 \PAB{Stay in the present tense. \newline
    4 \url{https://plg.uwaterloo.ca/~pabuhr/technicalWriting.shtml}}
    5 \newline
    6 \PAB{Note, \lstinline{lstlisting} normally bolds keywords. None of the keywords in your thesis are bolded.}
    7 
    8 % Talk about Cforall and exceptions generally.
    9 %This thesis goes over the design and implementation of the exception handling
    10 %mechanism (EHM) of
    11 %\CFA (pernounced sea-for-all and may be written Cforall or CFA).
    12 Exception handling provides alternative dynamic inter-function control flow.
     3% The highest level overview of Cforall and EHMs. Get this done right away.
     4This thesis goes over the design and implementation of the exception handling
     5mechanism (EHM) of
     6\CFA (pronounced sea-for-all and may be written Cforall or CFA).
     7\CFA is a new programming language that extends C, that maintains
     8backwards-compatibility while introducing modern programming features.
     9Adding exception handling to \CFA gives it new ways to handle errors and
     10make other large control-flow jumps.
     11
     12% Now take a step back and explain what exceptions are generally.
     13Exception handling provides dynamic inter-function control flow.
    1314There are two forms of exception handling covered in this thesis:
    1415termination, which acts as a multi-level return,
    1516and resumption, which is a dynamic function call.
    16 Note, termination exception handling is so common it is often assumed to be the only form.
    17 Lesser know derivations of inter-function control flow are continuation passing in Lisp~\cite{CommonLisp}.
     17Termination handling is much more common,
     18to the extent that it is often seen
     19This seperation is uncommon because termination exception handling is so
     20much more common that it is often assumed.
     21% WHY: Mention other forms of continuation and \cite{CommonLisp} here?
     22A language's EHM is the combination of language syntax and run-time
     23components that are used to construct, raise and handle exceptions,
     24including all control flow.
    1825
    1926Termination exception handling allows control to return to any previous
    … …  
    2431\end{center}
    2532
    26 Resumption exception handling calls a function, but asks the functions on the
    27 stack what function that is.
     33Resumption exception handling seaches the stack for a handler and then calls
     34it without adding or removing any other stack frames.
    2835\todo{Add a diagram showing control flow for resumption.}
    2936
    … …  
    3542most of the cost only when the error actually occurs.
    3643
    37 % Overview of exceptions in Cforall.
    38 
    39 \PAB{You need section titles here. Don't take them out.}
    40 
    4144\section{Thesis Overview}
    42 
    43 This thesis goes over the design and implementation of the exception handling
    44 mechanism (EHM) of
    45 \CFA (pernounced sea-for-all and may be written Cforall or CFA).
    46 %This thesis describes the design and implementation of the \CFA EHM.
     45This work describes the design and implementation of the \CFA EHM.
    4746The \CFA EHM implements all of the common exception features (or an
    4847equivalent) found in most other EHMs and adds some features of its own.
    … …  
    7776harder to replicate in other programming languages.
    7877
    79 \section{Background}
    80 
    8178% Talk about other programming languages.
    8279Some existing programming languages that include EHMs/exception handling
    … …  
    8481exceptions which unwind the stack as part of the
    8582Exceptions also can replace return codes and return unions.
    86 In functional languages will also sometimes fold exceptions into monads.
    87 
    88 \PAB{You must demonstrate knowledge of background material here.
    89 It should be at least a full page.}
    90 
    91 \section{Contributions}
    9283
    9384The contributions of this work are:
    … …  
    10293\end{enumerate}
    10394
    104 \todo{I can't figure out a good lead-in to the overview.}
    105 Covering the existing \CFA features in \autoref{c:existing}.
    106 Then the new features are introduce in \autoref{c:features}, explaining their
    107 usage and design.
     95\todo{I can't figure out a good lead-in to the roadmap.}
     96The next section covers the existing state of exceptions.
     97The existing state of \CFA is also covered in \autoref{c:existing}.
     98The new features are introduced in \autoref{c:features},
     99which explains their usage and design.
    108100That is followed by the implementation of those features in
    109101\autoref{c:implement}.
    110 % Future Work \autoref{c:future}
     102The performance results are examined in \autoref{c:performance}.
     103Possibilities to extend this project are discussed in \autoref{c:future}.
     104
     105\section{Background}
     106\label{s:background}
     107
     108Exception handling is not a new concept,
     109with papers on the subject dating back 70s.
     110
     111Their were popularised by \Cpp,
     112which added them in its first major wave of non-object-orientated features
     113in 1990.
     114% https://en.cppreference.com/w/cpp/language/history
     115
     116Java was the next popular language to use exceptions. It is also the most
     117popular language with checked exceptions.
     118Checked exceptions are part of the function interface they are raised from.
     119This includes functions they propogate through, until a handler for that
     120type of exception is found.
     121This makes exception information explicit, which can improve clarity and
     122safety, but can slow down programming.
     123Some of these, such as dealing with high-order methods or an overly specified
     124throws clause, are technical. However some of the issues are much more
     125human, in that writing/updating all the exception signatures can be enough
     126of a burden people will hack the system to avoid them.
     127Including the ``catch-and-ignore" pattern where a catch block is used without
     128anything to repair or recover from the exception.
     129
     130%\subsection
     131Resumption exceptions have been much less popular.
     132Although resumption has a history as old as termination's, very few
     133programming languages have implement them.
     134% http://bitsavers.informatik.uni-stuttgart.de/pdf/xerox/parc/techReports/
     135%   CSL-79-3_Mesa_Language_Manual_Version_5.0.pdf
     136Mesa is one programming languages that did and experiance with that
     137languages is quoted as being one of the reasons resumptions were not
     138included in the \Cpp standard.
     139% https://en.wikipedia.org/wiki/Exception_handling
     140\todo{A comment about why we did include them when they are so unpopular
     141might be approprate.}
     142
     143%\subsection
     144Functional languages, tend to use solutions like the return union, but some
     145exception-like constructs still appear.
     146
     147For instance Haskell's built in error mechanism can make the result of any
     148expression, including function calls. Any expression that examines an
     149error value will in-turn produce an error. This continues until the main
     150function produces an error or until it is handled by one of the catch
     151functions.
     152
     153%\subsection
     154More recently exceptions seem to be vanishing from newer programming
     155languages.
     156Rust and Go reduce this feature to panics.
     157Panicing is somewhere between a termination exception and a program abort.
     158Notably in Rust a panic can trigger either, a panic may unwind the stack or
     159simply kill the process.
     160% https://doc.rust-lang.org/std/panic/fn.catch_unwind.html
     161Go's panic is much more similar to a termination exception but there is
     162only a catch-all function with \code{Go}{recover()}.
     163So exceptions still are appearing, just in reduced forms.
     164
     165%\subsection
     166Exception handling's most common use cases are in error handling.
     167Here are some other ways to handle errors and comparisons with exceptions.
     168\begin{itemize}
     169\item\emph{Error Codes}:
     170This pattern uses an enumeration (or just a set of fixed values) to indicate
     171that an error has occured and which error it was.
     172
     173There are some issues if a function wants to return an error code and another
     174value. The main issue is that it can be easy to forget checking the error
     175code, which can lead to an error being quitely and implicitly ignored.
     176Some new languages have tools that raise warnings if the return value is
     177discarded to avoid this.
     178It also puts more code on the main execution path.
     179\item\emph{Special Return with Global Store}:
     180A function that encounters an error returns some value indicating that it
     181encountered a value but store which error occured in a fixed global location.
     182
     183Perhaps the C standard @errno@ is the most famous example of this,
     184where some standard library functions will return some non-value (often a
     185NULL pointer) and set @errno@.
     186
     187This avoids the multiple results issue encountered with straight error codes
     188but otherwise many of the same advantages and disadvantages.
     189It does however introduce one other major disadvantage:
     190Everything that uses that global location must agree on all possible errors.
     191\item\emph{Return Union}:
     192Replaces error codes with a tagged union.
     193Success is one tag and the errors are another.
     194It is also possible to make each possible error its own tag and carry its own
     195additional information, but the two branch format is easy to make generic
     196so that one type can be used everywhere in error handling code.
     197
     198This pattern is very popular in functional or semi-functional language,
     199anything with primitive support for tagged unions (or algebraic data types).
     200% We need listing Rust/rust to format code snipits from it.
     201% Rust's \code{rust}{Result<T, E>}
     202
     203The main disadvantage is again it puts code on the main execution path.
     204This is also the first technique that allows for more information about an
     205error, other than one of a fix-set of ids, to be sent.
     206They can be missed but some languages can force that they are checked.
     207It is also implicitly forced in any languages with checked union access.
     208\item\emph{Handler Functions}:
     209On error the function that produced the error calls another function to
     210handle it.
     211The handler function can be provided locally (passed in as an argument,
     212either directly as as a field of a structure/object) or globally (a global
     213variable).
     214
     215C++ uses this as its fallback system if exception handling fails.
     216\snake{std::terminate_handler} and for a time \snake{std::unexpected_handler}
     217
     218Handler functions work a lot like resumption exceptions.
     219The difference is they are more expencive to set up but cheaper to use, and
     220so are more suited to more fequent errors.
     221The exception being global handlers if they are rarely change as the time
     222in both cases strinks towards zero.
     223\end{itemize}
     224
     225%\subsection
     226Because of their cost exceptions are rarely used for hot paths of execution.
     227There is an element of self-fulfilling prophocy here as implementation
     228techniques have been designed to make exceptions cheap to set-up at the cost
     229of making them expencive to use.
     230Still, use of exceptions for other tasks is more common in higher-level
     231scripting languages.
     232An iconic example is Python's StopIteration exception which is thrown by
     233an iterator to indicate that it is exausted. Combined with Python's heavy
     234use of the iterator based for-loop.
     235% https://docs.python.org/3/library/exceptions.html#StopIteration

  • doc/theses/andrew_beach_MMath/performance.tex

    r6ba6846 rb680198  
    44\textbf{Just because of the stage of testing there are design notes for
    55the tests as well as commentary on them.}
     6\todo{Revisit organization of the performance chapter once tests are chosen.}
     7% What are good tests for resumption?
    68
    79Performance has been of secondary importance for most of this project.
    8 Instead, the goal has been to get the features working.
    9 The only performance
    10 requirements is to ensure the exception tests for correctness ran in a reasonable
     10Instead, the focus has been to get the features working. The only performance
     11requirements is to ensure the tests for correctness run in a reasonable
    1112amount of time.
    12 Much of the implementation is still reasonable and could be used for similar prototypes.
    13 Hence,
    14 the work still has some use.
    15 To get a rough idea about the \CFA implementation, tests are run on \CFA, C++ and Java, which have similar termination-handling exceptions.
    16 Tests are also run on \CFA and uC++, which has similar resumption-handling exceptions.
    1713
    18 \section{Termination Comparison}
     14%\section{Termination Comparison}
     15\section{Test Set-Up}
     16Tests will be run on \CFA, C++ and Java.
     17
    1918C++ is the most comparable language because both it and \CFA use the same
    2019framework, libunwind.
    … …  
    2423there are some features it does not handle.
    2524
    26 The Java comparison is an opportunity to compare a managed memory model with unmanaged,
    27 to see if there are any effects related to the exception model.
     25Java is another very popular language with similar termination semantics.
     26It is implemented in a very different environment, a virtual machine with
     27garbage collection.
     28It also implements the finally clause on try blocks allowing for a direct
     29feature-to-feature comparison.
    2830
    29 \subsection{Test Set-Up}
    30 All tests are run inside a main loop that performs the test
    31 repeatedly. This design avoids start-up or tear-down time from
     31All tests are run inside a main loop which will perform the test
     32repeatedly. This is to avoids start-up or tear-down time from
    3233affecting the timing results.
    33 A consequence is that tests cannot terminate the program, which does limit
    34 how tests can be implemented. There are catch-alls to keep unhandled
     34A consequence of this is that tests cannot terminate the program,
     35which does limit how tests can be implemented.
     36There are catch-alls to keep unhandled
    3537exceptions from terminating tests.
    3638
    37 The exceptions used in this test are always a new exception based off of
     39The exceptions used in these tests will always be a exception based off of
    3840the base exception. This requirement minimizes performance differences based
    3941on the object model.
    … …  
    4446hot.
    4547
    46 \subsection{Tests}
    47 The following tests capture the most important aspects of exception handling and should provide
    48 a reasonable guide to programmers of where EHM costs occur.
     48\section{Tests}
     49The following tests were selected to test the performance of different
     50components of the exception system.
     51The should provide a guide as to where the EHM's costs can be found.
    4952
    5053\paragraph{Raise/Handle}
    … …  
    5255
    5356There are a number of factors that can effect this.
    54 For \CFA this includes
    55 the type of raise,
     57For \CFA this includes the type of raise,
    5658
    5759Main loop, pass through a catch-all, call through some empty helper functions
    … …  
    6567This has the same set-up as the raise/handle test except the intermediate
    6668stack frames contain either an object declaration with a destructor or a
    67 @try@ statement with no handlers except and a @finally@ clause.
     69try statement with no handlers except for a finally clause.
    6870
    6971\paragraph{Enter/Leave}
    … …  
    7173is thrown?
    7274
    73 The test is a simple matter of entering
     75This test is a simple pattern of entering
    7476and leaving a try statement.
    7577
    … …  
    8284In this case different languages approach this problem differently, either
    8385through a re-throw or a conditional-catch.
    84 Where \CFA uses its condition, other languages must unconditionally
     86Where \CFA uses its condition other languages will have to unconditionally
    8587catch the exception then re-throw if the condition if the condition is false.
    8688
    … …  
    9092% We could do a Cforall test without the catch all and a new default handler
    9193% that does a catch all.
    92 As a point of comparison, one of the raise/handle tests (which one?) has
     94As a point of comparison one of the raise/handle tests (which one?) has
    9395same layout but never catches anything.
    9496
    … …  
    105107%related to -fexceptions.)
    106108
    107 
    108 \section{Resumption Comparison}
    109109% Some languages I left out:
    110110% Python: Its a scripting language, different
    111111% uC++: Not well known and should the same results as C++, except for
    112112%   resumption which should be the same.
     113
     114%\section{Resumption Comparison}
    113115\todo{Can we find a good language to compare resumptions in.}
Note: See TracChangeset for help on using the changeset viewer.