網路行銷
Over 200 billions Hobbitses. Hobbitses in your phone, in your TV, in your computer. Hobbitses everywhere! *
* With apologies to J.R.R. Tolkien
Telecoms giant AT&T once had giant computing ambitions. Its Bell Labs research arm invented the transistor and developed the C programming language and the Unix operating system. As the owner of Western Electric, AT&T manufactured electronic equipment in volume. After it was forced to spin off the ‘Baby Bells’ in 1984, AT&T acquired computer and ATM manufacturer NCR.
So we shouldn’t be surprised then that AT&T designed and manufactured its own microprocessors. In this post we’re going to look at the history and design of one of those designs1, the Hobbit.
We’ve met the Hobbit twice already. First, as the processor that Apple initially used when they started to design the Newton handheld, only to abandon it in favour of the ARM architecture. Then, we encountered it as the processor used in the early designs of Jean-Louis Gassée’s BeBox.
It’s fun to consider an alternative history where Apple uses the Hobbit processor in the Apple Newton. Apple then uses it in the iPod, the iPhone and the iPad. The Hobbit becomes enormously popular and takes on the role now occupied by Arm designs : ubiquitous, low power processors used in the devices that we carry around with us and use every day.
Could this alternative history have happened?
The Hobbit is now a footnote in history, but it’s a really interesting microprocessor. It’s quite different to the ARM that replaced it and to most modern designs. So let’s have a look at the Hobbit and its story.
The story starts with the development of the C programming language at AT&T’s Bell Labs.
C was devised by Dennis Ritchie in the early 1970s as a system implementation language for the nascent Unix operating system. It has since become one of today’s most important programming languages. Initially developed to run on a DEC PDP-11 minicomputer, it was soon implemented on a wide variety of machines, ranging from 8-bit microcomputers to large mainframes.
By the end of the 1970s C was becoming more popular and work was initiated in Bell Labs to develop a processor that was optimised to run C.
Today this might seem like a slightly strange idea. C is so ubiquitous and so important that one would expect that all processor designs would need to run C well. Then, the range of languages in use today running on a small set of instruction set architectures means that optimising for just one language possibly seems – well – suboptimal.
In the 1970s though C wasn’t yet ubiquitous. The range of processor architectures was greater. Mainframes, minis and microcomputers were all relevant. New architectures were appearing regularly. As we saw in our post on the Intel iAPX432, designing an architecture around a language (Ada in the case of the iAPX432) was an approach that was used elsewhere at the time.
So engineers at Bell Labs started to design a machine to run C well, known, perhaps somewhat unimaginatively, as the ‘C Machine’.
Building a machine to run C meant looking at what C programs actually did. When the Bell Labs engineers looked at their data, one of the central observations from this analysis was that C programs spent a lot of time manipulating the stack2, as programs called subroutines and passed data to and from those subroutines by pushing it on or popping it from onto the stack. From Wikipedia:
Generally they use a stack containing local variables and other information for subroutines known as a stack frame or activation record. The compiler writes code to create activation records using the underlying processor’s load-store design.
So the Bell Labs engineers focused on how to make access to the stack fast. They did this by ‘caching’ the top of the stack in the processor and including instructions to manipulate the stack directly.
They also observed that register instructions were often used just to help with the management of the stack. So they did something radical. They omitted general purpose registers completely (the design had special purpose registers such as the program counter but no registers that could be used to manipulate data or hold memory addresses for example).
Why were registers omitted? Quoting the paper ‘Register Allocation for Free: The C Machine Stack Cache’ by Dave Ditzel and H.R. McLellan, which discusses the design of the ‘C Machine’:
Registers: Why Not
The use of registers also has several drawbacks. Registers must usually be saved across procedure calls; this saving tends to make procedure calls time consuming. Expensive procedure calls inhibit structured programming techniques that encourage many small procedures. To achieve any benefit, registers must be efficiently allocated. The predominant use of high level languages places the burden of register allocation on compilers.
The need for a large, slow, expensive and often bug ridden compiler has been eliminated while achieving most of the benefits. The hardware to implement the Stack Cache is simple, and the registers can be cheaply duplicated for parallel operand access.
So the ‘C Machine’ was explicitly designed to reduce reliance on compilers.
It’s interesting that one of the key developers of the ‘C Machine’ (and one of the authors of the paper above) was Dave Ditzel, who had worked with David Patterson at UC Berkeley and had co-authored with Patterson, “The Case for the Reduced Instruction Set Computer”, one of the key early papers making the case for RISC.
The C Machine was only ever partly built. What was built used discrete components based on ECL technology, as had been used in the IBM 801.
In the 1983 a new team was formed in Bell Labs to build on the work of the ‘C Machine’ and develop a design that became known as CRISP (for C-language Reduced Instruction Set Processor).
This time, CRISP would a microprocessor built using CMOS technology:
The AT&T CRISP Microprocessor is a high performance general purpose 32-bit processor. It has been implemented as a single CMOS chip containing 172,163 transistors in a 1.75 p CMOS technology and runs at a clock frequency of 16 MHz.
CRISP used many techniques that were also adopted by RISC designs in order to speed program execution, such as instruction pipelining and the inclusion of a small instruction cache. Again though, like the ‘C Machine’, it had no general purpose registers:
Unlike most computers CRISP has no visible data or address registers. Instead, 32 internal Stack Cache registers are mapped into the address space corresponding to the top of the stack. The Stack Cache is byte-addressable and looks like memory in every way. It can contain strings, structures and arrays. The Stack Cache is implemented as a circular buffer of registers, maintained by a head and tail pointer, called the Stack Pointer (SP) and Maximum Stack Pointer (MSP).
How did the CRISP design perform against competing RISC designs of the time? Benchmarking of the CRISP design showed strong performance both against a DEC VAX 11/780 minicomputer and against the MIPS R2000 RISC processor.
The first CRISP design was sent for fabrication in January 1986. It would be built in 1.75 micron CMOS technology would be the first microprocessor that could execute more than one instruction per clock tick – i.e. the first ‘superscalar’ microprocessor.
Early microprocessors sometimes incorporated the initials of the designers on the die. The CRISP would go one step further. It would include tiny ‘portraits’ of seven of the designers in the middle of the CPU die.
This all looked promising, so the next stage in the evolution of the design was its commercialisation into a design that would be known as the Hobbit, and manufactured by AT&T Microelectronics.
Apple was engaged as a customer, with the expectation that Apple would use it in its Newton handheld computer, and AT&T and Apple engineers worked closely on the development of the design. Apple paid millions for its development and the Hobbit was intended to exclusive to Apple for a period of time.
There is, though, one aspect of the decision to use the Hobbit in the Newton that looks strange. The Hobbit was designed to be optimal for programs written in C. The Newton, however, was to be programmed in Dylan, a functional and object oriented language, that was quite different to C.
Early Newton designs used three Hobbits, but to reduce costs and increase battery life that was cut down to a single Hobbit. That single processor struggled to run the Newton’s software.
In addition, the Hobbit was buggy and, as the Hobbit was exclusive to Apple, AT&T wanted millions more dollars from Apple to continue development for the Newton. So Apple looked at the ARM architecture instead. Benchmarks showed the ARM design outperforming the Hobbit. So Larry Tesler, now in charge of the Newton project, orchestrated a switch to the ARM architecture in 1990. Apple became a joint venture partner with Acorn in the new ARM business.
Perhaps ironically, Dylan would ultimately be abandoned in the Newton and Apple would use C++ in the final designs.
But, even if Apple had dropped the Hobbit from the Newton, AT&T had its own ambitions in the world of personal mobile computing. The company took majority ownership of EO Inc. the hardware spinout from GO Corporation, the developers of portable computers with a pen-based user interface.
In a twist of history, EO would be led by Herman Hauser, one of the founders of Acorn Computers and a key backer of the development of the ARM architecture. Hauser’s Active Book Company had previously been bought by AT&T and was merged into EO with Hauser becoming CEO.
By the start of 1993 January edition of Byte presented AT&T’s vision of personal communications centred on the AT&T EO Personal Communicator. From the perspective of the 2020s it looks stunningly prescient:
The Computer as a Telephone
In conjunction with Go Corp., AT&T has recently entered the personal communications arena in a big way. AT&T and Go hope to establish their view of personal communicators as a standard platform for personal communications devices.
The EO Communicator would, of course, compete directly against the Hobbit’s original home, the Apple Newton, which had launched the previous year.
Naturally, the EO Communicator used the Hobbit as its CPU, and the Byte article sets out how design of the Hobbit.
Again, the Hobbit used in the EO machine had no user addressable general-purpose registers, with instead the top of the stack held in a rapidly accessible cache:
The goal of the stack cache is to keep the top elements of the stack in high-speed registers (the stack grows to lower addresses). The stack cache consists of a bank of 64 registers (4 bytes wide) organized as a circular buffer maintained by two registers: the maximum stack pointer (MSP) and the stack pointer (SP).
Two addressing modes were available to access values on the stack or pointed to by addresses on the stack:
Stack Offset
In the stack offset addressing mode, a signed, two’s complement offset stored in the instruction is added to the current stack pointer (CSP) value to obtain the operand address.
or pointed to by addresses on the stack:
Stack Offset Indirect
In the stack offset indirect addressing mode, an offset is added to the CSP value to obtain the address of the operand’s address.
The EO Personal Communicator was launched with a huge marketing campaign reportedly costing over $40m.
It wouldn’t be long before the vision started to fail. Sales of the EO Personal Communicator fell well below target and it was soon axed.
Eo, Inc., 52 percent owned by AT&T, shut down operations on July 29, 1994, after failing to meet its revenue targets and to secure the funding to continue. It was reported that 10,000 of the computers had been sold.3
That also meant the end of the Hobbit.
The long journey, stretching over more than a decade and a half, from C Machine, to CRISP, to Hobbit had come to an end.
In latest tech news the takeover of processor designer Hobbit Inc. by Nvidia has been halted on antitrust grounds. Commentators say that this leaves the Hobbit homeless. In related news Hobbit Inc. has finally reached an undisclosed settlement with the J.R.R. Tolkien estate and has agreed to rename the company as AT&T RISC Machines or ARM for short.
Could this alternative history, where Hobbit replaces Arm, have happened?
In short, I think it’s unlikely, for two reasons.
First, AT&T’s management would have had to show sustained commitment to the architecture and in a way that enabled it to thrive. Arm’s low-margin licensing business model was a key part of the businesses success. Would AT&T have licensed the Hobbit and accepted such a low-margin model. I think that’s very unlikely.
Second, stack architectures haven’t prospered. The merits of stack vs register based architectures needs a full post of its own, but register based architectures dominate completely today. That means that modern compilers have been optimised to work with register based machines, taking away much of the rationale behind the Hobbit’s design.
Let’s finish with an ironic accident of history. When Steve Jobs announced the first iPhone he did so with a cellular carrier partner with a famous name: AT&T.
AT&T once had the vision that its own devices powered by its own Hobbit chips would power a mobile revolution. Instead AT&T4 had a minor, walk on part in a vision laid out by its one-time partner.
If you’ve got this far you probably want the full ‘Chip Letter’ experience! So please consider becoming a paid subscriber.
Paid subscribers get supplementary posts with more analysis, links and background reading . Including this time: was the Hobbit a RISC processor?, further reading on the Hobbit architecture and New York’s Museum of Modern Art!
As a trial, in order to avoid cluttering inboxes, I’m going to start sending out paid subscriber supplementary posts a few days after the main post.
I’ll also be trialling early access to some posts for paid subscribers. The first one will look at Nvidia, and will be sent to paid subscribers next week, and to free subscribers a week later.
