40 milioni di chip mobile Intel nel 2014? Un obiettivo forse non alla portata

[cdimauro]

Originariamente inviato da LMCH

Perchè quel che è avvenuto ha avuto conseguenze pesanti a lungo termine.

E ne ha ancora, ma non persarci sarebbe stato anche peggio.

Dipende da cosa si intende per competitivi e per pari livello.
Il vantaggio degli ARM è che i core "base" coprono un sacco di nicchie ed i vari produttori a loro volta propongono SoC per tutte le esigenze e fascie di prezzo.
Intel non riesce a fare altrettanto e non sembra in grado di farlo.

Nemmeno aziende come Qualcomm, ad esempio, sono interessate a coprire tutti i segmenti, e si rivolgono alla fascia medio-alta.

Nella fascia bassa è estremamente difficile competere coi cinesi. Per chiunque.

Intel ha dalla sua il vantaggio delle fabbriche, per cui rispetto agli altri produttori può sfruttare questo vantaggio, ma la sua storia dimostra che non le interessa correre per i centesimi.

Con ARM si può scegliere tra un sacco di core diversi in base alle proprie esigenze, tra un sacco di SoC con differenti caratteristiche e se necessario "si può far da se".
Con gli x86 non è possibile fare altrettanto e specialmente se si cerca di ridurre i consumi o la complessità circuitale, la "x86-tax" pesa eccome.

Hai mai provato a vedere su siti come Chip Architect la dimensione del core della CPU, e quella dell'unità di decodifica x86 (che è la principale imputata della x86-tax) e della sua FPU (molto, molto meno rispetto al decoder)?

Fallo e avrai un'idea quanto incida una CPU in un SoC, e quelle unità sulla CPU e, di conseguenza, sul SoC.

Io ho numeri molto precisi sia sulla dimensione dell'area impegnata sia sul consumo a runtime, ma non posso divulgarli. Un'idea, comunque, la si può fare lo stesso con quanto suggerito sopra.

Poi per quanto sia "piccola", la cpu rimane un elemento critico di tutto il SoC visto che l'esecuzione del software avviene principalmente li, quindi la sua efficienza ha ripercussioni su tutto il resto degli elementi del SoC.

Mi spiace, ma non è così. I numeri sono importanti, e continui a non volerne tenere conto.

Un core da un po' di decine di milioni di transistor su un SoC da un miliardo di transistor ha un peso molto basso sul totale. E un'unità di decodifica da un milione di transistor su un po' di decine di milioni ne ha un altro, tanto per fare un altro esempio. Facendo le debite proporzioni puoi comprendere da te l'incidenza della parte legacy dei core x86 sul totale di un SoC.

Se fai qualche ricerca magari riesci a ottenere dei numeri più precisi, ma il concetto che ho esposto è quello.

Per il software vale la regola che non serve ottimizzare tutto il codice per migliorare le prestazioni, ma giusto i punti caldi che vengono eseguiti più frequentemente e più a lungo.

Hai mai visto lo spettro termico di un SoC? Ecco, questo ti può fornire un'altra misura / prova di quello che ho scritto sopra.

Una regola analoga vale per i SoC e la "x86-tax" va a colpire uno dei punti caldi dei SoC con conseguenze più ampie e profonde di quanto appaia guardando solo al numero di gate o all'area del chip.

Vedi sopra. E aggiungo che siamo ormai molto lontani da quando la complessità di un core CISC aveva un enorme peso rispetto a un core RISC. Finché si parlava di centinaia di migliaia e milioni di transistor un confronto aveva senso. Ma da quando la parte del leone la fanno le cache e le unità SIMD, tutto si è notevolmente ridimensionato. A maggior ragione quando un core è immerso in un SoC di cui lui stesso è una piccola parte.

T'invito a documentarti in merito. Puoi anche chiedere informazioni sul newsgroup comp.arc, che è frequentato da parecchi esperi in materia.

[LMCH]

Originariamente inviato da cdimauro

Hai mai visto lo spettro termico di un SoC? Ecco, questo ti può fornire un'altra misura / prova di quello che ho scritto sopra.

Per punto caldo intendevo nel senso di utilizzo estensivo ed intensivo, non di calore sviluppato.
Come in un software intervenendo sulle sequenze di codice più frequentemente utilizzate si possono migliorare (o peggiorare) in modo notevole le prestazioni, altrettanto avviene a livello di architetture.
Puoi avere cache enormi, ma se il core che esegue il codice ha "un piccolo svantaggio" rispetto ad un altro core, a parità di dimensionamento di cache e del resto del SoC la cosa si nota.
Di solito eventuali svantaggi intrinseci nel core si possono compensare con bus più ampi/veloci, cache più ampie ecc. ma questa comporta pagare un altro prezzo su altre caratteristiche.

Altrimenti, se fosse vero che "la x86-tax non conta più", come mai Intel ha avuto così grandi difficoltà a contenere i costi ed consumi a livelli accettabili rispetto alla concorrenza che usava ARM ?
In teoria hanno il personale ed il know-how per produrre dispositivi fatti come si deve e l'unica differenza rilevante rispetto alla concorrenza ARM è guardacaso la cpu.

[cdimauro]

Originariamente inviato da LMCH

Per punto caldo intendevo nel senso di utilizzo estensivo ed intensivo, non di calore sviluppato.

OK, parlavi di hot spot.

Come in un software intervenendo sulle sequenze di codice più frequentemente utilizzate si possono migliorare (o peggiorare) in modo notevole le prestazioni, altrettanto avviene a livello di architetture.

Indubbiamente, ma quanto della "x86-tax" incide su tutto ciò?
Ho scritto una serie di articoli un paio d'anni fa sull'argomento, di cui trovi qui l'ultimo. Un'altra serie di articoli l'ho scritta circa un anno fa riguardo alle statistiche relative alle istruzioni eseguite, di cui trovi l'ultimo qui.

Con questo materiale puoi vedere in che modo incide l'aspetto legacy di x86 sia a livello di funzionamento interno sia per quanto riguarda il codice effettivamente eseguito. Per quest'ultimo è bene notare che la stragrandissima maggioranza di istruzioni eseguite NON sono roba vecchia & datata, ma istruzioni di gran lunga più semplici, che in genere sono mappate 1:1 con le cosiddette uop "RISC". Niente "legacy", insomma.

A ciò aggiungiamo il fatto che già da parecchi anni proprio negli hot spot viene attivato il cosiddetto Loop Stream Detector (LSD), che consente di disabilitare i decoder ed eseguire direttamente le uop da questa piccola cache interna, consentendo un notevole risparmio di energia (con Haswell mi pare che mediamente l'80% del tempo la CPU lavora coi decoder spenti grazie a questa tecnologia).

Il quadro adesso dovrebbe essere più chiaro e completo.

Puoi avere cache enormi, ma se il core che esegue il codice ha "un piccolo svantaggio" rispetto ad un altro core, a parità di dimensionamento di cache e del resto del SoC la cosa si nota.
Di solito eventuali svantaggi intrinseci nel core si possono compensare con bus più ampi/veloci, cache più ampie ecc. ma questa comporta pagare un altro prezzo su altre caratteristiche.

E viceversa, ci sono anche vantaggi dal fatto di avere istruzioni più complesse e a lunghezza variabile.

Questo significa, ad esempio, che il codice è più denso, quindi:
- meno spazio occupato
- tutta la gerarchia di memoria (cache L1/L2/L3, memoria) è meno stressata;
- più TLB hit e meno flush
Questo comporta un minor consumo per tutte queste componenti.

Altro esempio, con istruzioni più complesse è possibile eseguire meno istruzioni per implementare un particolare algoritmo. Anche qui vale quanto scritto sopra, a cui si aggiunge il risparmio di energia dovuto all'esecuzione di meno istruzioni.

Per cui è vero che l'aspetto legacy di x86 porta problemi, ma è anche vero che porta pure vantaggi, e non di poco conto, che incidono sulla bilancia energetica.

Altrimenti, se fosse vero che "la x86-tax non conta più",

Con questi numeri in gioco, è praticamente trascurabile. Anche questo l'avevo scritto in un altro articolo ancora più vecchio, di 5 anni fa, dove trovi le mie riflessioni in merito verso la metà del pezzo. Da notare che ho parlato anche della cessione della divisione XScale.

La situazione, come dicevo, è cambiata, e un core Atom non è più solo, ma si trova all'interno di SoC da miliardi di transistor...

come mai Intel ha avuto così grandi difficoltà a contenere i costi ed consumi a livelli accettabili rispetto alla concorrenza che usava ARM ?
In teoria hanno il personale ed il know-how per produrre dispositivi fatti come si deve e l'unica differenza rilevante rispetto alla concorrenza ARM è guardacaso la cpu.

Perché la CPU è soltanto un piccolo pezzo del SoC, come già detto. Intel non ha tutto il personale e know-how necessario in questo campo: infatti è anche per questo che non integra ancora alcun modem LTE, tanto per fare l'esempio più noto e di notevole importanza (anche per i consumi). Ovviamente ci sta lavorando, ma la concorrenza è in vantaggio, essendo partita molto prima.

Ci sono altri pezzi integrati in un SoC, su cui è possibile fare lo stesso ragionamento. Qualcomm è famosa per avere realizzato e integrato un DSP particolarmente efficiente a cui demandare parecchie delle operazioni relative ai modem e al multimedia.

Infine, un altro esempio lampante è dato dalle GPU. Come sai, quelle Intel non eccellono rispetto alle controparti, e penso che la situazione sia la stessa anche in ambito mobile: probabilmente non sono efficienti, sia a livello prestazionale sia di consumi, rispetto alla concorrenza.

Si tratta di una situazione non idilliaca, dunque, ma nemmeno così malvagia, a giudicare dai risultati raggiunti da qualche tempo. E la cosa interessante è che ci sono ampii margini di miglioramento per Intel...

Ricapitolando, se una CPU oggi occupa circa il 10% dell'area di un SoC, puoi facilmente immaginare perché il rimanente 90% sia così importante e quanto incida a livello di consumi.

Purtroppo, essendo i componenti del SoC totalmente diversi non solo a livello di CPU, non è possibile fare dei confronti diretti, e bisogna accontentarsi delle misure dell'intero SoC. Ma anche senza i dati a disposizione relativi ai singoli pezzi, puoi comunque farti un'idea del peso che ha oggi una CPU incastonata in un SoC da miliardi di transistor, e trarre da solo le tue conclusioni.

P.S. Al solito le mie sono soltanto opinioni personali: non riporto informazioni aziendali, ma soltanto ciò che in giro può trovare chiunque.

[LMCH]

Originariamente inviato da cdimauro

Indubbiamente, ma quanto della "x86-tax" incide su tutto ciò?
Ho scritto una serie di articoli un paio d'anni fa sull'argomento, di cui trovi qui l'ultimo. Un'altra serie di articoli l'ho scritta circa un anno fa riguardo alle statistiche relative alle istruzioni eseguite, di cui trovi l'ultimo qui.

Ti ricordi la prima versione della cpu SPARC che non aveva moltiplicatore/divisore implementato in hardware perche secondo i tipi di Sun "statistiche alla mano" erano istruzioni poco utilizzate e non influivano più di tanto sulle prestazioni ?
Ecco, la x86-tax è uguale, crea piccoli problemi che fanno pendere l'ago della bilancia verso altre direzioni nei settori in cui gli x86 non dominano già e la retrocompatibilità con software per x86 non è sufficientemente rilevante.

Originariamente inviato da cdimauro

Con questo materiale puoi vedere in che modo incide l'aspetto legacy di x86 sia a livello di funzionamento interno sia per quanto riguarda il codice effettivamente eseguito. Per quest'ultimo è bene notare che la stragrandissima maggioranza di istruzioni eseguite NON sono roba vecchia & datata, ma istruzioni di gran lunga più semplici, che in genere sono mappate 1:1 con le cosiddette uop "RISC". Niente "legacy", insomma.

A ciò aggiungiamo il fatto che già da parecchi anni proprio negli hot spot viene attivato il cosiddetto Loop Stream Detector (LSD), che consente di disabilitare i decoder ed eseguire direttamente le uop da questa piccola cache interna, consentendo un notevole risparmio di energia (con Haswell mi pare che mediamente l'80% del tempo la CPU lavora coi decoder spenti grazie a questa tecnologia).

Il quadro adesso dovrebbe essere più chiaro e completo.

Il problema è che ad esempio un risc senza loop stream detector può essere altrettanto efficiente nell'eseguire codice di un x86 con conseguenti benefici
nell'implementazione e nelle prestazioni.

Originariamente inviato da cdimauro

E viceversa, ci sono anche vantaggi dal fatto di avere istruzioni più complesse e a lunghezza variabile.

Questo significa, ad esempio, che il codice è più denso, quindi:
- meno spazio occupato
- tutta la gerarchia di memoria (cache L1/L2/L3, memoria) è meno stressata;
- più TLB hit e meno flush
Questo comporta un minor consumo per tutte queste componenti.

Solo che ora i compilatori ottimizzano in modo più efficiente e sopratutto il grosso del carico computazionale è legato al leggere e scrivere dati e non a caricare codice in cache.
Quindi tali vantaggi non sono più rilevanti come un tempo e per le applicazioni in cui lo sono gli ARM possono usare le estensioni THUMB che sono molto più efficienti su quel lato anche rispetto alle istruzioni x86.

Originariamente inviato da cdimauro

La situazione, come dicevo, è cambiata, e un core Atom non è più solo, ma si trova all'interno di SoC da miliardi di transistor...

Perché la CPU è soltanto un piccolo pezzo del SoC, come già detto. Intel non ha tutto il personale e know-how necessario in questo campo: infatti è anche per questo che non integra ancora alcun modem LTE, tanto per fare l'esempio più noto e di notevole importanza (anche per i consumi). Ovviamente ci sta lavorando, ma la concorrenza è in vantaggio, essendo partita molto prima.

Ci sono altri pezzi integrati in un SoC, su cui è possibile fare lo stesso ragionamento. Qualcomm è famosa per avere realizzato e integrato un DSP particolarmente efficiente a cui demandare parecchie delle operazioni relative ai modem e al multimedia.

Infine, un altro esempio lampante è dato dalle GPU. Come sai, quelle Intel non eccellono rispetto alle controparti, e penso che la situazione sia la stessa anche in ambito mobile: probabilmente non sono efficienti, sia a livello prestazionale sia di consumi, rispetto alla concorrenza.

Si tratta di una situazione non idilliaca, dunque, ma nemmeno così malvagia, a giudicare dai risultati raggiunti da qualche tempo. E la cosa interessante è che ci sono ampii margini di miglioramento per Intel...

Ricapitolando, se una CPU oggi occupa circa il 10% dell'area di un SoC, puoi facilmente immaginare perché il rimanente 90% sia così importante e quanto incida a livello di consumi.

Purtroppo, essendo i componenti del SoC totalmente diversi non solo a livello di CPU, non è possibile fare dei confronti diretti, e bisogna accontentarsi delle misure dell'intero SoC. Ma anche senza i dati a disposizione relativi ai singoli pezzi, puoi comunque farti un'idea del peso che ha oggi una CPU incastonata in un SoC da miliardi di transistor, e trarre da solo le tue conclusioni.

P.S. Al solito le mie sono soltanto opinioni personali: non riporto informazioni aziendali, ma soltanto ciò che in giro può trovare chiunque.

Il problema è che se si trattasse solo delle altre componenti del SoC, Intel dovrebbe vendere alla grande almeno nel settore dei tablet "non Windows 8", ma così non è.
Il grosso problema per Intel è la componente radio/modem, ma per tutto il resto (inclusa la GPU) non ha svantaggi significativi se non maggiori consumi legati al voler avere per forza maggiori prestazioni anche quando sarebbe il caso di pensare di più a ridurre i consumi.

[cdimauro]

Originariamente inviato da LMCH

Ti ricordi la prima versione della cpu SPARC che non aveva moltiplicatore/divisore implementato in hardware perche secondo i tipi di Sun "statistiche alla mano" erano istruzioni poco utilizzate e non influivano più di tanto sulle prestazioni ?
Ecco, la x86-tax è uguale, crea piccoli problemi che fanno pendere l'ago della bilancia verso altre direzioni nei settori in cui gli x86 non dominano già e la retrocompatibilità con software per x86 non è sufficientemente rilevante.

Ma qui parlavamo di consumi. Se quelle vecchie istruzioni non le esegui, non incidono sulla bilancia energetica. Disassembla pure qualunque applicazioni, e te ne renderai conto da solo.

Il fatto che citi riguardo Sun è corretto, ma oggi i processori, anche RISC, includono CENTINAIA di istruzioni perché tendono a coprire particolari casi che però sono molto importanti. Vedi, ad esempio, il supporto al CRC32, all'AES, e allo SHA, che di recente è stato aggiunto su praticamente tutti i processori.

Ma questo non c'entra nulla con le vecchie istruzioni legacy x86. Dimmi, secondo te, che utilità può avere una AAD, ad esempio? Infatti vorrei vedere il compilatore che riesce a riconoscere il contesto e a emetterla correttamente.

Poi che siano presenti in vecchissimo codice e, dunque, eseguite, nulla da dire. Ma chi esegue quel codice? Rispetto alle centinaia e centinaia di milioni di PC che eseguono codice, sarà una sparuta minoranza di aziende che eseguono applicazioni DOS-based (magari "portate" su Windows con la classica... CUI).

Viceversa, disassembla qualunque gioco o applicazione da un bel po' di anni a questa parte, e vedrai che i loro compilatori, come pure eventuali parti in assembly, non abbiano fatto uso di quelle istruzioni.

Il problema è che ad esempio un risc senza loop stream detector può essere altrettanto efficiente nell'eseguire codice di un x86 con conseguenti benefici nell'implementazione e nelle prestazioni.

I RISC generalmente non hanno il problema di tradurre le istruzioni, ma alcuni lo fanno. Vedi i PowerPC e gli ARM che hanno istruzioni molto complesse, come quelle di Load/Store multiple sui registri, e qui, se non erro, ricorrono pure loro al microcodice (bloccando la pipeline). Si tratta di istruzioni utili (Motorola 68K docet: una goduria da usare), ma che... ti complicano la vita se devi implementarle ed eseguirle. Non è un caso che ARM abbia buttato un po' di roba legacy con la nuova architettura a 64 bit, incluse queste istruzioni ovviamente, avvicinandosi ad architetture come MIPS o Alpha. Ma in ogni caso se le porta sul groppone perché rimane compatibile con la "vecchia" architettura a 64-bit.

Riguardo all'efficienza dei RISC, immagino riguardi l'implementazione / facilità di esecuzione (a parte le eccezioni di cui sopra) e i relativi consumi. Quindi non a livello prestazionale (qui l'ISA incide, come già detto).

Solo che ora i compilatori ottimizzano in modo più efficiente e sopratutto il grosso del carico computazionale è legato al leggere e scrivere dati e non a caricare codice in cache.

Permettimi: i compilatori non posso superare i limiti dell'ISA, ma devono per forza conviverci. Se, ad esempio, hai da caricare un costante "grande" a 32-bit, puoi piangere in aramaico: o la costruisci con una serie di MOV con dati immediati più piccoli + shift + ADD / OR (oppure ricorrerendo ad approsite istruzioni di MOV che coinvolgono la parte alta del registro, per le ISA che ce l'hanno), oppure la carichi direttamente dalla memoria (e qui devi scomodare una ben più costosa LOAD dalla memoria, con tutto ciò che comporta).
Per cui, ricapitolando: se prediligi le prestazioni ricorri a una serie di istruzioni ma espandi il codice (e stressi molto la cache codice & relativa banda di memoria). Se, invece, prediligi lo spazio, ricorri alla load e stressi la cache dati (e il memory controller). Ovviamente quest'ultimo caso vale solo se risulta semplice raggiungere la costante in memoria usando il piccolo offset che una LOAD mette a disposizione, altrimenti è facile che ti convenga la prima soluzione.

Questo esposto è un caso molto comune in ambito RISC (e in generale di programmazione, ma i CISC hanno, in genere, la possibilità di specificare direttamente un valore immediato, anche lungo, per cui non si pongono tutti questi problemi), e coi quali i compilatori possono combattere quanto vogliono, ma le problematiche rimangono.

Quindi tali vantaggi non sono più rilevanti come un tempo e per le applicazioni in cui lo sono gli ARM possono usare le estensioni THUMB che sono molto più efficienti su quel lato anche rispetto alle istruzioni x86.

Indubbiamente con THUMB la densità di codice degli ARM è nettamente migliorata (e compete con x86), ma... a che prezzo? THUMB è un'ISA CISC, a lunghezza variabile, per cui il decoder si complica, e viene introdotto un ulteriore stadio nella pipeline per la "decompressione" dell'istruzione nell'equivalente ARM.

Dulcis in fundo, funziona soltanto a 32-bit: non ne è stata presentata una versione a 64-bit, ed è difficile che accada (perché si perderebbero i vantaggi dei 32 registri introdotti), anche se non impossibile (leggi: con molti più compromessi rispetto alla versione a 32-bit).

Ma a parte questo, rimangono i problemi tipici dei RISC di cui ho discusso prima.

Il problema è che se si trattasse solo delle altre componenti del SoC, Intel dovrebbe vendere alla grande almeno nel settore dei tablet "non Windows 8", ma così non è.

Qui penso che il problema sia dovuto ai ritardi e a una strategia commerciale coi partner che non è stata azzeccata.

Il grosso problema per Intel è la componente radio/modem, ma per tutto il resto (inclusa la GPU) non ha svantaggi significativi se non maggiori consumi legati al voler avere per forza maggiori prestazioni anche quando sarebbe il caso di pensare di più a ridurre i consumi.

Appunto. Il problema è nei consumi, ma di tutto il resto del SoC. Ci vorrà tempo per aggiustare pure quelli (lato CPU ritengo che abbiano fatto un ottimo lavoro, e comunque la CPU incide poco sul totale, come già detto). Inoltre la GPU non brilla certo per le prestazioni. E per il modem, l'hai già detto tu...

[LMCH]

Originariamente inviato da cdimauro

Ma qui parlavamo di consumi. Se quelle vecchie istruzioni non le esegui, non incidono sulla bilancia energetica. Disassembla pure qualunque applicazioni, e te ne renderai conto da solo.

Incidono comunque nell'efficienza del decoder, costringendo a ricorrere a soluzioni circuitali più complesse che hanno conseguenze sulla frequenza massima raggiungibile, latenze, ecc.

Originariamente inviato da cdimauro

Il fatto che citi riguardo Sun è corretto, ma oggi i processori, anche RISC, includono CENTINAIA di istruzioni perché tendono a coprire particolari casi che però sono molto importanti. Vedi, ad esempio, il supporto al CRC32, all'AES, e allo SHA, che di recente è stato aggiunto su praticamente tutti i processori.

Ma questo non c'entra nulla con le vecchie istruzioni legacy x86. Dimmi, secondo te, che utilità può avere una AAD, ad esempio? Infatti vorrei vedere il compilatore che riesce a riconoscere il contesto e a emetterla correttamente.

Il mio punto era che avevano sottostimato gli effetti negativi di decisioni progettuali che sulla carta sembravano non essere sufficientemente rilevanti.

Originariamente inviato da cdimauro

Poi che siano presenti in vecchissimo codice e, dunque, eseguite, nulla da dire. Ma chi esegue quel codice? Rispetto alle centinaia e centinaia di milioni di PC che eseguono codice, sarà una sparuta minoranza di aziende che eseguono applicazioni DOS-based (magari "portate" su Windows con la classica... CUI).

Viceversa, disassembla qualunque gioco o applicazione da un bel po' di anni a questa parte, e vedrai che i loro compilatori, come pure eventuali parti in assembly, non abbiano fatto uso di quelle istruzioni.

Ma a causa della loro presenza il set d'istruzioni presenta molti più casi speciali da gestire ad hoc (tipo dove usare prefissi quando si usano certi registri o certe modalità di indirizzamento, ecc. ecc.), mentre sui RISC le estensioni di solito vengono fatte ad un set d'istruzioni che spesso "nasce" per essere decodificato in modo efficiente e lo stesso vale per le estensioni.

Originariamente inviato da cdimauro

I RISC generalmente non hanno il problema di tradurre le istruzioni, ma alcuni lo fanno. Vedi i PowerPC e gli ARM che hanno istruzioni molto complesse, come quelle di Load/Store multiple sui registri, e qui, se non erro, ricorrono pure loro al microcodice (bloccando la pipeline). Si tratta di istruzioni utili (Motorola 68K docet: una goduria da usare), ma che... ti complicano la vita se devi implementarle ed eseguirle. Non è un caso che ARM abbia buttato un po' di roba legacy con la nuova architettura a 64 bit, incluse queste istruzioni ovviamente, avvicinandosi ad architetture come MIPS o Alpha. Ma in ogni caso se le porta sul groppone perché rimane compatibile con la "vecchia" architettura a 64-bit.

Ma trattandosi di set d'istruzioni molto più regolari e simmetrici (nel senso di pochi casi particolari nello schema di decodifica) il costo della retrocompatibilità è di gran lunga inferiore.
Infatti per esempio a parità di processo produttivo un core Cortex A53 (64bit armv8) occupa il 40% in meno di un core Cortex A9 (32bit armv7) ed in modalità a 64bit ha le stesse prestazioni in termini di capacità di elaborazione.
L'A53 non ha le ottimizzazioni circuitali dell'A9 ma in modalità a 64bit se la gioca alla pari in termini di potenza i calcolo (suppongo nel senso di quando si elaborano dati in unita da 64bit).
Insomma anche con l'aumento di complessità dovuto ai 64bit ed al supporto della modalità a 32bit si sono potuti permettere di togliere roba ed avere qualcosa di più "leggero" in termini di implementazione.


[quote=cdimauro;41386945] Permettimi: i compilatori non posso superare i limiti dell'ISA, ma devono per forza conviverci. Se, ad esempio, hai da caricare un costante "grande" a 32-bit, puoi piangere in aramaico: o la costruisci con una serie di MOV con dati immediati più piccoli + shift + ADD / OR (oppure ricorrerendo ad approsite istruzioni di MOV che coinvolgono la parte alta del registro, per le ISA che ce l'hanno), oppure la carichi direttamente dalla memoria (e qui devi scomodare una ben più costosa LOAD dalla memoria, con tutto ciò che comporta).
Per cui, ricapitolando: se prediligi le prestazioni ricorri a una serie di istruzioni ma espandi il codice (e stressi molto la cache codice & relativa banda di memoria). Se, invece, prediligi lo spazio, ricorri alla load e stressi la cache dati (e il memory controller). Ovviamente quest'ultimo caso vale solo se risulta semplice raggiungere la costante in memoria usando il piccolo offset che una LOAD mette a disposizione, altrimenti è facile che ti convenga la prima soluzione.

Questo esposto è un caso molto comune in ambito RISC (e in generale di programmazione, ma i CISC hanno, in genere, la possibilità di specificare direttamente un valore immediato, anche lungo, per cui non si pongono tutti questi problemi), e coi quali i compilatori possono combattere quanto vogliono, ma le problematiche rimangono.

Originariamente inviato da cdimauro

Indubbiamente con THUMB la densità di codice degli ARM è nettamente migliorata (e compete con x86), ma... a che prezzo? THUMB è un'ISA CISC, a lunghezza variabile, per cui il decoder si complica, e viene introdotto un ulteriore stadio nella pipeline per la "decompressione" dell'istruzione nell'equivalente ARM.

La decodifica da istruzioni THUMB ad istruzioni ARM è 1:1 quindi il "decoder thumb" è un singolo stadio con espansione "a schema fisso" degli opcode THUMB in opcode ARM "classici" (ed eventualmente bypass della word successiva se contiene un valore costante).
Quando si eseguono istruzioni ARM quello stadio viene semplicemente bypassato.
Insomma, il supporto di THUMB non pesa sulla decodifica ed esecuzione delle istruzioni ARM a 32bit e quando viene attivato l'incremento di densità delle istruzioni compensa ampiamente gli svantaggi ... presenti solo in modalità THUMB.

Originariamente inviato da cdimauro

Dulcis in fundo, funziona soltanto a 32-bit: non ne è stata presentata una versione a 64-bit, ed è difficile che accada (perché si perderebbero i vantaggi dei 32 registri introdotti), anche se non impossibile (leggi: con molti più compromessi rispetto alla versione a 32-bit).

Questo perche se si sta usando una cpu a 64bit significa che si dispone di molta ram e bus dati molto ampi, senza contare che usando le istruzioni a 64bit si ha nel caso peggiore circa la stessa densità di codice che si avrebbe usando codice ARM a 32bit senza THUMB.
Se poi consideri che THUMB è stato introdotto essenzialmente per dare il compo di grazia alla concorrenza che per roba embedded proponeva cpu a 16bit o anche ad 8bit ...

Poi sarebbe il caso di ricordare che il vantaggio di compattezza del codice "asimmetrico ed irregolare" degli x86 non è stato decisivo nei confronto degli altri RISC ... ma nei confronti degli Itanium.

[cdimauro]

Originariamente inviato da LMCH

Incidono comunque nell'efficienza del decoder, costringendo a ricorrere a soluzioni circuitali più complesse che hanno conseguenze sulla frequenza massima raggiungibile, latenze, ecc.

Certamente, e sappiamo che i decoder x86/x64 sono nettamente più complessi rispetto a quelli dei RISC. Su questo non ci piove.

Il mio punto era che avevano sottostimato gli effetti negativi di decisioni progettuali che sulla carta sembravano non essere sufficientemente rilevanti.

Purtroppo errori del genere li può fare chiunque. Ad esempio le prime versioni degli ARM potevano indirizzare al massimo 64MB di memoria (26 bit d'indirizzamento), e se pensi che sono usciti nel 1985, direi che è stata una decisione folle. Rimanendo su x86, nessuno dei progettisti dell'8086 poteva pensare a dove sarebbe arrivata quest'architettura, e quali problemi avrebbero creato certe scelte che, però, all'epoca erano assolutamente sensate e molto vantaggiose.

Ma a causa della loro presenza il set d'istruzioni presenta molti più casi speciali da gestire ad hoc (tipo dove usare prefissi quando si usano certi registri o certe modalità di indirizzamento, ecc. ecc.), mentre sui RISC le estensioni di solito vengono fatte ad un set d'istruzioni che spesso "nasce" per essere decodificato in modo efficiente e lo stesso vale per le estensioni.

Tranne per i RISC che... diventano CISC introducendo ISA con opcode a lunghezza variabile, o che magari fanno uso di prefissi. Il problema è sempre lo stesso: le esigenze cambiano col tempo, e bisogna mettere delle pezze a quanto già realizzato.

A parte questo, la realtà di x86 (e x64) è che la stragrande maggioranza delle istruzioni si mappa 1:1 con le uop, perché... si tratta di istruzioni semplici. Dunque non serve un decoder enormemente complesso per gestire il caso peggiore, con istruzioni molto lunghe (che sono una rarità) o che fanno uso di tanti prefissi (al più se ne usa uno, e questo avviene o per indirizzare memoria locale del thread, oppure quella del s.o., oppure per mappare le istruzioni SIMD). Difatti già da parecchi anni esiste UN solo decoder complesso per gestire tutti i casi possibili, che è affiancato da 2 o 3 (nei processori degli ultimi anni) decoder molto più semplici (ed efficienti / parchi di energia & transistor) che si smazzano le istruzioni molto più comunemente usate.

Ecco qui un link a un articolo interessante in merito, di cui riporto alcune parti significative:

"In a typical x86 program, more than 2/3 of the instructions are simple enough to be represented by a single (non-fused) micro-op. Most of the other 1/3 can be decoded into 4 micro-ops or less, with a (very) few taking more to execute. Recognizing these facts, especially the 2:1 simple-to-complex ratio, the P6 design divides its decoders into the well-known 4-1-1 structure, giving only one decoder full capability:
[...]
By differentiating the decoders and put performance emphasis on the common simple-instruction cases, instruction decode and issue complexity can be minimized, and higher clock rate can be reached. RISC design rule #1: Make the common-case fast."

Mi sembra sia abbastanza eloquente.

Per informazioni più dettagliate sui decoder delle varie micro-architetture, c'è il solito Agner Fog e il suo omnio manuale.

Ma trattandosi di set d'istruzioni molto più regolari e simmetrici (nel senso di pochi casi particolari nello schema di decodifica) il costo della retrocompatibilità è di gran lunga inferiore.

Certamente, ma ARM si trascina ARM32, Thumb-2, Thumb-EE, e adesso ARM64, che sono abbastanza diverse (solo le due Thumb sono molto simili), quindi servono decoder ad hoc per ognuna, e questo ha certo costo, soprattutto per Thumb.

Infatti per esempio a parità di processo produttivo un core Cortex A53 (64bit armv8) occupa il 40% in meno di un core Cortex A9 (32bit armv7) ed in modalità a 64bit ha le stesse prestazioni in termini di capacità di elaborazione.
L'A53 non ha le ottimizzazioni circuitali dell'A9 ma in modalità a 64bit se la gioca alla pari in termini di potenza i calcolo (suppongo nel senso di quando si elaborano dati in unita da 64bit).

Le prestazioni per ARMv8 sono migliori perché sono stati raddoppiati i registri general purpose e quelli di FPU/SIMD, portandoli da 16 a 32 (30, in realtà; mi pare che 2 siano riservati per particolari scopi).

Insomma anche con l'aumento di complessità dovuto ai 64bit ed al supporto della modalità a 32bit si sono potuti permettere di togliere roba ed avere qualcosa di più "leggero" in termini di implementazione.

La roba "pesante" l'hanno tolta soltanto dall'ISA a 64-bit, ma rimane nelle altre ISA, dove continua ad avere il suo peso.

Ha senso parlare di zavorra eliminata soltanto per processori che implementino esclusivamente ARMv8 come architettura.

La decodifica da istruzioni THUMB ad istruzioni ARM è 1:1 quindi il "decoder thumb" è un singolo stadio con espansione "a schema fisso" degli opcode THUMB in opcode ARM "classici" (ed eventualmente bypass della word successiva se contiene un valore costante).
Quando si eseguono istruzioni ARM quello stadio viene semplicemente bypassato.

Sì, lo so, ma questo stadio in più incide sulle prestazioni di Thumb.

Insomma, il supporto di THUMB non pesa sulla decodifica ed esecuzione delle istruzioni ARM a 32bit e quando viene attivato l'incremento di densità delle istruzioni compensa ampiamente gli svantaggi ... presenti solo in modalità THUMB.

Per la densità nulla da dire. Ma Thumb rimane una macchina LOAD/STORE, per cui si porta dietro gli stessi problemi dell'architettura ARM32 di cui ho parlato prima... allungati di uno stadio.

Questo perche se si sta usando una cpu a 64bit significa che si dispone di molta ram e bus dati molto ampi,

Vada per la RAM, che è in continuo aumento, ma non per la dimensione del bus, che può rimanere la stessa. Anzi, vedere bus dati ampii su architetture mobile è difficile a prescindere, per ovvi motivi (di spazio & layout & consumi).

senza contare che usando le istruzioni a 64bit si ha nel caso peggiore circa la stessa densità di codice che si avrebbe usando codice ARM a 32bit senza THUMB.

Assolutamente no. Dipende dal codice, ovviamente, ma a naso direi che mediamente il codice dovrebbe essere meno denso. Ricorda che da ARMv8 sono state rimosse istruzioni, sì, pesanti, ma anche molto utili e che incidono non poco sulla densità di codice.

Non ho dati in merito, e mi piacerebbe vederne qualcuno, ma per quello che ho visto delle due ISA la mia esperienza mi porta a dedurre che sia così.

Se poi consideri che THUMB è stato introdotto essenzialmente per dare il compo di grazia alla concorrenza che per roba embedded proponeva cpu a 16bit o anche ad 8bit ...

E' un problema che hanno avuto anche altre ISA. Anche MIPS, se non ricordo male, ha una sua versione "compatta" con opcode a 16-bit. Forse anche SPARC ha qualcosa di simile, ma in generale è un trend ben noto per i processori RISC.

Checché se ne dica, la densità di codice rimane molto importante a prescindere, perché non impatta soltanto sullo spazio occupato, ma anche sulla banda di memoria e sulle cache TLB.

Ecco perché tanti produttori di RISC alla fine sono stati costretti a calare le corna, e adottare un'ISA a lunghezza variabile (e, dunque, CISC; questo era uno dei punti fermi e distintivi fra le due macro-famiglie).

Poi sarebbe il caso di ricordare che il vantaggio di compattezza del codice "asimmetrico ed irregolare" degli x86 non è stato decisivo nei confronto degli altri RISC ... ma nei confronti degli Itanium.

Ma anche no: Itanium è stata una vittima illustre, in quanto si tratta di un'architettura "di famiglia", ma x86 aveva già fatto fuori tanti altri RISC.

[LMCH]

Originariamente inviato da cdimauro

Certamente, e sappiamo che i decoder x86/x64 sono nettamente più complessi rispetto a quelli dei RISC. Su questo non ci piove.

Purtroppo errori del genere li può fare chiunque. Ad esempio le prime versioni degli ARM potevano indirizzare al massimo 64MB di memoria (26 bit d'indirizzamento), e se pensi che sono usciti nel 1985, direi che è stata una decisione folle. Rimanendo su x86, nessuno dei progettisti dell'8086 poteva pensare a dove sarebbe arrivata quest'architettura, e quali problemi avrebbero creato certe scelte che, però, all'epoca erano assolutamente sensate e molto vantaggiose.

Considerando che nel 1995 (10 anni dopo) il grosso dei pc era tanto se avevano 16MB non è stata una scelta così insensata e la cosa fu risolta mantendo la retrocompatibilità a livello di set d'istruzioni senza dover introdurre modalità totalmente diverse.

Originariamente inviato da cdimauro

Tranne per i RISC che... diventano CISC introducendo ISA con opcode a lunghezza variabile, o che magari fanno uso di prefissi. Il problema è sempre lo stesso: le esigenze cambiano col tempo, e bisogna mettere delle pezze a quanto già realizzato.

RISC o CISC sono più modelli generici di riferimento che delle religioni.

Non a caso gli ARM erano i "meno RISC" tra le cpu uscite negli anni '80 e '90
(quasi tutte le istruzioni erano condizionali con cose tipo addizioni a tre operanti e barrel shifter bidirezionale sul terzo operando).

Ad esempio, il seguente statement in C:
a = b + (c << 2);
Corrisponde ad un singola istruzione ARM se a,b e c sono già caricati in registri:
ADD Ra, Rb, Rc, LSL #2

Ma anche le altre cpu RISC avevano le loro particolarità (i set di registri "a finestre" degli SPARC, l'execution slot dopo i jump dei MIPS, ecc.).

Originariamente inviato da cdimauro

A parte questo, la realtà di x86 (e x64) è che la stragrande maggioranza delle istruzioni si mappa 1:1 con le uop, perché... si tratta di istruzioni semplici. Dunque non serve un decoder enormemente complesso per gestire il caso peggiore, con istruzioni molto lunghe (che sono una rarità) o che fanno uso di tanti prefissi (al più se ne usa uno, e questo avviene o per indirizzare memoria locale del thread, oppure quella del s.o., oppure per mappare le istruzioni SIMD). Difatti già da parecchi anni esiste UN solo decoder complesso per gestire tutti i casi possibili, che è affiancato da 2 o 3 (nei processori degli ultimi anni) decoder molto più semplici (ed efficienti / parchi di energia & transistor) che si smazzano le istruzioni molto più comunemente usate.

A voler essere pignoli ci sono decoder "semplici" ed il decoder "complesso" da un lato, mentre dall'altro si hanno decoder "molto più semplici" e basta.

Originariamente inviato da cdimauro

Certamente, ma ARM si trascina ARM32, Thumb-2, Thumb-EE, e adesso ARM64, che sono abbastanza diverse (solo le due Thumb sono molto simili), quindi servono decoder ad hoc per ognuna, e questo ha certo costo, soprattutto per Thumb.

Ma tutti i vari decoder sono a livello di quelli "semplici" x86 se non più semplici.
Nel caso dei Thumb si possono pure implementare come "uno stadio in più" su un decoder ARM32 con costi ridottissimi in termini di implementazione rispetto ad un decoder "completo".
Senza contare lo schema di estensioni basato sui coprocessori.

Originariamente inviato da cdimauro

Le prestazioni per ARMv8 sono migliori perché sono stati raddoppiati i registri general purpose e quelli di FPU/SIMD, portandoli da 16 a 32 (30, in realtà; mi pare che 2 siano riservati per particolari scopi).

La roba "pesante" l'hanno tolta soltanto dall'ISA a 64-bit, ma rimane nelle altre ISA, dove continua ad avere il suo peso.

Ma proprio per la "leggerezza" e semplicità dello schema di decodifica
per ARM è stato possibile realizzare il Cortex A53 (la versione "economica" ed a basso consumo della prima generazione ARMv8) in modo da renderlo competitivo a parità di tecnologia di implementazione con un Cortex A9 sia in termini di prestazioni che di area su chip.

Originariamente inviato da cdimauro

Ma anche no: Itanium è stata una vittima illustre, in quanto si tratta di un'architettura "di famiglia", ma x86 aveva già fatto fuori tanti altri RISC.

Il vantaggio del "set d'istruzioni più compatto" degli x86 è stato davvero rilevante solo nei confronti dell'Itanium.

I RISC furono davvero battuti a livello di prestazioni per quel che riguarda desktop e server solo quando Intel cominciò a produrre cpu con 1..2 step di scala d'integrazione di vantaggio sulla concorrenza RISC.
Mentre per tutto il resto del tempo fu la retrocompatibilità con il software x86 già in circolazione a fare la fortuna di Intel.
Senza contare che a far fuori definitivamente MIPS ed Alpha nel settore server furono gli accordi commerciali in vista dell' "inevitabile" successo degli Itanium.

[cdimauro]

Originariamente inviato da LMCH

Considerando che nel 1995 (10 anni dopo) il grosso dei pc era tanto se avevano 16MB non è stata una scelta così insensata

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.

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.

e la cosa fu risolta mantendo la retrocompatibilità a livello di set d'istruzioni senza dover introdurre modalità totalmente diverse.

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).

RISC o CISC sono più modelli generici di riferimento che delle religioni.

Non a caso gli ARM erano i "meno RISC" tra le cpu uscite negli anni '80 e '90
(quasi tutte le istruzioni erano condizionali con cose tipo addizioni a tre operanti e barrel shifter bidirezionale sul terzo operando).

Ad esempio, il seguente statement in C:
a = b + (c << 2);
Corrisponde ad un singola istruzione ARM se a,b e c sono già caricati in registri:
ADD Ra, Rb, Rc, LSL #2

Ma anche le altre cpu RISC avevano le loro particolarità (i set di registri "a finestre" degli SPARC, l'execution slot dopo i jump dei MIPS, ecc.).

Sì, lo so, e aggiungiamo pure che il set d'istruzioni già da anni non è più così ridotto, ma qualunque ISA RISC conta centinaia di istruzioni. E alcuni adottano pure microcodice (che prima era di dominio esclusivo dei CISC e visto come fumo negli occhi dai progettisti RISC).

Ma almeno un paio di punti per discernere se un'ISA è RISC o CISC dovrebbero essere rimasti: esclusivo modello load/store per l'accesso alla memoria e opcode a lunghezza fissa, mentre viceversa possibilità per (la maggior parte del)le istruzioni di accedere direttamente alla memoria e opcode a lunghezza variabile.

Il tutto IMO, ovviamente, ma qualcosa serve per distinguere le due famiglie, altrimenti parliamo soltanto di processori e ISA senza tenere conto di queste due etichette.

A voler essere pignoli ci sono decoder "semplici" ed il decoder "complesso" da un lato, mentre dall'altro si hanno decoder "molto più semplici" e basta.

Mi sembra che su questo siamo d'accordissimo, e l'avevo pure scritto. Ma andava chiarito cosa succede realmente a runtime / "real life", perché incide anche nei consumi di cui abbiamo parlato. Un decoder più semplice occupa molti meno transistor e consuma molto meno rispetto a quello più complicato che gestisce qualunque caso.

Ma tutti i vari decoder sono a livello di quelli "semplici" x86 se non più semplici.
Nel caso dei Thumb si possono pure implementare come "uno stadio in più" su un decoder ARM32 con costi ridottissimi in termini di implementazione rispetto ad un decoder "completo".

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.

Senza contare lo schema di estensioni basato sui coprocessori.

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 proprio per la "leggerezza" e semplicità dello schema di decodifica
per ARM è stato possibile realizzare il Cortex A53 (la versione "economica" ed a basso consumo della prima generazione ARMv8) in modo da renderlo competitivo a parità di tecnologia di implementazione con un Cortex A9 sia in termini di prestazioni che di area su chip.

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...

Il vantaggio del "set d'istruzioni più compatto" degli x86 è stato davvero rilevante solo nei confronti dell'Itanium.

I RISC furono davvero battuti a livello di prestazioni per quel che riguarda desktop e server solo quando Intel cominciò a produrre cpu con 1..2 step di scala d'integrazione di vantaggio sulla concorrenza RISC.
Mentre per tutto il resto del tempo fu la retrocompatibilità con il software x86 già in circolazione a fare la fortuna di Intel.
Senza contare che a far fuori definitivamente MIPS ed Alpha nel settore server furono gli accordi commerciali in vista dell' "inevitabile" successo degli Itanium.

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.

[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.

[cdimauro]

Originariamente inviato da LMCH

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.

Ricordo molto bene la storia di ARM/Acorn, e l'obiettivo era competere coi personal computer. ARM si riciclerà nell'embedded molto dopo, non avendo trovato spazio nel mercato dei PC (l'Acorn Archimedes ebbe un buon successo in Gran Bretagna, ma non riuscì a sfondare a livello globale).

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.

Persino il Motorola 68012, che non era certo pensato per server (non aveva MMU), aveva 31 bit di spazio d'indirizzamento e poteva indirizzare 2GB di memoria (8GB suddividendo lo spazio d'indirizzamento in supervisor / utente e in codice / dati).
Nell'84 Intel presentò l'80386, che rese disponibile nell'85. L'80386 consentiva 46 bit d'indirizzamento virtuale e 32 bit d'indirizzamento per la memoria fisica.
Lo stesso anno Motorola presentò e commercializzò il 68020, che era dotato di bus esterno a 32-bit, e si poteva indirizzare fino a 4GB di memoria (o 16GB; vedi sopra per il 68012).
Nell'84 era arrivato il Macintosh che montava un 68000, il quale poteva già indirizzare 16MB e fino a 64MB (idem come sopra per il 68012), ma queste limitazioni erano esclusivamente dovute alla dimensione del bus esterno: internamente l'architettura era 32-bit era lo spazio d'indirizzamento era 32-bit. Era Motorola che, per meglio differenziare il suo catalogo e i target di mercato, offriva processori con bus esterni (indirizzo e/o dati) castrati (vedi anche 68008: bus indirizzi a 20 e dati a 8, ma i registri dati e indirizzi erano sempre a 32-bit, come per tutta la famiglia di processori 68K fin dal day 1).
Nell'85 arrivano Atari ST prima e Amiga dopo, che montavano entrambi il 68000.
Il primo modello di ARM fu presentato nell'85 (quindi un anno dopo la presentazione del 386 e dello 020, e di cui Acorn era sicuramente a conoscenza), ma il primo prodotto arrivò soltanto l'anno dopo. Il primo Archimedes arrivò soltanto nell'87, per competere finalmente nel mercato dei personal computer.

Con ciò voglio dire che Acorn, a mio avviso, sbagliò completamente il design dell'architettura ARM, con quel limite invalicabile dei 26 bit di spazio d'indirizzamento. Il trend dell'industry era ben noto e consolidato, come ho mostrato. Il fatto che all'epoca non esistessero personal computer con 64MB o più di memoria fisica non vuol dire che non si potessero realizzare: era estremamente costoso farlo, senz'altro, e aveva poco senso all'epoca. Ma non c'era alcun limite fisico in ciò, che invece era presente negli ARM.
E stiamo parlando della sola memoria fisica, ma più di 64MB di memoria virtuale avevano perfettamente senso già all'epoca.

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.

Nelle chiamate a funzioni non serve assolutamente conservare anche i flag. Serve soltanto conservare l'indirizzo dell'istruzione successiva alla chiamata.

In ambito embedded (il mercato dominante quando ormai il problema andava affrontato) non era un gran problema,

ARM passò alla versione full 32-bit soltanto 7 anni dopo la presentazione del primo ARM, nel'92, ma nel settore embedded non c'era alcun motivo per estendere lo spazio d'indirizzamento a 32-bit: 26-bit erano perfettamente sufficienti.

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).

Io ho programmato abbondantemente entrambi i processori, ma quasi mai ho avuto bisogno di macro di prologo o epilogo nelle routine che scrivevo. Raramente ho avuto bisogno di più registri di quelli a disposizione e, dunque, di mettere qualche parametro o variabile locale sullo stack (dunque di creare uno stack-frame). Anche perché le istruzioni ENTER/LEAVE e LINK/UNLINK erano decisamente pesanti, per cui in genere evitavo (o, al limite, ricorrevo a qualche "push" / "pop"). In ogni caso si trattava di singole scelte che facevo direttamente, senza ricorrere a macro.

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).

No, sono due cose completamente diverse. I modelli "huge" e "small" per 8086 e 80286 prevedevano l'uso o meno di segmenti/selettori per indirizzare la memoria, e dunque i puntatori erano a 16 o 32-bit (16 bit per segmento/selettore e 16 bit per offset). Con l'80386 si aggiunse il modello a 48-bit (16 + 32-bit), che però ebbe poca diffusione (la dimensione del puntatore è decisamente strana, non essendo una potenza del 2).

Per le architetture ARM a 26 e 32-bit, invece, i puntatori erano sempre della stessa dimensione: 32-bit. L'unica differenza è che nel primo caso alcuni bit erano a zero / inutilizzati, e che se si salvava il PC ci si trascinava dietro anche il registro di stato & flag (idem per il ripristino).

Dunque le applicazioni non andavano cambiate per quanto riguarda l'indirizzamento della memoria (i puntatori rimanevano gli stessi), ma soltanto nelle parti di codice che manipolavano il PC e/o i flag.

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).

Lo stadio in più di cui parli fa uso di un apposito decoder che riconosce soltanto le istruzioni THUMB, e produce il corrispettivo opcode / istruzione ARM da eseguire. E', a tutti gli effetti, un nuovo, diverso decoder che è stato inserito nel processore.

Puoi vederlo come un decoder semplice di x86, che traduce un'istruzione x86 in un uop RISC: sarà quest'ultima a essere poi decodificata ed eseguita.

Le versioni THUMB-only non hanno bisogno di questa traduzione, ovviamente, per cui non è necessario avere entrambi il decoder: ce n'è soltanto uno, più grosso di quello ARM ma inferiore alla somma dei decoder THUMB + ARM.

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").

Certamente, ma ha avuto tutto il tempo e se l'è presa comoda: era l'unica architettura "di spicco" a essere rimasta a 32-bit.

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.

Ma io ho sempre parlato di x86. Itanium è stato un fallimento, e lo sappiamo tutti, anche se sul codice in virgola mobile (NON SIMD) aveva delle ottime prestazioni.

Per quanto riguarda x86, già verso la fine degli anni '90 aveva prestazioni sugli "interi" comparabili a quelle dei migliori RISC, Alpha incluso. Peccava nei calcoli in virgola mobile, complice la vecchia FPU x87. La musica, però, è cambiata con l'introduzione delle SSE, che con apposito codice consentivano prestazioni mediamente superiori anche all'Alpha.

Alpha è una bella architettura, senz'altro, ma era votata esclusivamente alle prestazioni, e il codice era tutt'altro che denso. Oltre al fatto che la opcode table era già abbastanza inflazionata, e c'era ben poco spazio per aggiunte come una nuova unità SIMD. Con l'esplosione dei SIMD dubito che sarebbe rimasta competitiva. In ogni caso il suo target era esclusivamente quello dei server / workstation.

[LMCH]

Originariamente inviato da cdimauro

Io ho programmato abbondantemente entrambi i processori, ma quasi mai ho avuto bisogno di macro di prologo o epilogo nelle routine che scrivevo. Raramente ho avuto bisogno di più registri di quelli a disposizione e, dunque, di mettere qualche parametro o variabile locale sullo stack (dunque di creare uno stack-frame). Anche perché le istruzioni ENTER/LEAVE e LINK/UNLINK erano decisamente pesanti, per cui in genere evitavo (o, al limite, ricorrevo a qualche "push" / "pop"). In ogni caso si trattava di singole scelte che facevo direttamente, senza ricorrere a macro.

Se hai programmato in assembly senza far uso di macro, specialmente di quelle di prologo ed epilogo significa che hai scritto roba ad-hoc (tipo: ottimizzazione in assembly di singole funzioni precedentemente scritte in C), io ho scritto roba un pochino differente (tipo generatori di codice assemby a partire da bytecode di plc) in cui il codice assembly generato chiamava o veniva chiamato da funzioni scritte in C (con conseguente necessità di supportare l'ABI usata dal compilatore C).
Visto che con certi compilatori l'ABI può variare anche in base alle opzioni di compilazione (uso oppure no di registri come base pointer, numero degli scratch register, ecc.), usare macro (in modo da cambiare il codice in un solo punto invece che ad ogni entry point o punto di chiamata) era una scelta quasi obbligata.

Insomma, le modifiche richieste per il passaggio dal modello a 26bit a quello a 32bit con un ISA come quella degli ARM non mi sembrano così problematiche.

[LMCH]

Originariamente inviato da cdimauro

ARM passò alla versione full 32-bit soltanto 7 anni dopo la presentazione del primo ARM, nel'92, ma nel settore embedded non c'era alcun motivo per estendere lo spazio d'indirizzamento a 32-bit: 26-bit erano perfettamente sufficienti.

Perche 7 anni dopo le cose erano cambiate parecchie, ARM era stato sviluppato da Acorn Computers in primo luogo per il suo home computer, ma 5 anni dopo la IP di ARM era sotto il controllo di ARM Holdings e questa cercava di proporlo anche in altri settori (non necessariamente quello embedded) e quindi iniziarono a rimuovere cose che potevano essere percepite come limitazioni per i nuovi possibili utilizzi.
Insomma, 7 anni dopo la presentazione, ma 2 anni dopo il passaggio ad ARM Holdings che aveva idee differenti riguardo i possibili campi d'impiego.

[LMCH]

Originariamente inviato da cdimauro

Puoi vederlo come un decoder semplice di x86, che traduce un'istruzione x86 in un uop RISC: sarà quest'ultima a essere poi decodificata ed eseguita.

Le versioni THUMB-only non hanno bisogno di questa traduzione, ovviamente, per cui non è necessario avere entrambi il decoder: ce n'è soltanto uno, più grosso di quello ARM ma inferiore alla somma dei decoder THUMB + ARM.

Ma nei casi in cui si usa un decoder THUMB-only la cosa non è un problema perche l'obiettivo principale è la densità del codice e la riduzione globale di complessità del core.

[LMCH]

Originariamente inviato da cdimauro

Alpha è una bella architettura, senz'altro, ma era votata esclusivamente alle prestazioni, e il codice era tutt'altro che denso. Oltre al fatto che la opcode table era già abbastanza inflazionata, e c'era ben poco spazio per aggiunte come una nuova unità SIMD. Con l'esplosione dei SIMD dubito che sarebbe rimasta competitiva. In ogni caso il suo target era esclusivamente quello dei server / workstation.

Scusa, ma hai presente la parte riguardo "architettura nata a 64bit" ?

Era ovvio che aveva codice poco "denso" rispetto ad un x86 nato come cpu a 16bit, ma era anche vero che nasceva con un set di 64 registri a 64bit
(32 interi e 32 fp) e che la direttiva primaria era avere il massimo delle prestazioni ottenibili con un architettura a 64bit.

Tra le altre cose aveva istruzioni SIMD (le MVI) ma i suoi progettisti per EV8 avevano già previsto di implementare un "vero" multithreading (non quella roba assurdamente mal dimensionata dei Pentium 4).

Per rendere l'idea EV8 doveva avere 4 thread per core con sino ad 8 istruzioni per ciclo per thread (il numero di thread era dimensionato in modo tale che nel caso peggiore le pipeline funzionassero comunque a pieno regime o quasi).

Roba che avrebbe prodotto prestazioni "da ottimizzazioni SIMD" anche eseguendo codice normale o che non poteva essere parallelizzato in modo efficiente con istruzioni SIMD.

Roba che non si poteva fare con gli x86 senza modifiche radicali al loro set d'istruzioni (e per cui per essi l'unica strada percorribile era introdurre le SIMD e nuovi registri).

SOLO DOPO EV8 era prevista l'aggiunta di estensioni SIMD "stile SSE2" per continuare a salire di prestazioni, guardacaso si trattava di registri a 128bit
(non a 256bit o 512bit come per gli x86) perche per come era strutturata l'architettura conveniva di più "aggiungere thread" invece che "allargare troppo i registri".

Il fatto che anche gli ARM (inclusi gli ARMv8) abbiano registri "SIMD" che sono "solo" a 128bit non è casuale.
Il set d'istruzioni non è così irrilevante, ha influenzato l'evoluzione stessa degli x86 ed ora con ARMv8 forse si potrà verificare se la roadmap dei progettisti di Alpha influenza anche da un differente set d'istruzioni era valida oppure no.

[cdimauro]

Originariamente inviato da LMCH

Se hai programmato in assembly senza far uso di macro, specialmente di quelle di prologo ed epilogo significa che hai scritto roba ad-hoc (tipo: ottimizzazione in assembly di singole funzioni precedentemente scritte in C), io ho scritto roba un pochino differente (tipo generatori di codice assemby a partire da bytecode di plc) in cui il codice assembly generato chiamava o veniva chiamato da funzioni scritte in C (con conseguente necessità di supportare l'ABI usata dal compilatore C).
Visto che con certi compilatori l'ABI può variare anche in base alle opzioni di compilazione (uso oppure no di registri come base pointer, numero degli scratch register, ecc.), usare macro (in modo da cambiare il codice in un solo punto invece che ad ogni entry point o punto di chiamata) era una scelta quasi obbligata.

Le tue, però, non sono le esigenze comuni di chi deve rimpiazzare una funzione (o parte di essa) con un'equivalente in assembly. Come nel mio caso.

Insomma, le modifiche richieste per il passaggio dal modello a 26bit a quello a 32bit con un ISA come quella degli ARM non mi sembrano così problematiche.

Non ho mai detto questo, infatti. Ho sottolineato soltanto che le due ISA erano incompatibili, e l'errore progettuale nella scelta di Acorn per la prima.

Originariamente inviato da LMCH

Perche 7 anni dopo le cose erano cambiate parecchie, ARM era stato sviluppato da Acorn Computers in primo luogo per il suo home computer, ma 5 anni dopo la IP di ARM era sotto il controllo di ARM Holdings e questa cercava di proporlo anche in altri settori (non necessariamente quello embedded) e quindi iniziarono a rimuovere cose che potevano essere percepite come limitazioni per i nuovi possibili utilizzi.
Insomma, 7 anni dopo la presentazione, ma 2 anni dopo il passaggio ad ARM Holdings che aveva idee differenti riguardo i possibili campi d'impiego.

Senz'altro, ma visto che l'orientamento era verso il settore embedded ormai, aveva poco senso un passaggio dall'architettura a 26 a quella a 32 bit, viste le esigenze tipiche del settore embedded, specialmente in quel periodo.

Voglio dire, è paradossale che per i personal computer (e pure i server; infatti Acorn cercò di inserirsi anche nel mercato Unix) abbia proposto un'architettura castrata, salvo poi, diverso tempo dopo, riprogettarla in maniera più pulita quando si stava buttando sul settore embedded (che aveva, e spesso ha pure oggi, esigenze di gran lunga minori).

Originariamente inviato da LMCH

Ma nei casi in cui si usa un decoder THUMB-only la cosa non è un problema perche l'obiettivo principale è la densità del codice e la riduzione globale di complessità del core.

Assolutamente d'accordo su questo.

Originariamente inviato da LMCH

Scusa, ma hai presente la parte riguardo "architettura nata a 64bit" ?

Certamente.

Era ovvio che aveva codice poco "denso" rispetto ad un x86 nato come cpu a 16bit, ma era anche vero che nasceva con un set di 64 registri a 64bit
(32 interi e 32 fp) e che la direttiva primaria era avere il massimo delle prestazioni ottenibili con un architettura a 64bit.

Nulla da dire su questo, infatti.

Tra le altre cose aveva istruzioni SIMD (le MVI)

Le MVI erano una piccola pezza, ben più piccola di quella che ARM aveva introdotto nella sua ISA per cercare di sfruttare qualche vantaggio del paradigma SIMD, sfruttando la stessa tecnica (utilizzare i registri interi per conservare i dati "impacchettati").

ma i suoi progettisti per EV8 avevano già previsto di implementare un "vero" multithreading (non quella roba assurdamente mal dimensionata dei Pentium 4).

L'Hyperthreading per il Pentium 4 nasce per ben altre esigenze.

Per rendere l'idea EV8 doveva avere 4 thread per core con sino ad 8 istruzioni per ciclo per thread (il numero di thread era dimensionato in modo tale che nel caso peggiore le pipeline funzionassero comunque a pieno regime o quasi).

Da quel che ho trovato qui sembra che il frontend fosse in grado di inviare fino a 8 istruzioni intere e fino a 4 in virgola mobile alle rispettive unità di calcolo per ciclo di clock; ovviamente per 4 thread hardware.

Roba che avrebbe prodotto prestazioni "da ottimizzazioni SIMD" anche eseguendo codice normale o che non poteva essere parallelizzato in modo efficiente con istruzioni SIMD.

Vedi sopra. Se ci pensi bene, non è molto come dato complessivo. Un Pentium 3 con la sua unità SIMD riesce a macinare 4 istruzioni in virgola mobile per ciclo di clock, con un'architettura di gran lunga più semplice. Ovviamente sono due processori pensati per ambiti completamente diversi, ma se guardi ai numeri grezzi (per il calcolo in virgola mobile) l'EV8 non è così impressionante.

Per essere chiari, pensare di competere con un'unità SIMD con un'architettura come quella di EV8 è come sparare a una mosca con un cannone: hai messo in campo enormi risorse quando la problematica ne richiede molte meno per essere risolta. Comunque ne parlo meglio dopo.

Roba che non si poteva fare con gli x86 senza modifiche radicali al loro set d'istruzioni (e per cui per essi l'unica strada percorribile era introdurre le SIMD e nuovi registri).

Questo come fai a dedurlo, scusa? EV8 non introduce istruzioni particolari o qualche modalità d'esecuzione speciale. Si tratta di una particolare micro-implementazione di Alpha.

Non c'è nulla che impedisca di fare lo stesso con x86. Non lo si fa perché i vantaggi non sono commisurati all'implementazione troppo complicata. Oggi ci sono altre vie per ottenere prestazioni anche migliori; vedi sotto.

SOLO DOPO EV8 era prevista l'aggiunta di estensioni SIMD "stile SSE2" per continuare a salire di prestazioni,

Non ho trovato notizie di ciò. Comunque secondo te perché avrebbero scelto l'approccio SIMD anziché continuare sulla strada del modello EV8?

guardacaso si trattava di registri a 128bit
(non a 256bit o 512bit come per gli x86)

Veramente le SSE erano e sono a 128 bit (e le MMX erano addirittura a 64-bit). Soltanto di recente con AVX i registri SIMD sono diventati a 256-bit (e diventeranno a 512-bit con AVX-512), mentre Larrabee/Xeon Phi offre dall'inizio registri SIMD a 512-bit.

perche per come era strutturata l'architettura conveniva di più "aggiungere thread" invece che "allargare troppo i registri".

Beh, se ti vai a vedere i dettagli di EV8 i registri li hanno comunque allargati molto, in termini numerici, e questo ha influenzato pesantemente l'architettura.

E se Alpha aveva deciso di introdurre un'unità SIMD dopo EV8, sarà stato sicuramente a causa dell'enorme complessità dell'implementazione di EV8 per gestire tutta quella roba, che invece con un modello SIMD è di gran lunga più semplice (i registri "larghi" servono anche a questo: a "spalmare" la complessità di gestione dei registri sulla loro ampiezza. Meno registri ma più larghi -> molta meno logica per gestire il tutto).

Il fatto che anche gli ARM (inclusi gli ARMv8) abbiano registri "SIMD" che sono "solo" a 128bit non è casuale.

Potrebbero averli anche a 256, 512, o più bit: non è prerogativa di x86 avere registri SIMD "ampii". Tra l'altro ARM non ha micro-architetture fortemente multi-thread come EV8. Dunque vorrei capire cos'è che volevi esprimere in questa parte della discussione, riguardo alla necessità / convenienza di avere o meno registri a 128 o più bit, perché non mi è chiaro.

Il set d'istruzioni non è così irrilevante, ha influenzato l'evoluzione stessa degli x86 ed ora con ARMv8 forse si potrà verificare se la roadmap dei progettisti di Alpha influenza anche da un differente set d'istruzioni era valida oppure no.

Senz'altro. Io sono un forte sostenitore che l'ISA abbia un suo ruolo, anche forte.

Stamattina mi sono divertito a smazzarmi un po' di documentazione sugli Alpha, inclusa la opcode table. Le istruzioni load/store e di salto si mangiano più di metà dello spazio, ma ho visto che ci sono diversi buchi che potrebbero essere tranquillamente utilizzati per implementare le istruzioni di load/store per l'unità SIMD, come pure le istruzioni necessarie; con un'opportuna codifica ci sarebbe anche spazio per istruzioni quaternarie (con 4 registri; molto utili per particolari istruzioni come FMAC & FMA).

Altra cosa interessante è il fatto che Alpha è comunque abbastanza complessa come ISA, contando qualche centinaia di istruzioni (fra cui alcune per il "legacy" che si porta dietro dai VAX), di cui alcune abbastanza complicate. La ricordavo molto più semplicemente, ma evidentemente anche Digital ha pensato di allinearsi alla tendenza ormai delineata, inserendo istruzioni specializzate nella sua ISA.

Rimane sempre una "bella" architettura, anche se scarsamente densa per il codice. Ma gli obiettivi, appunto, erano ben altri.

[LMCH]

Originariamente inviato da cdimauro

Non ho trovato notizie di ciò. Comunque secondo te perché avrebbero scelto l'approccio SIMD anziché continuare sulla strada del modello EV8?

Perche grazie al set d'istruzioni utilizzato aggiungevano (ricorda che lo avevano già fatto) nuove istruzioni e nuovi registri in modo più flessibile.

Il motivo per cui intendevano aggiungere istruzioni SIMD con registri a 128bit era perche con essi avrebbero aggiunto nche il supporto in hardware dei float a 128bit (con "gratis" altre istruzioni SIMD che tornavano utili).

Non si erano spinti oltre perche se si esagera con l'ampiezza dei registri si hanno maggiori limitazioni sulla frequenza operativa massima (per tener sotto controllo il clock skew) e su quanti thread si possono eseguire in simultanea.

I progettisti di Alpha privilegiavano il multithreading perchè il software che facevano girare traeva più vantaggio senza dover ricompilare dal multithreading che dalle istruzioni SIMD, inoltre questo permettera di scalare maggiormente di prestazioni senza dover cambiare il set d'istruzioni per accomodare registri SIMD più grandi in mancanza di alternative migliori come attualmente fa Intel.

Inoltre con il multithreading si possono aggiungere ulteriori thread o rimuoverli completamente dall'implementazione mantenendo la retrocompatibilita totale con il software già sviluppato, mentre è più complicato "tornare indietro" se si cambia il set d'istruzioni (e diventa sempre più complicato "andare avanti" aggiungendo nuove istruzioni).

Non si risolve tutto a colpi di registri SIMD sempre più ampi.

Intel segue una certa strada perche le sono precluse altre opzioni che invece erano disponibili per gli Alpha.

[cdimauro]

Originariamente inviato da LMCH

Perche grazie al set d'istruzioni utilizzato aggiungevano (ricorda che lo avevano già fatto) nuove istruzioni e nuovi registri in modo più flessibile.

Le nuove, ma pochissime, istruzioni vettoriali facevano uso dei registri interi.

Il motivo per cui intendevano aggiungere istruzioni SIMD con registri a 128bit era perche con essi avrebbero aggiunto nche il supporto in hardware dei float a 128bit (con "gratis" altre istruzioni SIMD che tornavano utili).

Per cui probabilmente avrebbero esteso i registri dell'FPU a 128-bit, anziché aggiungere un banco di nuovi registri a 128-bit.

Non si erano spinti oltre perche se si esagera con l'ampiezza dei registri si hanno maggiori limitazioni sulla frequenza operativa massima (per tener sotto controllo il clock skew) e su quanti thread si possono eseguire in simultanea.

Il passaggio da SSE (128-bit) ad AVX (256-bit) non ha visto una diminuzione della frequenza massima dei processori (anzi, è leggermente migliorata; ovviamente mi riferisco a parità di processo produttivo utilizzato dalle rispettive famiglie di processori). Per quello da AVX ad AVX-512 (512-bit) si dovrà attendere l'arrivo di Broadwell prima, e Skylake dopo (in modo da confrontare le frequenze a parità di processo produttivo utilizzato) per controllare (ma sono fiducioso che non ci saranno sorprese).

Riguardo al numero di thread, l'unica famiglia di processori x86 che ne adotta 4 per core è Xeon Phi, che ha registri SIMD a 512-bit, ma frequenze ridotte per contenere i consumi. Per cui non si può prendere a campione per analizzare l'impatto della lunghezza dei registri SIMD sul numero di thread.

I progettisti di Alpha privilegiavano il multithreading perchè il software che facevano girare traeva più vantaggio senza dover ricompilare dal multithreading che dalle istruzioni SIMD, inoltre questo permettera di scalare maggiormente di prestazioni senza dover cambiare il set d'istruzioni per accomodare registri SIMD più grandi in mancanza di alternative migliori come attualmente fa Intel.

Inoltre con il multithreading si possono aggiungere ulteriori thread o rimuoverli completamente dall'implementazione mantenendo la retrocompatibilita totale con il software già sviluppato, mentre è più complicato "tornare indietro" se si cambia il set d'istruzioni (e diventa sempre più complicato "andare avanti" aggiungendo nuove istruzioni).

Eppure l'approccio multithreading spinto di EV8 non ha attecchito, e molte famiglie di processori non l'hanno adottato, preferendo, invece, ricorrere all'integrazione di un'unità SIMD. Evidentemente il primo porta molti più problemi rispetto al secondo.

Non si risolve tutto a colpi di registri SIMD sempre più ampi.

I numeri al momento dimostrano che danno una grande mano.

Intel segue una certa strada perche le sono precluse altre opzioni che invece erano disponibili per gli Alpha.

Anche altri produttori di processori non hanno seguito la strada di Alpha, preferendo passare dalla via dell'unità SIMD. E Alpha stesso avrebbe adottato quest'ultima.

Finora aumentare l'ampiezza dei registri SIMD ha dato ragione a Intel, come pure l'assenza di implementazioni multithreading estremamente aggressive da parte di altri vendor (eccetto IBM con POWER8 che dovrebbe essere confrontabile con EV8, se non ricordo male, ma presenta consumi elevatissimi ed è pensato per ambiti molto specializzati).

La microelettronica non è il mio campo, ma a naso direi che quest'ultima soluzione crea decisamente più problemi rispetto alla prima, ed è il motivo per cui sia praticamente scomparsa a favore della prima soluzione.

[LMCH]

Originariamente inviato da cdimauro

Le nuove, ma pochissime, istruzioni vettoriali facevano uso dei registri interi.

Le MVI furono introdotte nel 1997, mentre EV8 con il SMT era inizialmente previsto per il 2003 e le nuove istruzioni SIMD ed i nuovi registri a 128bit erano pianificati per dopo EV8.
Non erano "nuove" ed evidentemente non c'era tutta quell'urgenza di introdurre nuove istruzioni SIMD.

Originariamente inviato da cdimauro

Per cui probabilmente avrebbero esteso i registri dell'FPU a 128-bit, anziché aggiungere un banco di nuovi registri a 128-bit.

Era una delle opzioni in teoria possibili, ma probabilmente avrebbero aggiunto dei registri distinti in modo da aver maggior libertà nelle ottimizzazioni a livello di implementazione (es: unita di esecuzione separate con più alta latenza ma con maggior throughput complessivo nella manipolazione di vettori).

Originariamente inviato da cdimauro

Il passaggio da SSE (128-bit) ad AVX (256-bit) non ha visto una diminuzione della frequenza massima dei processori (anzi, è leggermente migliorata; ovviamente mi riferisco a parità di processo produttivo utilizzato dalle rispettive famiglie di processori). Per quello da AVX ad AVX-512 (512-bit) si dovrà attendere l'arrivo di Broadwell prima, e Skylake dopo (in modo da confrontare le frequenze a parità di processo produttivo utilizzato) per controllare (ma sono fiducioso che non ci saranno sorprese).

Riguardo al numero di thread, l'unica famiglia di processori x86 che ne adotta 4 per core è Xeon Phi, che ha registri SIMD a 512-bit, ma frequenze ridotte per contenere i consumi. Per cui non si può prendere a campione per analizzare l'impatto della lunghezza dei registri SIMD sul numero di thread.

Ma negli x86 il decoder e gli altri colli di bottiglia sono differenti, senza contare che da anni una volta venuta meno la "minaccia" di AMD non spinge più di tanto il clock delle sue cpu.

Originariamente inviato da cdimauro

Finora aumentare l'ampiezza dei registri SIMD ha dato ragione a Intel, come pure l'assenza di implementazioni multithreading estremamente aggressive da parte di altri vendor (eccetto IBM con POWER8 che dovrebbe essere confrontabile con EV8, se non ricordo male, ma presenta consumi elevatissimi ed è pensato per ambiti molto specializzati).

La microelettronica non è il mio campo, ma a naso direi che quest'ultima soluzione crea decisamente più problemi rispetto alla prima, ed è il motivo per cui sia praticamente scomparsa a favore della prima soluzione.

Con l' aumentare della scala d'integrazione e l'enfasi sulla riduzione dei consumi, l'approccio multithreading si è trasformato in un approccio multicore
(vedi le soluzioni multi-core ARM).
Ma come tu stesso hai notato, dove sono le prestazioni il requisito primario e dove il set d'istruzioni lo permette (i POWER di IBM) si segue un approccio multi-thread e multi-core.

L'approccio SIMD "modalità smodata" è un "successo" (per gli x86) perchè Intel è ritornata a dettar legge riguardo i set d'istruzioni x86 (dopo che AMD per una volta riuscì ad imporre come standard di fatto x86-64, ma ci riuscì solo per il supporto di Microsoft che si rifiutò di supportare un altro standard a 64bit per x86 come Intel era disposta a fare).

Tutti gli altri hanno introdotto nel tempo istruzioni SIMD ma "guardacaso" si sono limitati a registri a 128bit (Altivec, NEON, e MIPS SIMD) e se servivano maggiori prestazioni hanno aumentato il numero di core.

[cdimauro]

Originariamente inviato da LMCH

Le MVI furono introdotte nel 1997, mentre EV8 con il SMT era inizialmente previsto per il 2003 e le nuove istruzioni SIMD ed i nuovi registri a 128bit erano pianificati per dopo EV8.
Non erano "nuove" ed evidentemente non c'era tutta quell'urgenza di introdurre nuove istruzioni SIMD.

O non c'erano risorse, visti i tempi di sviluppo molto lunghi di EV8?

Era una delle opzioni in teoria possibili, ma probabilmente avrebbero aggiunto dei registri distinti in modo da aver maggior libertà nelle ottimizzazioni a livello di implementazione (es: unita di esecuzione separate con più alta latenza ma con maggior throughput complessivo nella manipolazione di vettori).

Avere registri distinti è comodo se hai una vecchia ISA come x87 che è troppo diversa dall'unità SIMD (SSE, nel caso di x86), per cui o usi l'una oppure l'altra anche se devi usare codice scalare. Infatti le SSE supportano sia codice scalare sia vettoriale, per cui ha senso usare x87 soltanto per la precisione estesa (80-bit).

In ogni caso le applicazioni eseguono in genere soltanto codice scalare (per l'FPU, intendo) o vettoriale. Per cui riutilizzare lo stesso register set per entrambi è una gran comodità.

Specialmente nel caso dell'introduzione dei float a 128-bit, visto che si tratta di codice scalare e Alpha ha già un'FPU molto veloce e potente, sarebbe stato meglio estenderne i registri a 128-bit e aggiungere il supporto questo nuovo tipo di dato. D'altra parte l'FPU supporta pure il formato floating point VAX (per questioni legacy, ovviamente), e dunque gestire un altro tipo non sarebbe certo un problema.

A questo punto avendo esteso l'FPU con registri a 128-bit, si sarebbero potuti aggiungere gli opcode opportuni (e distinti) per i calcoli vettoriali SIMD.

Ma negli x86 il decoder e gli altri colli di bottiglia sono differenti,

Scusami, ma il decoder che c'entra qui? AVX, peraltro, è un formato molto più compatto e di gran lunga più semplice da decodificare rispetto alle istruzioni "intere" ed SSE.

Voglio dire: non è certo un problema per il decoder gestire le nuove istruzioni SIMD che operano su 256-bit. Non è certamente questo che limiterebbe la frequenza massima raggiungibile dal processore.

La tua tesi era che l'aumento della dimensione dei registri SIMD portasse a problemi nello scalare in frequenza. L'introduzione delle AVX con registri a 256-bit (tock) non ha mostrato nulla di ciò, pur usando lo stesso processo produttivo della precedente famiglia di processori (tick). Vedremo poi fra Broadwell (AVX2, 256-bit) e Skylake (AVX-512, 512-bit) cosa succederà, nelle medesime condizioni.

senza contare che da anni una volta venuta meno la "minaccia" di AMD non spinge più di tanto il clock delle sue cpu.

Magari fosse quello! Purtroppo, come ben sai, scalare in frequenza col silicio è diventato estremamente difficile da una dozzina d'anni a questa parte. Ci sono voluti circa 10 anni per tornare nuovamente a raggiungere i 4Ghz, dopo il capitolo Pentium 4, e si procede ormai a incrementi di qualche centinaio di Mhz ogni tanto.

Con l' aumentare della scala d'integrazione e l'enfasi sulla riduzione dei consumi, l'approccio multithreading si è trasformato in un approccio multicore (vedi le soluzioni multi-core ARM).

E' quello che fanno tutti, Intel inclusa. Il multithreading, quando implementato da Intel, non è mai stato votato alle prestazioni estreme, infatti, ma per tenere impegnate le unità di calcolo esistenti cercando di ottimizzarne l'uso.

Ma come tu stesso hai notato, dove sono le prestazioni il requisito primario e dove il set d'istruzioni lo permette (i POWER di IBM) si segue un approccio multi-thread e multi-core.

Non è questione di ISA: POWER8 non ha nulla di particolare per l'aggressiva implementazione multi-threaded. E' che IBM con questa ISA ha deciso di spingere su questo fronte, ma il prezzo da pagare sono i consumi elevatissimi. Adesso non ricordo di preciso perché è passato tempo, ma mi sembra che un POWER8 a 3Ghz con 4 core consumasse qualcosa come 500W o più. Se vuole continuare su questa strada, faccia pure, ma a mio avviso è un segnale che stanno ormai alla canna del gas...

L'approccio SIMD "modalità smodata" è un "successo" (per gli x86) perchè Intel è ritornata a dettar legge riguardo i set d'istruzioni x86 (dopo che AMD per una volta riuscì ad imporre come standard di fatto x86-64, ma ci riuscì solo per il supporto di Microsoft che si rifiutò di supportare un altro standard a 64bit per x86 come Intel era disposta a fare).

Beh, ne è passato di tempo fra l'introduzione di x86-64 e quella di AVX.

Comunque cosa doveva fare Intel? Continuare a mettere pezze all'ISA per le SSE? Se dai un'occhiata alla struttura degli opcode di AVX, ti renderai conto da solo che rappresenta il classico uovo di Colombo per quest'architettura: opcode molto semplici da decodificare (nessun prefisso!), che consentono codice molto denso, supporto alle operazioni ternarie, estensione dei registri a 256-bit, e una schema pensato per future estensioni senza mettere pezze.

Tutti gli altri hanno introdotto nel tempo istruzioni SIMD ma "guardacaso" si sono limitati a registri a 128bit (Altivec, NEON, e MIPS SIMD) e se servivano maggiori prestazioni hanno aumentato il numero di core.

Stai parlando di scelte fatte quando le AVX non c'erano ancora. Intel ha introdotto le AVX da qualche anno. Può darsi che in futuro anche i produttori di processori RISC faranno qualche scelta del genere, ma ci vorrà tempo per innovazioni di questo tipo, come c'è voluto tempo per passare dalle SSE ad AVX.

Nel frattempo Intel continuerà per la sua strada, allargando i registri SIMD, raddoppiando le prestazioni in maniera più economica rispetto all'aggiunta di core (una sola istruzione da decodificare, ma molte più operazioni eseguite: SIMD docet), e offrendo anche un supporto migliore alla doppia precisione.

Sì, perché dimentichi anche è ormai possibile eseguire 4 operazioni a doppia precisione per ciclo di clock con le AVX, grazie al fatto che in 256-bit è possibile impacchettare 4 dati di questo tipo. Se in futuro verrà aggiunto il supporto a precisione quadrupla a 128-bit, con le AVX-512 sarà possibile fare lo stesso.

Gli altri RISC potranno pure continuare a usare registri a 128-bit, e offrire prestazioni castrate per questi tipi di dati, che perà sono sempre più utilizzati.