Section 2 - Commodore Computers

May, 1982. 1982, Issue l$Sue 7& 2.4 COMPUTE! COMPUTlI 143
Considering
Considering
SpaceAnd
Time In The
Atari
Atari
C Michael Levy and G rant Levy
C. Michael Levy and Grant Levy
Gainesville, FL
Would you like to know how to speed up some of
your programs, or make them use up less memory?
As everyone comes to learn as they gam gain experience
in m programming, programmmg, small and often very subtle
changes cha.nges in even very simple programs can n have
major consequences. Consider the following owing four
programs. Each has exactly y 1000 lines. Each makes
two references to variable B, 994 assignments to
variable vanable A, contain six GOSUBs COSUBs and six RETURNs,
one POKE, one PEEK, one PRINT and one STOP.
They all achieve the same end: they determine that
the value of variable A is zero and print the number
of clock ticks (each lasting l/60th 1I60th sec.) required for
execulIon of the program. They are equivalent,
execution of the program. They are equivalent,
right? n glll' Wrong! W1"Dllg!
Programs 1I and 2 each require about 15000
bytes of memory, nearly 66% more than the ap
bytes of memory, nearl y 66% more than the approximately
9100 bytes required for Programs 3
and 4. The reason for this is the way Atari BASIC
handles constants and variables. Each and every
reference to a constant (zero, in these programs)
consumes seven bytes. This is true even if the statements
using those constants are never executed in
the program. (as are lines 2-994 in Program 1I and
hnes lines 8-1000 I in In Program 2). Programs 3 and 4
involve v?lve the ~ssi.g assignment e nt of a constant to only one
vanable variable (B 111 in llIle line I); 1); variable A assumes its values
by reference to this value. Each such reference
requires onlyy one byte.
. So the first lesson is to use constants sparingly,
If at all. Develop a schema for assigning variable
if at all. Develop a schema for assigning variable
names to constants so that youu will not confuse
them with "real" variables. For example, consider
them with "real" variables. For example, consider
DO = 0, 0 I = I , or CO = 0, C I = I , etc. where the
DO = 0, D1 = 1, or CO = 0, C1 = 1, etc. where the
symbol "D" is a mneumonic for digit or "C" reminds
symbol "0 " is a mneumonic for digit o r "C" reminds
you that it is a consta:nt. constant. Any other combination of
letters andlor and/or digits could then represent variables
which V{I1),. vary.
Speed DIfferences
Differences
While Programs I 1 and 2 are identical in memory
requirements, and Programs 3 and 4 are also iden­
requirements, and Programs 3 and 4 are also iden
tical to each other in terms of memory, these pairs
of programs are vastly different in execution execUlion speed.
Here we find that Programs 2 and 4 each require
only y one clock tick for completion. In marked
contrast are Programs 1 and 3 which are 42 times
contrast are Programs I and 3 which are 42 times
slower!
slower!
The reason for this enormous discrepancy is
the way that Atari Atan BASIC seems to locate subroutines.
BASIC is apparently incapable of immediately
jumping Jumping to the desired line referenced in a GOSUB. COSUB.
Rather, it appears to start from the first line of or the
program, and sequentially search through the list
pl:o,gram , and sequentially sea rch through the list
of lines hnes until unlIllt it finds what it wants. Thus, in Programs
3 and 4, when it encounters in line 1000 a
GOSUB COS U B 999, it must begin at line one and look at
each of the 998 intervening lines until it reaches
999. There, it encounters a GOSUB COSUB 998. Back to
the top of the list it goes, fruitlessly examining 997
lines. And so on. BASIC performs the same sequence
of steps in Programs 2 and 4, but it obviously
has to do fewer of them, since all of the subroutines
are near the top of the list of line e numbers.
Thus the second lesson, is to place subroutines
as close as possible to the beginning of or each program.
Some of your programs that heretofore
seemed to drag on unmercifully could now have
more zip.
And, finally, we answer the question n that has
been bothering you for some time. No, we are not
masochists. We did no/ not type in 1000 lines of code in
order to perform these benchmark tests. Instead, , a
one-line program was written to create a 1000-line
skeleton for Programs 1I and 2:
10 OPEN #2,8,0,"D:PROGRAM : FORJ= FOR] = 1 TO 1000
:?? #2J;" " A=O": A = 0" : NEXT]: J : CLOSE #2
. Then PROCRAM was ENTERed, the approp­
Then PROGRAM was ENTERed, the approp
riate n minor mlllor changes made to only seven lines, and
then RUN. The same procedure was followed for
then RUN. The same procedure was fo llowed for
Program 1.
1 POKE 20,0 : B=O B = 0 ,GOSUB : 1000, : B=PEEK(20)
B = :?B:STOP: ? B : 2 A=O A = 0
3 A=O A = 0
4 A=O A=0
5 A A=O = 0
6 A=O A = 0
7 A=O A = 0
8 A=O A = 0
9 A=O
9 A = 0
ere. etc.
995 A=O: A = 0:RETURN
996 GOSUB 995 : RETURN
997 GOSUB 996 : RETURN
998 GOSUB 997 : RETURN
999 GOSUB 998 : RETURN
GOSUB 995 : RETURN
GOSUB 996 : RETURN
GOSUB 997 : RETURN
999 GOSUB 998 : RETURN
1000 GOSUB 999: RETURN