[net.micro.mac] Assembly-language Sieve source / object

jer@peora.UUCP (J. Eric Roskos) (03/02/85)

Recently a number of Sieve benchmarks have been posted for the Macintosh
demonstrating various compilers.

Such benchmarks are beneficial (although they don't substitute for a
simple visual examination of the generated object code), but merely posting
the results of existing compilers has always seemed to me to be only half
the task, albeit the harder one.  To know whether a given benchmark result is
"good", you need to have something to compare it to --- otherwise, you
could have a lot of slow compilers, and never know it.

I have posted to net.sources.mac an assembly-language version of the Sieve
benchmark.  A BINHEX version 4 object file is included, along with the
source for the sieve part of the program.  (For a variety of reasons, I
have not posted the startup or termination code, or the runtime routines:
they are long, not particularly interesting, and make the program hard
to read -- and, of course, they don't influence the benchmark time.)

My attempt in writing this program was to produce the sort of code that
a reasonably good globally-optimizing compiler could be expected to produce:
a fairly algorithmic translation from the Pascal source code, but with
some traditional optimizations such as allocation of loop variables to
registers, common subexpression elimination, etc.  At the same time, I've
TRIED not to do anything that would be unreasonable for a non-human
compiler to do; though I leave it to the experienced compiler-writers
reading this to say if this effort succeeded.

Regarding the program itself: in order to get enough space for the flags
array, I allocated the array on the heap.  Thus the variable "flags" con-
tains a pointer to the array, rather than being the first element of the
array.  Also, the routine prd3 which prints the D3 register does so in
hexadecimal (because it was a little easier to do).  Other than that,
the program is straightforward, and comments show (in Pascal) what's going
on in the assembly language code.

Hopefully this will show something near a lower-bound for Sieve execution
time (though it would be nice if a compiler eventually produced code
even faster).   The optimization techniques used are not those that are
common for microcomputer compilers (although, judging from their previous
products, some of the compiler writers currently producing compilers are
capable of producing such optimizers); so it is not really fair to fault
those whose execution times do not come close.  Rather, one should aspire
to see compilers that fast (and maybe compiler writers should take it
as a challenge!)