Context Navigation

-                      rd0b9247
+                      r9cdfa5fb
 \label{s:VirtualSystem}
 % Virtual table rules. Virtual tables, the pointer to them and the cast.
 While the \CFA virtual system currently has only one public features, virtual
+While the \CFA virtual system currently has only two public features, virtual
 cast and virtual tables,
-% ??? refs (see the virtual cast feature \vpageref{p:VirtualCast}),
 substantial structure is required to support them,
 and provide features for exception handling and the standard library.
 …
 as part of field-by-field construction.
 \subsection{Type Id}
 Every virtual type has a unique id.
+\subsection{Type ID}
+Every virtual type has a unique ID.
 These are used in type equality, to check if the representation of two values
 are the same, and to access the type's type information.
 …
 Our approach for program uniqueness is using a static declaration for each
 type id, where the run-time storage address of that variable is guaranteed to
+type ID, where the run-time storage address of that variable is guaranteed to
 be unique during program execution.
 The type id storage can also be used for other purposes,
+The type ID storage can also be used for other purposes,
 and is used for type information.
 The problem is that a type id may appear in multiple TUs that compose a
 program (see \autoref{ss:VirtualTable}); so the initial solution would seem
 to be make it external in each translation unit. Hovever, the type id must
+The problem is that a type ID may appear in multiple TUs that compose a
+program (see \autoref{ss:VirtualTable}), so the initial solution would seem
+to be make it external in each translation unit. Hovever, the type ID must
 have a declaration in (exactly) one of the TUs to create the storage.
 No other declaration related to the virtual type has this property, so doing
 this through standard C declarations would require the user to do it manually.
 Instead the linker is used to handle this problem.
+Instead, the linker is used to handle this problem.
 % I did not base anything off of C++17; they are solving the same problem.
 A new feature has been added to \CFA for this purpose, the special attribute
 \snake{cfa_linkonce}, which uses the special section @.gnu.linkonce@.
 When used as a prefix (\eg @.gnu.linkonce.example@) the linker does
+When used as a prefix (\eg @.gnu.linkonce.example@), the linker does
 not combine these sections, but instead discards all but one with the same
 full name.
 So each type id must be given a unique section name with the linkonce
 prefix. Luckily \CFA already has a way to get unique names, the name mangler.
+So, each type ID must be given a unique section name with the \snake{linkonce}
+prefix. Luckily, \CFA already has a way to get unique names, the name mangler.
 For example, this could be written directly in \CFA:
 \begin{cfa}
 …
 __attribute__((section(".gnu.linkonce._X1fFv___1"))) void _X1fFv___1() {}
 \end{cfa}
 This is done internally to access the name manglers.
+This is done internally to access the name mangler.
 This attribute is useful for other purposes, any other place a unique
 instance required, and should eventually be made part of a public and
 …
 \subsection{Type Information}
 There is data stored at the type id's declaration, the type information.
 The type information currently is only the parent's type id or, if the
+There is data stored at the type ID's declaration, the type information.
+The type information currently is only the parent's type ID or, if the
 type has no parent, the null pointer.
 The ancestors of a virtual type are found by traversing type ids through
+The ancestors of a virtual type are found by traversing type IDs through
 the type information.
 An example using helper macros looks like:
 …
 \item
 Generate a new structure definition to store the type
 information. The layout is the same in each case, just the parent's type id,
+information. The layout is the same in each case, just the parent's type ID,
 but the types used change from instance to instance.
 The generated name is used for both this structure and, if relevant, the
 …
 \item
 The definition is generated and initialized.
 The parent id is set to the null pointer or to the address of the parent's
+The parent ID is set to the null pointer or to the address of the parent's
 type information instance. Name resolution handles the rest.
 \item
 …
 file as if it was a forward declaration, except no definition is required.
 This technique is used for type-id instances. A link-once definition is
+This technique is used for type ID instances. A link-once definition is
 generated each time the structure is seen. This will result in multiple
 copies but the link-once attribute ensures all but one are removed for a
 …
 \subsection{Virtual Table}
 \label{ss:VirtualTable}
+Each virtual type has a virtual table type that stores its type id and
+%\todo{Clarify virtual table type vs. virtual table instance.}
+Each virtual type has a virtual table type that stores its type ID and
 virtual members.
 Each virtual type instance is bound to a table instance that is filled with
 …
 The layout always comes in three parts (see \autoref{f:VirtualTableLayout}).
 The first section is just the type id at the head of the table. It is always
+The first section is just the type ID at the head of the table. It is always
 there to ensure that it can be found even when the accessing code does not
 know which virtual type it has.
 The second section are all the virtual members of the parent, in the same
+The second section is all the virtual members of the parent, in the same
 order as they appear in the parent's virtual table. Note that the type may
 change slightly as references to the ``this" change. This is limited to
 …
 This, combined with the fixed offset to the virtual table pointer, means that
 for any virtual type, it is always safe to access its virtual table and,
 from there, it is safe to check the type id to identify the exact type of the
+from there, it is safe to check the type ID to identify the exact type of the
 underlying object, access any of the virtual members and pass the object to
 any of the method-like virtual members.
 …
 the context of the declaration.
 The type id is always fixed; with each virtual table type having
 exactly one possible type id.
+The type ID is always fixed, with each virtual table type having
+exactly one possible type ID.
 The virtual members are usually filled in by type resolution.
 The best match for a given name and type at the declaration site is used.
 There are two exceptions to that rule: the @size@ field, the type's size,
 is set using a @sizeof@ expression and the @align@ field, the
+is set using a @sizeof@ expression, and the @align@ field, the
 type's alignment, is set using an @alignof@ expression.
 Most of these tools are already inside the compiler. Using simple
 code transformations early on in compilation, allows most of that work to be
+code transformations early on in compilation allows most of that work to be
 handed off to the existing tools. \autoref{f:VirtualTableTransformation}
 shows an example transformation, this example shows an exception virtual table.
+shows an example transformation; this example shows an exception virtual table.
 It also shows the transformation on the full declaration.
 For a forward declaration, the @extern@ keyword is preserved and the
 …
         struct __cfavir_type_id * const * child );
 \end{cfa}
 The type id for the target type of the virtual cast is passed in as
+The type ID for the target type of the virtual cast is passed in as
 @parent@ and
 the cast target is passed in as @child@.
 …
 The virtual cast either returns the original pointer or the null pointer
 as the new type.
 So the function does the parent check and returns the appropriate value.
 The parent check is a simple linear search of child's ancestors using the
+The function does the parent check and returns the appropriate value.
+The parent check is a simple linear search of the child's ancestors using the
 type information.
 …
 % The implementation of exception types.
 Creating exceptions can roughly divided into two parts,
+Creating exceptions can be roughly divided into two parts:
 the exceptions themselves and the virtual system interactions.
 …
 All types associated with a virtual type,
 the types of the virtual table and the type id,
+the types of the virtual table and the type ID,
 are generated when the virtual type (the exception) is first found.
 The type id (the instance) is generated with the exception, if it is
+The type ID (the instance) is generated with the exception, if it is
 a monomorphic type.
 However, if the exception is polymorphic, then a different type id has to
+However, if the exception is polymorphic, then a different type ID has to
 be generated for every instance. In this case, generation is delayed
 until a virtual table is created.
 …
 When a virtual table is created and initialized, two functions are created
 to fill in the list of virtual members.
 The first is a copy function that adapts the exception's copy constructor
+The first is the @copy@ function that adapts the exception's copy constructor
 to work with pointers, avoiding some issues with the current copy constructor
 interface.
 Second is the msg function that returns a C-string with the type's name,
+Second is the @msg@ function that returns a C-string with the type's name,
 including any polymorphic parameters.
 …
 % Discussing multiple frame stack unwinding:
 Unwinding across multiple stack frames is more complex because that
+Unwinding across multiple stack frames is more complex, because that
 information is no longer contained within the current function.
 With separate compilation,
 a function does not know its callers nor their frame layout.
 Even using the return address, that information is encoded in terms of
 actions in code, intermixed with the actions required finish the function.
+actions in code, intermixed with the actions required to finish the function.
 Without changing the main code path it is impossible to select one of those
 two groups of actions at the return site.
 The traditional unwinding mechanism for C is implemented by saving a snap-shot
 of a function's state with @setjmp@ and restoring that snap-shot with
+The traditional unwinding mechanism for C is implemented by saving a snapshot
+of a function's state with @setjmp@ and restoring that snapshot with
 @longjmp@. This approach bypasses the need to know stack details by simply
 reseting to a snap-shot of an arbitrary but existing function frame on the
 stack. It is up to the programmer to ensure the snap-shot is valid when it is
 reset and that all required clean-up from the unwound stacks is performed.
+reseting to a snapshot of an arbitrary but existing function frame on the
+stack. It is up to the programmer to ensure the snapshot is valid when it is
+reset and that all required cleanup from the unwound stacks is performed.
 This approach is fragile and requires extra work in the surrounding code.
 With respect to the extra work in the surrounding code,
 many languages define clean-up actions that must be taken when certain
 sections of the stack are removed. Such as when the storage for a variable
+many languages define cleanup actions that must be taken when certain
+sections of the stack are removed, such as when the storage for a variable
 is removed from the stack, possibly requiring a destructor call,
 or when a try statement with a finally clause is
 (conceptually) popped from the stack.
 None of these cases should be handled by the user --- that would contradict the
 intention of these features --- so they need to be handled automatically.
+None of these cases should be handled by the user -- that would contradict the
+intention of these features -- so they need to be handled automatically.
 To safely remove sections of the stack, the language must be able to find and
 run these clean-up actions even when removing multiple functions unknown at
+run these cleanup actions even when removing multiple functions unknown at
 the beginning of the unwinding.
 …
 provided storage object. It has two public fields: the @exception_class@,
 which is described above, and the @exception_cleanup@ function.
 The clean-up function is used by the EHM to clean-up the exception, if it
+The cleanup function is used by the EHM to clean up the exception. If it
 should need to be freed at an unusual time, it takes an argument that says
 why it had to be cleaned up.
 …
 of the most recent stack frame. It continues to call personality functions
 traversing the stack from newest to oldest until a function finds a handler or
 the end of the stack is reached. In the latter case, raise exception returns
 @_URC_END_OF_STACK@.
 Second, when a handler is matched, raise exception moves to the clean-up
 phase and walks the stack a second time.
+the end of the stack is reached. In the latter case,
+@_Unwind_RaiseException@ returns @_URC_END_OF_STACK@.
+Second, when a handler is matched, @_Unwind_RaiseException@
+moves to the cleanup phase and walks the stack a second time.
 Once again, it calls the personality functions of each stack frame from newest
 to oldest. This pass stops at the stack frame containing the matching handler.
 If that personality function has not install a handler, it is an error.
 If an error is encountered, raise exception returns either
+If that personality function has not installed a handler, it is an error.
+If an error is encountered, @_Unwind_RaiseException@ returns either
 @_URC_FATAL_PHASE1_ERROR@ or @_URC_FATAL_PHASE2_ERROR@ depending on when the
 error occurred.
 …
         _Unwind_Stop_Fn, void *);
 \end{cfa}
+It also unwinds the stack but it does not use the search phase. Instead another
+It also unwinds the stack but it does not use the search phase. Instead,
+another
 function, the stop function, is used to stop searching. The exception is the
+same as the one passed to raise exception. The extra arguments are the stop
+same as the one passed to @_Unwind_RaiseException@.
+The extra arguments are the stop
 function and the stop parameter. The stop function has a similar interface as a
 personality function, except it is also passed the stop parameter.
 …
 one list per stack, with the
 list head stored in the exception context. Within each linked list, the most
 recently thrown exception is at the head followed by older thrown
+recently thrown exception is at the head, followed by older thrown
 exceptions. This format allows exceptions to be thrown, while a different
 exception is being handled. The exception at the head of the list is currently
 …
 exception into managed memory. After the exception is handled, the free
 function is used to clean up the exception and then the entire node is
 passed to free, returning the memory back to the heap.
+passed to @free@, returning the memory back to the heap.
 \subsection{Try Statements and Catch Clauses}
 …
 The three functions passed to try terminate are:
 \begin{description}
 \item[try function:] This function is the try block, it is where all the code
+\item[try function:] This function is the try block. It is where all the code
 from inside the try block is placed. It takes no parameters and has no
 return value. This function is called during regular execution to run the try
 …
 from the conditional part of each handler and runs each check, top to bottom,
 in turn, to see if the exception matches this handler.
 The match is performed in two steps, first a virtual cast is used to check
+The match is performed in two steps: first, a virtual cast is used to check
 if the raised exception is an instance of the declared exception type or
 one of its descendant types, and then the condition is evaluated, if
 present.
 The match function takes a pointer to the exception and returns 0 if the
 exception is not handled here. Otherwise the return value is the id of the
+exception is not handled here. Otherwise, the return value is the ID of the
 handler that matches the exception.
 …
 \end{description}
 All three functions are created with GCC nested functions. GCC nested functions
 can be used to create closures,
+can be used to create closures;
 in other words,
 functions that can refer to variables in their lexical scope even
+functions that can refer to variables in their lexical scope even though
 those variables are part of a different function.
 This approach allows the functions to refer to all the
 …
 At each node, the EHM checks to see if the try statement the node represents
 can handle the exception. If it can, then the exception is handled and
 the operation finishes, otherwise the search continues to the next node.
+the operation finishes; otherwise, the search continues to the next node.
 If the search reaches the end of the list without finding a try statement
 with a handler clause
 …
 if the exception is handled and false otherwise.
 The handler function checks each of its internal handlers in order,
 top-to-bottom, until it funds a match. If a match is found that handler is
+top-to-bottom, until it finds a match. If a match is found that handler is
 run, after which the function returns true, ignoring all remaining handlers.
 If no match is found the function returns false.
 The match is performed in two steps, first a virtual cast is used to see
+The match is performed in two steps. First a virtual cast is used to see
 if the raised exception is an instance of the declared exception type or one
+of its descendant types, if so then it is passed to the custom predicate
+of its descendant types, if so, then the second step is to see if the
+exception passes the custom predicate
 if one is defined.
 % You need to make sure the type is correct before running the predicate
 …
 % Recursive Resumption Stuff:
 \autoref{f:ResumptionMarking} shows search skipping
 (see \vpageref{s:ResumptionMarking}), which ignores parts of
+(see \autoref{s:ResumptionMarking}), which ignores parts of
 the stack
 already examined, and is accomplished by updating the front of the list as
 …
 This structure also supports new handlers added while the resumption is being
 handled. These are added to the front of the list, pointing back along the
 stack --- the first one points over all the checked handlers ---
+stack -- the first one points over all the checked handlers --
 and the ordering is maintained.
 …
 %\autoref{code:cleanup}
 A finally clause is handled by converting it into a once-off destructor.
 The code inside the clause is placed into GCC nested-function
+The code inside the clause is placed into a GCC nested-function
 with a unique name, and no arguments or return values.
 This nested function is
 then set as the cleanup function of an empty object that is declared at the
 beginning of a block placed around the context of the associated try
 statement (see \autoref{f:FinallyTransformation}).
+statement, as shown in \autoref{f:FinallyTransformation}.
 \begin{figure}
 …
 % Stack selections, the three internal unwind functions.
 Cancellation also uses libunwind to do its stack traversal and unwinding,
 however it uses a different primary function: @_Unwind_ForcedUnwind@. Details
 of its interface can be found in the Section~\vref{s:ForcedUnwind}.
+Cancellation also uses libunwind to do its stack traversal and unwinding.
+However, it uses a different primary function: @_Unwind_ForcedUnwind@. Details
+of its interface can be found in Section~\vref{s:ForcedUnwind}.
 The first step of cancellation is to find the cancelled stack and its type:

Note: See TracChangeset for help on using the changeset viewer.

Context Navigation

Changeset 9cdfa5fb for doc/theses/andrew_beach_MMath/implement.tex

Legend:

doc/theses/andrew_beach_MMath/implement.tex

Download in other formats: