The AT&T Hobbit is a microprocessor design that AT&T Corporation developed in the early 1990s. It was based on the company's CRISP (C-language Reduced Instruction Set Processor) design, which in turn grew out of Bell Labs' C Machine design of the late 1980s. C Machine, CRISP and Hobbit were optimized for running the C programming language. The design concentrated on fast instruction decoding, indexed array access and procedure calls. Its processor was partially RISC-like. The project ended in 1994 because the Hobbit failed to achieve commercially viable sales.
In a traditional RISC design, better referred to as load-store architecture, memory is accessed explicitly through commands that load data into registers and back out to memory. Instructions that manipulate those data generally work solely on the registers. This allows the processor to clearly separate the movement of data from the processing done on it, making it easier to tune the instruction pipelines and add superscalar support. However, programming languages do not actually operate in this fashion. 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.
The C Machine, and the CRISP and Hobbit that followed, directly supported the types of memory access that programming languages used and was optimized for running the C programming language. Instructions could access memory directly, including structures within memory such as stack frames and arrays. Although this "memory-data" model was typical of the earlier CISC designs, in the C Machine data access was handled entirely via a stack of 64 32-bit registers; the registers were not otherwise addressable (in contrast with the INMOS Transputer and other stack-based designs). Using a stack for data access can dramatically reduce code size as there is no need to specify the location of the data needed by the instructions. On such a stack machine, most instructions implicitly use the data on the top of the stack. Higher code density means less data movement on the memory bus, improving performance.