Introduction

Between 16th May and 13th June 1965, three people from the Atlas Computing Laboratory in the UK visited the United States, they were Bob Churchhouse (RFC), Bart Fossey (EBF) and Bob Hopgood (FRAH).

The material on this page was retrieved and extracted from a larger document located (with other computer historic materials) at http://www.chilton-computing.org.uk

The primary reason for the visit was to attend the IFIP Conference held in New York from 23rd to 30th May; the secondary reason was to visit a number of computing laboratories and computer manufacturers.

Following is the portion from their trip report relevant to Control Data Corporation.

Extract from their visit to Carnegie Institute of Technology (Pittsburgh) 31st May/1st June 1965

...Perlis showed us an interesting gadget during our visit. This was a typewriter device with a black box attached into which a telephone could be fitted - the earpiece and mouthpiece fitting into two cup-shaped holders. By dialling a number connected to the computer one would be automatically on-line and could use the machine exactly as in MAC. This gadget was the first of its kind at Carnegie (it had been made there); it weighed about 100 pounds in all. Two days later, at C.D.C., we saw a similar and considerably lighter device (the CDC 6060).

Visit to C.D.C. (Minneapolis) Wednesday, 2nd June 1965

EBF. having left us to visit Oakridge, we (RFC and FRAH) flew from Pittsburgh to Minneapolis on 1st June. The journey was memorable in that it took several hours, partly because we landed at Cleveland, Detroit and Milwaukee, but principally because we arrived in Minneapolis just in time to be caught in one of the worst storms in memory. The rain began within minutes of our arrival and during the next 24 hours several inches of rain fell, most of it within an hour of the start. Within minutes the roads were like raging torrents and in places trees seemed to have been washed out of the ground.

We spent most of 2nd June with John Lacey and his colleagues at the main CDC production plant outside Minneapolis. Lacey, who was an S.S.0. at GCHQ in 1961, is now second in command of this plant, which employs about 2,000 people. After a discussions on the administrative structure of CDC we had a talk on the 6600, illustrated by slides and examples. The interesting sections of the administrative charts of CDC's activities are given below:

  • President: W. Norris
    • Computer Group, Head: Vice-President Frank Mullaney
    • Industrial Group
    • Peripherals Group

The Computer Group is organised into the following Divisions:

  • Computer Division
  • Data Display
  • Government Systems
  • Chippewa Labs
  • System Sciences Division

A diagram of the organisation of the Computer Division is given below. Of the other divisions it is perhaps worth remarking that the Chippewa Labs., which are in Wisconsin, are run by Seymour Cray (Chief Designer and a Vice-President of CDC) who has a total staff of 34 people with him. The first machine of each new series goes to the Chippewa Group. The System Sciences Division is at Los Angeles, their responsibility is to produce all special software and hardware (if necessary); in particular they are producing the software for the 6000 series machines.

The structure of the Computer Division is:

  • Computer Division: R. N. Kisch
    • Software: C. E. Miller
      • Advanced Work: Dr Zemlin
      • Applications: Dr A. C. Downing
      • COBOL etc: E. S. Williams
    • Hardware: E. D. Zinner

Zemlin, Williams and Miller are at Palo Alto, Downing (who used to be at Oakridge) is in Minneapolis. We spoke to Downing and he told us that among other topics the people in his group were working on: Communications Science (including Time-sharing), Management Science, Physical Science and a variety of other topics including Game-Playing.

On the 6600 we learned little new. An example of programming the 6600 in machine code was worked out; it was quite instructive, although clearly designed to take advantage of the multiple registers of the machine. The example is given below (times are given in minor cycles = 0.1 secs).

Example: A = (B ∗ C) + (D ∗ E)

Step               Issue at time   Start execution  Complete instruction  Result available
B to A1                   0              0                   3                    8
C to A2                   1              1                   4                    9
X0 = X1 ∗ X2              2              9                  19
D to A3                   3              3                   6                   11
E to A4                   4              4                   7                   12
X6 = X3 ∗ X4              5             12                  22
X7 = X0 + X6              6             22                  26
A7 to A                   7             26                  29                   39

Thus the total time is 39 minor cycles, or 3.9 microseconds. Instruction have to be delayed when it requires the result of a previous instruction.

We saw the 6600 and 3000 series assembly-lines. There were working machines of each type on view. There was a very nice card punch working at 300c.p.m. attached to the 6600.

The production lines are nothing like so automated as those at IBM, Poughkeepsie. Much more work is done manually - there seems to be a good supply of people to do low-grade wiring etc available in Minneapolis. The back-wiring of the 6600 looked a terrible mess; on the other hand the machine seemed to work satisfactorily.

We also saw the CDC 6060, a small typewriter console intended for using a machine via a telephone connection. In principle it was similar to the gadget we'd seen at Carnegie, i.e. it had a black-box which includes a kind of telephone-holding cup and the user merely dialled the number of the computer and began to type. The 6060 however had some extra keys on the typewriter which gave access to various library functions (square root, determinant, eigenvalue, log, cos, sin etc). This device was developed by the Los Angeles people (System Sciences Division).

There were some illuminating discussions about CDC managerial policy. They are proud of the fact that their over-riding policy is

Decentralisation with profit/loss responsibility pushed to the lowest practicable level.

(This is borne out in practice as is apparent in any dealings with CDC. The UK representatives for example seem to be empowered to cut their prices when bidding against rivals without consulting Minneapolis).

It also appears that around 1st June each year there is an edict to all Divisions to cut staff by 5-10% within the next three months: pruning off the dead-wood.

We were amazed to learn that CDC were unaware of the existence of the ICT 1900 series until April this year. When we told them that we found this hard to credit since, (a) the 1900 series was announced publicly in September 1964 and (b) the existence of the 1900 series must be affecting their sales in the U.K, they replied that they had decided not to worry about sales in the U.K. because (1) there was a strong home computer industry, (2) there was now a 15% surcharge on imports and (3) the Government were apparently pushing a buy-British policy. It sounded sensible enough but we had the feeling of a rather sour grapes attitude behind the facade.

Visit to C.D.C. System. Sciences Division (Los Angeles) 11th June 1965

The C.D.C. System Sciences Division is a medium size group of people (~ 100) under R. E. Fagen. The structure chart is:

  • R. E. Fagen , General Manager
    • Computer Sciences: B. Clayton
    • Mathematical Sciences: Reed Dawson
    • Systems manager: W. Hopper
    • System Development Lab: Jim Johnson

Clayton's group is the largest, about 60 in all. Hopper's group has 9 or 10; Dawson's is quite small, only about 5 or 6. We were not told the size of Johnson's group but it is unlikely to exceed 20.

Clayton's group has the responsibility of producing the 6600 Fortran Compiler etc. Any special routines for the 6600, 3600, 6800 etc. that are required are written in Los Angeles.

Johnson's group developed the CDC 6060 which is a typewriter/telephone device designed to permit access to a computer from any telephone. This was similar to the equipment which Perlis showed us at Carnegie on 1st June. The 6060 was considerably lighter than the one at Carnegie (about 40 lbs compared to 100 lbs) and it had a number of keys allowing calling of library routines (these appeared to be a luxury; e.g. they included automatic finding of the largest eigenvalue of a 3 x 3 matrix). For a suitably designed computer system the 6060 could provide a very cheap way of adding a large number of MAC-type consoles; one could be placed in any room which had a telephone, regardless of its physical distance from the computer. The telephone line would then only be tied up when the 6060 was in use.

RFC spent some time discussing mathematical problems with W.J. Westlake* of Reed Dawson's group. Westlake is particularly interested at present in queueing theory, mainly in relation to multiple access consoles. His work is partly theoretical (and I suspect that others have got further in this direction) and partly quite practical: his model consists of two queues of different priorities. Queue 1 gets a short run fairly often, and Queue 2 gets a somewhat longer run less often. RFC hadn't heard of this approach to the MAC-problem before. There is nothing dramatic to report at this stage; Westlake was experimenting with varying the time quanta for each queue. These quanta are of the order of a few milliseconds (~ 6 or 8) . If the quantum is allowed to become very much larger (~50) a bottleneck soon appears. In the system Westlake was investigating it seemed that 54 milliseconds was approximately the largest tolerable value of the long-run quantum.

RFC and WJW had shared 'digs' in London in 1952/3. They had both subsequently worked at different times with Fagen, Clayton, Dawson and Hopper in Washington. Small world!

Westlake is also interested in testing random-number generators. His work is very much along the lines of MacLaren and Marsaglia of Boeing Labs., as given in their recent paper Uniform Random Number Generators, Journal A.C.M., Vol. 12, Part 1, Jan. 1965, 83-89.

Westlake is largely responsible for deciding which mathematical routines, particularly those connected with statistics, should be provided for the CO-OP (CDC Users) Library. He does very little of the actual programming himself; he provides the specification and the program is written by a member of Clayton's group.

Whilst RFC was with Westlake, EBF and FRAH talked to Neal Smith of Clayton's Group about some aspects of the 6600 software.

The original supervisor for the 6600 was the Chippewa System which was not very flexible and had a fairly crude Fortran Compiler. At present the basic CIPROS system is available and modifications and improvements are being made to this. One headache which is causing quite a lot of disagreement among users is the tape labelling system to be used. This will probably be similar to the Atlas system although operator overriding of requests may be allowed. Some users do not like this and a jump out to their own system will probably be inserted so that they may be able to take any action they like. The basic buffer size for tape transfers is 512 words. Not everyone likes this and for long records a two buffer system is being implemented using two peripheral processors. One buffer is filled while the other is being read.

FORTRAN

Fortran 66 is compatible with 3600 Fortran. It allows assembly language statements to be mixed with Fortran Statements in the same routine. At present code is generated in assembly language form and then it uses the assembler to finish the compi1ation. No attempt is made, at present, to bypass any of the assembler and reanalysis of identifiers and other time consuming actions take place. Later it is hoped to bypass the first stage of the assembler. At present the assembler compiles at 12000 orders per minute which forces compilation to be rather slow in the Fortran compiler. If no listing of the assembled code is asked for, it is hoped that compi1ation may go straight to code in the future. Code generation at present is very bad for indexed expressions. No special action is taken for constants and

A(2,3) = B(4,5,6)

requires 30 instructions at present.

(End of the portion of the trip report relevant to CDC)

Return to Home Page