Translating Fundamental Program Structures to Assembly
Flow Charting
In the 1960s, programmers tended to write what we today call spaghetti
code: code with an obscure flow of control, in which branches tended
to be both from and to places in the code that were convenient
regardless of the effect on the overall flow of the program. ``Flow
charting'' was developed as a means of trying to visualize the flow of
a program. There was quite a language of flow charting; we are only
interested in two symbols: the process and the decision.
- Process
-
|
A process is simply a sequence of events with a single entry
point and a single exit point. The simplest process is a single
instruction.
|
- Decision
-
|
A decision is just what the name implies: a decision is made as
to whether there should be a branch in the flow of control.
|
Fundamental Forms
When structured programming was a new programming methodology
(early 1970s), Dijkstra observed that any algorithm can be described
by using nested sequences of just three fundamental forms defined in
terms of processes and sequences. Each of these forms is itself a
process. The forms are:
- Sequence
-
|
A sequence is a series of processes with no branches between
them.
|
- If-Then-Else
-
|
An if-then-else is a decision and two sub-processes. Either of
the sub-sequences may be empty.
|
- While-Do
-
|
The While-Do is a a decision and a process; the process is
executed over and over again while the condition remains true (the
text refers to this form as a do-while; due to the fact that a repeat
is a control structure in C that conforms to the do-until structure in
the text, I want to call it a While-Do like a while loop in C where
the condition is at the top).
|
Using the languages in common use at the time, writing structured code
required quite a bit of discipline on the part of the programmer.
Using modern languages, the mechanics of writing structured code are
taken care of for you, since the sort of nested control structures
provided by modern procedural languages reflect these fundamental
forms (as well as extensions such as break and
continue statements, and C for and
switch statements).
An historical aside to mention here is that one of the reasons
programmers gave at the time for objecting to structured programming
was that they felt that they could better optimize their code if they
had the freedom to write spaghetti code. Today, compilers can
optimize code better than people can, and are best able to work with
structured code.
We can translate a program written in a high level language into
assembly code by recognizing the fundamental forms that are present in
the code, and translating them into assembly code.