Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!ucsd!sdcsvax!ucsdhub!hp-sdd!hplabs!sdcrdcf!ism780c!news
From: news@ism780c.UUCP (News system)
Newsgroups: comp.arch
Subject: Re: IBM 704 nostalgia (was Re: FORTRAN Horror)
Message-ID: <9630@ism780c.UUCP>
Date: 5 Apr 88 02:14:59 GMT
References: <24861@yale-celray.yale.UUCP> <1135@pembina.UUCP> <25461@yale-celray.yale.UUCP> <793@houxs.UUCP> <9545@ism780c.UUCP> <2562@saturn.ucsc.edu>
Reply-To: marv@ism780.UUCP (Marvin Rubenstein)
Organization: Interactive Systems Corp., Santa Monica CA
Lines: 25

>>An intresting feature of the 704 and its sucessors (709, 7090, 7094, 7044)
>>was that the accumulator was 2 bits wider than a word.  Thus one could
>>produce 4 overflows before any information was lost.
>>
>This was a holdover from the 701.  This feature was explained in the
>Proceeding of the I.R.E. article circa 1953 by Werner Buchholz, as
>I recall.  I suspect by the time of the 704 they regretted it.
>Floating point operations were said to give unpredictable results
>if these bits were not zero at the start of an operation (this is
>from memory, may be wrong).

Your memory is close but not exact.  Actually the behavior of floating point
operations (with the extra bits not zero) was defined in the principles of
operation manual.  When I was building  an emmulator of the machine I
concluded that floating operations with the extra bits bits initially not
zero was meaningless.  So I ignored the bits.  And guess what, there was a
program that did not run correctly under emulation!  I had to change my
emulation to correspond to the actual hardware (with a performance hit in
the normal case).  One of the things I learned from this:  if your hardware
has a bug like this don't document it as a feature or you will have to live
with it.

BTW.  Accounting for those two extra bits added about 17% to our alu chip
count.

      Marv Rubinstein - Computer Historian