[net.micro.mac] Benchmarking Assemblers

jer@peora.UUCP (J. Eric Roskos) (05/09/85)

A long time ago, in <118@peora.UUCP>, I posted what I felt was a reasonable
hand-compilation of the Byte magazine Sieve Benchmark.  The goals in making
the hand-compilation were to generate an assembly-language program that
was algorithmically produced, but which used optimization methods that
are well-known in the non-microcomputer-compiler industry.  The reason for
doing this was to provide a test program against which the code generated
by current microcomputer compilers could be compared; because it has been
commonly the case that people compare compiler-generated programs against
assembly-language programs which were optimized in ways that no reasonable
compiler could be expected to approach.

Well, twice in the past 2 or 3 months, someone (the same person) has posted
benchmarks in INFO-MAC, using a different assembler from the one I used, in
which the execution times are 20% slower than the results I got.  This has
made me very curious, because I know (having written many assemblers,
including the one used to produce a well-known product line for the IBM PC)
that it is indeed possible for assemblers to generate code with different
execution times.  Typically this happens when the assembler generates long-
operand instructions when short-operand or PC-relative instructions are
possible; it can also happen, however, when two opcodes exist that do the
same thing, but have different execution times (as was the case with the
above-mentioned 8086 assembler).

This has made me wonder: has anybody benchmarked the assemblers that are
used as code generators for the currently available C compilers for the
Mac?  If two compilers produce compatible assembly code, it would be an
interesting experiment whether you could "mix and match" assemblers,
assuming you own more than one compiler, to produce faster code. (This was
a more viable question on the IBM PC, since some compilers allowed you to
produce assembly code both for their assembler and for another
manufacturer's; but is an interesting question on the Mac as well.) In
particular, a compiler that provided a particularly good implementation of C
but generated grossly inefficient machine code could be improved by writing
your own assembler for it.
-- 
Full-Name:  J. Eric Roskos
UUCP:       ..!{decvax,ucbvax,ihnp4}!vax135!petsd!peora!jer
US Mail:    MS 795; Perkin-Elmer SDC;
	    2486 Sand Lake Road, Orlando, FL 32809-7642