Skip to content

Instantly share code, notes, and snippets.

@pervognsen
Last active May 6, 2017 18:54
Show Gist options
  • Save pervognsen/bef8d82519ffa238a0101c457220b15b to your computer and use it in GitHub Desktop.
Save pervognsen/bef8d82519ffa238a0101c457220b15b to your computer and use it in GitHub Desktop.

http://archive.computerhistory.org/resources/access/text/2012/06/102746190-05-01-acc.pdf

Wilson: So that was 1981. We converted a lot of the system range capabilities to make the BBC machine [the BBC Micro] in the first place, and we built a lot of peripherals specifically for the BBC machine. And then we started implementing language processors. So the BBC machine had a socket underneath of it for the second processor, and its two-processor model. I designed the Tube, interconnection between the two things, and wrote all the software protocols that ran the Tube. The Tube was basically a dual-direction DMA controller plus four FIFO channels of communication so that you could virtualize your operating system. So a second processor operating system, all they had to do was send the right commands across the Tube, and the I/O processor machine would do all the right stuff for them. So we got all of that working and we started building second processors. The only one that sold a lot was a 4-megahertz 6502, 2-megahertz 6502 in the base machine. And with these two things linked together, then everything just ran. You put your 4-megahertz 6502 on, and programs were copied across to it, and executed twice as rapidly. And without-- well, more than twice as rapidly if you were doing lots of I/O stuff at the same time, because the other processor would still be working away. And that was quite successful. Some people even wrote games for the dual processor, so there was a very successful game called Elite, which was David Braben and Ian Bell's space trading game, with three-dimensional wire-frame graphics, and that had a version for the second processor as well. So we'd built lots of second processors, and we came up against this thing that they were no better than the 4-megahertz 6502. You could get an 8- megahertz 68000, I think it was in the days, just before 68010 came out; an 8-megahertz 80286, which we built into a machine, and Hermann [Hauser] had this plan to sell an Acorn business machine based on the 80286 running CPM86, multitasking version of CPM. And we'd gotten with National Semiconductor on the chip originally called 16032, and then renamed 32016, and built the same processor in that. And they were all very disappointing. These high-end processors with their clock rates twice the 6502s with their bus widths twice the 6502s were actually, in many circumstances, slower. This was because they didn't use the memory system effectively. On the 6502 at 4 megahertz, each cycle is a memory access. So it accesses 4 megabytes a second. On all these other ones, a memory access is four cycles of the master clock on a 68000. So an 8-megahertz 68000 would only do two bus accesses per microsecond, and they would be two bytes wide. So they only had four megabytes bandwidth, just the same as the 6502. But in building the 6502-based systems, we knew how to make very high-performance memory systems. And if we made the memory system wider, a 16- or 32-bit wide memory system, we could easily design a memory system with 16 to 32 megabyte-per-second memory bandwidth. But we couldn't find a microprocessor that could eat that. We became convinced-- which we think is still true for cacheless microprocessors-- that memory system bandwidth is direct predictor of system performance. You fetch in your instructions, you're doing all your I/O; without a cache, the memory system bandwidth is the system performance. So we knew we could build a faster memory system, but we couldn't find a microprocessor. One of the avenues we followed to get a faster microprocessor was to go back to the developers of our favorite 6502. So Western Design Center was discussing a successor to the 6502, the 65SC816. So Steve [Furber] and myself and a guy called Andrew McKernan, who ran Acorn's Advanced Research department at the time, flew out to Phoenix to visit Western Design Center and talk to them about their processor. And that wasn't too unusual for us. We had flown out to Israel to talk to National Semiconductor about the NS32016 development, and we saw in Israel kind of what we expected-- massive building on a science park with loads of people working. When we came into Western Design Center, these people who had build our favorite processor, what we found was essentially some bungalows next to each other with ordinary drawing boards in them, and William D. Mensch and some college kids designing processors by sticking bits of sticky tape, Rubylith tape, on transparent things to-- this was less sophisticated than we were. [...] So we came away, well, fairly convinced that, although the 65SC816 was an advance on the 6502, it wasn't what we wanted. We also came away fairly convinced that if they could build a processor, then we sure as hell could. So we started thinking about building computers, processors ourselves. Professor Hopper, Andy Hopper, at that stage saw the very first publications of RISC chips. So he put on my desk first press releases and papers, and about a month later the IBM801 papers were published. So I had them all on my desk, and I looked at them all, and thought, "Hmm, we could do this." So then we spent-- by we, I mean me, Steve and Hermann-- Hermann was an integral part of this, not in terms of providing any of the technology, but in providing somebody for us to talk about. So I started designing an instruction set. It wasn't the first time I'd designed an instruction set. I did one during university years as well, but this one would be more real. Steve started researching how you made these things work, what a microprocessor pipeline is. We had figured out that 6502's sort of semi-pipelined structure was noticeably more efficient than what Motorola did the 6800 and 6809. We already appreciated that things overlapping well really worked for us, and we had a philosophy for ARM that we actually pipelined the memory BUS as well, which was later on removed because people found it too confusing to design with. But it was very good performance gain-- so I mean, Hermann, Chris [Curry] and I, we-- Hermann, Steve and I would work separately for part of the time and then we'd walk down to lunch from the Acorn building to the nearest pub, talking all the time, and come back and revise things and keep doing it. And we got more and more convinced that we could indeed make this thing. Hermann set up an official project in Acorn to do it, and we had me, Steve, and Hermann gradually acquired four VLSI design engineers, originally led by Robert Heaton, and later on by Jamie Urquhart. And we did it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment