| 251 |      1 | % !TEX program = xelatex
 | 
| 6 |      2 | \documentclass{article}
 | 
| 62 |      3 | \usepackage{../style}
 | 
| 78 |      4 | \usepackage{../langs}
 | 
| 218 |      5 | \usepackage{disclaimer}
 | 
|  |      6 | \usepackage{tikz}
 | 
|  |      7 | \usepackage{pgf}
 | 
|  |      8 | \usepackage{pgfplots}
 | 
|  |      9 | \usepackage{stackengine}
 | 
|  |     10 | %% \usepackage{accents}
 | 
|  |     11 | \newcommand\barbelow[1]{\stackunder[1.2pt]{#1}{\raisebox{-4mm}{\boldmath$\uparrow$}}}
 | 
|  |     12 | 
 | 
| 325 |     13 | %% change Console to scala.io.StdIn.readByte()
 | 
|  |     14 | 
 | 
| 6 |     15 | 
 | 
|  |     16 | \begin{document}
 | 
|  |     17 | 
 | 
| 356 |     18 | \section*{Part 5 (Scala, 10 Marks)}
 | 
| 6 |     19 | 
 | 
| 336 |     20 | \mbox{}\hfill\textit{``If there's one feature that makes Scala, `Scala',}\\
 | 
|  |     21 | \mbox{}\hfill\textit{ I would pick implicits.''}\smallskip\\
 | 
|  |     22 | \mbox{}\hfill\textit{ --- Martin Odersky (creator of the Scala language)}\bigskip\bigskip
 | 
| 278 |     23 | 
 | 
|  |     24 | 
 | 
|  |     25 | \noindent
 | 
| 337 |     26 | This part is about a small (esoteric) programming language called
 | 
| 336 |     27 | brainf***. Actually, we will implement an interpreter for our own version
 | 
|  |     28 | of this language called brainf*ck++.\bigskip
 | 
| 218 |     29 | 
 | 
| 355 |     30 | \IMPORTANT{This part is worth 10\% and you need to submit it on \cwTEN{} at 5pm.
 | 
|  |     31 | Any 1\% you achieve counts as your ``weekly engagement''.}
 | 
| 62 |     32 | 
 | 
|  |     33 | \noindent
 | 
| 218 |     34 | Also note that the running time of each part will be restricted to a
 | 
|  |     35 | maximum of 30 seconds on my laptop.
 | 
|  |     36 | 
 | 
|  |     37 | \DISCLAIMER{}
 | 
| 268 |     38 | \newpage
 | 
| 86 |     39 | 
 | 
| 230 |     40 | \subsection*{Reference Implementation}
 | 
|  |     41 | 
 | 
| 268 |     42 | As usual, this Scala assignment comes with a reference implementation in
 | 
|  |     43 | form of two \texttt{jar}-files. You can download them from KEATS. They
 | 
|  |     44 | allow you to run any test cases on your own computer. For example you
 | 
|  |     45 | can call Scala on the command line with the option \texttt{-cp bf.jar}
 | 
|  |     46 | and then query any function from the \texttt{bf.scala} template file.
 | 
|  |     47 | You have to prefix the calls with \texttt{CW10a} and \texttt{CW10b},
 | 
|  |     48 | respectively. For example
 | 
| 230 |     49 | 
 | 
|  |     50 | 
 | 
|  |     51 | \begin{lstlisting}[language={},xleftmargin=1mm,numbers=none,basicstyle=\ttfamily\small]
 | 
|  |     52 | $ scala -cp bf.jar
 | 
|  |     53 | scala> import CW10a._  
 | 
| 292 |     54 | scala> run(load_bff("sierpinski.bf")) ; ()
 | 
| 230 |     55 |                                *
 | 
|  |     56 |                               * *
 | 
|  |     57 |                              *   *
 | 
|  |     58 |                             * * * *
 | 
|  |     59 |                            *       *
 | 
|  |     60 |                           * *     * *
 | 
|  |     61 |                          *   *   *   *
 | 
|  |     62 |                         * * * * * * * *
 | 
|  |     63 |                        *               *
 | 
|  |     64 |                       * *             * *
 | 
|  |     65 |                      *   *           *   *
 | 
|  |     66 |                     * * * *         * * * *
 | 
|  |     67 |                    *       *       *       *
 | 
|  |     68 |                   * *     * *     * *     * *
 | 
|  |     69 |                  *   *   *   *   *   *   *   *
 | 
|  |     70 |                 * * * * * * * * * * * * * * * *
 | 
|  |     71 |                *                               *
 | 
|  |     72 |               * *                             * *
 | 
|  |     73 |              *   *                           *   *
 | 
|  |     74 |             * * * *                         * * * *
 | 
|  |     75 |            *       *                       *       *
 | 
|  |     76 |           * *     * *                     * *     * *
 | 
|  |     77 |          *   *   *   *                   *   *   *   *
 | 
|  |     78 |         * * * * * * * *                 * * * * * * * *
 | 
|  |     79 |        *               *               *               *
 | 
|  |     80 |       * *             * *             * *             * *
 | 
|  |     81 |      *   *           *   *           *   *           *   *
 | 
|  |     82 |     * * * *         * * * *         * * * *         * * * *
 | 
|  |     83 |    *       *       *       *       *       *       *       *
 | 
|  |     84 |   * *     * *     * *     * *     * *     * *     * *     * *
 | 
|  |     85 |  *   *   *   *   *   *   *   *   *   *   *   *   *   *   *   *
 | 
|  |     86 | * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
 | 
|  |     87 | \end{lstlisting}%$
 | 
|  |     88 | 
 | 
| 268 |     89 | \newpage
 | 
| 218 |     90 | 
 | 
| 307 |     91 | \subsection*{Part A (6 Marks)}
 | 
| 218 |     92 | 
 | 
| 229 |     93 | Coming from Java or C++, you might think Scala is a rather esoteric
 | 
| 218 |     94 | programming language.  But remember, some serious companies have built
 | 
|  |     95 | their business on
 | 
|  |     96 | Scala.\footnote{\url{https://en.wikipedia.org/wiki/Scala_(programming_language)\#Companies}}
 | 
| 230 |     97 | I claim functional programming is not a fad.  And there are far, far
 | 
| 336 |     98 | more esoteric languages out there. One is called \emph{brainf***}. 
 | 
|  |     99 | \here{https://esolangs.org/wiki/Brainfuck}
 | 
|  |    100 | You
 | 
| 230 |    101 | are asked in this part to implement an interpreter for
 | 
| 336 |    102 | a slight extension of this language.
 | 
| 218 |    103 | 
 | 
| 336 |    104 | Urban M\"uller developed the original version of brainf*** in 1993.  A close
 | 
|  |    105 | relative of this language was already introduced in 1964 by Corado
 | 
|  |    106 | B\"ohm, an Italian computer pioneer. The main feature of brainf*** is
 | 
|  |    107 | its minimalistic set of instructions---just 8 instructions in total
 | 
|  |    108 | and all of which are single characters. Despite the minimalism, this
 | 
|  |    109 | language has been shown to be Turing complete\ldots{}if this doesn't
 | 
|  |    110 | ring any bell with you: it roughly means that every(!) algorithm can,
 | 
|  |    111 | in principle, be implemented in brainf***. It just takes a lot of
 | 
|  |    112 | determination and quite a lot of memory resources.
 | 
|  |    113 | 
 | 
|  |    114 | Some relatively sophisticated sample programs in brainf*** are given
 | 
|  |    115 | in the file \texttt{bf.scala}, including a brainf*** program for the
 | 
|  |    116 | Sierpinski triangle and the Mandelbrot set.  There seems to be even a
 | 
|  |    117 | dedicated Windows IDE for bf programs, though I am not sure whether
 | 
|  |    118 | this is just an elaborate April fools' joke---judge yourself:
 | 
| 247 |    119 | 
 | 
|  |    120 | \begin{center}
 | 
|  |    121 | \url{https://www.microsoft.com/en-us/p/brainf-ck/9nblgggzhvq5}
 | 
| 268 |    122 | \end{center}  \bigskip
 | 
| 247 |    123 | 
 | 
| 218 |    124 | 
 | 
|  |    125 | \noindent
 | 
| 336 |    126 | As mentioned above, the original brainf*** has 8 single-character
 | 
|  |    127 | commands. Our version of bf++ will contain the commands \texttt{'>'},
 | 
|  |    128 | \texttt{'<'}, \texttt{'+'}, \texttt{'-'}, \texttt{'.'}, \texttt{'['}
 | 
|  |    129 | and \texttt{']'} from the original, and in addition the commands
 | 
|  |    130 | \texttt{'@'}, \texttt{'*'} and \texttt{'\#'}.  Every other character
 | 
|  |    131 | is considered a comment.
 | 
|  |    132 | 
 | 
|  |    133 | Our interpreter for bf++ operates on memory cells containing
 | 
| 337 |    134 | integers. For this it uses a single memory pointer, called
 | 
|  |    135 | \texttt{mp}, that points at each stage to one memory cell.
 | 
|  |    136 | 
 | 
|  |    137 | \begin{center}
 | 
|  |    138 | \begin{tikzpicture}
 | 
|  |    139 |   \draw [line width=1mm, rounded corners] (0,0) rectangle (5, 0.5);
 | 
|  |    140 |   \draw (0.5, 0) -- (0.5, 0.5);
 | 
|  |    141 |   \draw (1.0, 0) -- (1.0, 0.5);
 | 
|  |    142 | 
 | 
|  |    143 |   \draw (2.5, 0) -- (2.5, 0.5);
 | 
|  |    144 |   \draw (2.0, 0) -- (2.0, 0.5);
 | 
|  |    145 | 
 | 
|  |    146 |   \draw (4.5, 0) -- (4.5, 0.5);
 | 
|  |    147 |   \draw (4.0, 0) -- (4.0, 0.5);
 | 
|  |    148 | 
 | 
|  |    149 |   \draw (1.5,0.25) node {$\cdots$};
 | 
|  |    150 |   \draw (3.0,0.25) node {$\cdots$};
 | 
|  |    151 | 
 | 
|  |    152 |   \draw [->, thick] (2.25, -0.5) -- (2.25, -0.15);
 | 
|  |    153 |   \draw (2.25,-0.8) node {\texttt{mp}};
 | 
|  |    154 | 
 | 
|  |    155 |   \draw (0.7,0.7) node {\sf\footnotesize memory};
 | 
|  |    156 | \end{tikzpicture}    
 | 
|  |    157 | \end{center}  
 | 
|  |    158 | 
 | 
|  |    159 | \noindent
 | 
|  |    160 | This pointer can be moved forward by one memory cell by using the
 | 
|  |    161 | command \texttt{'>'}, and backward by using \texttt{'<'}. The commands
 | 
|  |    162 | \texttt{'+'} and \texttt{'-'} increase, respectively decrease, by 1
 | 
|  |    163 | the content of the memory cell to which the memory pointer currently
 | 
|  |    164 | points to. The command for output in bf++ is \texttt{'.'} whereby output works
 | 
|  |    165 | by reading the content of the memory cell to which the memory pointer
 | 
|  |    166 | points to and printing it out as an ASCII character.\footnote{In the
 | 
|  |    167 |   original version of bf, there is also a command for input, but we
 | 
|  |    168 |   omit it here. All our programs will be ``autonomous''.}  The
 | 
| 336 |    169 | commands \texttt{'['} and \texttt{']'} are looping
 | 
| 218 |    170 | constructs. Everything in between \texttt{'['} and \texttt{']'} is
 | 
|  |    171 | repeated until a counter (memory cell) reaches zero.  A typical
 | 
|  |    172 | program in brainf*** looks as follows:
 | 
|  |    173 | 
 | 
|  |    174 | \begin{center}
 | 
|  |    175 | \begin{verbatim}
 | 
| 230 |    176 |    ++++++++[>++++[>++>+++>+++>+<<<<-]>+>+>->>+[<]<-]>>.>---.++
 | 
|  |    177 |    +++++..+++.>>.<-.<.+++.------.--------.>>+.>++.
 | 
| 218 |    178 | \end{verbatim}
 | 
|  |    179 | \end{center}  
 | 
|  |    180 | 
 | 
|  |    181 | \noindent
 | 
| 336 |    182 | This one prints out Hello World\ldots{}obviously \texttt{;o)} We also
 | 
| 337 |    183 | add 3 new commands in the bf++-version of the bf-language. The purpose
 | 
|  |    184 | of these commands we explain later.
 | 
| 336 |    185 | 
 | 
| 218 |    186 | 
 | 
|  |    187 | \subsubsection*{Tasks (file bf.scala)}
 | 
| 109 |    188 | 
 | 
|  |    189 | \begin{itemize}
 | 
| 237 |    190 | \item[(1)]  Write a function that takes a filename (a string) as an argument
 | 
| 229 |    191 |   and requests the corresponding file from disk. It returns the
 | 
| 237 |    192 |   content of the file as a string. If the file does not exists,
 | 
| 337 |    193 |   the function should return the empty string.
 | 
| 229 |    194 |   \mbox{}\hfill[1 Mark]
 | 
|  |    195 |   
 | 
| 336 |    196 | \item[(2)] Brainf**k++ memory is represented by a \texttt{Map} from
 | 
| 218 |    197 |   integers to integers. The empty memory is represented by
 | 
|  |    198 |   \texttt{Map()}, that is nothing is stored in the
 | 
| 229 |    199 |   memory; \texttt{Map(0 -> 1, 2 -> 3)} stores \texttt{1} at
 | 
|  |    200 |   memory location \texttt{0}, and at \texttt{2} it stores \texttt{3}. The
 | 
| 218 |    201 |   convention is that if we query the memory at a location that is
 | 
|  |    202 |   \emph{not} defined in the \texttt{Map}, we return \texttt{0}. Write
 | 
| 268 |    203 |   a `safe-read' function, \texttt{sread}, that takes a memory (a \texttt{Map}) and
 | 
| 237 |    204 |   a memory pointer (an \texttt{Int}) as arguments, and `safely' reads the
 | 
| 218 |    205 |   corresponding memory location. If the \texttt{Map} is not defined at
 | 
|  |    206 |   the memory pointer, \texttt{sread} returns \texttt{0}.
 | 
|  |    207 | 
 | 
|  |    208 |   Write another function \texttt{write}, which takes a memory, a
 | 
| 237 |    209 |   memory pointer and an integer value as arguments and updates the
 | 
|  |    210 |   \texttt{Map} with the value at the given memory location. As usual,
 | 
| 218 |    211 |   the \texttt{Map} is not updated `in-place' but a new map is created
 | 
| 237 |    212 |   with the same data, except the new value is stored at the given memory
 | 
| 218 |    213 |   pointer.\hfill[1 Mark]
 | 
|  |    214 | 
 | 
| 229 |    215 | \item[(3)] Write two functions, \texttt{jumpRight} and
 | 
| 237 |    216 |   \texttt{jumpLeft}, that are needed to implement the loop constructs
 | 
| 336 |    217 |   in brainf**k++. They take a program (a \texttt{String}) and a program
 | 
| 237 |    218 |   counter (an \texttt{Int}) as arguments and move right (respectively
 | 
| 218 |    219 |   left) in the string in order to find the \textbf{matching}
 | 
|  |    220 |   opening/closing bracket. For example, given the following program
 | 
|  |    221 |   with the program counter indicated by an arrow:
 | 
|  |    222 | 
 | 
|  |    223 |   \begin{center}
 | 
| 336 |    224 |   \texttt{--[\barbelow{.}.+>--].>.++}
 | 
| 218 |    225 |   \end{center}
 | 
|  |    226 | 
 | 
|  |    227 |   then the matching closing bracket is in 9th position (counting from 0) and
 | 
|  |    228 |   \texttt{jumpRight} is supposed to return the position just after this
 | 
| 109 |    229 |   
 | 
| 218 |    230 |   \begin{center}
 | 
| 336 |    231 |   \texttt{--[..+>--]\barbelow{.}>.++}
 | 
| 218 |    232 |   \end{center}
 | 
|  |    233 | 
 | 
| 237 |    234 |   meaning it jumps to after the loop. Similarly, if you are in 8th position,
 | 
| 218 |    235 |   then \texttt{jumpLeft} is supposed to jump to just after the opening
 | 
|  |    236 |   bracket (that is jumping to the beginning of the loop):
 | 
| 109 |    237 | 
 | 
| 218 |    238 |   \begin{center}
 | 
| 336 |    239 |     \texttt{--[..+>-\barbelow{-}].>.++}
 | 
| 218 |    240 |     \qquad$\stackrel{\texttt{jumpLeft}}{\longrightarrow}$\qquad
 | 
| 336 |    241 |     \texttt{--[\barbelow{.}.+>--].>.++}
 | 
| 218 |    242 |   \end{center}
 | 
|  |    243 | 
 | 
|  |    244 |   Unfortunately we have to take into account that there might be
 | 
|  |    245 |   other opening and closing brackets on the `way' to find the
 | 
| 336 |    246 |   matching bracket. For example in the brain*ck++ program
 | 
| 218 |    247 | 
 | 
|  |    248 |   \begin{center}
 | 
| 336 |    249 |   \texttt{--[\barbelow{.}.[+>]--].>.++}
 | 
| 218 |    250 |   \end{center}
 | 
| 109 |    251 | 
 | 
| 218 |    252 |   we do not want to return the index for the \texttt{'-'} in the 9th
 | 
| 336 |    253 |   position, but the program counter for \texttt{'.'} in 12th
 | 
| 218 |    254 |   position. The easiest to find out whether a bracket is matched is by
 | 
|  |    255 |   using levels (which are the third argument in \texttt{jumpLeft} and
 | 
|  |    256 |   \texttt{jumpLeft}). In case of \texttt{jumpRight} you increase the
 | 
|  |    257 |   level by one whenever you find an opening bracket and decrease by
 | 
|  |    258 |   one for a closing bracket. Then in \texttt{jumpRight} you are looking
 | 
|  |    259 |   for the closing bracket on level \texttt{0}. For \texttt{jumpLeft} you
 | 
|  |    260 |   do the opposite. In this way you can find \textbf{matching} brackets
 | 
|  |    261 |   in strings such as
 | 
|  |    262 | 
 | 
|  |    263 |   \begin{center}
 | 
| 336 |    264 |   \texttt{--[\barbelow{.}.[[-]+>[.]]--].>.++}
 | 
| 218 |    265 |   \end{center}
 | 
| 109 |    266 | 
 | 
| 218 |    267 |   for which \texttt{jumpRight} should produce the position:
 | 
|  |    268 | 
 | 
|  |    269 |   \begin{center}
 | 
| 336 |    270 |   \texttt{--[..[[-]+>[.]]--]\barbelow{.}>.++}
 | 
| 218 |    271 |   \end{center}
 | 
|  |    272 | 
 | 
|  |    273 |   It is also possible that the position returned by \texttt{jumpRight} or
 | 
|  |    274 |   \texttt{jumpLeft} is outside the string in cases where there are
 | 
|  |    275 |   no matching brackets. For example
 | 
|  |    276 | 
 | 
|  |    277 |   \begin{center}
 | 
| 336 |    278 |   \texttt{--[\barbelow{.}.[[-]+>[.]]--.>.++}
 | 
| 218 |    279 |   \qquad$\stackrel{\texttt{jumpRight}}{\longrightarrow}$\qquad
 | 
| 336 |    280 |   \texttt{--[..[[-]+>[.]]-->.++\barbelow{\;\phantom{+}}}
 | 
| 218 |    281 |   \end{center}
 | 
| 229 |    282 |   \hfill[2 Marks]
 | 
| 109 |    283 | 
 | 
|  |    284 | 
 | 
| 230 |    285 | \item[(4)] Write a recursive function \texttt{compute} that runs a
 | 
| 336 |    286 |   brain*u*k++ program. It takes a program, a program counter, a memory
 | 
| 218 |    287 |   pointer and a memory as arguments. If the program counter is outside
 | 
| 230 |    288 |   the program string, the execution stops and \texttt{compute} returns the
 | 
| 218 |    289 |   memory. If the program counter is inside the string, it reads the
 | 
|  |    290 |   corresponding character and updates the program counter \texttt{pc},
 | 
|  |    291 |   memory pointer \texttt{mp} and memory \texttt{mem} according to the
 | 
|  |    292 |   rules shown in Figure~\ref{comms}. It then calls recursively
 | 
| 230 |    293 |   \texttt{compute} with the updated data. The most convenient way to
 | 
| 336 |    294 |   implement the brainf**k++ rules in Scala is to use pattern-matching
 | 
| 230 |    295 |   and to calculate a triple consisting of the updated \texttt{pc},
 | 
| 229 |    296 |   \texttt{mp} and \texttt{mem}.
 | 
| 218 |    297 | 
 | 
| 230 |    298 |   Write another function \texttt{run} that calls \texttt{compute} with a
 | 
| 336 |    299 |   given brainfu*k++ program and memory, and the program counter and memory pointer
 | 
| 230 |    300 |   set to~$0$. Like \texttt{compute}, it returns the memory after the execution
 | 
| 336 |    301 |   of the program finishes. You can test your brainf**k++ interpreter with the
 | 
| 229 |    302 |   Sierpinski triangle or the Hello world programs (they seem to be particularly
 | 
|  |    303 |   useful for debugging purposes), or have a look at
 | 
| 109 |    304 | 
 | 
| 218 |    305 |   \begin{center}
 | 
|  |    306 |   \url{https://esolangs.org/wiki/Brainfuck}
 | 
| 337 |    307 |   \end{center}
 | 
|  |    308 | 
 | 
|  |    309 |   \noindent for more bf/bf++-programs and the test cases given in \texttt{bf.scala}.\\
 | 
|  |    310 |   \mbox{}\hfill[2 Marks]
 | 
| 109 |    311 |   
 | 
| 218 |    312 |   \begin{figure}[p]
 | 
|  |    313 |   \begin{center}
 | 
| 230 |    314 |     \begin{tabular}{|@{\hspace{0.5mm}}p{0.8cm}|l|}
 | 
| 218 |    315 |       \hline
 | 
|  |    316 |       \hfill\texttt{'>'} & \begin{tabular}[t]{@{}l@{\hspace{2mm}}l@{}}
 | 
|  |    317 |                        $\bullet$ & $\texttt{pc} + 1$\\
 | 
|  |    318 |                        $\bullet$ & $\texttt{mp} + 1$\\
 | 
|  |    319 |                        $\bullet$ & \texttt{mem} unchanged
 | 
|  |    320 |                      \end{tabular}\\\hline   
 | 
|  |    321 |       \hfill\texttt{'<'} & \begin{tabular}[t]{@{}l@{\hspace{2mm}}l@{}}
 | 
|  |    322 |                        $\bullet$ & $\texttt{pc} + 1$\\
 | 
|  |    323 |                        $\bullet$ & $\texttt{mp} - 1$\\
 | 
|  |    324 |                        $\bullet$ & \texttt{mem} unchanged
 | 
|  |    325 |                      \end{tabular}\\\hline   
 | 
|  |    326 |       \hfill\texttt{'+'} & \begin{tabular}[t]{@{}l@{\hspace{2mm}}l@{}}
 | 
|  |    327 |                        $\bullet$ & $\texttt{pc} + 1$\\
 | 
|  |    328 |                        $\bullet$ & $\texttt{mp}$ unchanged\\
 | 
|  |    329 |                        $\bullet$ & \texttt{mem} updated with \texttt{mp -> mem(mp) + 1}\\
 | 
|  |    330 |                      \end{tabular}\\\hline   
 | 
|  |    331 |       \hfill\texttt{'-'} & \begin{tabular}[t]{@{}l@{\hspace{2mm}}l@{}}
 | 
|  |    332 |                        $\bullet$ & $\texttt{pc} + 1$\\
 | 
|  |    333 |                        $\bullet$ & $\texttt{mp}$ unchanged\\
 | 
|  |    334 |                        $\bullet$ & \texttt{mem} updated with \texttt{mp -> mem(mp) - 1}\\
 | 
|  |    335 |                      \end{tabular}\\\hline   
 | 
|  |    336 |       \hfill\texttt{'.'} & \begin{tabular}[t]{@{}l@{\hspace{2mm}}l@{}}
 | 
|  |    337 |                        $\bullet$ & $\texttt{pc} + 1$\\
 | 
|  |    338 |                        $\bullet$ & $\texttt{mp}$ and \texttt{mem} unchanged\\
 | 
|  |    339 |                        $\bullet$ & print out \,\texttt{mem(mp)} as a character\\
 | 
|  |    340 |                      \end{tabular}\\\hline   
 | 
| 336 |    341 |       %\hfill\texttt{','} & \begin{tabular}[t]{@{}l@{\hspace{2mm}}l@{}}
 | 
|  |    342 |       %                 $\bullet$ & $\texttt{pc} + 1$\\
 | 
|  |    343 |       %                 $\bullet$ & $\texttt{mp}$ unchanged\\
 | 
|  |    344 |       %                 $\bullet$ & \texttt{mem} updated with \texttt{mp -> \textrm{input}}\\
 | 
|  |    345 |       %                 \multicolumn{2}{@{}l}{the input is given by \texttt{Console.in.read().toByte}}
 | 
|  |    346 |       %               \end{tabular}\\\hline   
 | 
| 218 |    347 |       \hfill\texttt{'['} & \begin{tabular}[t]{@{}l@{\hspace{2mm}}l@{}}
 | 
|  |    348 |                        \multicolumn{2}{@{}l}{if \texttt{mem(mp) == 0} then}\\
 | 
|  |    349 |                        $\bullet$ & $\texttt{pc = jumpRight(prog, pc + 1, 0)}$\\
 | 
|  |    350 |                        $\bullet$ & $\texttt{mp}$ and \texttt{mem} unchanged\medskip\\
 | 
|  |    351 |                        \multicolumn{2}{@{}l}{otherwise if \texttt{mem(mp) != 0} then}\\
 | 
|  |    352 |                        $\bullet$ & $\texttt{pc} + 1$\\
 | 
|  |    353 |                        $\bullet$ & $\texttt{mp}$ and \texttt{mem} unchanged\\
 | 
|  |    354 |                      \end{tabular}
 | 
|  |    355 |                      \\\hline   
 | 
|  |    356 |       \hfill\texttt{']'} & \begin{tabular}[t]{@{}l@{\hspace{2mm}}l@{}}
 | 
|  |    357 |                        \multicolumn{2}{@{}l}{if \texttt{mem(mp) != 0} then}\\
 | 
|  |    358 |                        $\bullet$ & $\texttt{pc = jumpLeft(prog, pc - 1, 0)}$\\
 | 
|  |    359 |                        $\bullet$ & $\texttt{mp}$ and \texttt{mem} unchanged\medskip\\
 | 
|  |    360 |                        \multicolumn{2}{@{}l}{otherwise if \texttt{mem(mp) == 0} then}\\
 | 
|  |    361 |                        $\bullet$ & $\texttt{pc} + 1$\\
 | 
|  |    362 |                        $\bullet$ & $\texttt{mp}$ and \texttt{mem} unchanged\\
 | 
| 336 |    363 |                            \end{tabular}\\\hline
 | 
|  |    364 |       \hfill\texttt{'*'} & \begin{tabular}[t]{@{}l@{\hspace{2mm}}l@{}}
 | 
|  |    365 |                        $\bullet$ & $\texttt{pc} + 1$\\
 | 
|  |    366 |                        $\bullet$ & $\texttt{mp}$ unchanged\\
 | 
| 337 |    367 |                        $\bullet$ & \texttt{mem} updated with \texttt{mp -> mem(mp) * mem(mp - 1)}\\
 | 
|  |    368 |                              \multicolumn{2}{@{}l}{this multiplies the content of the memory cells at
 | 
|  |    369 |                              \texttt{mp} and \texttt{mp - 1}}\\
 | 
|  |    370 |                              \multicolumn{2}{@{}l}{and stores the result at \texttt{mp}}
 | 
|  |    371 |                            \end{tabular}\\\hline
 | 
|  |    372 |       \hfill\texttt{'@'} & \begin{tabular}[t]{@{}l@{\hspace{2mm}}l@{}}
 | 
|  |    373 |                        $\bullet$ & $\texttt{pc} + 1$\\
 | 
|  |    374 |                        $\bullet$ & $\texttt{mp}$ unchanged\\
 | 
|  |    375 |                              $\bullet$ & \texttt{mem} updated with
 | 
|  |    376 |                                          \texttt{mem(mp) -> mem(mp - 1)}\\
 | 
|  |    377 |                              \multicolumn{2}{@{}l}{this updates the memory cell having the index stored at \texttt{mem(mp)},}\\
 | 
|  |    378 |                              \multicolumn{2}{@{}l}{with the value stored at \texttt{mem(mp - 1)},}
 | 
| 336 |    379 |                            \end{tabular}\\\hline
 | 
|  |    380 |       \hfill\texttt{'\#'} & \begin{tabular}[t]{@{}l@{\hspace{2mm}}l@{}}
 | 
|  |    381 |                        $\bullet$ & $\texttt{pc} + 1$\\
 | 
| 337 |    382 |                        $\bullet$ & $\texttt{mp}$ and \texttt{mem} unchanged\\
 | 
|  |    383 |                        $\bullet$ & print out \,\texttt{mem(mp)} as a number\\
 | 
| 336 |    384 |                      \end{tabular}\\\hline  
 | 
| 218 |    385 |       any other char & \begin{tabular}[t]{@{}l@{\hspace{2mm}}l@{}}
 | 
|  |    386 |                          $\bullet$ & $\texttt{pc} + 1$\\
 | 
|  |    387 |                          $\bullet$ & \texttt{mp} and \texttt{mem} unchanged
 | 
|  |    388 |                        \end{tabular}\\
 | 
|  |    389 |       \hline                 
 | 
|  |    390 |     \end{tabular}
 | 
| 337 |    391 |     \\\mbox{}\\[-10mm]\mbox{}
 | 
| 218 |    392 |   \end{center}
 | 
| 337 |    393 |   \caption{The rules for how commands in the brainf***++ language update the
 | 
|  |    394 |     program counter \texttt{pc},
 | 
| 230 |    395 |     the memory pointer \texttt{mp} and the memory \texttt{mem}.\label{comms}}
 | 
| 218 |    396 |   \end{figure}
 | 
|  |    397 | \end{itemize}\bigskip  
 | 
|  |    398 | 
 | 
| 268 |    399 | %%\newpage
 | 
| 233 |    400 | 
 | 
| 307 |    401 | \subsection*{Part B (4 Marks)}
 | 
| 218 |    402 | 
 | 
| 337 |    403 | I am sure you agree while it is fun to marvel at bf++-programs, like the
 | 
| 233 |    404 | Sierpinski triangle or the Mandelbrot program, being interpreted, it
 | 
| 337 |    405 | is much more fun to write a compiler for the bf++-language.
 | 
| 233 |    406 | 
 | 
|  |    407 | 
 | 
|  |    408 | \subsubsection*{Tasks (file bfc.scala)}
 | 
|  |    409 | 
 | 
|  |    410 | \begin{itemize}
 | 
| 337 |    411 | \item[(5)] Compilers, in general, attempt to make programs run
 | 
| 233 |    412 |   faster by precomputing as much information as possible
 | 
|  |    413 |   before running the program. In our case we can precompute the
 | 
|  |    414 |   addresses where we need to jump at the beginning and end of
 | 
|  |    415 |   loops. 
 | 
|  |    416 | 
 | 
|  |    417 |   For this write a function \texttt{jtable} that precomputes the ``jump
 | 
| 337 |    418 |   table'' for a bf++-program. This function takes a bf++-program 
 | 
| 233 |    419 |   as an argument and returns a \texttt{Map[Int, Int]}. The 
 | 
| 237 |    420 |   purpose of this Map is to record the information, in cases
 | 
|  |    421 |   a pc-position points to a '\texttt{[}' or a '\texttt{]}',
 | 
|  |    422 |   to which pc-position do we need to jump next?
 | 
| 233 |    423 |  
 | 
|  |    424 |   For example for the program
 | 
|  |    425 |     
 | 
|  |    426 |   \begin{center}
 | 
|  |    427 |     \texttt{+++++[->++++++++++<]>--<+++[->>++++++++++}
 | 
|  |    428 |     \texttt{<<]>>++<<----------[+>.>.<+<]}
 | 
|  |    429 |   \end{center}
 | 
|  |    430 | 
 | 
|  |    431 |   we obtain the Map (note the precise numbers might differ depending on white
 | 
|  |    432 |   spaces etc.~in the bf-program):
 | 
|  |    433 | 
 | 
|  |    434 |   \begin{center}
 | 
|  |    435 |   \texttt{Map(69 -> 61, 5 -> 20, 60 -> 70, 27 -> 44, 43 -> 28, 19 -> 6)}
 | 
|  |    436 |   \end{center}  
 | 
|  |    437 |   
 | 
|  |    438 |   This Map states that for the '\texttt{[}' on position 5, we need to
 | 
|  |    439 |   jump to position 20, which is just after the corresponding '\texttt{]}'.
 | 
|  |    440 |   Similarly, for the '\texttt{]}' on position 19, we need to jump to
 | 
|  |    441 |   position 6, which is just after the '\texttt{[}' on position 5, and so
 | 
|  |    442 |   on. The idea is to not calculate this information each time
 | 
|  |    443 |   we hit a bracket, but just look up this information in the 
 | 
|  |    444 |   \texttt{jtable}. 
 | 
|  |    445 | 
 | 
|  |    446 |   Then adapt the \texttt{compute} and \texttt{run} functions
 | 
|  |    447 |   from Part 1 in order to take advantage of the information
 | 
|  |    448 |   stored in the \texttt{jtable}. This means whenever \texttt{jumpLeft}
 | 
|  |    449 |   and \texttt{jumpRight} was called previously, you should look
 | 
|  |    450 |   up the jump address in the \texttt{jtable}. Feel free to reuse
 | 
|  |    451 |   the function \texttt{jumpLeft} and \texttt{jumpRight} for
 | 
|  |    452 |   calculating the \texttt{jtable}.\hfill{[1 Mark]}
 | 
|  |    453 | 
 | 
| 237 |    454 | \item[(6)] Compilers try to eliminate any ``dead'' code that could
 | 
|  |    455 |   slow down programs and also perform what is often called
 | 
|  |    456 |   \emph{peephole
 | 
|  |    457 |     optimisations}.\footnote{\url{https://en.wikipedia.org/wiki/Peephole_optimization}}
 | 
|  |    458 |   For the latter consider that it is difficult for compilers to
 | 
| 241 |    459 |   comprehend what is intended with whole programs, but they are very good
 | 
| 237 |    460 |   at finding out what small snippets of code do, and then try to
 | 
|  |    461 |   generate faster code for such snippets.
 | 
| 233 |    462 | 
 | 
| 337 |    463 |   In our case, dead code is everything that is not a bf++-command.
 | 
| 233 |    464 |   Therefore write a function \texttt{optimise} which deletes such
 | 
| 337 |    465 |   dead code from a bf++-program. Moreover this function should replace every substring
 | 
| 233 |    466 |   of the form \pcode{[-]} by a new command \texttt{0}. 
 | 
|  |    467 |   The idea is that the loop \pcode{[-]} just resets the
 | 
|  |    468 |   memory at the current location to 0. It is more efficient
 | 
| 237 |    469 |   to do this in a single step, rather than stepwise in a loop as in
 | 
| 337 |    470 |   the original bf++-programs.
 | 
| 218 |    471 | 
 | 
| 233 |    472 |   In the extended \texttt{compute3} and \texttt{run3} functions you should
 | 
|  |    473 |   implement this command by writing 0 to \pcode{mem(mp)}, that is use
 | 
|  |    474 |   \pcode{write(mem, mp, 0)} as the rule for the command \texttt{0}.
 | 
|  |    475 |   The easiest way to modify a string in this way is to use the regular
 | 
| 337 |    476 |   expression \pcode{"""[^<>+-.\\[\\]@\#*]"""}, which recognises everything that is 
 | 
|  |    477 |   not a bf++-command. Similarly, the
 | 
| 237 |    478 |   regular expression \pcode{"""\\[-\\]"""} finds all occurrences of \pcode{[-]}.  By using the Scala method \pcode{.replaceAll} you can replace substrings
 | 
|  |    479 |   with new strings.\\
 | 
|  |    480 |   \mbox{}\hfill{[1 Mark]}
 | 
| 233 |    481 | 
 | 
| 337 |    482 | \item[(7)] Finally, real compilers try to take advantage of modern
 | 
|  |    483 |   CPUs which often provide complex operations in hardware that can
 | 
|  |    484 |   combine many smaller instructions into a single faster instruction.
 | 
| 233 |    485 | 
 | 
| 237 |    486 |   In our case we can optimise the several single increments performed at a
 | 
| 233 |    487 |   memory cell, for example \pcode{++++}, by a single ``increment by
 | 
|  |    488 |   4''. For this optimisation we just have to make sure these single
 | 
| 237 |    489 |   increments are all next to each other. Similar optimisations should apply
 | 
| 233 |    490 |   for the bf-commands \pcode{-}, \pcode{<} and
 | 
|  |    491 |   \pcode{>}, which can all be replaced by extended versions that take
 | 
|  |    492 |   the amount of the increment (decrement) into account. We will do
 | 
| 337 |    493 |   this by introducing two-character bf++-commands. For example
 | 
| 233 |    494 | 
 | 
|  |    495 |   \begin{center}
 | 
|  |    496 |     \begin{tabular}{l|l}
 | 
|  |    497 |       original bf-cmds & replacement\\
 | 
|  |    498 |       \hline
 | 
|  |    499 |       \pcode{+} & \pcode{+A}\\
 | 
|  |    500 |       \pcode{++} & \pcode{+B}\\
 | 
|  |    501 |       \pcode{+++} & \pcode{+C}\\
 | 
|  |    502 |       \ldots{} & \ldots{}\\
 | 
|  |    503 |       \pcode{+++....++} & \pcode{+Z}\\
 | 
|  |    504 |       \hspace{5mm}(these are 26 \pcode{+}'s)\\
 | 
|  |    505 |     \end{tabular} 
 | 
|  |    506 |   \end{center}  
 | 
|  |    507 | 
 | 
|  |    508 | 
 | 
| 237 |    509 |   If there are more
 | 
|  |    510 |   than 26 \pcode{+}'s in a row, then more than one ``two-character''
 | 
| 233 |    511 |   bf-commands need to be generated (the idea is that more than
 | 
| 337 |    512 |   26 copies of a single bf++-command in a row is a rare occurrence in
 | 
|  |    513 |   actual bf++-programs). Similar replacements apply
 | 
| 237 |    514 |   for \pcode{-}, \pcode{<} and \pcode{>}, but
 | 
| 337 |    515 |   all other bf++-commands should be unaffected by this
 | 
| 233 |    516 |   change. 
 | 
|  |    517 | 
 | 
|  |    518 |   For this write a function \texttt{combine} which replaces sequences
 | 
|  |    519 |   of repeated increment and decrement commands by appropriate
 | 
| 237 |    520 |   two-character commands. In the functions \pcode{compute4} and
 | 
| 233 |    521 |   \pcode{run4}, the ``combine'' and the optimisation from (6) should
 | 
| 337 |    522 |   be performed. Make sure that when a two-character bf++-command is
 | 
| 233 |    523 |   encountered you need to increase the \pcode{pc}-counter by two in
 | 
| 237 |    524 |   order to progress to the next command. For example
 | 
| 233 |    525 | 
 | 
|  |    526 |   \begin{center}
 | 
|  |    527 |   \pcode{combine(optimise(load_bff("benchmark.bf")))}  
 | 
|  |    528 |   \end{center}  
 | 
|  |    529 | 
 | 
|  |    530 |   generates the improved program
 | 
|  |    531 | 
 | 
|  |    532 |   \begin{center}
 | 
|  |    533 |   \pcode{>A+B[<A+M>A-A]<A[[}\hspace{3mm}\ldots{}
 | 
|  |    534 |   \end{center}  
 | 
|  |    535 | 
 | 
|  |    536 |   for the original benchmark program
 | 
|  |    537 | 
 | 
|  |    538 |   \begin{center}
 | 
|  |    539 |     \pcode{>++[<+++++++++++++>-]<[[}\hspace{3mm}\ldots
 | 
|  |    540 |   \end{center}    
 | 
|  |    541 | 
 | 
| 241 |    542 |   As you can see, the compiler bets on saving a lot of time on the
 | 
|  |    543 |   \pcode{+B} and \pcode{+M} steps so that the optimisations is
 | 
| 233 |    544 |   worthwhile overall (of course for the \pcode{>A}'s and so on, the compiler incurs a
 | 
|  |    545 |   penalty). Luckily, after you have performed all
 | 
|  |    546 |   optimisations in (5) - (7), you can expect that the
 | 
| 234 |    547 |   \pcode{benchmark.bf} program runs four to five times faster.
 | 
|  |    548 |   You can also test whether your compiler produces the correct result
 | 
| 337 |    549 |   by  testing for example
 | 
| 234 |    550 | 
 | 
|  |    551 |   \begin{center}
 | 
|  |    552 |   \pcode{run(load_bff("sierpinski.bf")) == run4(load_bff("sierpinski.bf"))}
 | 
|  |    553 |   \end{center}
 | 
|  |    554 | 
 | 
|  |    555 |   which should return true for all the different compiler stages. \\ 
 | 
|  |    556 |   \mbox{}\hfill{[2 Marks]}
 | 
| 233 |    557 | \end{itemize}  
 | 
| 6 |    558 | 
 | 
|  |    559 | \end{document}
 | 
|  |    560 | 
 | 
| 68 |    561 | 
 | 
| 6 |    562 | %%% Local Variables: 
 | 
|  |    563 | %%% mode: latex
 | 
|  |    564 | %%% TeX-master: t
 | 
|  |    565 | %%% End: 
 |