Regularity
From Maze
Contents[hide] |
The Grid: Regularity in Space
Repeating: Regularity in Time and Process
The Flow of Control
In any imperative programming language, commands are processed in a particular order that relates to the left-to-right, then top-to-bottom path that the Western reader's eyes stereotypically take along a page. If one types in two PRINT commands directly to the Commodore 64's BASIC interpreter, with a colon between them, like so:
PRINT "FIRST": PRINT "SECOND"
The result is
FIRST SECOND
The command on the left is executed first; then, probably not very surprisingly, the command on the right is carried out. In executing the following program, the topmost, leftmost command is run first, then the one to the right, and then the one on the next line, so that three lines that read FIRST, SECOND, and THIRD are printed:
10 PRINT "FIRST": PRINT "SECOND" 20 PRINT "THIRD"
The order in which these two lines are actually typed in by the programmer is completely irrelevant to how the program runs. The lines of a BASIC program are executed based on their line numbers, not based on when lines were entered.
There are some important ways to complicate this straightforward program flow. All of these ways involve branching, which causes program flow to continue at some other command rather than what would is, according to left-to-right, top-to-bottom program structure, the next one.
At the low level of machine code and its execution by the processor, the way program flow works is similar. Machine language is a sequence of numbers, and the next number is usually processed. However, an executing machine language program, like a high-level program in BASIC or another imperative language, can either continue to process the next instruction or can move out of sequence to process a different instruction. The standard case is when a processor continues to the next machine language instruction, just as the reader of a text moves to the next word or line. This involves incrementing the program counter so that it points to the place where the next instruction is located in memory. If the current instruction is one that can change the flow of control, however, the program may jump or branch to a new memory location and a new piece of code.
Conditional and Unconditional Branching
There are two essential ways that the flow of control can change and a program can "branch," or continue at a new point. An unconditional branch always directs the program to jump to a new location, like the instruction "Go directly to Jail -- do not pass Go" in Monopoly. The assembly mnemonic for an unconditional branch is JMP; the corresponding BASIC keyword is GOTO.
When an unconditional branch is used to point back to an earlier instruction, it can accomplish repetition in process. In 10 PRINT, the GOTO command is used to cause the program to loop, so that the PRINT command is repeated again and again.
The other type of branch is a conditional branch, a type of instruction that is critical to general-purpose computing. There are many different types of conditional branches in assembly, since there are many different types of conditions. BEQ is "branch if equal," for instance; when used after a comparison (CMP), the branch will be taken only if the compared values are equal. BMI, "branch if minus," checks to see if the last computation resulted in a negative value. In BASIC, using the IF ... THEN statement is the most straightforward way to accomplish a conditional branch, as this program demonstrates:
10 INPUT A$ 20 IF A$ = "1" THEN PRINT "YOU TYPED ONE!" : END 30 PRINT "SOMETHING ELSE..."
If, after running this program, the user types just the digit "1" and then presses RETURN, all of the statements on line 20 will be executed. "YOU TYPED ONE!" will be printed and then the program will terminate as END instructs. This is another way to change the flow of the program, of course: use END or STOP to terminate the program. If STOP is used, the CONTINUE command can be issued to pick up where the program left off.
If the user types anything else before pressing RETURN, the flow of control moves to line 30; both the first PRINT statement and the END are skipped. "SOMETHING ELSE..." is printed instead.
This program, although written differently, does exactly the same thing:
10 INPUT A$ 20 IF A$ = "1" THEN GOTO 40 30 PRINT "SOMETHING ELSE..." : END 40 PRINT "YOU TYPED ONE!"
Instead of using the IF ... THEN to directly determine whether two statements (the PRINT and END statements) should be executed, this one changes the flow of control with GOTO. The GOTO statement is used to skip ahead past PRINT "SOMETHING ELSE..." and END to line 40. Although this isn't a very exciting program, it shows that unconditional branching can be used to move ahead in the sequence of lines; there is nothing about GOTO that means it must be used to repeat or loop.
Although there is no IF ... THEN statement in 10 PRINT, and the program does not by any interpretation contain a conditional branch, this short program does accomplish a very small-scale sort of variation. By computing 205.5+RND(1) and passing that value to the function CHR$, the program prints either PETSCII character 205 or PETSCII character 206. This variation between two characters is a one-bit variation, a selection from the smallest possible set of options. Yet, in combination with the regularity of a repeating processes and the regularity of the Commodore 64's screen grid, these selections take shape as something evocative and visually interesting.
