Departmental Memorandum

Dr S Gill

5/8/1960

Distribution

• Mr P D Hall
• Mr B B Swann
• Dr A A Robinson
• Dr C M Wilson
• Mr G G Scarrott
• Mr E T Warburton
• Dr R H Kerr
• Professor T Kilburn
• Dr D B G Edwards
• Mr R A Brooker
• Dr R B Payne
• Mr C H Devonald
• Mr D Milledge
• Dr D J Howarth
• Mr J A Fotheringham
• Mrs E M Leslie-Smith
• Mr B C Chapman

Atlas Order Code: Notes by A R Curtis

The following notes were arrived at on a discussion of the above between Mr. Milledge, Dr. Howarth, Mrs. Leslie-Smith, Mr. Chapman and myself on August 4th.

The points made by Curtis did not seem to us to constitute very fundamental criticism of the Atlas design. In many cases he merely comments on the lack of information in our privately circulated description, a lack which we are aware of and which it is the purpose of the whole project to remove. His criticisms of the design itself are largely a matter of the relative speed and ease of doing various operations, but this can only be criticised in relation to the engineering facts of life and Curtis obviously has not been in a position to see how these have influenced the design of Atlas. In particular he would like to see more functions made basic rather than Extracode, but he has no information about the effect that this would have on the speed of everything. Also he would apparently like to do many logical operations in the accumulator, but again does not know what this would cost and it is not clear whether he has a sound reason for wanting it or is merely expecting to do things in the same way as they are done on the 709.

In fact his main points are ones which have already been thrashed out in discussions involving both Ferranti and the University. The paucity of comments containing new and worthwhile suggestions was encouraging, but these few points should obviously be looked into.

One general comment which might be taken seriously is that in concentrating on single precision floating arithmetic, and leaving many other operations to be extracoded, we have made these other operations so much slower that they are seriously affecting the speed of the machine. He claims, for example, that Monte Carlo calculations necessarily involve a great deal of packing and unpacking which is comparatively slow on Atlas. We ought to do an investigation to see exactly how one would programme Monte Carlo on Atlas, with particular reference to packing and to drum transfers, but we are unlikely to be able to start on this very soon. In any case, it is too late to have much effect on the design of the design of the machine and we can only hope that ways will be found of doing Monte Carlo reasonably efficiently.

The following points should be discussed with the engineers.

1. The exact specification of division if it can now be given; in particular whether operation 21 could divide the whole of the accumulator, what happens if the divisor is zero, whether the iterative loop shown in Curtis' flow chart at the top of page 2 does or could exist, etc.
2. Could Curtis' comment number 8 be met, i.e. an instruction to round the accumulator?
3. Is the exact timing of the change of the digits giving the angular position of the drum fixed by the present design or can it be arranged to suit the drum transfer routine? (It will probably turn out to be best for it to change at a time which does not coincide with the beginning and end of sectors on the drum.)

Information is wanted on the following specific points:

1. How long does it take to enter an Extracode routine?
2. Check that accumulator Extracode functions 38 to 43 apply to the exponent as well as the fractional part.
3. What is meant by 'e' in the accumulator test functions 8 to 13?

The following work should be done by programmers somewhere:

1. Compile an updated list of lengths, times and full specifications of Extracode routines. The following in particular need looking into.
   1. Accumulator functions 87 to 90.
   2. B-function e16.
   3. The variable length magnetic tape transfers.
2. The time taken to pack and unpack two or three floating-point numbers per word should be determined and compared with the 709 (Mrs. Leslie-Smith will see to this).
3. The kind of fixed point operation suggested by Curtis in comment 7 seems good and should be investigated as a possibility for Extracode.
4. The separation of integral and fractional parts of a number in the accumulator (Extracode?).
5. Fixed point addition into l should be investigated (comment 14).
6. The accumulation of scalar products should be looked into (comment 15).
7. Comparison between the accumulator and a store register would probably be useful, but it is not clear whether Curtis' suggestion 17 is the right way to do it.
8. Curtis' comment 38 should be borne in mind in deciding the programmed drum transfers. It is not clear why he wants to specify pages, but his operations (a), (c), (e) and (g) seem sensible, although they are not clearly stated.
9. We should look into the idea of having an instruction for entering a closed subroutine, although specification should not necessarily be as suggested in Curtis' comment 27.

Apart from the above we felt that Curtis' other comments should be answered as follows:

• 5. Agreed.
• 9. Agreed except for the last sentence which would be very messy to achieve.
• 10. No reason for this.
• 1.3. Agreed.
• 19. Already rejected because of speed.
• 20. 0166 is not like the preceding two instructions. These are specials and are not intended to form a group. Anything else on these lines would be of considerably less importance.
• 21. Hardware shifts other than those provided have already been rejected. We should, therefore, be prepared to use a big Extracode routine to make it as fast as possible and we shall obviously not use one as slow as that suggested by Curtis.
• 24. Please read the description again.
• 27. (Last part). A bright but pointless idea which would slow down the machine.
• 28. We cannot see why.
• 29. Hideous to engineer.
• 32. Agreed that we must be able to take an integral part somehow, but the assertions about rounding are curious.
• 36. We can see no real reason for this.
• 37. There does not seem to be a serious shortage of function codes yet and we hope that there will not be an enormous number of additions in the future.
• 39. Curtis' comments on this are obviously tentative and there is no direct clash of proposals yet, but we should bear his remarks in mind. We have, however, tried to include the ability to modify the deck number and Curtis' suggestions do not allow this.