source: doc/theses/andrew_beach_MMath/existing.tex @ c2409fd

ADTarm-ehast-experimentalenumforall-pointer-decayjacob/cs343-translationnew-ast-unique-exprpthread-emulationqualifiedEnum
Last change on this file since c2409fd was 6e7b969, checked in by Andrew Beach <ajbeach@…>, 4 years ago

Andrew MMath: First draft of existing features and updated framework.

  • Property mode set to 100644
File size: 9.4 KB
Line 
1\chapter{\CFA{} Existing Features}
2
3\section{Overloading and extern}
4Cforall has overloading, allowing multiple definitions of the same name to
5be defined.
6
7This also adds name mangling so that the assembly symbols are unique for
8different overloads. For compatability with names in C there is also a
9syntax to diable the name mangling. These unmangled names cannot be overloaded
10but act as the interface between C and \CFA code.
11
12The syntax for disabling mangling is:
13\begin{lstlisting}
14extern "C" {
15    ...
16}
17\end{lstlisting}
18
19To re-enable mangling once it is disabled the syntax is:
20\begin{lstlisting}
21extern "Cforall" {
22    ...
23}
24\end{lstlisting}
25
26Both should occur at the declaration level and effect all the declarations
27in \texttt{...}. Neither care about the state of mangling when they begin
28and will return to that state after the group is finished. So re-enabling
29is only used to nest areas of mangled and unmangled declarations.
30
31\section{References}
32\CFA adds references to C. These are auto-dereferencing pointers and use the
33same syntax as pointers except they use ampersand (\codeCFA{\&}) instead of
34the asterisk (\codeCFA{*}). They can also be constaint or mutable, if they
35are mutable they may be assigned to by using the address-of operator
36(\codeCFA\&) which converts them into a pointer.
37
38\section{Constructors and Destructors}
39
40Both constructors and destructors are operators, which means they are just
41functions with special names. The special names are used to define them and
42may be used to call the functions expicately. The \CFA special names are
43constructed by taking the tokens in the operators and putting \texttt{?} where
44the arguments would go. So multiplication is \texttt{?*?} while dereference
45is \texttt{*?}. This also make it easy to tell the difference between
46pre-fix operations (such as \texttt{++?}) and post-fix operations
47(\texttt{?++}).
48
49The special name for contructors is \texttt{?\{\}}, which comes from the
50initialization syntax in C. The special name for destructors is
51\texttt{\^{}?\{\}}. % I don't like the \^{} symbol but $^\wedge$ isn't better.
52
53Any time a type T goes out of scope the destructor matching
54\codeCFA{void ^?\{\}(T \&);} is called. In theory this is also true of
55primitive types such as \codeCFA{int}, but in practice those are no-ops and
56are usually omitted for optimization.
57
58\section{Polymorphism}
59\CFA uses polymorphism to create functions and types that are defined over
60different types. \CFA polymorphic declarations serve the same role as \CPP
61templates or Java generics.
62
63Polymorphic declaractions start with a forall clause that goes before the
64standard (monomorphic) declaration. These declarations have the same syntax
65except that you may use the names introduced by the forall clause in them.
66
67Forall clauses are written \codeCFA{forall( ... )} where \codeCFA{...} becomes
68the list of polymorphic variables (local type names) and assertions, which
69repersent required operations on those types.
70
71\begin{lstlisting}
72forall(dtype T | { void do_once(T &); })
73void do_twice(T & value) {
74    do_once(value);
75    do_once(value);
76}
77\end{lstlisting}
78
79A polymorphic function can be used in the same way normal functions are.
80The polymorphics variables are filled in with concrete types and the
81assertions are checked. An assertion checked by seeing if that name of that
82type (with all the variables replaced with the concrete types) is defined at
83the the call site.
84
85As an example, even if no function named \codeCFA{do\_once} is not defined
86near the definition of \codeCFA{do\_twice} the following code will work.
87\begin{lstlisting}
88int quadruple(int x) {
89    void do_once(int & y) {
90        y = y * 2;
91    }
92    do_twice(x);
93    return x;
94}
95\end{lstlisting}
96This is not the recommended way to implement a quadruple function but it
97does work. The complier will deduce that \codeCFA{do\_twice}'s T is an
98integer from the argument. It will then look for a definition matching the
99assertion which is the \codeCFA{do\_once} defined within the function. That
100function will be passed in as a function pointer to \codeCFA{do\_twice} and
101called within it.
102
103To avoid typing out long lists of assertions again and again there are also
104traits which collect assertions into convenent packages that can then be used
105in assertion lists instead of all of their components.
106\begin{lstlisting}
107trait done_once(dtype T) {
108    void do_once(T &);
109}
110\end{lstlisting}
111
112After this the forall list in the previous example could instead be written
113with the trait instead of the assertion itself.
114\begin{lstlisting}
115forall(dtype T | done_once(T))
116\end{lstlisting}
117
118Traits can have arbitrary number of assertions in them and are usually used to
119create short hands for, and give descriptive names to, commond groupings of
120assertions.
121
122Polymorphic structures and unions may also be defined by putting a forall
123clause before the declaration. The type variables work the same way except
124are now used in field declaractions instead of parameters and local variables.
125
126\begin{lstlisting}
127forall(dtype T)
128struct node {
129    node(T) * next;
130    T * data;
131}
132\end{lstlisting}
133
134The \codeCFA{node(T)} is a use of a polymorphic structure. Polymorphic types
135must be provided their polymorphic parameters.
136
137There are many other features of polymorphism that have not given here but
138these are the ones used by the exception system.
139
140\section{Concurrency}
141
142\CFA has a number of concurrency features, \codeCFA{thread}s,
143\codeCFA{monitor}s and \codeCFA{mutex} parameters, \codeCFA{coroutine}s and
144\codeCFA{generator}s. The two features that interact with the exception system
145are \codeCFA{thread}s and \codeCFA{coroutine}s; they and their supporting
146constructs will be described here.
147
148\subsection{Coroutines}
149Coroutines are routines that do not have to finish execution to hand control
150back to their caller, instead they may suspend their execution at any time
151and resume it later.
152Coroutines are not true concurrency but share some similarities and many of
153the same underpinnings and so are included as part of the \CFA threading
154library.
155
156In \CFA coroutines are created using the \codeCFA{coroutine} keyword which
157works just like \codeCFA{struct} except that the created structure will be
158modified by the compiler to satify the \codeCFA{is\_coroutine} trait.
159
160These structures act as the interface between callers and the coroutine,
161the fields are used to pass information in and out. Here is a simple example
162where the single field is used to pass the next number in a sequence out.
163\begin{lstlisting}
164coroutine CountUp {
165    unsigned int next;
166}
167\end{lstlisting}
168
169The routine part of the coroutine is a main function for the coroutine. It
170takes a reference to a coroutine object and returns nothing. In this function,
171and any functions called by this function, the suspend statement may be used
172to return execution to the coroutine's caller. When control returns to the
173function it continue from that same suspend statement instead of at the top
174of the function.
175\begin{lstlisting}
176void main(CountUp & this) {
177    unsigned int next = 0;
178    while (true) {
179        this.next = next;
180        suspend;
181        next = next + 1;
182    }
183}
184\end{lstlisting}
185
186Control is passed to the coroutine with the resume function. This includes the
187first time when the coroutine is starting up. The resume function takes a
188reference to the coroutine structure and returns the same reference. The
189return value is for easy access to communication variables. For example the
190next value from a count-up can be generated and collected in a single
191expression: \codeCFA{resume(count).next}.
192
193\subsection{Monitors and Mutex}
194
195True concurrency does not garrenty ordering. To get some of that ordering back
196\CFA uses monitors and mutex (mutual exclution) parameters. A monitor is
197another special declaration that contains a lock and is compatable with mutex
198parameters.
199
200Function parameters can have the \codeCFA{mutex} qualifiers on reference
201arguments, for example \codeCFA{void example(a_monitor & mutex arg);}. When the
202function is called it will acquire the lock on all of the mutex parameters.
203
204This means that all functions that mutex on a type are part of a critical
205section and only one will ever run at a time.
206
207\subsection{Threads}
208While coroutines allow new things to be done with a single execution path
209threads actually introduce new paths of execution that continue independently.
210Now for threads to work together their must be some communication between them
211and that means the timing of certain operations does have to be known. There
212or various means of syncronization and mutual exclution provided by \CFA but
213for exceptions only the basic two -- fork and join -- are needed.
214
215Threads are created like coroutines except the keyword is changed:
216\begin{lstlisting}
217thread StringWorker {
218    const char * input;
219    int result;
220};
221
222void main(StringWorker & this) {
223    const char * localCopy = this.input;
224    // ... do some work, perhaps hashing the string ...
225    this.result = result;
226}
227\end{lstlisting}
228The main function will start executing after the fork operation and continue
229executing until it is finished. If another thread joins with this one it will
230wait until main has completed execution. In other words everything the thread
231does is between fork and join.
232
233From the outside this is the creation and destruction of the thread object.
234Fork happens after the constructor is run and join happens before the
235destructor runs. Join also happens during the \codeCFA{join} function which
236can be used to join a thread earlier. If it is used the destructor does not
237join as that has already been completed.
Note: See TracBrowser for help on using the repository browser.