GPS Control Software Update Shows Glitch
On Sat, 23 Jan 2010 09:38:14 -0800 (PST), Mike Jr
wrote:
IBM had this problem in spades with System/360. Some operation would
have an undocumented side-effect of setting some memory location to
zero. Programmers would notice it and then write code that depended
on this side effect. Of course, there was nothing in the IBM System/
360 Principles of Operation (i.e. the "ICD") that would guarantee it.
A new version of the operating system would be released and the code
for that operation would change and no longer exhibit the side effect
of setting that memory location to zero.
Early S/360 Fortran compilers (nothing to do with Principles Of
Operation, a hardware manual, or the OS) would create code that would
do this under certain circumstances. If a complicated formula
generated code that required the use of more than the available 4
floating-point hardware registers, the machine code would store the
4th register, use it for temporary results, then zero it in
preparation to reload the previous temp result, but "forget" to reload
the saved value in the register before continuing the operation.
Whoever coded the compiler left the reload instruction out of the
resulting code, and it took such a long, complicated formula written
all in a single statement to cause the error that it rarely happened.
I was doing actuarial calcs for a life insurance company at the time,
and tracked down the problem - it took me a couple of days because I
was not an assembler programmer at the time and I was working from a
listing of the generated machine code. The formula that caused it was
such that a multiply-by-zero-or-by-one was used to include or exclude
a fairly complex term from the result, which helped to identify the
code error. A multiply by the erroneous zero was the giveaway.
I informed IBM about this obscure bug in their compiler around 1967/8,
but I don't know if they ever took it seriously coming from an
actuarial student at the time.
|