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