source: src/ASM/CPP2012-policy/algorithm.tex @ 3361

Last change on this file since 3361 was 3361, checked in by sacerdot, 6 years ago

15 pages version

File size: 10.1 KB
Line 
1\section{Our algorithm}
2
3\subsection{Design decisions}
4
5Given the NP-completeness of the problem, finding optimal solutions
6(using, for example, a constraint solver) can potentially be very costly.
7
8The SDCC compiler~\cite{SDCC2011}, which has a backend targetting the MCS-51
9instruction set, simply encodes every branch instruction as a long jump
10without taking the distance into account. While certainly correct (the long
11jump can reach any destination in memory) and a very fast solution to compute,
12it results in a less than optimal solution.
13
14On the other hand, the {\tt gcc} compiler suite~\cite{GCC2012}, while compiling
15C on the x86 architecture, uses a greatest fix point algorithm. In other words,
16it starts with all branch instructions encoded as the largest jumps
17available, and then tries to reduce the size of branch instructions as much as
18possible.
19
20Such an algorithm has the advantage that any intermediate result it returns
21is correct: the solution where every branch instruction is encoded as a large
22jump is always possible, and the algorithm only reduces those branch
23instructions whose destination address is in range for a shorter jump.
24The algorithm can thus be stopped after a determined number of steps without
25sacrificing correctness.
26
27The result, however, is not necessarily optimal. Even if the algorithm is run
28until it terminates naturally, the fixed point reached is the {\em greatest}
29fixed point, not the least fixed point. Furthermore, {\tt gcc} (at least for
30the x86 architecture) only uses short and long jumps. This makes the algorithm
31more efficient, as shown in the previous section, but also results in a less
32optimal solution.
33
34In the CerCo assembler, we opted at first for a least fixed point algorithm,
35taking absolute jumps into account.
36
37Here, we ran into a problem with proving termination, as explained in the
38previous section: if we only take short and long jumps into account, the jump
39encoding can only switch from short to long, but never in the other direction.
40When we add absolute jumps, however, it is theoretically possible for a branch
41instruction to switch from absolute to long and back, as previously explained.
42
43Proving termination then becomes difficult, because there is nothing that
44precludes a branch instruction from oscillating back and forth between absolute
45and long jumps indefinitely.
46
47To keep the algorithm in the same complexity class and more easily
48prove termination, we decided to explicitly enforce the `branch instructions
49must always grow longer' requirement: if a branch instruction is encoded as a
50long jump in one iteration, it will also be encoded as a long jump in all the
51following iterations. Therefore the encoding of any branch instruction
52can change at most two times: once from short to absolute (or long), and once
53from absolute to long.
54
55There is one complicating factor. Suppose that a branch instruction is encoded
56in step $n$ as an absolute jump, but in step $n+1$ it is determined that
57(because of changes elsewhere) it can now be encoded as a short jump. Due to
58the requirement that the branch instructions must always grow longer,
59the branch encoding will be encoded as an absolute jump in step
60$n+1$ as well.
61
62This is not necessarily correct. A branch instruction that can be
63encoded as a short jump cannot always also be encoded as an absolute jump, as a
64short jump can bridge segments, whereas an absolute jump cannot. Therefore,
65in this situation we have decided to encode the branch instruction as a long
66jump, which is always correct.
67
68The resulting algorithm, while not optimal, is at least as good as the ones
69from SDCC and {\tt gcc}, and potentially better. Its complexity remains
70the same (there are at most $2n$ iterations, where $n$ is the number of branch
71instructions in the program).
72
73\subsection{The algorithm in detail}
74
75The branch displacement algorithm forms part of the translation from
76pseudocode to assembler. More specifically, it is used by the function that
77translates pseudo-addresses (natural numbers indicating the position of the
78instruction in the program) to actual addresses in memory.
79
80Our original intention was to have two different functions, one function
81$\mathtt{policy}: \mathbb{N} \rightarrow \{\mathtt{short\_jump},
82\mathtt{absolute\_jump}, \mathtt{long\_jump}\}$ to associate jumps to their
83intended encoding, and a function $\sigma: \mathbb{N} \rightarrow
84\mathtt{Word}$ to associate pseudo-addresses to machine addresses. $\sigma$
85would use $\mathtt{policy}$ to determine the size of jump instructions.
86
87This turned out to be suboptimal from the algorithmic point of view and
88impossible to prove correct.
89
90From the algorithmic point of view, in order to create the $\mathtt{policy}$
91function, we must necessarily have a translation from pseudo-addresses
92to machine addresses (i.e. a $\sigma$ function): in order to judge the distance
93between a jump and its destination, we must know their memory locations.
94Conversely, in order to create the $\sigma$ function, we need to have the
95$\mathtt{policy}$ function, otherwise we do not know the sizes of the jump
96instructions in the program.
97
98Much the same problem appears when we try to prove the algorithm correct: the
99correctness of $\mathtt{policy}$ depends on the correctness of $\sigma$, and
100the correctness of $\sigma$ depends on the correctness of $\mathtt{policy}$.
101
102We solved this problem by integrating the $\mathtt{policy}$ and $\sigma$
103algorithms. We now have a function
104$\sigma: \mathbb{N} \rightarrow \mathtt{Word} \times \mathtt{bool}$ which
105associates a pseudo-address to a machine address. The boolean denotes a forced
106long jump; as noted in the previous section, if during the fixed point
107computation an absolute jump changes to be potentially re-encoded as a short
108jump, the result is actually a long jump. It might therefore be the case that
109jumps are encoded as long jumps without this actually being necessary, and this
110information needs to be passed to the code generating function.
111
112The assembler function encodes the jumps by checking the distance between
113source and destination according to $\sigma$, so it could select an absolute
114jump in a situation where there should be a long jump. The boolean is there
115to prevent this from happening by indicating the locations where a long jump
116should be encoded, even if a shorter jump is possible. This has no effect on
117correctness, since a long jump is applicable in any situation.
118
119\begin{figure}[t]
120\begin{algorithmic}
121\Function{f}{$labels$,$old\_sigma$,$instr$,$ppc$,$acc$}
122        \State $\langle added, pc, sigma \rangle \gets acc$
123        \If {$instr$ is a backward jump to $j$}
124                \State $length \gets \mathrm{jump\_size}(pc,sigma_1(labels(j)))$
125        \ElsIf {$instr$ is a forward jump to $j$}
126                \State $length \gets \mathrm{jump\_size}(pc,old\_sigma_1(labels(j))+added)$
127        \Else
128                \State $length \gets \mathtt{short\_jump}$
129        \EndIf
130        \State $old\_length \gets \mathrm{old\_sigma_1}(ppc)$
131        \State $new\_length \gets \mathrm{max}(old\_length, length)$
132        \State $old\_size \gets \mathrm{old\_sigma_2}(ppc)$
133        \State $new\_size \gets \mathrm{instruction\_size}(instr,new\_length)$
134        \State $new\_added \gets added+(new\_size-old\_size)$
135        \State $new\_sigma \gets old\_sigma$
136        \State $new\_sigma_1(ppc+1) \gets pc+new\_size$
137        \State $new\_sigma_2(ppc) \gets new\_length$ \\
138        \Return $\langle new\_added, pc+new\_size, new\_sigma \rangle$
139\EndFunction
140\end{algorithmic}
141\caption{The heart of the algorithm}
142\label{f:jump_expansion_step}
143\end{figure}
144
145The algorithm, shown in Figure~\ref{f:jump_expansion_step}, works by folding the
146function {\sc f} over the entire program, thus gradually constructing $sigma$.
147This constitutes one step in the fixed point calculation; successive steps
148repeat the fold until a fixed point is reached.
149
150Parameters of the function {\sc f} are:
151\begin{itemize}
152        \item a function $labels$ that associates a label to its pseudo-address;
153        \item $old\_sigma$, the $\sigma$ function returned by the previous
154                iteration of the fixed point calculation;
155        \item $instr$, the instruction currently under consideration;
156        \item $ppc$, the pseudo-address of $instr$;
157        \item $acc$, the fold accumulator, which contains $pc$ (the highest memory
158                address reached so far), $added$ (the number of bytes added to the program
159                size with respect to the previous iteration), and of course $sigma$, the
160                $\sigma$ function under construction.
161\end{itemize}
162
163The first two are parameters that remain the same through one iteration, the
164final three are standard parameters for a fold function (including $ppc$,
165which is simply the number of instructions of the program already processed).
166
167The $\sigma$ functions used by {\sc f} are not of the same type as the final
168$\sigma$ function: they are of type
169$\sigma: \mathbb{N} \rightarrow \mathbb{N} \times \{\mathtt{short\_jump},
170\mathtt{absolute\_jump},\mathtt{long\_jump}\}$; a function that associates a
171pseudo-address with a memory address and a jump length. We do this to be able
172to ease the comparison of jump lengths between iterations. In the algorithm,
173we use the notation $sigma_1(x)$ to denote the memory address corresponding to
174$x$, and $sigma_2(x)$ to denote the jump length corresponding to $x$.
175
176Note that the $\sigma$ function used for label lookup varies depending on
177whether the label is behind our current position or ahead of it. For
178backward branches, where the label is behind our current position, we can use
179$sigma$ for lookup, since its memory address is already known. However, for
180forward branches, the memory address of the address of the label is not yet
181known, so we must use $old\_sigma$.
182
183We cannot use $old\_sigma$ without change: it might be the case that we have
184already increased the size of some branch instructions before, making the program
185longer and moving every instruction forward. We must compensate for this by
186adding the size increase of the program to the label's memory address according
187to $old\_sigma$, so that branch instruction spans do not get compromised.
188
189Note also that we add the pc to $sigma$ at location $ppc+1$, whereas we add the
190jump length at location $ppc$. We do this so that $sigma(ppc)$ will always
191return a pair with the start address of the instruction at $ppc$ and the
192length of its branch instruction (if any); the end address of the program can
193be found at $sigma(n+1)$, where $n$ is the number of instructions in the
194program.
Note: See TracBrowser for help on using the repository browser.