Path: utzoo!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: <519@dms.UUCP>
Date: 1 Aug 88 17:17:43 GMT
References: <546@pcrat.UUCP>
Organization: Atari Games Inc., Milpitas, CA
Lines: 55

In article <12756@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek):
>a more strict regression test: add such multiplication to your test
>suite.  Indeed, add anything that has ever triggered a compiler bug
>to your test sets.  (This can quickly become unweildy :-) )

No kidding? The point of capping "ONLY" was that this was the only 16x16
multiply in the whole set of 6 modules that was hit. In a friend's case, only
one of 20 32x32 multiplies was bungled. These bugs seem very sensitive to
context, moving from one to another expression in a routine when, for example:
 fred() { int a; short b; ...} is changed to:
 fred() { short b; int a; ...} WHETHER or NOT a and b are involved in the
eventual "victim" multiply. Also, the 32x32 bug which got my friend was not
one of the classic "corner" cases. Should I check all possible 32x32 multiplies
across all possible permutations of variable declarations. Perhaps you were
under the impression that I have the sources to the compiler. I wish that
were the case, but I don't.

From article <546@pcrat.UUCP>, by rick@pcrat.UUCP (Rick Richardson):
> Never, ever, switch tools on production quality software unless you have
> to.  If you absolutely have to change tools, treat the software as you
> would the first time it is sent to system test -- take nothing for granted.

I am a lowly programmer :-).  People like system administrators decide when
to change releases of the compiler. They do so based on considerations like
how much disk space they can spare to hold old versions and how many other
people are screaming for the latest release to fix the OLD bugs that broke
THEIR code. They also have to deal with vendors who refuse to even listen
to bug-reports on any but the latest version.

	One of my responsibilities here is to maintain/extend a set of
tools and utility subroutines for use in embedded systems. While we no
longer manufacture the games for which they were originally written, there
is enough commonality to warrant re-use of code (I thought this was an
acceptable practice, using proven code rather than re-inventing the wheel :-)
But the release of the compiler that compiled the original code (circa 1982)
won't even run on the latest release of VMS (which is where I work).

> would the first time it is sent to system test -- take nothing for granted.
>                                                   ^^^^^^^^^^^^^^^^^^^^^^^^
	If you mean that literally, there is no point in using even an
assembler, let alone a compiler. And even if I coded in hex, the loader
could always "get" me :-) I have had cases where the inclusion of an
fprintf(stderr... was enough to get rid of the bug, but if the the
fprintf was removed, #if'd or even if ( debugsw == 1) ..., the bug
would re-appear. Is Heisenberg writing compilers these days :-)

	One of the things that worry me most about ADA is that so much
of the code in many "mission critical" systems will be in the form of
"packages" which, like my compiler, are "gauranteed" but not testable.
So we'll know who to sue for the next shuttle explosion or WWIII :-)


| 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
| The opinions expressed are my own (My boss is on vacation)