Avere a disposizione un prodotto incredibilmente innovativo, a dir poco rivoluzionario, dovrebbe essere motivo sufficiente per spalancargli le porte del mercato e, magari, dominarlo. In realtà la storia ci insegna che non sempre i prodotti più avanzati sono poi quelli che hanno fatto strada.
Un esempio su tutti è la GPU P10 di 3DLabs, per la quale la casa madre coniò addirittura il termine VPU (Visual Processing Unit) per enfatizzare le sue strabilianti capacità, ma che fu relegata poi al solo mercato professionale a causa della complessità del chip e delle difficoltà a ottenere driver ottimizzati in grado di sfruttarlo come si deve.
Il campo dei microprocessori, come al solito, non fa eccezione, e ci presenta nel lontano 1981 una CPU a 32 bit progettata nientemeno che da Intel e pensata per implementare in hardware funzionalità utili la programmazione a oggetti (OOP), che all’epoca faceva timidamente capolino cercando di farsi strada in un mondo dominato dal paradigma imperativo…
In realtà questo processore non era costituito da un singolo chip, ma l’architettura era talmente complessa per l’epoca che ne richiese la suddivisione in tre. Due di essi, chiamati GDP (General Data Processor), costituiscono la CPU vera e propria (il primo si occupa del fetch e della decodifica delle istruzioni, mentre il secondo della loro esecuzione) e insieme contengono circa 160mila transistor. Il terzo, chiamato IP (Interface Processor) e che si occupa dell’I/O, ne contiene 49mila.
Come potete immaginare, più di 200mila transistor sono una quantità impressionante e rendono bene l’idea della dimensione di questo progetto, che sovrasta praticamente tutte le soluzioni disponibili all’epoca ponendosi necessariamente su un mercato privilegiato, che è quello dei minicomputer e mainframe. Quindi totalmente fuori dal mondo consumer.
Tanti transistor equivalgono anche a tanta roba implementata. Di ciò sicuramente la più grossa fetta riguarda, come già detto, l’implementazione in hardware di funzionalità atte ad accelerare la programmazione orientata agli oggetti (ma non soltanto).
Questo paradigma permea tutta l’architettura della CPU, e lo si vede in ogni dettaglio. Basti pensare che qualunque elemento/struttura di sistema è costituito da oggetti: dallo stato del processore allo stack, dalle subroutine all’elenco dei processi.
Come un sistema a oggetti che si rispetti, esistono diversi tipi di oggetti predefiniti / di sistema, e altri personalizzabili se ne possono creare all’occorrenza. C’è, infatti, un completo type system, con tanto di manager per ogni tipo di oggetti che ne gestiscono l’accesso.
Ovviamente non esistono soltanto gli oggetti, e a livello di manipolazione di dati questo microprocessore offre pieno supporto per i classici tipi scalari: caratteri, interi a 16 e 32 bit, numeri in virgola mobile a 32, 64 e 80 bit, strutture, vettori e campi di bit.
Questo tipi di dati è comunque memorizzato all’interno di oggetti primitivi, chiamati generic object, che sono costituiti da segmenti di memoria aventi una ben definita struttura:
Come si può vedere, un segmento è diviso in due parti, chiamate rispettivamente data part e access part (che occupano al massimo 64KB ciascuna).
La prima, che si estende verso l’alto, contiene esclusivamente dati scalari. La seconda, che si estende verso il basso, contiene esclusivamente quelli che vengono chiamati access descriptor (AD) o, in gergo, capacità dell’oggetto (informazioni 32 bit tramite le quali si referenziano tutti gli oggetti presenti nel sistema).
Gli AD (che sono alla base di questa CPU) rappresentano anche il punto di collegamento con altri oggetti, visto che tutti i segmenti sono indirizzati tramite questo meccanismo. Considerato che anche le subroutine sono oggetti, si fa presto a parlare di metodi associati a un particolare oggetto.
Chi ha esperienza di design di compilatori di linguaggi OOP, oppure conosce i dettagli implementativi di basso livello del linguaggio di programmazione orientato agli oggetti che usa, sicuramente riconoscerà questo tipo di schema che separa i dati “grezzi” dalle informazioni “di servizio”.
Senza andare troppo nel dettaglio (ho preferito focalizzarmi sull’aspetto OOP del chip, altrimenti l’articolo sarebbe diventato chilometrico), altre caratteristiche (tutte implementate in hardware tramite particolari oggetti di sistema) di cui è dotato l‘iAPX 432 sono le seguenti:
- primitive di allocazione della memoria;
- garbage collector (di tipo mark & sweep);
- protezione della memoria;
- rigido e controllato accesso a qualunque risorsa (tramite access right e le già citate AD);
- accesso isolato a dati e AD (tramite apposite istruzioni che operano esclusivamente su uno dei due);
- capacità di multiprocessing (si possono realizzare sistemi con fino a 6 CPU collegate sullo stesso bus);
- scheduling degli oggetti process;
- messagebox per lo scambio di messaggi fra processi e/o processori.
Come si può vedere, si tratta di funzionalità che permettono di semplificare la scrittura dei sistemi operativi, oltre che migliorarne le prestazioni, grazie al supporto on-chip.
Singolare è anche l’ISA (Instruction Set Architecture), che è del tutto priva di registri. Infatti per le operazioni e memorizzare i risultati intermedi viene utilizzato lo stack (esattamente come avviene con molte macchine virtuali che, agendo in questo modo, sono chiamate appunto stack-based) oppure la memoria.
Può sembrare una grossa limitazione, ma dobbiamo anche considerare che, come dicevo in un precedente articolo, all’epoca le memorie erano più veloci dei microprocessori, per cui una scelta di questo tipo aveva senso.
E’ difficile da comprendere, invece, quella di codificare gli opcode delle istruzioni in termini di bit a lunghezza variabile. In pratica le istruzioni non occupano byte, ma bit (da 6 a più di 300), e possono essere posizionate a qualunque offset (di bit, ovviamente).
Se da una parte ciò consente di risparmiare spazio (codificando in maniera molto compatta gli opcode), dall’altra complica enormemente la loro decodifica, e riduce lo spazio a disposizione per i segmenti di codice (dove stanno le subroutine) a soli 8KB (perché viene utilizzato un offset a 16 bit per referenziare gli indirizzi del codice, che in termini di byte si traduce in 8KB di memoria indirizzabili).
Tra l’altro è singolare che si sia pensato a ottimizzare lo spazio per il codice quando i segment descriptor (strutture che racchiudono le informazioni fondamentali dei segmenti similmente alle più conosciute page directory entry), occupano ben 128 bit (16 byte).
A titolo di confronto, i segment descriptor (selector, per la precisione) di 80286 e 80386+ sono a 64 bit (8 byte). Le page directory entry per le architetture che utilizzano la paginazione sono a 32 bit per le ISA a 32 bit (4 byte), mentre per quelle a 64 bit sono a 64 bit (8 byte). E stiamo parlando di sistemi più recenti, non di roba del 1981…
E’ da soluzioni come queste, unite alle numerose e complesse funzionalità integrate (compreso un meccanismo di fault tolerance), che si può capire il perché del netto fallimento di questo microprocessore: era troppo lento.
Nonostante il notevole numero di transistor e le successive integrazioni di cache atte a ridurre i costi per l’accesso ai segmenti degli oggetti (similmente alle TLB delle PMMU), le prestazioni col codice tradizionale di quei tempi erano decisamente scarse, anche meno di 1/4 rispetto ad altri più economici e semplici chip concorrenti.
Il risultato è che l’iAPX 432 fu venduto in poche migliaia di esemplari, per lo più a università in cui la sperimentazione di nuovi sistemi operativi, linguaggi di programmazione, ecc. era (ed è) sempre molto fervida.
L’insuccesso di questa geniale (perché, specifiche alla mano, lo era) CPU dimostra che immettere un prodotto troppo innovativo (di OOP se ne parlava a malapena) senza che il mercato sia in grado di recepirlo (e, soprattutto, non bilanciando le innovazioni con le prestazioni) è una strada decisamente pericolosa.
Anche se una multinazionale come Intel certi buchi nell’acqua se li può permettere…
Interessante davvero, non ne avevo mai sentito parlare di un tale processore. E possibile che Intel sulla scia dei lisp processors della fine degli anni 70 inizio anni 80 si sia buttata in questa nicchia di mercato, privilegiando non il lisp ma il paradigma ad oggetti ?
Chissa’ perche’, fare macchine lisp non era troppo remunerativo ?
Con iAPX432 Intel voleva andare a prendersi il mercato mainframe all’epaco dominata da IBM e Digital usando l’allora promettente liguaggio di programmazione ADA, infatti un’altra caratteristica del chipset (non citata nell’articolo) era quella di supportare nativamente in hardware un sistemi di fault-tollerance sui sistemi multi-cpu, nel caso un singolo componente del chipset si fosse guastato sarebbe stato escluso in automatico ….
Comunque alla fine non tutto il progetto fu un insuccesso, infatti alcune caratteristiche anni dopo vennero riprese nel progetto P54 (pentium)e il “core” della cpu venne usato come base di partenza per lo sviluppo della cpu risc i960 (che ebbe largo successo come cpu-embedded).
@Andamus : cosi’ per curiosita’, ci sono oggi processori nel mercato server/mainframe che usano il meccanismo di fault tollerence in hardware ? E se si quali sono.
Grazie.
Quoto Andamus ;)
Intel ha fatto “fiasco” perchè era un settore troppo poco sviluppato, anche se non oserei dire Fiasco, ma semplicemente che non ha fruttato come dovrebbe.
Secondo me se questa tecnologia fosse rinnovata nel tempo sui nuovi processori intel consumer, brucia buona parte del mercato concorrenziale.
e che dire dei Transputer?
l’apx 432 però è significativo perchè mostra come spesso sotto la morte di una tecnologia innovativa non ci sono sempre le spinte economiche e lobbystiche di società senza scrupoli….del resto il processore era del monopolista Intel eppure non sfondò
e come dimenticare la fine miserabile che ha fatto il ( nei sogni di Intel ) mitico Itanium
c’è da dire che la semplicità d’utilizzo paga e alla fine è ciò che determina la vittoria o la sconfitta di una tecnologia
e visto che ci siamo perchè non parliamo anche del flop di Cell? ottimo processore, ma assurdamente complesso da programmare
Il processori Cell hanno fatto fiasco perchè l’unico OS che è supportato è Linux, il che a me non dispiace proprio per nulla, ma non me ne farei nulla di un processore Cell, mentre se usato in ambito server un processore Cell non è per niente male.
Wikipedia:
http://it.wikipedia.org/wiki/Cell_(processore)
http://it.wikipedia.org/wiki/Blue_Gene
Umhhhh!!!Interessante!!!!
@goldorak: probabilmente Intel voleva bruciare sul tempo la concorrenza presentando una CPU che incarnava in pieno la nascente OOP.
@Andamus: delle capacità di fault-tolerance, al contrario, ne ho parlato in fondo all’articolo, ma soltanto come accenno, perché il pezzo è venuto fuori già di per sé abbastanza lungo.
Non so quanto dello iAPX432 ci possa essere nei Pentium e nell’80960, perché trovo la sua architettura molto diversa da quella di queste due CPU.
@goldorak: se non ricordo male POWER di IBM, UltraSPARC di Sun e Itanium di Intel/HP abbiano funzionalità di fault-tolerance (ma devo andare a rispolverare queste architetture).
@SpyroTSK: è stato un fiasco perché le prestazioni erano veramente scarse, a fronte di un costo eccessivo.
Anche oggi non avrebbe vita facile, vista la notevole complessità dell’ISA.
Poi i moderni processori, sebbene non espressamente progettati per essa, se la cavano molto bene anche con la OOP.
@pabloski: all’epoca (1981) Intel non era una monopolista. Al contrario, il mercato dei microprocessori era molto variegato.
Transputer, Itanium e Cell (e altro ancora :D) saranno trattati in futuro. ;)
@Spock: grazie. Ti assicuro che lo è stato anche per me scoprire questa chicca. :)
@ Cesare
ehm ehm… Intel non è tecnicamente monopolista, detiene una posizione dominante sul mercato :-D
Stavamo parlando del 1981, anno di commercializzazione dell’iAPX 432. ;)
Oggi, e da molto tempo, ovviamente è come dici tu. :)
Secondo me definire geniale una cavolata del genere è voler regalare a tutti i costi complimenti non meritati. Progetto fallimentare: molto più complicato, farraginoso costoso e lento di quanto disponibile allora. E’ corretto dire che hanno fatto il passo più lungo della gamba, cercare di costruire qualcosa non essendo capaci di farlo davvero. La cosa straordinaria è convincere qualcuno (una persona sola, credo, in questo universo) che il progetto è buono nonostante l’evidente fallimento. Tanto buono che non è mai stato ripreso da nessuno, neanche lontanamente, nemmeno come idea di striscio.
Dalle mie parti dicono “ma va a ciapà i rat”!
Tre chip per fare il lavoro di uno solo, peggio e con maggior costi sia di hardware che di sviluppo software. Bella genialata!
Sì, “ma va a ciapà i rat” ci sta dentro tutto!
Se mi dite che hanno cercato di vendere il rospo a qualcuno per tamponare le spese di ricerca e sviluppo posso crederci, ma solo a questo e basta!
@Cesare Di Mauro
considerando anche che i compilatori di oggi fanno i miracoli … ;)
@sakuraki: che sia stato fallimentare sono stato il primo a dirlo, nelle conclusioni dell’articolo.
Che sia stato un progetto geniale, lo dico da studioso ed estimatore delle architetture degli elaboratori, analizzandone i dettagli e ammirando le scelte coerenti che sono state fatte dai progettisti.
@pietro: fanno molto sicuramente, ma non abbastanza. Basti prendere Itanium, che aveva puntato molto sulla loro bontà, e che s’è ritrovata ad avere prestazioni mediocri per gli obiettivi che s’erano prefissi Intel e HP. :P
@goldorak come cpu con sistemi di fault tollerance in hardware ci sono gli Itanium/Itanium II, varie versioni dei Power di IBM, alcune versione degli Ultrasparc e gli ormai estinti Alpha 21364.
@Cesare di Mauro, il riferimento all’eredità dell iAPX432 nel Pentium l’avevo trovata in una brochure della Intel, non mi ricordo se quella per i 20 o 25 anni di anniversario, mentre per quanto riguarda l’ i960 mi sono spegato male, intendevo dire che i team di sviluppo dei due processori era composto in buona parte dagli stessi uomini e che il secondo progetto fu molto influenzato dai pregi/difetti del primo. Cmq se hai bisogno di materiale (soprattutto foto) di “vecchie glorie” ne ho a disposizione tantissime essendo un collezionista ….
@sakuraki in quegli anni era prassi comune suddividere le varie funzioni di UNA cpu su più chip, ad esempio il Power 1 di IBM era basato su 11 o 9 diversi chip a seconda della versione.
@andamus, goldorak
Beh dipende da cosa intendi per fault tolerance: ad es. credo che tutti i processori abbiano ECC sulla cache dati, e parity check sulla cache istruzioni, e vari ECC sui certi bus. Se intendi cose piu’ sofisticate per proteggere i singoli flip-flop, registri, e logica combinatoria interna, mi pare che ancora non ci sia molto nei processori che usiamo noi, ma probabilmente ci sara’ in un futuro molto prossimo (col diminuire delle dimensioni i dispositivi stanno diventando via via piu’ inaffidabili).
@Andamus: OK per il 960 (mi pareva troppo strano, essendo un RISC e lo iAPX 432 un CISC estremamente complesso :D).
Per il Pentium mi rimane la curiosità.
Sulle foto… se ne hai, spedisci pure (a cesare chiocciolina pronto punto it), se non ti crea troppo disturbo. Come puoi vedere, in genere metto qualche foto dei chip di cui parlo nei miei articoli, e potrei utilizzare qualcuna delle tue. :)
@pleg. Il sistema di fault-tolerance dello iAPX 432 è di gran lunga più complesso ed efficace, perché viene utilizzata una coppia di CPU a cui vengono spedite le stesse istruzioni e poi confrontati i risultati per verificare se ci sono stati problemi, e individuare eventualmente quale delle due è malfunzionante, spegnendola.