Operating instructions
certain large blocks
of
code are used
repeatedly. Therefore, every
time
a
source program requests a certain type
of
activity
the compiler causes the ob-
ject code
to
jump
to the specified block
of code
that
can handle that activity.
Sometimes
two
activities are similar,
although not identical; but if the code for
each is very long and the differences are
minor, it is frequently more
efficient
to
generalize
the
code
and then
to
distinguish
between the differences
of
the
activities
within the block
of
code.
Now again, there are some trade·offs
most likely requiring some additional
branches for each
of
the activities
that
would
not
be
necessary if they had their
own unique code. We are in fact
"inter·
preting"
at
execution time some
of
the
code
within
the compiler·generated
code. This then is not true object code
for what was the source statement but is
in a very limited -sense Pseudo Code
(P-Code).
While
this
type
of
approach is
pre-
sent to some extent in almost all com-
pilers, some compilers make heavy use
of
this approach. The generalized code
that
will
interpret
the
specific
statements generated as object code
by
the compiler amounts
to
an "overhead"
in both usage
of
memory and in execu-
tion time.
Some FORTH and
PLM
compilers
currently available
for
the
PET
are so
heavily dependent on these techniques
that
the resulting object code executes
as
little
as 3 times as fast as the BASIC
Interpreter. These same compilers
re-
quire several K overhead in memory
for
the specialized routines
that
conse-
quently become a part
of
all programs,
whether they are actually used
or
not.
This can
be
very detrimental in some im-
portant situations.
It
is possible to write a compiler
that
is resident in memory and interprets
all
of
the code
at
execution time. In such
a case we have come full circle and have
what we started with--an interpreter.
This is indeed why many
of
the
so·called
compilers perform
little
better than an
interpreter.
How, then, can one tell whether or
not they have a
"true"
direct compiler
or
a largely P·code simulator? The answer
is
by
benchmarking. Because there are
different design philosophies behind dif-
ferent compilers, one
must
take a com-
piler and compare it to the
other
alter-
natives (Le.,
other
compilers
or
the inter-
preter). One does
this
by writing a test
program with
statements
similar to the
type they use in actual applications.
Perhaps for one user there are
lots
of
loops and string handling. Another user
may particularly use math
functions
and
arrays. The particular
test
program is
then run using both products and the
results are compared. Only in
this
way
January,
1980
will you know which
of
the two products
will perform better in terms
of
compile-
time
andlor
execution-time. Other impor-
tant
considerations
may
be
maintenance, direct access
to
the object
code
to
allow modification, types
of
statements available, ease
of
operation,
documentation, support, expected im-
provement or obsolescence, etc.
To summarize this section then, a
"direct-compiler"
uses relatively less
pseudo-code and executes faster than
straight P-code compulers. Performance
can only
be
determined by benchmark-
ing for specific applications.
Why Would a Basic Compiler be So
Useful on a
PET?
Aside from the considerable speed
improvement
that
can
be
obtained from
a well compiled program, are there any
other advantages
to
using a BASIC com-
piler? Most definitely, yes. However,
before elaborating let us pursue the
question
of
speed itself. For many ap-
plications
the PET's BASIC interpreter's
speed is entirely adequate.
It
is
in real
time
applications
(such as process con-
trol, where the
PET
is monitoring some
other device attached
to
it
through an in·
terface such as the IEEE-488 Port,
located on the back
of
the machine)
that
greater speed is needed. Since only the
PET
among popular personal micro-
computers has the necessary IEEE Port
for
attaching
many laboratory and
technical devices, faster programs are
also
more
significant
to
PET
users.
There are a number
of
S-100
bus ap-
plications
that
could benefit from in·
creased program speed and these can
be
implemented on the
PET
through
available
S-100
interface boards. Often
only a few specific routines need the
higher speed afforded by assembly
language programming and
this
could
be
accomplished by
writing
those few
routines in assembly language and do-
ing a
SYS
call from the BASIC program
to
them. This
latter
approach, however,
still
requires
that
the
programmer
understand
assembler
language;
whereas, by using a BASIC compiler, he
needs only know BASIC.
Where a BASIC compiler can really
shine
is
in
the
development
of
marketable systems. There are now
available
for
less than $300, systems
that interface directly
with
the
PET
that
can be used for burning PROMS (pro-
grammable read only memories) and
E-PROMS (ultra violet erasable proms).
These chips will
fit
into socket holders
inside the new 16K
PETS,
or
the socket
holders in
the
expansion boards on
the
old 8K
PETS,
and can hold a machine
language program in readiness
for
a
user, even when the computer
is turned
off--they are called non-volatile.
MICRQ
--
The 6502 Journal
This makes it convenient for users
still
to
be
able
to
use their computer
in
just
the same way as any other
PET
user.
But
at
the same time, they are able to
step up to a
PET
that
contains a
PROM
programmed for a specific task and im·
mediately access the special program
without
having
to
wait for it to load from
a tape or disk. In addition
to
making the
computer easier for the user to use,
this
is also a very convenient way for the
developer
to
distribute
his program and
makes copying
of
it much more
difficult
than
if
it were on tape. The producer's in-
cremental cost
of
duplicating programs
for
distribution
using
PROMS
should
be
well under
$20
each.
More importantly, we can go one
step further and take a program
that
has
been written on the
PET
in BASIC, com·
piled, and stored in
PROM
and use
that
PROM
along
with
a 6502
micro-
processor
to
build up an
entirely
separate device
that
no longer involves
the
PET
at
all. In this way the
PET
has
become a
very
powerful
development
tool for the garage or basement inventor
that
is
comparable to similar develop-
ment systems
that
have been used in in-
dustry for the
last
several years but
that
have cost
many
thousands
of
dollars. A
true BASIC direct compiler will therefore
allow serious
PET
users
to
develop from
PROMS, faster and more memory effi-
cient object code
while
using
the
power
of
the present PET BASIC
interpreter
for
rapid
program
development.
What is
the
Status
of
the CANPET
BASIC Compiler?
In June
1979
work was begun on a
PET
BASIC direct one-pass compiler.
The language supported by
this
com-
piler is intended to
be
identical with
that
supported
by
the
PET
BASIC interpreter
with the exception
of
dynamic array
decl~ration/allocation.
The Co-ordinators
of
the project,
Mr. Bruce Beach and Mr. Brian Beswick,
have retained the service
of
a Toronto-
based consulting firm with nearly
15
years
of
software experience and exper-
tise in compiler design. Assistance is
also being given
by
interested and
knowledgeable individuals in the Cana-
dian
PET
community, such as Mr.
Jim
Butterfield.
The first pre-releases
of
the com-
piier should
be
available for use
by
the
time this
article
appears in print. Initial
users will
be
sought in a wide diversity
of
applications so that the compiler's
performance can
be
critically evaluated.
Any persons who feel they would like
to
participate in the early evaluation pro-
cess are invited
to
contact
the Author.
20:11