Path: utzoo!utgpu!attcan!uunet!lll-winken!ubvax!weitek!dms!albaugh
From: albaugh@dms.UUCP (Mike Albaugh)
Newsgroups: comp.arch
Subject: Re: using assembler (vs HLL, etc)
Message-ID: <517@dms.UUCP>
Date: 29 Jul 88 15:49:09 GMT
References: <12729@mimsy.UUCP>
Organization: Atari Games Inc., Milpitas, CA
Lines: 41

Piggy-backing on article <12729@mimsy.UUCP>, by chris@mimsy.UUCP (Chris Torek):

	This is my first attempt to post anything in news, so please bear
with me. Apologies also to Chris Torek for doing it by replying to his message.
It seemed an easy way to get into an on-going discussion. I have two comments
and a question.

	First, in re: assembly. While I thoroughly concur that it should
be used sparingly, I cannot condone an outright prohibition. I'd rather
have to maintain an average C program than an average assembly program, but
I'd rather wrestle a rabid weasel than attempt to modify the sort of C that
all too often results when someone dogmatically refuses to 'descend' to
assembly, and instead pulls every trick the last version of his compiler let
him get away with. If you're so sure you know the right five assembly
instructons, just use them. Don't write ten lines of totally opaque C that
will break next release of the compiler (see below).

	Second, in re: hardware Blitters. I find it at least mildly amusing
that in a group where I might expect to see some discusion of algorithms to
run conventional (SISD) code on multiple processors and/or functional units,
someone is seriously proposing that it is a BAD IDEA to take an explicit,
programmer-given, clean partioning of the task and throw it away. Next I
suppose I'll hear that "Real men don't use disk controllers, they bit-boff the
read/write heads" :-)

	Last, the question. In the last two years I have increasingly run
across cases where new releases of the compiler have introduced bugs in my code.
I'm not talking about tighter type checking catching bogus constructs, I'm
talking about pushing the wrong length of data if a parameter is an expression
containing (0+fred) where fred is a short and the 0 resulted from folding some
#define's. Or would you believe forgeting how to multiply or divide (this seems
especially difficult for C compilers for the 68000). Anyway, what is the
orthodox way to deal with the fact that your 50,000 lines of debugged, tested
code become 50,000 lines of un-debugged, un-tested code every time a new
release of the compiler comes out. I know about regression testing, but the last
time it ONLY munged the multiply that was concerned with the average up-time
of a machine, so I didn't hear about it until a machine in the field had been
running continuously for over 32767 minutes. Any suggestions?

| Mike Albaugh (weitek!dms!albaugh) voice: (408)434-1709
| Atari Games Corp (Arcade Games, no relation to the makers of the ST)
| 675 Sycamore Dr. Milpitas, CA 95035