Changeset e8bad5c8

Timestamp:

Aug 25, 2021, 2:31:27 PM (3 years ago)

Author:

Andrew Beach <ajbeach@…>

Branches:

ADT, ast-experimental, enum, forall-pointer-decay, jacob/cs343-translation, master, pthread-emulation, qualifiedEnum

Children:

cfbab07

Parents:

ba2e8f0

Message:

Andrew MMath: Added implementation notes for the new virtual and exception syntax.

File:

• doc/theses/andrew_beach_MMath/implement.tex (modified) (4 diffs)

doc/theses/andrew_beach_MMath/implement.tex

@@ -14 +14 @@
 \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 feature, virtual
-cast (see the virtual cast feature \vpageref{p:VirtualCast}),
-substantial structure is required to support it,
+While the \CFA virtual system currently has only one 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.
 
@@ -215 +216 @@
 type's alignment, is set using an @alignof@ expression.
 
+Most of these tools are already inside the compiler. Using the is a simple
+code transformation 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.
+It also shows the transformation on the full declaration,
+for a forward declaration the @extern@ keyword is preserved and the
+initializer is not added.
+
+\begin{figure}[htb]
+\begin{cfa}
+vtable(example_type) example_name;
+\end{cfa}
+\transformline
+% Check mangling.
+\begin{cfa}
+const struct example_type_vtable example_name = {
+        .__cfavir_typeid : &__cfatid_example_type,
+        .size : sizeof(example_type),
+        .copy : copy,
+        .^?{} : ^?{},
+        .msg : msg,
+};
+\end{cfa}
+\caption{Virtual Table Transformation}
+\label{f:VirtualTableTransformation}
+\end{figure}
+
 \subsection{Concurrency Integration}
 Coroutines and threads need instances of @CoroutineCancelled@ and
@@ -251 +279 @@
 \end{figure}
 
-\begin{figure}
+\begin{figure}[htb]
 \begin{cfa}
 void main(Example & this) {
@@ -300 +328 @@
 
 \section{Exceptions}
-\todo{The entire exceptions section.}
+% The implementation of exception types.
+
+Creating exceptions can roughly divided into two parts,
+the exceptions themselves and the virtual system interactions.
+
+Creating an exception type is just a matter of preppending the field  
+with the virtual table pointer to the list of the fields
+(see \autoref{f:ExceptionTypeTransformation}).
+
+\begin{figure}[htb]
+\begin{cfa}
+exception new_exception {
+        // EXISTING FIELDS
+};
+\end{cfa}
+\transformline
+\begin{cfa}
+struct new_exception {
+        struct new_exception_vtable const * virtual_table;
+        // EXISTING FIELDS
+};
+\end{cfa}
+\caption{Exception Type Transformation}
+\label{f:ExceptionTypeTransformation}
+\end{figure}
+
+The integration between exceptions and the virtual system is a bit more
+complex simply because of the nature of the virtual system prototype.
+The primary issue is that the virtual system has no way to detect when it
+should generate any of its internal types and data. This is handled by
+the exception code, which tells the virtual system when to generate
+its components.
+
+All types associated with a virtual type,
+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
+a monomorphic type.
+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.
+% There are actually some problems with this, which is why it is not used
+% for monomorphic types.
+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 which adapts the exception's copy constructor
+to work with pointers, avoiding some issues with the current copy constructor
+interface.
+Second is the msg function, which returns a C-string with the type's name,
+including any polymorphic parameters.
 
 \section{Unwinding}