[LMCH]

Originariamente inviato da cdimauro

Lo era perché avevano posto un grosso limite all'ISA, e l'hanno fatto soltanto per cercare di risparmiare transistor pur di non avere un registro dedicato per lo stato / flag. Fondere PC e flag è stata una scelta infelice sia per il limite della memoria indirizzabile sia per avere messo assieme due cose che dovrebbero stare in posti diversi.

Ricorda che ARM è nato come successore spirituale del 6502, per questo aveva così tante "stranezze" rispetto agli altri RISC.
Si voleva una cpu molto efficiente su hardware che non fosse troppo costoso, con una gestione degli interrupt molto rapida ecc. ecc.
da usare su un home computer non su dei server.
Per questo mentre gli altri RISC debuttavano sui server e poi tentavano la "discesa" negli altri settori, ARM nacque già ad un passo dal settore embedded.

Originariamente inviato da cdimauro

Non mi possono raccontare che fosse una buona scelta all'epoca, perché la tendenza dei 32-bit era già ben delineata, coi maggiori produttori di CPU che avevano sfornato o stavano per sfornare ISA pienamente a 32-bit.

In quel settore (home computer e poi dopo embedded) 26bit di indirizzamento erano uno spazio di memoria enorme
(e lo sono stati molto a lungo) e si pensava di usarlo su prodotti che non avrebbero richiesto grandi quantità di ram prevedibilmente molto più a lungo di quanto serviva sui server e simili.

Poi combinare program counter e status register in un unica word a 32bit eliminava 1 load ed 1 store ad ogni chiamata di funzione C ed assembly, non era una cosa da poco; faceva parte delle tante piccole migliorie che rendevano gli ARM così performanti.

Originariamente inviato da cdimauro

No, le due ISA, 26 e 32 bit, non sono compatibili. Lo sono largamente le istruzioni, ma c'è il nuovo registro di stato per quella a 32-bit (con apposite istruzioni) in tutte le modalità d'esecuzione (sono presenti le copie shadow). In generale non c'è compatibilità a livello di s.o. (perché la presenza del registro di stato fa gestire interrupt ed eccezioni diversamente) e applicativo (se le istruzioni manipolano direttamente i flag oppure il PC).

Le applicazioni andavano ricompilate, oppure riscritte nelle parti in assembly che manipolavano il PC (e relativi flag).

In ambito embedded (il mercato dominante quando ormai il problema andava affrontato) non era un gran problema, senza contare che per le parti in assembly di solito si usavano le macro per "incapsulare" le sequenze ripetute più di frequente (ad esempio, che si trattasse di x86, di mc68000 o altro io usavo sempre delle macro PROLOG ed EPILOG che dove necessario incapsulavano il grosso delle convenzioni di chiamata per interfacciarsi con questo o quel compilatore o questo o quel modello di memoria).
Il "problema" del passagio di codice "a 26bit" verso i 32bit non era così differente da quello che avveniva con gli x86 a 16 bit (modello "small" a 64KB di dati, "large" a segmenti con limite di 64KB per una singola struct o array e "huge" con segment+offset gestiti emulando un puntatore con indirizzamento lineare).

Originariamente inviato da cdimauro

Aspetta. Quello serve per semplificare l'esecuzione delle istruzioni Thumb, in modo da "darle in pasto" alla circuiteria già esistente per ARM32. Ma il decoder Thumb non è così semplice come quello ARM32, per cui hai di fatto più che duplicato l'esistente circuiteria, visto che devi decodificare un'ISA abbastanza diversa, e pure a lunghezza variabile.

Nelle architetture ARM32+THUMB si usa un unico decoder (con lo "stadio aggiuntivo" THUMB) perché quando si usano le istruzioni THUMB si vuole principalmente maggior compattezza del codice, mentre nelle architetture THUMB-only ( ARM M0 ed M1) si usa un decoder ancora più semplice
(perche lo si può ottimizzare ulteriormente).

Originariamente inviato da cdimauro

Che è stato rimosso da ARMv8. Anche questo faceva parte del retaggio del passato, dove esisteva il concetto di coprocessore esterno al chip. Ormai la tendenza è di avere tutto on-die, per cui ARM ha pensato giustamente di recuperare spazio negli opcode sfruttando quella parte per organizzare meglio la opcode table (32-bit sembrano tanti, ma finiscono molto presto).

Ma nulla da dire su questo. Infatti ARMv8 è votato alla maggior semplicità e velocità d'esecuzione. Non sembra nemmeno un ARM, dati i cambiamenti radicali, ma un MIPS o un Alpha...

Infatti e non è un caso.
La transizione verso i 64bit degli ARM sta avvenendo in un contesto totalmente diverso da quando Intel tentò il "suo" passaggio ai 64bit ... con gli Itanium ed ARM non si fa problemi a seguire la strada tracciata dagli Alpha (letteralmente nati per essere cpu a 64bit "tutte prestazioni ed efficienza").

Originariamente inviato da cdimauro

Quando Itanium è stato introdotto x86 aveva già messo alla corda i RISC più rinomati. Persino Apple, nel 2000, voleva dare il benservito ai PowerPC, ma fu convinta a rimanere da un manager di IBM con la promessa del futuro G5, che però ha soltanto tardato il passaggio a x86...

Non è stata questione di processo produttivo, ma di prestazioni.

Poi sei ci fossero anche accordi commerciali, questo non lo so, ma non cambia nulla dal punto di vista prestazionale.

Gli Alpha, ovvero cpu ormai letteralmente morte per accordi commerciali, con un ultimo shrink e qualche ritocco (Alpha EV7z) continuarono a spaccare il culo agli Itanium per molti anni pure nell'ambito in cui questi erano più forti e superiori alle cpu x86 del periodo.
Furono letteralmente uccisi dall'accordo tra HP ed Intel, non perche non riuscissero a reggere il confronto.

Mentre SGI fu pure costretta a prolungare di due generazioni lo sviluppo di cpu MIPS "da server/workstation" a causa dei problemi di prestazioni degli Itanium.