Intel Itanium, il supporto all'architettura interamente a 64 bit rimosso dal kernel Linux

mi sembra ragionevole, anzi pensavo che lo avessero rimosso già da un pezzo, visto che in sostanza non ha mai preso piede

azz, dovevano essere clienti importantissimi per essere -pochi- e supportati per 16 anni

Molto bene, via il legacy inutile.

Che peccato, che architettura sprecata, secondo me era veramente una grande architettura. Peccato per i dannati compilatori. Secondo me una rivoluzione mancata.

Spesso sento dire,a morte x86 e viva arm,ma la realtà è molto diversa, ciò che sa fare bene una architettura,l'altra non la sa fare bene,quindi,se x86 è riuscita a sopravvivere a dec alpha e a itanium,mips e compagnia bella, è perché è ancora valida.

Più che altro c'era un contratto ferreo con HP che vincolava Intel a supportare gli Itanium oppure avrebbe pagato penali devastanti.

Infatti da un certo punto in poi Intel ha dedicato ad Itanium solo le risorse strettamente necessarie per non venire sventrata in tribunale da HP.

A parte questo, Itanium é un caso da manuale di EPIC fail a livello di management di un progetto "too big to fail".

In origine quello che divenne Itanium era un progetto di HP finalizzato a realizzare il successore della loro architettura RISC (PA-RISC) e poi si evolse in uno sviluppo congiunto tra HP ed Intel.

HP voleva sganciarsi dalla produzione di cpu per server e workstation di fascia alta senza dover dipendere da un concorrente.
Intel cercava un partner per riuscire a lanciare una nuova architettura che nel tempo sostituisse gli x86 e di cui non ci fossero concorrenti con licenze per la produzione di cpu compatibili (principalmente AMD e VIA).

L'architettura EPIC originale sembrava destinata ad essere il futuro, in pratica era un evoluzione delle cpu VLIW senza i difetti principali delle precedenti architetture VLIW.

Mi ricordo di aver letto sulla rivista Byte il primo articolo su quello che allora era solo EPIC, con una prima descrizione abbastanza dettagliata; sembrava predestinato a far fuori tutte le altre cpu di fascia alta (POWER, MIPS, UltraSparc, ecc. ) e poi "scendendo in basso" avrebbe spazzato via x86.

Il problema principale fu che il progetto originale molto snello ed orientato agli utilizzi "da server/supercomputer" poi con l'entrata in gioco di Intel cominciò a diventare qualcosa di sempre più pieno di fronzoli e di requisiti di retrocompatibilità con gli x86.

Ad esempio, i primi sistemi Itanium dovevano essere in grado di fare il boot di un S.O. per x86 e far girare i relativi software applicativi.

Inoltre mentre per HP le prestazioni nell'aritmetica floating point a 32 o 64 bit erano fondamentali (software di simulazione, applicativi di elaborazione di dati scientifici ed altra roba "pesante" a livello di calcoli in floating point), per la maggioranza del codice sorgente in origine scritto per x86 da portare su Itanium erano invece le prestazioni nell'aritmetica intera a 16 o 32 bit ad essere dominanti (su una cpu ottimizzata per lavorare su interi a 64bit).

Per questo le cpu Alpha (ancora sul mercati ma già di fatto "morte" da quando da DEC erano finite in mano a Compaq e poi ad HP) avevano prestazioni superiori alla prima generazione di Itanium; erano più equilibrate e non erano appesantite da fronzoli vari e requisiti di retrocompatibilità con x86.

Si infatti la sfortuna del processore Itanium è stata fortemente influenzata dal connubio contrattuale Intel-HP

Moltissimi clienti di "elevato spessore" utilizzavano server basati su Itanium, il problema è che questi server erano forniti solo ed esclusivamente da HP che ne deteneva il monopolio e non permetteva ad altri brand di produrre e commercializzare server basati appunto su Itanium.

Ѐ un vero peccato, Itanium meritava parecchio, era un processore multicore fortemente votato all'elaborazione parallela e l'unica debolezza che aveva era di non disporre di unità di calcolo adibite al riordino delle istruzioni proprio per massimizzare l'elaborazione parallela, ma questo non era assolutamente un problema grave, Intel aveva rilasciato l'assemblatore/compilatore specifico per Itanium che provvedeva al riordino delle istruzioni del codice e all'ottimizzazione di questo e forse anche sull'assemblatore/compilatore HP aveva il diritto di veto ...

Scusa, ma non é assolutamente così.

Intel vendeva Itanium a chiunque, inizialmente molti produttori pensavano che il successo di Itanium fosse "inevitabile", Silicon Graphics abbandonò i MIPS a 64bit per passare ad Itanium, anche IBM commercializzò dei sistemi basati su di esso. Solo Sun snobbò gli Itanium fin dal principio.

Solo che dopo l'uscita di Merced (la prima generazione di Itanium) furono subito evidenti le differenze tra quanto promesso anni prima e quello che che arrivò sul mercato.
Silicon Graphics nel frattempo fallì e tutti i produttori eccetto HP abbandonarono Itanium non appena possibile.

Solo HP continuò a produrre sistemi Itanium perché su di esso girava VMS ed erano quindi l'unica alternativa per chi doveva far girare software su VMS (HP aveva acquisito Compaq che a sue volta aveva acquisito quel che restava di DEC, quindi tutto il parco di clienti che usavano VMS).

Il contratto ferreo tra HP ed Intel garantiva la fornitura di Itanium per parecchi anni (usati da HP per fare con calma un ulteriore porting di VMS da Itanium ad x86-64).

Ovvio che Intel non era proprio contenta di produrre nuove generazioni di Itanium una volta chiaro il flop commerciale, ma nel caso di HP era obbligata a farlo, nel caso di altri invece poteva rifiutarsi di farlo.

Per quel che riguarda la toolchain, Itanium fu la dimostrazione pratica che demandare tutto il riordino delle istruzioni al compilatore non é proprio la strategia migliore per eseguire codice "generico", specialmente su un architettura con un sacco di feature che "sprecavano" il risparmio ottenuto eliminando la circuiteria di riordino microistruzioni.

Paradossalmente alla fine "ha vinto MIPS" nel senso che con le tecnologie attuali (ed i sorgenti attuali da conpilare) l'equilibrio ottimale nell'avere simultaneamente un compilatore che riordina le istruzioni e circuiteria di riordino nella pipeline consiste nell'avere un set di 32 registri per tipologia di dato (tipo 32 interi, 32 floating point, 32 vettoriali).

Con max. 32 registri per set di registri ci sono abbastanza registri affinché il programmatore o il compilatore facciano un riordino "ad alto livello" delle istruzioni (senza preoccuparsi di quante unità di esecuzione ci sono) mentre al tempo stesso la circuiteria di riordino può ulteriormente ottimizzare/riordinare le istruzioni/micro-op ragionando principalmente solo il termini di dipendenze tra registri ed unità di esecuzione.