Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxl!houxm!houxz!vax135!cornell!uw-beaver!tektronix!hplabs!sdcrdcf!sdcsvax!akgua!mcnc!decvax!cca!ima!ism780!patrick
From: patrick@ism780.UUCP
Newsgroups: net.micro.cbm
Subject: Re: VIC20 assembly lang. - (nf)
Message-ID: <325@ism780.UUCP>
Date: Tue, 24-Jul-84 00:12:28 EDT
Article-I.D.: ism780.325
Posted: Tue Jul 24 00:12:28 1984
Date-Received: Tue, 24-Jul-84 03:39:26 EDT
Lines: 67

#R:qumix:-25800:ism780:14900011:000:3005
ism780!patrick    Jul 16 12:44:00 1984

Some comments on coding in assembly-language from one who prefers it to
BASIC (I can write more readable, better-structured code in assembly
language than I can in that abominable 'language'):

Yes, of course your code will run much faster (good code should run 100
times faster than BASIC; I have no experience with 'compiled' languages
on the VIC/64).  Unfortunately, it is also likely to take you much longer
to produce the programs in assembly-language; perhaps not 100 times as
long, but it's certainly much more difficult.  This is, after all, why
higher-level languages were invented.

Some suggestions:

Get decent assembler; must be written in assembly-language, allow
'chaining' files together, or 'including' files inside other files, and
should allow macros with parameter substitution - more on this later.

Get a decent machine-language monitor (should come with the assembler),
for use in debugging your programs.

Code only the time-critical portions of your programs in assembler (no
point in spending days debugging assembly-language versions of code which
is executed only once, such as program initialization.)

Write small routines, make them as general-purpose as possible so you can
re-use them, and test them thoroughly in standalone mode before you
incorporate them into your programs.  (It is worth the extra effort to
build special test-drivers for these routines; it gives you a feeling of
confidence if the majority of code in your program has been fully tested
before you put it all together.)

Macros are a great boon - don't know how I ever managed without.  They
have two advantages:

They allow you to code only once those tricky sections of code which are
often used and which, due to Murphy's law, you seem to get wrong 90% of
the time.  (I can never remember the meaning of the condition codes after
a compare, and always had to look them up; even so, I often got them
wrong.  Now I simply code "bge (label)" and the bge macro inserts the
correct code for "branch greater or equal".)

They allow you to compensate for the limited instruction set, and for the
fact that you're using an 8-bit micro when most numbers in the real world
are greater than 255.  I have a full set of macros, used extensively,
which operate on 16-bit words, as opposed to 8-bit bytes (set, increment,
decrement, add to, subtract from, compare, etc.)   I can now code a loop
in which my counter is greater than 255 as easily as I can a smaller
loop.

To conclude: I love assembly-language programming, but it often drives me
crazy as it's so time-consuming.  It's worth the effort for the resulting
speed, but I must admit that if I had a decent high-level compiled
language - my favourite is C - I would do almost no assembly-language
programming.  There's no doubt that high-level languages (even BASIC)
improve productivity.


Patrick Curran
Interactive Systems Corp.
1212 Seventh St.
Santa Monica, CA 90401.

...{uscvax|ucla-vax|vortex}!ism780!patrick
...decvax!yale-co!ima!ism780!patrick