bpendlet@esunix.UUCP (01/30/87)
[]
My favorite bug was not a bug at all. I was working for Sperry Univac, I
was hired by Univac, but this is after they changed their name to Sperry
Univac and before they changed their name to Sperry. I was working on the
software for a peculiar machine called the UTS 4010.
The trouble was that the machine didn't exist. Oh, they were working on it,
but the hardware was about 6 months behind schedule. That was OK with us,
we were about 4 months behind schedule. We MIGHT have been on schedule if
we had had a machine to test on, but I doubt it.
There were three of us working on what turned out to be about a 10K
instruction assembly language program. The program implemented a COBOL
psuedomachine. The COBOL psuedomachine is not what I'm writing about, it
just sort of sets the mood.
We had been writing assembly language code for about 6 months. We had an
assembler, just no machine. One day we got a memo from the hardware
designers, it seems they had run out of microstore while implementing the
instruction set of the UTS 4010. The memo was a list of instructions that
they wanted to drop from the instruction set.
Imagine, 6 months of careful assembly language coding and now they want to
change the machine. I was given the job of finding every occurrence of the
nonexistent instructions in our code. The plan was to write macros or
recode around the dead instructions.
Much to my surprise I found that we had not used ONE of those instructions
in our code. Nowhere in the entire software development effort had a single
one of those instructions been used. No part of the software development
effort was affect by the deletion of those instructions. Not one of the 30
or so programmers doing software development on the machine had ever found
a use for those instructions.
I found out later that every one of the deleted instructions was there
because the electrical engineers doing the microcode had noticed that you
code implement some REALLY NEAT instruction with JUST ONE or maybe two
microinstructions.
Later, when we actually got a machine, we had the fun of finding out where
the instructions as implemented differed from the instructions as
documented. But that's another story.
--
---
Bob Pendleton
Evans & Sutherland Computer Corporation
UUCP Address: {decvax,ucbvax,ihnp4,allegra}!decwrl!esunix!bpendlet
Alternate: {ihnp4,seismo}!utah-cs!utah-gr!uplherc!esunix!bpendlet
hacking code, hacking code.
sometimes happy, sometimes bored,
almost lost in a pile of spode.
tell the people "I'm only hacking code."
---
I am solely responsible for what I say.
---amos@instable.UUCP (Amos Shapir) (02/01/87)
In article <343@esunix.UUCP> bpendlet@esunix.UUCP (Bob Pendleton) writes:
:We had been writing assembly language code for about 6 months. We had an
:assembler, just no machine. One day we got a memo from the hardware
:designers, it seems they had run out of microstore while implementing the
:instruction set of the UTS 4010. The memo was a list of instructions that
:they wanted to drop from the instruction set.
:
:Imagine, 6 months of careful assembly language coding and now they want to
:change the machine. I was given the job of finding every occurrence of the
:nonexistent instructions in our code. The plan was to write macros or
:recode around the dead instructions.
When something similar happened when I was working on the OS for CCI's 6/32
I just said 'Ok!', hacked the compiler's table a little, left a compilation
running overnight, and the system was ready the next morning. (A little
exaggeration perhaps, but it did take less than a week).
But of course, our system was written in C...
--
Amos Shapir
National Semiconductor (Israel)
6 Maskit st. P.O.B. 3007, Herzlia 46104, Israel
(011-972) 52-522261 amos%nsta@nsc.com 34.48'E 32.10'N