len@qumix.UUCP (Leonard Labar) (07/12/84)
Anyone out there have opinions about writing programs in 6502 assembly language vs. Basic? I hated 6502 at first but now that I'm getting into it I like it. I write my programs in Basic first to make sure they work and then convert to 6502. I agree that it isn't as nice as high level languages. The 6502 is very limited in fact as to num. of instructions. However, any program written in assembly language will run a lot faster than Basic. It will run faster than Forth or Pascal too. Now that I think about it, I can't understand why anyone would want a program that wasn't written in assembly language. Now that I've said that, let's see what happens.
calway@ecsvax.UUCP (07/18/84)
x
Add another vote for assembly language. It is not as difficult as it looks and
in some applications - graphics, for example - it is indispensable. Assembly
language lets you tap into the C-64's real power. Granted, the old 6502 is
limited, but if that is a real problem, the best solution is to get a different
computer.
James Calloway
The News and Observer
Box 191
Raleigh, N.C. 27602
(919) 829-4570
{akgua,decvax}!mcnc!ecsvax!calwaypatrick@ism780.UUCP (07/24/84)
#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