8: Procedural Programming in Assembly

Last updated
Save as PDF

Page ID: 76130

$ \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}}$

The structured programming paradigm says that all programs can be built using block structures based on just three (3) types of program control structures. These structures are:

sequences, where programs execute statements in order one after another
branches, where programs to jump to other points in a program
loops, that allow programs to execute a fragment of code multiple times

These three structures are applied to blocks of code. Block structure implies that the block can be treated as a single statement. In practical terms, this means that you can enter the block at the first statement in the block and leave it after the last statement of the block. Effectively, a block is a self-contained unit. While a statement in a block can call a function or method, any branching other than a subroutine call must be to a point inside the currently executing block.

Most modern HLLs are implemented based on block structure with these three program control structures. Most languages include some other structure elements that can be argued are nonstructured such as exception handling, continue, and break statements. The reason for this is that reasoning about structures, what this text will call programming plans, is nearly always more effective than trying to reason about logic flow.

Note that structured programming constructs are not available in assembly language. As was pointed out in Chapter 7 on function execution, the only way to control program execution sequence in assembly language is through the $pc register. Therefore, in assembly there are no native structured program constructs. This does not mean that an assembly language programmer should abandon the principals of structured programming. What the lack of language based structured programming constructs means is that the assembler programmer is responsible for writing code which aligns with these principals. Not following structured programming principals in assembly is a sure way to create spaghetti code, or code where control is passed uncontrolled around the program, much like the noodles intertwine in a bowl of spaghetti, and following individual strands becomes difficult.

This chapter will introduce pseudo code structure programming control structures similar to those in Java/C/C++/C#. Programmers familiar with those languages should be able to follow the programs with no problems. The text will then show how to translate each control structure from pseudo code into assembly. This text will argue for an approach that treats assembly language programs as a translation of logic that can be implemented in pseudo code, or even a HLL. By understanding the underlying assembly translation, it is hoped that readers who are novice programmers will gain a better understanding and insight into how to structure functions and programs.

All programs in this chapter will be preceded by a pseudo code implementation of the algorithm. Translation from the pseudo code into MIPS assembly will be shown, with the program always representing a translation from the pseudo code. No programs will be developed directly into assembly. The reason for this is though the direct implementation of the programs in assembly allows more flexibility, programmers in assembly language programming often implement these programs in very unstructured fashions which often result in poor programs and can develop into poor understanding and practices.

To reemphasize the point, it has been the experience of the author that although many new assembly language programmers often try to avoid the structured programming paradigm and reason through an assembly language program, the results are seldom satisfactory. The reader is strongly advised to follow the principals outlined in this chapter, and not attempt to develop the programs directly in assembly language.