8.2: Use of goto statements

Last updated
Save as PDF

Page ID: 76132

$ \newcommand{\vecs}[1]{\overset { \scriptstyle \rightharpoonup} {\mathbf{#1}} } $ $ \newcommand{\vecd}[1]{\overset{-\!-\!\rightharpoonup}{\vphantom{a}\smash {#1}}} $$\newcommand{\id}{\mathrm{id}}$ $ \newcommand{\Span}{\mathrm{span}}$ $ \newcommand{\kernel}{\mathrm{null}\,}$ $ \newcommand{\range}{\mathrm{range}\,}$ $ \newcommand{\RealPart}{\mathrm{Re}}$ $ \newcommand{\ImaginaryPart}{\mathrm{Im}}$ $ \newcommand{\Argument}{\mathrm{Arg}}$ $ \newcommand{\norm}[1]{\| #1 \|}$ $ \newcommand{\inner}[2]{\langle #1, #2 \rangle}$ $ \newcommand{\Span}{\mathrm{span}}$ $\newcommand{\id}{\mathrm{id}}$ $ \newcommand{\Span}{\mathrm{span}}$ $ \newcommand{\kernel}{\mathrm{null}\,}$ $ \newcommand{\range}{\mathrm{range}\,}$ $ \newcommand{\RealPart}{\mathrm{Re}}$ $ \newcommand{\ImaginaryPart}{\mathrm{Im}}$ $ \newcommand{\Argument}{\mathrm{Arg}}$ $ \newcommand{\norm}[1]{\| #1 \|}$ $ \newcommand{\inner}[2]{\langle #1, #2 \rangle}$ $ \newcommand{\Span}{\mathrm{span}}$$\newcommand{\AA}{\unicode[.8,0]{x212B}}$

Many readers of this text will quickly recognize the main mechanism for program control in assembly, the branch statement, as simply a goto statement. These readers have often been told since they started programming that goto statements are evil and should never be used. The reasoning behind this rule is seldom explained, and an almost religious adherence has developed to the principal that goto statements are always suspect and should never be used. Like most unexamined principles, this simply misses the larger point.

The problem with goto statements is that they allow unrestricted branching to any point in a program. Indeed, this type of unrestricted branching leads to many obfuscated programs before structured computing. However, with the advent of structured programming languages, the use of the term spaghetti code has even gone out of the normal programmer's vernacular. But it was never the use of goto statements that lead to obfuscated programs; it was programmers’ penchants for doing the expedient that resulted in unorganized programs. The unrestricted goto statement never was the problem, it simply was the mechanism that allowed the programmers to create problems.

In assembly language, the only method of program control is through the $pc, and the only way to implement branch statements. The branch statements themselves will not lead to unorganized programs, but the unorganized thoughts of the programmers will. So, this chapter will not teach how to reason about assembly language programs. All programs will be first structured in pseudo code and then translated into assembly language. Readers who follow the methodology presented in this text will never encounter an unrestricted goto. All branch statements will be explicitly structured, and all branches will be within the code blocks that contain them, just as in structured programming languages. So, the branch statements in this text are not evil, and the idea that somehow simply using a goto is wrong needs to be modified in the reader’s mind.