From: Eric Fischer Newsgroups: alt.folklore.computers Subject: Why 36 bits Date: 6 Apr 2001 22:53:02 GMT Organization: EnterAct Corp Turbo-Elite News Server Lines: 76 Message-ID: <9alhce$ndd$1@bob.news.rcn.net> X-Trace: UmFuZG9tSVbh2OEg4Kt6NXMmEkaErJ75pZ2hXU3ml6tFDjMVIaL73wUsw4nvlMKb X-Complaints-To: abuse@rcn.com NNTP-Posting-Date: 6 Apr 2001 22:53:02 GMT X-Newsreader: trn 4.0-test72 (19 April 1999) Originator: enf@enteract.com (Eric Fischer) Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!news-fra1.dfn.de!news-lei1.dfn.de!news-was.dfn.de!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed.skycache.com!Cidera!europa.netcrusader.net!207.172.3.44!feed2.news.rcn.net!feed1.news.rcn.net!rcn!not-for-mail Xref: chonsp.franklin.ch alt.folklore.computers:78346 A while ago in this newsgroup, I wrote: > What I don't know, and what would be extremely interesting to find > out, is whether multiple-of-6 architectures were designed that way > because four-zone punch cards naturally map to six bits, or whether > multiples of six were chosen for some other compelling reason and > the binary-coded-decimal mapping just happened to work out nicely. Since then I've done the reading and have the answer, at least for the IBM 36-bit machines. Werner Buchholz, in "The System Design of the IBM Type 701 Computer," gives the following rationale: ... with a given set of applications there will be an optimum word length for which the speed is at a maximum or the cost is at a minimum. ... For the 701 a survey of proposed applications was made, and it was found that the range of word lengths between 10 and 12 decimal digits would be satisfactory. There exists a broad peak of efficiency in this range. Below 10 digits there are too many problems requiring double-precision arithmetic, and there are not enough problems which could make effective use of more than 12 digits. Numbers of 10 or 12 decimal digits with sign can be represented in binary form by a minimum of 35 or 41 bits, respectively, including sign. Hence the survey showed that the word length of the 701 should be in the range of 35 to 41 bits. Several other factors then quickly narrowed down the choice of word length. The single-address type of instruction, with the number of operations and the memory size being considered, required a minimum length of 18 bits, so that for the most efficient packing of instructions in memory the word length should be a multiple of 18. For engineering reasons the magnetic tape was to be provided with up to six parallel information channels; hence words could be recorded on tape most efficiently if the word length was to be a multiple of six. The desire to reduce the bulk and cost of the computer further prompted a choice near the range of 35 to 41 bits. The final choice of 36 bits fills all these specifications. Unfortunately it's not clear what the engineering reasons were that made the tape six tracks wide, but it doesn't seem to have been directly related to the size of characters. In fact it seems to be just by coincidence that the 701 could handle character data at all. According to M. M. Astrahan and N. Rochester in "The Logical Organization of the New IBM Scientific Calculator," they originally planned to convert the decimal card code to BCD in hardware, but then realized that it was as easy to convert the raw punches to binary numbers as it was to convert BCD representations of them, so they eliminated the BCD conversion stage. Making the punches accessible directly as bits made the machine also capable of handling alphabetic punches. But Astrahan and Rochester do not seem to have envisioned that programs would ever produce textual output or accept textual input. Instead they refer to the facility only as a way of getting column headings onto numeric output, and don't even think that the text of the headings would be kept in character form inside the computer. Instead they suggest reading in an entire alphabetic card as a 24-word binary image and then sending it to the printer as the same 24-word image. Rochester, though, did do some character-oriented programming not long after. In "Symbolic Programming" he describes an assembler that works in sort of the opposite direction of later ones: its input is instructions in octal, but its (printed) output includes the alphabetic mnemonics associated with the octal instructions. It also accepted a small amount of alphabetic input: its statement labels (which took the form xx.yy.zz) were normally all-numeric, but the second digit of "xx" could be a letter instead. How these characters were represented in memory I unfortunately don't know. The labels are said to have taken one word of memory apiece, which means six bits per character, but it's not clear, then, why only the second character could be alphabetic. eric ###### From: steve@lgx.ch.unisys.com (Williams, Steve) Newsgroups: alt.folklore.computers Subject: Re: Why 36 bits Date: Sat, 07 Apr 2001 13:04:39 GMT Organization: Unisys (Schweiz) AG Lines: 34 Message-ID: <3acf023f.592953@news.rsvl.unisys.com> References: <9alhce$ndd$1@bob.news.rcn.net> NNTP-Posting-Host: 172.23.11.55 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: si05.rsvl.unisys.com 986616218 58683 172.23.11.55 (7 Apr 2001 04:03:38 GMT) X-Complaints-To: news@rsvl.unisys.com NNTP-Posting-Date: 7 Apr 2001 04:03:38 GMT X-Newsreader: Forte Agent 1.5/32.451 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.dplanet.ch!news-ge.switch.ch!news-fra1.dfn.de!news-koe1.dfn.de!news-was.dfn.de!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!hammer.uoregon.edu!enews.sgi.com!eanews1.unisys.com!si05!not-for-mail Xref: chonsp.franklin.ch alt.folklore.computers:78373 Eric Fischer wrote: >A while ago in this newsgroup, I wrote: > >> What I don't know, and what would be extremely interesting to find >> out, is whether multiple-of-6 architectures were designed that way >> because four-zone punch cards naturally map to six bits, or whether >> multiples of six were chosen for some other compelling reason and >> the binary-coded-decimal mapping just happened to work out nicely. > The scientific arm of Univac (originally Engineering Research Associates) appears to have made a concious decision to go with a 36-bit word twice in its 1100 series systems. The first of this line was delivered in December 1950 as part of Navy Project 13. 1. Around 1952 the 1103 was designed with a 36-bit word length. WIth a 6-bit instruction code and two 15-bit addresses, a 36-bit word seems just to be what was necessary to do the job. No magnetic tape device was originally available for this system. 2. In the late '50s the 1100 line was completely redesigned with an incompatible architecture, but the 36-bit word was retained. Many of the tecnical specifications for the 1107 came from the USAF, including, supposedly, the word length. For technical computing the precision of a 36- or 72-bit word was considered necessary for floating point. Additionally, at that time the FIELDATA system had been specified for army computing, including a 6-bit display character set. Univac was deeply involved in supplying military computers at that time and a multiple of 6 word length was considered useful. One current Unisys mainframe line still supports the original 1107 instruction set. Support of the FIELDATA character set can still be found in the architecture and in the software if one looks carefully.