AT&T Hobbit
Da Wikipedia, l'enciclopedia libera.
Gli Hobbit sono una famiglia di microprocessori prodotti all'inizio degli anni novanta dalla AT&T. Furono sviluppati a partire dal progetto CRISP (C-language Reduced Instruction Set Processor), un progetto che mirava a realizzare un processore ottimizzato per l'esecuzione di codice C. Il progetto si concentrò su una rapida decodifica delle istruzioni, una rapida gestione degli array e delle chiamate alle procedure. Sebbene fosse un processore di tipo RISC sotto molti punti di vista era un progetto diverso dagli altri processori e non riuscì mai a trovare un vero mercato di riferimento e la sua commercializzazione fu sospesa a metà degli anni novanta. Tuttavia il progetto ispirò molti progetti successivi.
In un progetto RISC tradizionale l'accesso alla memoria è di tipo load/store, cioè il processore per modificare un dato in memoria carica sempre esplicitamente il dato (load) in un registro, lo modifica e poi lo salva nuovamente in memoria (store). Spesso l'architettura RISC per questo motivo viene chiamata anche load/store. Questa tipologia di accesso alla memoria specifica chiaramente gli accessi alla memoria permettendo di realizzare pipeline in modo relativamente semplice e permette di realizzare processori superscalari con poca logica aggiuntiva. Tuttavia i linguaggi di programmazione non seguono questa filosofia di accesso alla memoria. Normalmente utilizzano una struttura a pila (stack) dove salvano le variabili locali e altre informazioni per la gestione delle sottoprocedure. Il compilatore quando compila il codice traduce la struttura a stack in una serie di load/store per il processore.
Il progetto CRISP e l'Hobbit invece gestiscono direttamente il metodo di accesso basato su stack utilizzato dai linguaggi di programmazione. Il processore includeva delle istruzioni che gestivano direttamente lo stack e gli array. Sebbene questa gestione della memoria fosse comuni dei primi processori CISC il progetto CRISP gestiva lo stack tramite 64 registri a 32 bit. I registri non erano accessibili direttamente (come dell'INMOS Transputer o in altri progetti basati su stack). L'utilizzo dello stack per accedere ai dati riduceva notevolmente la dimensione del codiice che non doveva indicare più esplicitamente la posizione dei dati per ogni operazione, i dati erano nello stack e basata scorrere lo stack per scorrere i dati da processare. Questo riduceva la dimensione del codice e diminuiva gli accessi alla memoria migliorando le prestazioni del processore.
Il progetto CRISP fu avviato nel 1987 principalmente come progetto di ricerca. Secondo molte fonti Apple Computer contattò AT&T e finanziò lo sviluppo di una versione a basso consumo del processore per il palmare che stava sviluppando. L'Hobbit venne prodotto nella versione 92010 nel 1992 con una cache dati dii 3 KiB. Nel 1994 venne presentato il 92020 con 6 KiB di cache. Apple decise di non utilizzare il processore e sviluppo il suo progetto sull'architettura ARM. AT&T comunque sviluppo un proprio palmare chiamato EO Personal Communicator e la Be Incorporated iniziò lo sviluppo del BeBox sulla piattaforma Hobbit. Tolti questi progetti non ci furono altri progetti commerciali basati su Hobbit e quindi AT&T dismise il progetto.
Un effetto secondario del progetto Hobbit fu l'ispirazione dei progettisti della macchina virtuale Dis (un progetto secondario del Plan 9) di utilizzare un sistema basato su registri strettamente abbinato con l'esterno del processore. I progettisti dei sistemi RISC avevano progettato un sistema basato su load/store per ottenere alte velocità e una macchina virtuale non basata su questa filosofia sarebbe stata necessariamente lenta per via della conversione da modalità a stack a modalità load/store. I progettisti di Dis si reseco conto che tutti i processori futuri si sarebbero basati su questa filosofia e quindi progettarono Inferno con questo paradigma per migliorarne le prestazioni. Questa filosofia di sviluppo era l'opposta di quella utilizzata da .NET e da java che basano la loro macchina virtuale sullo stack e che quindi ottengono prestazioni modeste quando sono eseguiti. Convertire un linguaggio basato su stack in un'assembly basato su load/store è un processo molto dispendioso e inefficiente. La macchina virtuale Java è molto più grande e più lenta della macchina virtuale di Limbo
