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:
|