News Round-Up

Rod Smith, who has been acting as liaison officer between the Society and the Science Museum for the past 10 years, retired in January. He was warmly thanked by the Committee for his untiring work on behalf of the CCS.

-101010101-

We look forward to work proceeding again on the Elliott 401 now that Arthur Rowles has become the new chairman of the Working Party in succession to Chris Burton. Arthur is a former employee of the Science Museum, who has the distinction of having recruited Doron Swade to the Museum back in 1975.

-101010101-

Arthur invites all members who have previously offered to join the 401 Working Party, or who would like to join it now, to get in touch with him. Contact details are inside the back cover.

-101010101-

Tony Sale reports that a Colossus cracked a code just before Christmas for the first time since 1945! Tony and his team are beavering away in a bid to ready the machine for the celebrations on 1 June marking the 60th anniversary of the first running of a Colossus Mark II.

-101010101-

The National Computing Collections Listing Project Web site is now accessible. Jenny Wetton reports that "it is fairly limited in the information contained within it and the quantity of collections covered, but members may want to consult it to find out what is held in the main public collections in the UK". Interested readers can access it at <www.sciencemuseum.org.uk/ncclp/welcome.htm>.

-101010101-

This year sees the Golden Jubilee of the Fortran programming language, which was first released in November 1954.

Society Activity

Elliott 401 Working Party

Owing to commitment priorities falling elsewhere, little or no on-site work has been undertaken on the 401 at Blythe House over several years. Former chairman Chris Burton requested an alternative chairman be appointed; I am he. With only three days work under our belts to date it is much too soon to report progress; but a proposed programme of up to four on-site days per month appears to have been accepted by the small band of supporters, and additional manpower is being sought.

Specification details of a 401 Order Code Emulator System are being worked out by Alan Martin, with engineering under Microsoft Windows proposed. This work is directed at (a) confirming understanding of the specific machine we are resurrecting, and (b) validating programs written for it, and furnishing a realistic training aid for potential demonstrators.

Contact Arthur Rowles at <rowles01 at globalnet.co.uk>.

Bombe Rebuild Project

With two notable exceptions there is nothing to report this time other than that in the near future we will have a major milestone to celebrate. There are 36 Letchworth Enigmas needed to complete the front of the machine: 118 commutators are required for this. All these commutators are now complete and will soon be built up into the last three Enigmas. Currently 33 are physically fitted and 29 are cabled up and fully tested. When the last three Enigmas are complete we estimate about another three days work will see the front of the machine complete. We are therefore on track to have the external aspects of the machine complete in time for the beginning of June events. The external covers are unlikely to be fitted at this time but perhaps that is just as well because this would make the interesting parts of the machine less visible.

Other items as previously reported have all made good progress and will be reported upon in more detail when we have more finished items to display.

The two major steps forward are in the area of Selenium Rectifiers and Special Resistors.

Acquiring Selenium Rectifiers to our original specifications has been a problem. For some years we put out calls for help but all that turned up was the odd single item, often not quite the correct type. We then decided to see if we could get them made. After a great deal of searching we were lucky and located a firm in the States which still made rectifiers. They came up with an item which is very close both physically and electrically to the originals. Better still, they gave us a below cost price and delivered in a few short weeks. We have now fitted 104 of these into the machine: they await their wiring.

Another item we had a great deal of trouble identifying was a wirewound non-inductive type of resistor. Again 104 are required. The problem was that we had been looking in the wrong place. We assumed that they would come, like the other wirewound resistors, from punched card equipment. It was a chance remark that led to us into realising that they were in fact GPO resistors. We now have two thirds of the number required and are not expecting any problems locating the rest. Most are the incorrect value and will have to be rewound. This led to another problem. Insulated resistance wire is virtually unobtainable but with a great deal of searching we found a firm with enough stock available, again in the States. This wire is currently on its way across the Atlantic. The interesting thing about this is that the supplier has told us that there will be no more of this wire manufactured unless somebody orders a quantity about 100-fold greater than our needs!

As I mentioned earlier, my next report should announce that the front of the machine is complete. This also means that the 12 miles of wiring will all have been completed, fitted and tested. Other items as mentioned in previous reports are progressing well. This leaves as the major task the various relays and associated circuitry to make and fit. After that we can start commissioning.

Our Web site can be accessed at https://www.bombe.org.uk/.

Inmos and the Transputer (part 2)

We then had to build a semiconductor plant in the UK. The Thatcher Government said "We're hands off. We don't involve ourselves with industry at all. We certainly wouldn't want to involve ourselves in any conflicts about where you locate the plant, but it had better be in South Wales"! So that's where it went.

We got the facility up, we got the process in, and then we hit trouble. We couldn't make the process work. We could make integrated circuits but they were unreliable and when we did tests on them we found they suffered from metal fatigue, and a small proportion didn't function correctly.

We identified a particular piece of process equipment which we didn't think worked very well. However the American company insisted that the fault must lie with the management of the operation - no problem with their process - it was the people who were running it in the UK.

Then, three or four months later, at Christmas 1982, we had a severe disaster. A semiconductor plant depends upon using copious quantities of very pure water and has enormous de-ionising facilities for the water to get to absolute, or very near absolute purity. I was rung up on Christmas Day with news that the water was anything but pure and was getting worse.

Even though we were now almost in full production, we had to close the whole plant down. It was not at all clear what had gone wrong. Eventually, after about three days, we identified that the problem lay with the resins which were used for the de-ionisation process - basically chemicals in huge 'tin cans'. The tin cans were about three metres in diameter and eight metres high. Something had gone wrong with them.

What we had to do - and this was all across the holiday period - was to physically dig out all this resin and get another lot trucked in and loaded. Virtually everybody in the company, including me, had shovels, and was standing in these great big tin cans shovelling resin.

The result was that the Americans said, "These Brits don't know what they're doing. Get rid of them!". The semiconductor facility was taken away and put under the control of the Americans who were deemed to understand these things.

What had actually happened, as we found out three months later, was that on Christmas Eve the engineers at the local reservoir decided to celebrate. They were supposed to stay on site, so what they did was to dump 100 times the standard level of chlorine into the water supply, then go off and have a Christmas party. That chlorine totally ruined our semiconductor plant.

We had many further problems. One was with money, because the pound collapsed and so my original £50 million had halved in value by the time we got around to spending the second half of it. So we ran out of money. We then had another highly protracted and visible round of arguments with the Government before we managed to extract another £15 million which was necessary to compensate for the fact that the second £25 million had been delayed.

We had just one staunch ally in the Thatcher Government - Keith Joseph. He consistently supported Inmos, consistently argued our case, and went to the Cabinet three times to get this money. While he was doing this he was being slated in the UK press for his lack of support for Inmos. A sad thing.

We eventually got our money. We got our process up. We got our SRAM out and Inmos became very successful. We were making a lot of money, and we had very good prospects. But Mrs Thatcher decided she didn't want Inmos, so it was politically unacceptable to recognise that we had been successful.

We suffered a succession of press and parliamentary statements about how unsatisfactory Inmos was. We also had the requirement placed upon us as management that we try to buy the company. I can tell you that it is extremely difficult to find a buyer for a company when your major shareholder is the Government and is saying that you're no good.

Our American partners did actually find an American company, which offered to take Inmos off the Government's hands for a fee of £15 million. Incredibly, this was agreed. So I went to the then chairman of Inmos and said, "Look this is totally wrong. We have a company that is doing extremely well and we have a deal which is being stitched up between an American company and our American partners to take it off the UK Government. For this they want to be paid - and then they are proposing to make a lot of money out of the US company."

My chairman said "Yes, I understand all that but I can't do anything about it. If you want to do something I will treat this conversation as privileged". So I went to see Mrs Thatcher and I told her that if the deal went through, in six months there would be so much mud on the face of the Tory Government that it would do them no good. That stopped it!

Back at the ranch, we were still trying to develop the transputer. I had the problem that I was trying both to direct the technical development of the transputer and to cope with my American partners and an unsatisfactory political environment. It was not a very pleasant time in many ways.

Going back to the transputer itself, we had two technical gurus, David May and Robert Milne. They were just like chalk and cheese - completely different in their approaches.

Robert was substantially more clever than David, and David's quite clever enough. When Robert wrote his PhD thesis in Edinburgh his supervisor Robin Milner, who was not lacking academically, said he couldn't understand a word of, it but seeing that Robert had written it, it must be right.

Unfortunately Robert did have the problem that he could not communicate very well with mere mortals. I spent my life trying to understand what it was he was saying. So we had a high level conflict between two people who were both very clear on their views on parallelism, one of whom had a simple vision and one of whom had a far more complicated vision.

Eventually I had to decide between the two. I had no hesitation, because David's position was basically where I had been some time before, but it was very painful at the time. Robert contributed a great deal to the underlying ideas and architecture of the transputer and he deserves recognition for that. Another thing he contributed, ironically, was the name Occam for our programming language.

In terms of process technology we had Peter Cavill from Marconi and Jonathan Edwards from Plessey. The depth of knowledge in the UK on process technology fundamentals was far better than in the United States, and most of the process ideas which were eventually developed came out of the UK company's microprocessor activities.

The CAD system and workstations were developed by Colin Whitby- Strevens and the actual detailed implementation and layout of the transputer was done by a team under Miles Chesney

We made an experimental microprocessor to prove the technique, to prove the design system, and to prove the process. We had to test a lot of the novel logical techniques that were being used inside. We made a cut-down version of the final transputer, without the on-chip memory and many of the more complicated instructions that relate to processes. We built a second chip to go with it which enabled us to take the outputs and display them; this drove a CRT display.

It all worked! Just like that! Bingo! I think we had one minor revision, but essentially we had produced a complex microprocessor which worked first time.

Essentially a transputer allows a set of programs or processes which are independent of one another to run concurrently, so that the processor is shared between a set of processes. The processors communicate with one another by a simple channel which passes messages and provides synchronisation.

We built the instruction set hardware so that what the programmer saw was effectively a set of parallel processes. The microprocessor implemented them and scheduled them. It did the scheduling in an optimally efficient way in terms of the number of times one swaps from one process to another. Again it all worked!

The trick was that we made sure that the communication between the processes that were running on a transputer was identical from a programmer point of view, whether it was done within one transputer or between multiple transputers. This meant it was invisible to the programmer whether he was using one transputer or several. The program was the same; it was just compiled in a different way depending how many transputers were being used.

Of course there was a performance overhead, and we put a lot of effort into ensuring that the overhead for going from one process to another was as small as possible. It was equivalent to something like three basic instructions, so we could have lightweight processes running very short programs with a negligible overhead. Some transputer applications were written with processes as small as 10 instructions.

The other thing we did was to create the Occam programming language, which directly mirrored the structure within the transputer. Occam was not a one-for-one assembly language; it was a high-level language built with predictability in terms of the length of time taken to execute any bit of compiled program.

All that was great. Everything worked just as the theory said it should. There was just one thing that went wrong - and that was the compilers.

It was quite clear that we were moving to a situation where we were going to have a programming language for our own internal purposes that effectively replaced an assembly language, but we expected that customers would want to program transputers in high-level languages.

That was a fundamental strategic goal from the beginning. It was obvious that people could not go on programming microprocessors in assembly language. There had to be a change.

We thought that if we had a chip which was designed properly to support high level programming languages, we would then be in a very strong position when that change occurred, compared to our competitor companies who were locked into architectures designed for hand-coding, because for them it would be extremely difficult to exploit compilers. We were right about that.

Unfortunately we had a problem - money! We had no money to develop the compilers we needed. Our funds had all been used up in the US. We tried to get away with using a cheap untried UK solution in which we were going to get three compilers generated from one basic piece of code - and it didn't work!

So by the time the transputer came to market everything was there, everything was right, except that we didn't have the compilers necessary to exploit the capability we had created. We never did get those compilers.

Reverting to the original business plan, the proposition that went to the NEB was to make an investment in a semiconductor company, to get it up and running, and establish a viable semiconductor business in the UK. Then the intention was to sell it off, doing away with the need for the NEB by refinancing Inmos in the UK as a UK company.

The plan said that this would happen in 1984. I had forecast that in that year Inmos would have a turnover of £150 million - which it did - that it would have a profitability of £12 million - I think we actually made £15 million - that the NEB would exit during the year, and that the company would be valued at £125 million. That is exactly what happened.

I bet nobody's ever produced a business plan and got it as right as that. I have to admit that if you look at the forecast for any one of the preceding years, they were totally and utterly wrong. But 1984 I got exactly right!

The Government was desperate for us to be privatised in some way, but they had no takers. I devised something I called the white pawn strategy. You've heard of white knights - white pawns are the poor man's version. There was no company in the UK that looked like a white knight, but I did think there were perhaps half a dozen companies that we might persuade to invest in Inmos to provide an underlying resource to support their businesses.

One of these was Thorn EMI. Come the middle of 1984, the then Chairman of Thorn EMI, Peter Laister, started to get ambitious and wanted to acquire something significant. He bid for British Aerospace, failed, and attracted a lot of criticism. One bright young man in his private office said to him "Why don't you buy Inmos instead?", and so he did, in less than a week.

He paid £125 million for Inmos. It was quite sudden, totally unexpected and, from my point of view, very surprising. I was called up one day and told "There's this company that wants to buy you". I went to various meetings, the last of them at the Department of Industry offices in Victoria Street. It started about midday and went on until midnight at which point the deal was done.

I was excluded from most of the meeting. I had no direct involvement, and I was told, "Just go down the corridor and find somewhere to sit". So I did. I sat down in an office and after about 10 minutes I started to look round and realised it was rather a grand office. I looked a bit more and realised there were papers on the desk. I was actually sitting at the Minister's desk. That's security for you!

Eventually I was called back into the meeting and was told the deal had been done. Peter Laister produced a transputer chip from his pocket, waved it at the assembled audience, which consisted of one person from the NEB, one from the Government and 50 lawyers and said, "Look, I've paid £125 million for this".

There was one flaw. The business plan said that in 1984 not only would the company be sold, but that it would be refinanced, because we knew at that stage we would want money put in to expand our business further. But there was no refinancing, and no money went into Inmos. The £125 million went straight to the Treasury.

So from that moment on we had no cash to do anything. We couldn't advance the technology in any way. We couldn't develop our memory products. It was not really Thorn's fault. They shouldn't have bought Inmos - it was a really stupid thing to do, and Peter Laister was ousted from that company within three months. Thorn did try their best to look after us. It was just that they didn't have the kind of cash that was necessary to fund and run a large-scale semiconductor company.

We had been doing very well. Our static RAM products, in spite of the technical problems, had knocked Intel out of the market. We had something like a 60% share of the world's market for them and our only competitors were Japanese companies. We had dynamic RAMs of high performance, and we had transputers just about coming to market. So we were in a very good technical position. We just didn't have the money to exploit it.

There was one other unfortunate occurrence at this stage. Almost immediately after selling the company, it started to become apparent that some of our customers were having failures in their static RAM memory chips. This problem escalated, and after about six months it became clear that we had a serious reliability problem.

The problem was due to a faulty piece of equipment. Inmos was not the only company to suffer at that time and two or three semiconductor companies actually went under as a result. Which piece of equipment was it? Yes, you've guessed it, it was the problem we had identified in the UK factory when we started to manufacture the static RAM in 1982. At that time, not only had the US taken over control and management of the UK factory, but they had also transferred production of the static RAM back to the US - it was a highly profitable product, and the company making the static RAM automatically had the better balance sheet. Heads rolled, and much of the US management was dismissed.

So we had to cut back the company and lost half our transputer design team. We tried to retrench in an appropriate management fashion and to create something valuable out of it, so we actually hived off some of our best people into a new company which then went into business making parallel computers.

The story got worse. Eventually I had the ironic situation where I was in the US running the US company and I had to sell it off. It was actually sold to Seymour Cray, whom I had spent quite a long time trying to convince of the value of the transputer.

It wasn't all doom and gloom because we had, as I have said, good technology. We had developed fundamental patents for static RAMs, for dynamic RAMs and for microprocessors, to the extent that every static RAM or dynamic RAM made involved a significant patent from Inmos. IBM was so concerned about our patent position in microprocessors they gave us rights to all their patents in return for rights in our patents.

Eventually dear old Thorn made something like £150 million to £200 million out of the Inmos patents, which is hardly ever mentioned. They got their money back all right.

There were two other money spinners. Our dynamic RAM technology was very good, and we were able to licence it to a Japanese company and set up an automated manufacturing facility in Japan. The other product was the second test chip we had made for the transputer. We persuaded IBM to use this as their next generation graphic chip, and it became embedded in the PC as the SVGA standard. Some of the oddities in the present Windows operating system stem directly from the way this chip was designed to work with the transputer.

But from the point of view of the transputer we did not have the resources to do what was necessary. We did do one clever thing which was to add a floating-point unit to the existing microprocessor. We exploited the improved process technology to be able to put on board a floating-point unit and again we used formal techniques. We were able to prove what we were doing and we were able to design a floating-point unit better than anything else on the market by a very long chalk. That gave us another couple of years lease of life.

The end came in 1989 when Inmos was sold to SGS Thompson. SGS Thompson was essentially a semiconductor company set up by the French and Italian Governments to do what Inmos had planned to do in the UK.

The Managing Director, Pasquale Pistorio, was very enthusiastic about the transputer. He thought it was an extremely good product and wanted to revive it. He was prepared to put a substantial amount of money in this. But there was a fundamental problem. No work had been done on the transputer in terms of implementation and design since about 1985, and this was 1989.

There were two routes that we could go down. One was to take the existing design and just re-implement it again in the latest process technology, taking advantage of various tricks and getting more memory on the chip and things like that. The most favourable view was that this could be done by 1991; my personal belief was that it would take at least a year or two years longer and would not be competitive.

The alternative was to start from scratch and design a new transputer, keeping the concept and making sure it was software-compatible and connectable and things like that, but changing the instruction set and being quite radical.

The quite radical thing was to put four transputers onto a chip. You could say that we were doing much the same thing as the very long instruction word microprocessors. We were going to produce a system with a full 64-bit internal bus with 32-bit addressing, four address units, four arithmetic units, and two 64-bit floating-point units. We were going to put a 50 Mbps link between the transputers and everything was absolutely divine. The trouble is that this would take a long time to do, and it wouldn't have been available until 1992 or 1993.

So there was no real way for the company to survive. A decision was made to go the route of re-implementing the existing design in the latest technology, and it was a failure as expected. That was the T9000 - it never really saw the light of day. That was the last of the transputer and very recently ST Microelectronics, as SGS Thompson has become, announced that there will be no more transputers, which is sad.

If we look back now, it is clear that Inmos was a glorious failure. It had enormous technical successes. The static RAM technology design is the way that the world now designs static RAM. The same thing is true for dynamic RAM technology. We had the transputer which was a unique design, and we had, as I have said, this very strong patent base. Our problem was the corporate failures.

The underlying issue was the control of the company. There were conflicts between the US and UK, which led to extreme mistrust. We had an antagonistic shareholder. Originally there were difficulties within the Labour Government, because there was one minister who objected - Tony Benn. Later our antagonistic shareholder was Margaret Thatcher.

I had a number of discussions with her aides about the problem. Mrs Thatcher continually said her aim was to support sunrise industries, and that she wanted to compete with the Japanese, and Inmos, of course, was doing all of those things. I was told that she had a very simplistic view towards life and liked to get things down to one basic idea. Her one basic idea about Inmos could not be changed, and that was that Inmos had been started by Tony Benn. Madam didn't like him very much.

At a management level we had the quality failures. There was also the underlying issue, which hits UK companies time and time again, that you can get the money to start, but when you get market success you really need more and you cannot raise it. What went wrong with Inmos more than anything else was the failure to get that second round of finance.

I think you will find that microprocessors in the future look more and more like transputers. You won't see it from the outside but it will be embedded in the way that they actually do their operations.

For all the problems, though, it was great fun, and I'm glad I did it.

Editor's note; this is an edited version of part of the talk given by the author to the Society at the Science Museum on 19 November 1998. The first part, describing how Inmos came into being and the thinking behind the Transputer, appeared in issue 32.

Iann Barron is at <iann at mynchen.demon.co.uk>.

A Management Perspective on Orion

Peter Hall

I make no apology for my decisions which led to the real problems with Orion 1, but I think it might be interesting to put on record how they came about and make some comments about the consequences.

I took over the Computer Department in 1958, having been given the job because the then Manager Brian Pollard had left and a few years previously an old wartime friend and colleague Bill Elliott who had been running the southern laboratories - Lily Hill - had also resigned. Bill had taken a few key people with him to IBM!

I can only assume that I was given the job because I had rescued another ailing department - it certainly was not because I knew anything about computers - I knew nothing. Perhaps I should add here that on taking over the Department I got no briefing from any of the senior Ferranti management - except "Put it right"! I had no briefing from Brian Pollard: he had gone before I arrived.

Ted Braunholtz's reports of meetings with Sebastian Ferranti and with Brian Pollard concerned with a justifiable warning about "neurons" were news to me. I heard of them first when I spoke to Ted a few weeks before the seminar. If only he had been able to get hold of me in 1958 the story might have been different.

The southern team at Lily Hill had been responsible for the development of Perseus. Delivery was late and the machine for the Old Mutual in Cape Town was very late indeed. In July 1959 I had to go to South Africa with Peter Hunt to placate a very irate customer who had written a vitriolic letter to Vincent Ferranti. This was not an easy trip, and while I judged that the Lily Hill lot was a competent gang, from my standpoint they had certainly made my first year tiresome! Perhaps the previous management had given them a job too big for the resources made available. The team at Lily Hill had, it seemed, been left after Bill Elliott had gone without a clear management structure. I soon put Peter Dorey in charge. He later became one of Ferranti's senior and most successful managers and a director of the company.

Peter Dorey expressed no desire to take on another major project, and I gave no thought to getting them in on the Orion act. With hindsight this was clearly a mistake.

The West Gorton situation was different. Mercury and Pegasus were in production, seemingly reasonably on time and not causing any serious headaches. Perhaps here I should correct a statement made at the seminar regarding the University machines.

The university made what used to be called "bread boards"; while West Gorton was responsible for turning the circuits and the logical design into an engineered product, and for developing enhancements. Sales were going OK and the only problem seemed to be that we were making too much profit on Pegasus and we would have to give some money back to NRDC!

But there was a flaming row going on about what computer we should develop next. So it wasn't just the war between north and south I had to cope with but between two factions in West Gorton - the university protagonists and the "in house" people, who rarely seemed to talk to each other.

Fortunately I knew the university people well. Freddy Williams and Tom Kilburn were at the same wartime Radar Research Establishment as me (TRE), and I knew of their work. They were an exceptional team at TRE and I knew that their work at the university would be first class. Tom's proposal for a machine sounded exciting and would mean that we would establish a world lead in high speed computing. Could we do it? I judged that together we could.

On the other hand was the internal faction led by a man with a proven reputation (in imaginative thinking and in circuit design from Cambridge) - Gordon Scarrott. Gordon later proved his worth leading the teams on CAFS and DAP. Their proposal was for a more modest machine geared to the commercial market and to the cheaper end of the scientific market.

The circuits Gordon proposed, and had christened "neurons", had been tested in an experimental machine they called Newt - they seemed to work well. Later Newt was re-engineered and was sold as Sirius. Sirius was a success - again proving the circuits. The circuits were attractive because they were extremely powerful logically, and also from a production standpoint because many fewer types would be required than if we had used competing circuits. How wrong we were!

I made up my mind that we would go for both machines. This put far too much strain on all our resources - particularly when both programmes ran late; cash got more than a bit short! The neurons became our biggest problem.

It was not just that current-driven logic was difficult to commission; the circuit tolerances were just not good enough when used in such large numbers, and on such a physically large machine. We could have used "griblons" (as in Orion 2) from the word go! But nobody suggested we should.

I should have had a closer look at the neurons. Remember, though, that such was the infighting that nobody could be trusted to give an unbiased view. I wish Ted had got through to me - and I wish I had had "more hindsight sooner"!

I would like to make a comment regarding the relationship between Orion 1 and Orion 2. I felt (but I could not hear half of the soundtrack so I may be mistaken) that more acknowledgement should have been given in the seminar to the fact that the Orion 2 project started from a computer design that was known to work - Orion 1. The change in circuits meant a significant logical redesign, but essentially the job was only to re- engineer Orion with "Griblons" instead of "Neurons" - nothing else. With an architecture that was known to work and proven software - OMP in particular - it seemed to me a straightforward job.

In these circumstances it was possible to agree a very tough development programme. Indeed if it was not done quickly it would not meet our urgent need as an Orion 1 replacement. Although the Prudential requested some additional facilities the team did a fantastic job in meeting the delivery without incurring penalties. It is interesting to note that Orion 1 took roughly five years to develop compared to about three years for Orion 2.

A small point, but perhaps important, is that Nebula was not an Orion 2 project - we did it for Orion 1. It should not just be bracketed with Orion 2. We did hope of course that Nebula would be carried forward into later machines. I hope the contribution made to the Nebula programme by Peter Hunt was properly recognised. I believe Peter was a very outstanding software project manager.

There was a suggestion at the seminar that Ferranti should have done more market research before embarking on development projects. This is a difficult one. Rely on market research and you develop a Perseus, sell only two, and lose a fortune! If you just get on with the job, and stop thinking (as Freddie Williams told Tom Watson of IBM ) then you make an Atlas, and, you may be surprised to hear, make a little money! Seriously, there must be both "technology push" and an understanding of the market - "market pull". (But don't pretend customers know what they want).

Finally I should like to echo what Ted said in relation to our memories. We are looking back over 40 years and memories are fallible. Some things can be checked from various archives of course, but most of my comments are from my memory of those events long ago! I know I get things wrong (I have proved it to myself in relation to some wartime work).

Contact Peter Hall at <peterdhall at hotmail.com>.

Before Moore's Law

Brian Wichmann

Moore's first statement concerned the number of components on a semiconductor that provided the minimum cost. At any given time, increasing the number of components beyond this threshold reduced the yield, making it less economic. The number defining this threshold seemed to be doubling every year.

This prediction was reasonably sound from 1959 to 1975. But the real driver to increase the number of components was the ability to provide functionality to a large market, via the general-purpose microprocessor.

In 1979, Moore's key message concerned the number of components on the largest chips, which gave a three year doubling rate over the period 1959-1975.

There are some fundamental problems with an analysis in terms of components per chip. As the technology improves, so does the packing density. Also, some chips, such as memory chips, are much simpler than others, such as a microprocessor.

The advent of memory and cpu chips changed the market completely. Intel's own figures for microprocessors over the period 1971-2001 show initially a doubling of the transistor count over 22 months, then over 33 months, and then in the last eight years over 54 months. The rate is clearly slowing down.

This analysis does not address the real point, which is the performance supplied to the user. Unfortunately, the industry tends to advertise performance in terms of the clock rate, while the user really wants to know how long a specific activity will take. For scientific computing a compromise would be the number of floating point operations that can be executed per second. On this basis, the Intel figures for the period 1971- 1995 give a doubling rate of about three years.

Measuring actual performance is difficult, since the relative speed of two machines depends critically on the task undertaken. When Intel published technical details of the 386 processor, it used the Whetstone benchmark which I wrote with Harold Curnow. However, Intel's coding (in C) was not a correct transcription of the original program. It is very hard to avoid such problems.

My interest here is in the speed of computers during the period 1960- 1977. From 1965 to 1977, I spent some time at the National Physical Laboratory (NPL) studying the speed of computers and also the effectiveness of Algol compilers. Over this period, it was possible to move programs in Fortran or Algol 60 to a variety of machines and measure their relative speed. For Algol 60, it was possible to measure the times for individual statements, partly due to the absence of any effective optimization!

Algol performance

My first study collected the execution times of some basic statements in Algol 60. These were all given in microseconds - hardly an appropriate unit today. An analysis was then undertaken on the basis of a simple model that the time for any statement should be approximately the product of a factor depending on the complexity of the statement and another factor inversely proportional to the speed of the machine. The analysis was then presented by taking Atlas as the machine of unit performance.

The use of Atlas in this regard was even enshrined in a Ministerial statement which required Government to go single tender to ICL for machines more powerful than Atlas.

The analysis of these statement times indicated which statements were implemented well and which were poor. Another study indicated the main reasons for the differences, at least for five compilers (again, including Atlas). The last report collecting these statement times included a graph of the performance of 34 machines. This is shown in Figure 1.

Figure 1: Statement time analysis for 34 machines

Machine performance

These performance analyses failed to answer some basic questions, such as what should be the performance of a particular computer? It was clear that some Algol 60 compilers did show some machines in a good light and that other languages, particularly Fortran, would provide very different results.

A small database was constructed and a substantial amount of information was provided by the Central Computer Agency (CCA) in addition to that from NPL. The CCA computed the Gibson Mix and ADP Mix for machines procured by Government. Also, as part of the acceptance test, they ran some benchmark programs and timed them. A research report documenting the results about this created a lot of interest, so it was decided to produce a 'commercial' report using the same analysis technique and incorporating further information from CCA.

Clifford Nott spent much time and effort producing a Guide to the Processing Speed of Computers which would do credit to NPL and justify its market price (£50). When 200 copies in a flashy red ring file were ready, I produced a press release to mark the occasion. This was duly presented to the then Director of NPL, Dr Paul Dean. Unfortunately, he decided the material was too 'commercial' being perhaps like a Which? report. I suspect I have the sole remaining copy of the (non-)publication. The crucial figures giving the performance of the machines appear in Figures 2 and 3.

Figure 2: Summary, Part 1

Figure 3: Summary, Part 2

Postscript

The data on performance which relates to Moore's Law is really only applicable when microprocessors became the main computing engines for large parts of the industry. In contrast, the data that I collected in 1977 related to large mainframe computers. However, the two are clearly related and indeed, the benchmark programs can easily be run on modern microprocessor-based systems to give a direct comparison.

The long-term success of computing is amazing. When I retired in 1999, I calculated that my home computer (an iMac) was 13,000,000 times more cost-effective than the KDF9 which I used when I started work in 1964. This represents a doubling of cost-performance roughly every 18 months.

Unfortunately, my data lacks any indication of when the computers first came into operation. If this could be added, then an analysis of the increase in computing power over the period 1966-1977 should be possible. I hope to work with Professor Bob Hopgood to add this information so that the extrapolation of Moore's Law can be determined over the period 1960-1977. Hence I would be delighted to know the relevant dates for any of the machines listed.

Editor's note: Contact the author at <Brian.Wichmann at bcs.org.uk>.

Obituary: John Gosden

John Gosden, software pioneer, died in New York on 18 December 2003 at the age of 73.

Gosden joined J Lyons as a trainee programmer in 1953. At that time its small Leo team was engaged on the final trials of the payroll programme for the Cadby Hall bakeries. The Leo system of the time was equipped with only the most rudimentary systems software: the programmer had to do it all. By the time that Gosden left six years later he had sketched a full body of systems software for the latest Leo system, based on his rich experience in implementing programs of all kinds and on his study of the most advanced work elsewhere.

A key part of Gosden's work was in working alongside John Pinkerton, Leo's Chief Engineer, to ensure that Leo III incorporated all the facilities required to meet business application needs. This system was able to run several programs at the same time and was microprogrammed to enable users to devise new macroinstructions to implement frequently used sequences. Gosden also devised the high level language Cleo for the system.

On joining the Auerbach Corporation in the United States in 1960, Gosden raised the Standard EDP Reports to new levels and then managed the construction of a multi-computer operating system for the US Navy. Later, at the Mitre Corporation, he was responsible for planning the database requirements for the Joint Chiefs of Staff, and then at the Equitable Life Assurance Society of New York he was VP responsible for major projects and policy. Among other activities over the years he chaired a committee advising on White House support systems. Well into his retirement he advised the Museum of Modern Art and the Cornell Medical Centre on their database systems.

Notwithstanding his crowded US career, John Gosden remained very close to his Leo roots. He was Associate Editor of LEO, the Incredible Story of the World's First Business Computer in 1987 and contributed a chapter entitled "Toward Systems Software". In 2001, although already in failing health he crossed the Atlantic to contribute to the fiftieth anniversary celebrations of the first business computer application in London's Guildhall.

Letters to the Editor

Dear Editor,

I was interested by Iann Barron's article on Inmos and the Transputer in Issue Number 32 of Resurrection.

The DAP (Distributed Array Processor) preceded Inmos. I remember Iann visiting the ICL research labs in Stevenage to look at the Pilot DAP (which had 1024 1-bit Processing Elements) as part of a government inspection delegation, I think early in 1976. I remember Iann holding one of our boards with 16 PEs on it, and looking thoughtfully at it for some time. We had been advised not to engage in argument with the delegation, so there was little discussion. I would be interested if Iann remembers the visit, and if it had any influence on his thinking about the Transputer.

After considerable rivalry and many generations of both the SIMD DAP and the MIMD Transputer, they both more or less died. However, there is what might be described as a joint successor technology alive today. The DAP lineage ended with CPP (Cambridge Parallel Computing), which folded in March last year. The previous year I left CPP to join a startup, WorldScape Inc (<www.wscapeinc.com>), that is involved in SIMD technology in association with ClearSpeed (<www.clearspeed.com>), a company (formerly known as PixelFusion) in Bristol that is an indirect descendant of Inmos. There is currently a 64-PE chip available which includes IEEE floating point units in every PE. There are traces of Transputer heritage in the architecture, but it is essentially SIMD technology from some of the Inmos MIMD veterans. A new beginning.

Returning to the early years. I first met Iann at a computer workshop in Grenoble in June 1973, where I presented the first paper on ideas that became the DAP, but I don't expect this caught Iann's attention. The biggest players in the early DAP scene were David Hunt and Peter Flanders in my Stevenage team, and Dennis Parkinson in ICL technical marketing. My manager at the start was John Iliffe.

One day I may write more on DAP history.

Stewart Reddaway
By email from <Stewart.Reddaway at wscapeinc.com>
17 February 2004

Forthcoming Events

Every Tuesday at 1200 and 1400 Demonstrations of the replica Small- Scale Experimental Machine at Manchester Museum of Science and Industry.

13 May 2004 AGM, followed by London meeting: "The History of Health Computing in the UK". Speaker Professor Bernard Richards.

1 June 2004 Colossus Anniversary meeting, Science Museum.

Details are subject to change. Members wishing to attend any meeting are advised to check in the Diary section of the BCS Web site, or in the Events Diary columns of Computing and Computer Weekly, where accurate final details will be published nearer the time. London meetings take place in the Director's Suite of the Science Museum, starting at 1430. North West Group meetings take place in the Conference room at the Manchester Museum of Science and Industry, starting at 1730; tea is served from 1700.

Queries about London meetings should be addressed to Hamish Carmichael, and about Manchester meetings to William Gunn on 01663 764997 or at <william.gunn at ntlworld.com>.

CCS Web Site Information

The Society has its own World Wide Web (WWW) site: it is located at <www.bcs.org.uk/sg/ccs/>. This is in addition to the FTP site at <ftp.cs.man.ac.uk/pub/CCS-Archive> (please note that this latter URL is case-sensitive). Readers wishing to access past issues of Resurrection should use this FTP site. The Web site includes information about the SSEM project as well as selected papers from Resurrection. Readers can download files, including simulators for historic machines.

Committee of the Society

[The printed version carries contact details of committee members]

Chairman  Dr Roger Johnson FBCS
Vice-Chairman  Tony Sale Hon FBCS
Secretary  Hamish Carmichael FBCS
Treasurer  Dan Hayton
Science Museum representative Dr Xerxes Mazda
Museum of Science & Industry in Manchester representative  Jenny Wetton
National Archives representative  Jeffrey Darlington
Computer Museum at Bletchley Park representative  Michelle Moore
Chairman, Elliott 803 Working Party  John Sinclair
Chairman, Elliott 401 Working Party  Arthur Rowles
Chairman, Pegasus Working Party  Len Hewitt MBCS
Chairman, DEC Working Party  Kevin Murrell
Chairman, S100 bus Working Party  Robin Shirley
Chairman, Bombe Rebuild Project  John Harper CEng, MIEE, MBCS
Chairman, Mil-DAP Working Party  Brian M Russell CEng MIEE
Chairman, Software Conservation  Dr Dave Holdsworth CEng Hon FBCS
Digital Archivist and Chairman, Our Computer Heritage Working Party  Professor Simon Lavington FBCS FIEE CEng
Chairman, North West Group  Tom Hinchliffe
Editor, Resurrection  Nicholas Enticknap
Dr David Anderson
Peter Barnes FBCS
Chris Burton CEng FIEE FBCS
Dr Martin Campbell-Kelly
George Davis CEng Hon FBCS
Harold Gearing Hon FBCS
Eric Jukes
Ernest Morris
Dr Doron Swade CEng FBCS

Point of Contact

Readers who have general queries to put to the Society should address them to the Secretary: contact details are given elsewhere.

Members who move house should notify Hamish Carmichael of their new address to ensure that they continue to receive copies of Resurrection. Those who are also members of the BCS should note that the CCS membership is different from the BCS list and so needs to be maintained separately.

Aims and objectives

The Computer Conservation Society (CCS) is a co-operative venture between the British Computer Society, the Science Museum of London and the Museum of Science and Industry in Manchester.

The CCS was constituted in September 1989 as a Specialist Group of the British Computer Society (BCS). It thus is covered by the Royal Charter and charitable status of the BCS.

The aims of the CCS are to

• Promote the conservation of historic computers and to identify existing computers which may need to be archived in the future
• Develop awareness of the importance of historic computers
• Encourage research on historic computers and their impact on society

Membership is open to anyone interested in computer conservation and the history of computing.

The CCS is funded and supported by voluntary subscriptions from members, a grant from the BCS, fees from corporate membership, donations, and by the free use of Science Museum facilities. Some charges may be made for publications and attendance at seminars and conferences.

There are a number of active Working Parties on specific computer restorations and early computer technologies and software. Younger people are especially encouraged to take part in order to achieve skills transfer.