Download Ipso Facto Issue 5

EDITOR' S
RE~·11\RKS
BAR. 26, 1978
I am pleased to report that, as of this date, our membership
stands at 351 paid members. This includes 242 Canadians, 105
Americans, and 4 International members. I would like also to report
that, out of this total membership, less than 35 people have contributed to the Newsletter (not counting letters to the Editor). I trust
the remaining 90% are seriously considering a submission in the near
future. Remember: you don't have to be an expert in your field to
write for this Newsletter. All you need is an idea, a pencil and a
piece of paper! You don't even have to have a working application;
if you've been mulling over some idea, put it down on paper in the
foru of a proposal, and send it in. Perhaps someone can help you
out with some practical suggestions; or perhaps they have already
d on e it, and can tell you how to get yours wor-k.Lng , Surely you
haven't all packed your 1802s into a box on the shelf and forgotten
about it! The prime purpose of this Newsletter is to communicate
ideas between members, but you must put your ideas down on paper
first, so get to it!
MACHINE OR ASSEMBLY LANGUAGB?
The question of whether to document a pro~ram in machine language
is a many-faceted one. On the one hand, a hex dump in machine
language is a simple procedure, taking little time, and occupying
only a small space. On the other hand, an assembly language listing,
wi th comuerrt.s and assembled machine code, is a lengthy procedure,
requiring a large expenditure of time, and generally occupying a
substantial amount of space. But consider the real purpose of writing a pr-ozr-arn down on paper. Generally, you wish to make it available to s ome or:e else, or even to vour seLf , at a later date. Unless
your pro~ram is a trivial one (say 10 bytes or less), will you or
anyone else be able to understand what it does, or how? Will your
fri ends (or f'e LLow ACS mercber s ) be able to modify your program to.
run vii th a different clock frequency, or different I/O devices?
What if they load your program, and it doesn't work. Will they ever
be able to figure out for themselves what's wrong? All of the above
q ue st i ons point to the need for commen t s on a pr-ocr.im Ii stine;, to
explain t h s. details of a programs operation. Com.aent s aren't
difficult to produce; they usually reflect the thinking of a programmer
as he desicns a program, and gets it to work. All the pro~rammer
n e eds to do is write down a com.r errt , each time he wr i tes a machine
instruction. Easy, right?
The use of assembly language a I Lows the pr-ogr-ammer- to easily remember an instruction by its mnemonic rather than by its hex code.
It also allows the use of labels for branch points and variable or
fixed data locations. These labels can be easily found later, when
you mus~ re-assemble your program because you needed an extra instruction in the middle.
The ~iggest argument against the use of assembly lan~uage is said
to b e the reqUirement for an as senb l er- pr-or-r-am. Tlds simply isn't
true. Ad;nittedly ~ an assembler is ni ce to nave , but you cal: [T,ain
many 0.1. t.ne bene r i ts of assembly language when hand-assembl1.ng t he
.C'