From: rfd@po.CWRU.Edu (Richard F. Drushel)
Subject: Assembler and Optimization (was Re: The need for an assembler (was: Favorite CPU))
Reply-To: rfd@po.CWRU.Edu (Richard F. Drushel)
Organization: Case Western Reserve University, Cleveland, OH (USA)
Date: Mon, 31 Aug 92 21:11:45 GMT


	I am trying to come to some kind of personal consensus about
the ongoing "discussion" of the merits/demerits of assembler/HLLs.
Since I am a frequent user of both (as a hobbyist, not a professional),
I have a few practical ideas on the subject, which I would like to run
up the flagpole and see if anybody shoots :)

	Assembler.  If you need to talk to the hardware, you usually
need an assembler, because off-the-shelf HLLs don't give you the
commands necessary to get at it.  If you want to be able to do it
from a HLL, you will have to hack the interpreter/compiler (again in
assembler, or more likely by patching a binary) to add the convenient
extensions you want.  I think there are some versions of QuickBASIC
which let you code INTs and register setups in-line.  Sometimes IN and
OUT statements are available to communicate with I/O ports, but never
as the ANSI specs for your HLL :)  For my hobby computer, the Coleco
ADAM, I wrote my own SmartBASIC extensions to do IN and OUT, EOS
function calls directly, and wrote a bunch of driver code in assembly
which could be invoked by convenient command words instead of a mess
of POKEs and CALLs--but only after a year of hacking.  The next guy's
job is now easier...

	If program size is *utterly critical*, use assembler.  I have
been rewriting ADAM's EOS operating system to support new 3rd-party
hardware.  It *MUST* fit into the upper 8K of memory, unless you want
the burden of disassembling and patching about 20 binary applications
to know that they know where the new EOS starts, to stay clear of it.
In an obsolete 64K microcomputer, every byte of RAM is a precious, non-
renewable resource.  I started with the factory EOS, and squeezed over
1K out of it by compaction and other obfuscating optimizations.  Now I
have to make sure that my extensions are as terse as possible.  This
means all the "tricks" for reusing code, PUSHing as few registers as
possible, clever arrangement of code blocks so you can use relative
jumps (2 bytes) instead of absolute (3 bytes), etc.  And of course
making sure that you didn't break a working routine when you crunched
it down.

	If program speed is *utterly critical*, use assembler for that
part.  Others have pointed out that counting clock cycles ain't what
it used to be, given the frequent increases in mHz for given CPUs
these days, but there are probably absolute timer chips etc. which
can be used for benchmarks.  For interrupt service routines, however,
you don't care how fast just so it is as fast as possible--and assembler
gives you complete control over how many instructions are used.

	HLLs.  If you don't care how big the executable file is,
or how fast it runs, but want it to run on many different CPUs, then
write your program in a HLL.  If your code is going to be maintained
by gorillas after you're gone, then use HLLs, simply because it is
easier for the gorillas.  If you have a horrendously complex program,
use an HLL because you don't need any more grief than necessary, and
the HLL will protect you from the nasty hardware (at least a little).

	Thesis and antithesis out of the way, it's time for some
synthesis...In the newer computers (e.g. '286s and up for the DOS line,
Mac IIs, and all the sundry UNIX boxes I hear you guys talk about)
RAM and HD storage space go on for ever, the machines run at 25 mHz or
more, and have all kinds of number-crunching features to the CPUs
(built-in math coprocessors, hardware division and multiplication).
For your basic new PROGRAM.EXE, the important thing is *not* that it does
its job--gives you the right answer at the end, if you will.  It has
to be optimized more toward warm and fuzzy things like pretty screen
colors or fancy windows with 3-D buttons or cute icons, than toward
overall size or execution speed.  Face it, folks, the upcoming horde
of new computer users is going to buy computers and programs the way
they buy automobiles or toasters or furniture--that it performs its
function is a given, so gingerbread is the remaining discriminant.

	Gingerbread takes space.  Gingerbread is not just numeric
or string manipulation.  Graphical objects are pretty hard to deal
with in assembly language, unless you build some pretty high-level
routines out of primitives--and then you are paying for the convenience.

	HLLs and assembler each have their place.  I am afraid, however,
that assembler is more and more being relegated to a strictly device-
driver role, and that its days of being the primary language type for
composing new application software are over.  All of the really good
arguments in its favor--small size and fast execution--are mostly
irrelevant now, whereas its disadvantages--harder to write, less
forgiving of mistakes, not portable across disparate CPUs--are as
pungent as ever.  If you have an obsolete micro--like my ADAM--then
you need assembler to survive.  But who these days would run his
business or lab off an ADAM?

	At age 29, I am a fossil.  I can work on automobiles, build
radios, and program computers in assembly language.  None of these are
at the cutting edge any more.  I can understand cjl's apparent rage
at being brilliant at something nobody gives a damn about nowadays.
It is the rage of the blacksmith and wheelwright and cobbler and
cooper and a hundred other occupations reduced to antiquarian
curiosities by technological change.  This too may happen to HLLs;
who can say for sure?
-- 
Rich Drushel ** rfd@po.CWRU.edu *** Biology Ph.D. Student ** Cleveland FreeNet
Co-Sysop, Coleco ADAM Forum --- Assistant Sysop, Science Fiction & Fantasy SIG
"Solda pung apfashat ro des-marno, / Marn ladir o armag noth yeni arno. / Hell
miryat it, / Jambo iat it, / Os lasse wei ticip kati baldo." / Old Ennish poem
Newsgroups: alt.folklore.computers