Fino a 20 core x86 per le prossime CPU FX ed Opteron (2016-17)

[Sasha]

perchè, dall'esterno, è appunto CISC… Poi è la CPU che, per eseguirle, si "spezza" internamente le istruzioni CISC in altre RISC…

ARM e MIPS li vedo ancora poco minacciosi nel settore ad alte prestazioni su singolo die… magari, e sicuramente, in cluster e in determinati ambiti d'uso sono/potranno essere un validissimo avversario… Ma non ovunque…

[Alessio89]

Per ora è prevista la produzione nel 2016 di CPU server a 20 core x86-64 e arm-v8 64. Che vi saranno due famiglie differenti la cosa la vedo probabile, fino ad ora nessuno è riuscito a fare una pipeline che sia in grado di leggere nativamente il microcodice di ARM e x86, sebbene entrambi RISC (x86 ricordo che di CISC ha solo l'assembly da un sacco di tempo). I socket dovrebbero tuttavia essere compatibili, o quantomeno molto simili.
Ovviamente il 2016 resta una data vana, ma se venisse rispettata significa che nel 2017 vi sarebbe la vendita in massa all'utente finale di socket a 20 core nativi per arm e x86, il che non sarebbe male. Ovviamente rimane tutto relativo, per ora non mi pare che la fonte abbia a disposizione un vero e proprio sample..

ah, questo non lo sapevo: allora perché sono definite ancora come CISC?
comunque non dimentichiamoci che se la Cina e Russia inizieranno a fare sul serio coi MIPS, ci sarà un terzo incomodo mica da poco, anzi con un bacino da 1.5 Miliardi di persone potenzialmente perse...

Perché una volta erano appunto dei CISC, sia a livello software (assembly e codice macchina), sia a livello hardware (microcodice), tuttavia con il 486 intel migrò per una pipeline RISC-like e di conseguenza il microcodice diventò RISC.
L'assembly e il codice macchina rimangono lo stesso CISC perché altrimenti si romperebbe la compatibilità. Da codice macchina a microcodice avviene una traduzione "on-the-fly" senza perdite di performance o comunque del tutto trascurabili.
Avere un microcodice RISC-like ha permesso agli x86 di continuare a vivere fino ad oggi, rendendo lo sviluppo delle pipeline nettamente più semplice, nonché consente di introdurre delle modifiche a livello di architettura in maniera molto più semplice in quanto basta rispettare il codice macchina (e di conseguenza l'assembly) prestabilito, poi l'implementazione può essere fatta come si vuole.
La maggioranza delle CPU odierne adotta questa strategia.
Ovviamente il fatto che l'implementazione di tutte le CPU moderne x86 siano RISC a livello di microcodice non significa che questa siano implementate in maniera analoga agli ARM, rimangono infatti le differenza sul numero dei registri e su come questi vengono utilizzati.

perchè, dall'esterno, è appunto CISC… Poi è la CPU che, per eseguirle, si "spezza" internamente le istruzioni CISC in altre RISC…

ARM e MIPS li vedo ancora poco minacciosi nel settore ad alte prestazioni su singolo die… magari, e sicuramente, in cluster e in determinati ambiti d'uso sono/potranno essere un validissimo avversario… Ma non ovunque…

Se le GPU spezzeranno il gap prestazionale sulle operazioni con gli interi (cosa che stanno facendo, anche se lentamente) non la vedo così rosea per ARM e MIPS nei server-cluster. AMD GCN ma anche NVIDIA Maxwell su questo punto di vista hanno fatto passi da gigante (seppur siamo ancora lontani ad avere la stessa efficienza sugli interi che hanno con i floating point).

[Jena Plisskin]

Scusa Alessio ma sono curioso. Tu dici che dal 486 viene implementato il Risc per poi tradurle in CISC. A parte il discorso superpipeline, in effetti proveniente dal RISC, io sapevo che questa operazione fu fatta per primo da NextGen poi acquisita da AMD che lo propose nel suo k6. Intel fece questa operazione mi sembra dal PII o PIII. Ricordo male ?

[Alessio89]

Non è stata una trasformazione avvenuta in un colpo solo, ma "per gradi", diciamo che è iniziata con i 486 di intel e amd (con una prima pipeline con un proprio microcodice risc-like) ed è praticamente finita con i primi pentium 4. AMD oltre a CPU x86 produceva anche vere e proprie CPU RISC con ISA differenti nei primi tempi (per poi abbandonare il tutto). Ora di preciso non con quale modello abbiano cambiato cosa, anche perché sono parti relative all'architettura implementativa e non vengono diffusi più di tanto. Forse in qualche manuale o libro di architettura deragliata trovi più informazioni. Ovviamente tieni conto che un conto è avere un microcodice per una pipeline RISC-like è differente dall'avere un'intera architettura pensata come RISC (tipo gli ARM e i MIPS).

[Jena Plisskin]

Si in effetti pensadoci bene deve essere come dici tu. il passaggio di NextGen probabilmente fù per la parte core, ma il resto era stato in parte adottato.

[Alessio89]

mini enciclica sui registri:

MIPS:
MIPS32, architettura RISC per eccellenza, ha 32 registri (utilizzati in diverso modo per operazioni su interi e virgola mobile)
MIPS64 ne ha ben 64 (32 per gli interi e 32 per i virgola mobile se non erro).
Diverse gruppi di estensioni opzionali SIMD-like (nulla a confronto con quello che segue sotto).

x86:
x86-IA32 ne ha 8 e le operazioni aritmetiche disponibili sono solo per gli interi
x86-64 ne ha ben 16 e le operazioni aritmetiche disponibili sono solo per gli interi
x87, l'architettura per i calcoli in virgola mobile con precisione fino a 80 bit, ha 8 registri.
MMX: 16 registri da 64-bit solo per le operazioni su interi a 32, 16 e 8 bit (e volendo a 64-bit) Impossibilità di usare in contemporanea la FPU poiché i registri sono in conflitto (quelli di MMX condividono i primi 64-bit con quelli della FPU a livello di indirizzi).
3DNow! (da e solo su AMD, non più supportato eccetto per due istruzioni): come MMX a livello di registri solo che supporta le operazioni su virgola mobile a singola precisione (32-bit), impossibilità di essere usata assieme ad MMX per via dello stesso spazio indirizzi (e di conseguenza anche niente FPU), tuttavia il problema si pone poco (fa entrambe le cose per i 32-bit). 3DNow! alla fine muore, Intel ne copia alcune funzionalità nelle SSE3 e un paio di funzioni originali di 3DNow! sono tutt'ora presenti in tutte le recenti CPU (anche con nomi diversi ma quelle sono).
SSE: 8 registri a 128-bit solo per le operazioni sui virgola mobile a 32 bit. Possono essere utilizzati assieme ad MMX o alla FPU in quanto lo spazio dei nomi dei registri questa volta è diverso.
SSE2: stessi registri di SSE ma finalmente possono essere utilizzati anche per interi e virgola mobile a 16, 32 e 64-bit oppure per operazioni su byte (8-bit). Presenti in tutte le CPU x86-64, pertanto un compilatore intelligente ottimizza il software per x64 con le istruzioni SSE2.
SSE3: soliti registri di SSE2, ma con alcune funzionalità nuove (copiate in parte da 3DNow!), utili per operazioni tipiche dei DSP e in ambito 3D (per quanto una GPU sia sempre migliore).
SSE3S: ulteriore miglioramento delle SSE3 con 16 nuove istruzioni (e sì, si accumulano!)
SSE4: tre varianti, 4.1, 4.2 e 4A. Le prime due sviluppate da intel, sempre sulla scia delle SSE2 (e 3 e 3S), aggiungono altre "bellissime" istruzioni (rispettivamente 47 e 7), supportate da AMD solo tardamente (K10). Le SSE4A sono 4 istruzioni sviluppate da AMD, ritenute all'epoca le 4 più importanti fra le 54 delle prime due varianti! AMD inoltre implementa due istruzioni (ABM) supportate da intel pienamente solo a partire da Haswell (alla fine Intel ne ha riconosciuto l'utilità!)
SSE5: sviluppate inizialmente da AMD sotto forma di SIMD a 256-bit per spazzare via Intel, in seguito ad un "balletto" tragicomico fra le due su chi supportava cosa e su come dovevano essere implementate alla fine vengono ritardate e spezzettate (AMD non poteva permettersi il lusso di rischiare di creare delle estensioni, seppur fantastiche, incompatibili per via dello spazio nomi con le CUP intel).
XOP, FMA4, CVT16 (o FC16): formano le SSE5 di AMD rivedute per non creare problemi con l'operando di intel. Sulla carta sono una gran figata ma non semplicissime da usare e non implementano appieno ancora le SSE4(!).
AVX: creato da intel per mettere i bastoni tra le ruote alle SSE5 di AMD, equivalgono grossomodo ad XOP (la compatibilità non è perfetta ma si risolve "facilmente"), AVX supporta anche FC16 (inizialmente chiamata CVT16), mentre FMA4 non è ancora supportata.
AVX2: miglioramento di AVX soprattutto per le operazioni sugli interi, con istruzioni FMA3 (variente più semplicedelle FMA4).
AVX-512: istruzioni SIMD a 512-bit, evoluzione in arrivo delle AVX2, in diverse varianti con un "core" comune ed ulteriori gruppi di funzionalità ed istruzioni opzionali. Coprono tutti i registi delle SSEx e di AVX.

AMD piazza 3DNow! (sfortunato ma non così sbagliato), AMD64 (copitate da intel sotto nome di EMT64, poi rinominate Intel 64) che va a definire lo standard core di x86-64 (o x64 che dir si voglia), le SSE5 non le piazza (le spezzetta) e vengono copiate spudoratamente in AVX (AMD supporta entrambi visto che le differenze sono minime).
Intel piazza gli standard di base (16-bit, ia32) e il grosso delle estensioni SIMD (MMX/SSE/2/3/3s/4, AVX2, AVX-512).
Vi sono ulteriori istruzioni per la sicurezza (manipolazione dei bit tipo ABM) e la virtualizzazione hardware (inventata da intel, potenziata molto da AMD e migliorata successivamente ad altalena dalle due).
Dalle SSE ad ogni evoluzione lo spazio dei registri e delle funzionalità viene "coperato" da quello successivo (eccezion fatta per le SSE5 di AMD, che la costringono successivamente ad adottare finalmente le SSE4).
Il supporto alle varie estensioni dopo le SSE2 è altalenante fra AMD ed Intel e CPU nate lo stesso anno non supportano tutte le ultime estensioni disponibili da entrambe le parti.
Via praticamente ha fatto poco o nulla.

ARM:
ARM (32-bit, pre-Cortex): 16 registri a 32 bit per gli interi,
ARM (32-bit Cortex): 16 registri a 32 bit per gli interi, fino a 32 registri da 64-bit per i floating point/simd (via ARM NEON).
ARM (32/64 bit Cortex): 31 registri a 64-bit per gli interi, 32 registri da 128-bit per scalari, fp e simd (via ARM NEON)
ARM NEON: agglomerato di registri e di funzioni che volendo possono essere paragonati grossomodo alle SSE2 con le istruzioni chiave di SSE3 ed SSE4, a seconda dell'architettura il supporto varia.


In tutti i casi non ho contato eventuali registri per lo store/load e altri registri ad hoc. Ho lasciato perdere la variante a 16-bit di x86 anche se è da lì che nasce tutto.
Morale della favola: le architetture RISC hanno nettamente più registri di base e sono più semplici da usare (con MIPS in particolare non si diventa dementi con la tabella delle istruzioni), x86 pur avendo microcodice RISC è di fatto una CISC nel suo complesso, ha pochi registri general-purpose ma compensa con un comparto SIMD che attualmente è forse il migliore e con la relativa serie di funzioni ad hoc.
Su wikipedia potete leggere la tragicommedia delle SSE5.

[Sasha]

sei troppo forte
salvata, fa troppo comodo

[gridracedriver]

mini enciclica sui registri:

...

N° 1
ps. ma non tanto per l'elenco, quello lo si reperisce in qualche modo, ma per la voglia di scrivere in nabbo-like

[Alessio89]

Bug in Haswell su una delle nuove istruzioni "fiche", risultato? Intel la disabilita via microcodice in tutte le CPU prodotte dopo la scoperta XD

http://techreport.com/news/26911/errata ... dwell-cpus

[Il nabbo di turno]

Ma lol!