# source:src/ASM/CPP2012-policy/problem.tex@2679

Last change on this file since 2679 was 2099, checked in by boender, 8 years ago
• added reference to Intel dev manual
File size: 10.1 KB
RevLine
[2054]1\section{Introduction}
[1889]2
3The problem of branch displacement optimisation, also known as jump encoding, is
[2091]4a well-known problem in assembler design~\cite{Hyde2006}. It is caused by the
5fact that in many architecture sets, the encoding (and therefore size) of some
6instructions depends on the distance to their operand (the instruction 'span').
[2096]7The branch displacement optimisation problem consists of encoding these
[2091]8span-dependent instructions in such a way that the resulting program is as
9small as possible.
[1889]10
[2085]11This problem is the subject of the present paper. After introducing the problem
12in more detail, we will discuss the solutions used by other compilers, present
[2096]13the algorithm we use in the CerCo assembler, and discuss its verification,
14that is the proofs of termination and correctness using the Matita proof
15assistant~\cite{Asperti2007}.
[2085]16
17The research presented in this paper has been executed within the CerCo project
18which aims at formally verifying a C compiler with cost annotations. The
19target architecture for this project is the MCS-51, whose instruction set
20contains span-dependent instructions. Furthermore, its maximum addressable
[2096]21memory size is very small (64 Kb), which makes it important to generate
[2085]22programs that are as small as possible.
[1889]23
[2085]24With this optimisation, however, comes increased complexity and hence
[2091]25increased possibility for error. We must make sure that the branch instructions
26are encoded correctly, otherwise the assembled program will behave
27unpredictably.
[2085]28
29\section{The branch displacement optimisation problem}
30
[2091]31In most modern instruction sets that have them, the only span-dependent
32instructions are branch instructions. Taking the ubiquitous x86-64 instruction
[2096]33set as an example, we find that it contains eleven different forms of the
[2091]34unconditional branch instruction, all with different ranges, instruction sizes
[2085]35and semantics (only six are valid in 64-bit mode, for example). Some examples
[2085]37
[1889]38\begin{figure}[h]
[2085]39\begin{center}
[1889]40\begin{tabular}{|l|l|l|}
41\hline
42Instruction & Size (bytes) & Displacement range \\
43\hline
44Short jump & 2 & -128 to 127 bytes \\
45Relative near jump & 5 & $-2^{32}$ to $2^{32}-1$ bytes \\
46Absolute near jump & 6 & one segment (64-bit address) \\
47Far jump & 8 & entire memory \\
48\hline
49\end{tabular}
[2085]50\end{center}
[2091]51\caption{List of x86 branch instructions}
[1889]52\label{f:x86jumps}
53\end{figure}
54
55The chosen target architecture of the CerCo project is the Intel MCS-51, which
[2085]56features three types of branch instructions (or jump instructions; the two terms
[2096]57are used interchangeably), as shown in Figure~\ref{f:mcs51jumps}.
[1889]58
59\begin{figure}[h]
[2085]60\begin{center}
[1889]61\begin{tabular}{|l|l|l|l|}
62\hline
63Instruction & Size    & Execution time & Displacement range \\
64            & (bytes) & (cycles) & \\
65\hline
66SJMP (short jump') & 2 & 2 & -128 to 127 bytes \\
[2085]67AJMP (absolute jump') & 2 & 2 & one segment (11-bit address) \\
[1889]68LJMP (long jump') & 3 & 3 & entire memory \\
69\hline
70\end{tabular}
[2085]71\end{center}
[2091]72\caption{List of MCS-51 branch instructions}
[1889]73\label{f:mcs51jumps}
74\end{figure}
75
[2091]76Conditional branch instructions are only available in short form, which
77means that a conditional branch outside the short address range has to be
78encoded using three branch instructions (for instructions whose logical
79negation is available, it can be done with two branch instructions, but for
[2096]80some instructions this is not available); the call instruction is
[2091]81only available in absolute and long forms.
[1889]82
[2096]83Note that even though the MCS-51 architecture is much less advanced and simpler
84than the x86-64 architecture, the basic types of branch instruction
[2091]85remain the same: a short jump with a limited range, an intra-segment jump and a
86jump that can reach the entire available memory.
[1889]87
[2096]88Generally, in code fed to the assembler as input, the only
89difference between branch instructions is semantics, not span. This
[2091]90means that a distinction is made between an unconditional branch and the
91several kinds of conditional branch, but not between their short, absolute or
92long variants.
[2085]93
[2091]94The algorithm used by the assembler to encode these branch instructions into
95the different machine instructions is known as the {\em branch displacement
[2096]96algorithm}. The optimisation problem consists of finding as small an encoding as
[2091]97possible, thus minimising program length and execution time.
[1889]98
99This problem is known to be NP-complete~\cite{Robertson1979,Szymanski1978},
100which could make finding an optimal solution very time-consuming.
101
[2085]102The canonical solution, as shown by Szymanski~\cite{Szymanski1978} or more
103recently by Dickson~\cite{Dickson2008} for the x86 instruction set, is to use a
[2096]104fixed point algorithm that starts with the shortest possible encoding (all
105branch instruction encoded as short jumps, which is likely not a correct
[2091]106solution) and then iterates over the program to re-encode those branch
107instructions whose target is outside their range.
[1889]108
[1889]110
[2049]111In both papers mentioned above, the encoding of a jump is only dependent on the
112distance between the jump and its target: below a certain value a short jump
113can be used; above this value the jump must be encoded as a long jump.
[1889]114
[2064]115Here, termination of the smallest fixed point algorithm is easy to prove. All
[2091]116branch instructions start out encoded as short jumps, which means that the
117distance between any branch instruction and its target is as short as possible.
118If, in this situation, there is a branch instruction $b$ whose span is not
119within the range for a short jump, we can be sure that we can never reach a
120situation where the span of $j$ is so small that it can be encoded as a short
121jump. This argument continues to hold throughout the subsequent iterations of
[2096]122the algorithm: short jumps can change into long jumps, but not \emph{vice versa},
123as spans only increase. Hence, the algorithm either terminates early when a fixed
[2091]124point is reached or when all short jumps have been changed into long jumps.
[1889]125
126Also, we can be certain that we have reached an optimal solution: a short jump
127is only changed into a long jump if it is absolutely necessary.
128
129However, neither of these claims (termination nor optimality) hold when we add
[2096]130the absolute jump, as with absolute jumps, the encoding of a branch
[2091]131instruction no longer depends only on the distance between the branch
132instruction and its target: in order for an absolute jump to be possible, they
133need to be in the same segment (for the MCS-51, this means that the first 5
134bytes of their addresses have to be equal). It is therefore entirely possible
135for two branch instructions with the same span to be encoded in different ways
136(absolute if the branch instruction and its target are in the same segment,
137long if this is not the case).
[1889]138
[2096]139\begin{figure}[ht]
140\begin{alltt}
141    jmp X
142    \vdots
143L$$\sb{0}$$:
144    \vdots
145    jmp L$$\sb{0}$$
146\end{alltt}
147\caption{Example of a program where a long jump becomes absolute}
148\label{f:term_example}
149\end{figure}
150
151This invalidates our earlier termination argument: a branch instruction, once encoded
[2091]152as a long jump, can be re-encoded during a later iteration as an absolute jump.
[2096]153Consider the program shown in Figure~\ref{f:term_example}. At the start of the
[2091]154first iteration, both the branch to {\tt X} and the branch to $\mathtt{L}_{0}$
155are encoded as small jumps. Let us assume that in this case, the placement of
156$\mathtt{L}_{0}$ and the branch to it are such that $\mathtt{L}_{0}$ is just
157outside the segment that contains this branch. Let us also assume that the
158distance between $\mathtt{L}_{0}$ and the branch to it are too large for the
159branch instruction to be encoded as a short jump.
[1889]160
[2091]161All this means that in the second iteration, the branch to $\mathtt{L}_{0}$ will
162be encoded as a long jump. If we assume that the branch to {\tt X} is encoded as
163a long jump as well, the size of the branch instruction will increase and
164$\mathtt{L}_{0}$ will be propelled' into the same segment as its branch
165instruction, because every subsequent instruction will move one byte forward.
166Hence, in the third iteration, the branch to $\mathtt{L}_{0}$ can be encoded as
167an absolute jump. At first glance, there is nothing that prevents us from
[2096]168constructing a configuration where two branch instructions interact in such a
169way as to iterate indefinitely between long and absolute encodings.
[1889]170
[2096]171This situation mirrors the explanation by Szymanski~\cite{Szymanski1978} of why
172the branch displacement optimisation problem is NP-complete. In this explanation,
173a condition for NP-completeness is the fact that programs be allowed to contain
174{\em pathological} jumps. These are branch instructions that can normally not be
175encoded as a short(er) jump, but gain this property when some other branch
176instructions are encoded as a long(er) jump. This is exactly what happens in
177Figure~\ref{f:term_example}. By encoding the first branch instruction as a long
178jump, another branch instruction switches from long to absolute (which is
179shorter).
[1889]180
[2096]181In addition, our previous optimality argument no longer holds. Consider the program
182shown in Figure~\ref{f:opt_example}. Suppose that the distance between
[1889]183$\mathtt{L}_{0}$ and $\mathtt{L}_{1}$ is such that if {\tt jmp X} is encoded
184as a short jump, there is a segment border just after $\mathtt{L}_{1}$. Let
[2091]185us also assume that the three branches to $\mathtt{L}_{1}$ are all in the same
[1889]186segment, but far enough away from $\mathtt{L}_{1}$ that they cannot be encoded
187as short jumps.
188
[2096]189\begin{figure}[ht]
[1889]190\begin{alltt}
191L$$\sb{0}$$: jmp X
192X:
193    \vdots
194L$$\sb{1}$$:
195    \vdots
196    jmp L$$\sb{1}$$
197    \vdots
198    jmp L$$\sb{1}$$
199    \vdots
200    jmp L$$\sb{1}$$
201    \vdots
202\end{alltt}
203\caption{Example of a program where the fixed-point algorithm is not optimal}
204\label{f:opt_example}
205\end{figure}
[2096]206
207Then, if {\tt jmp X} were to be encoded as a short jump, which is clearly
208possible, all of the branches to $\mathtt{L}_{1}$ would have to be encoded as
209long jumps. However, if {\tt jmp X} were to be encoded as a long jump, and
210therefore increase in size, $\mathtt{L}_{1}$ would be `propelled' across the
211segment border, so that the three branches to $\mathtt{L}_{1}$ could be encoded
212as absolute jumps. Depending on the relative sizes of long and absolute jumps,
213this solution might actually be smaller than the one reached by the smallest
214fixed point algorithm.
Note: See TracBrowser for help on using the repository browser.