Perché x86 è brutto? Perché è considerato inferiore rispetto ad altri? [chiuso]

Recentemente ho letto alcuni archivi SO e ho riscontrato dichiarazioni contro l'architettura x86.

• Perché abbiamo bisogno di un'architettura CPU diversa per server e mini / mainframe e mixed-core? dice
  "L' architettura del PC è un disastro, qualsiasi sviluppatore di sistemi operativi te lo direbbe " .

• Vale la pena imparare il linguaggio Assembly? ( archiviato ) dice
  " Renditi conto che l'architettura x86 è orribile nella migliore delle ipotesi "

• Qualche modo semplice per imparare l'assembler x86? dice
  " La maggior parte delle università insegna l'assemblaggio su qualcosa come MIPS perché è molto più semplice da capire, l'assembly x86 è davvero brutto "

e molti altri commenti mi piace

• "Rispetto alla maggior parte delle architetture, X86 fa schifo piuttosto male."

• " È decisamente opinione comune che X86 sia inferiore a MIPS, SPARC e PowerPC "

• " x86 è brutto "

Ho provato a cercare ma non ho trovato alcun motivo. Non trovo che x86 sia dannoso probabilmente perché questa è l'unica architettura con cui ho familiarità.

Qualcuno può gentilmente darmi ragioni per considerare x86 brutto / cattivo / inferiore rispetto ad altri.

Un paio di possibili ragioni per questo:

1. x86 è un ISA relativamente vecchio (i suoi progenitori erano gli 8086, dopotutto)
2. x86 si è evoluto molte volte in modo significativo, ma è necessario hardware per mantenere la retrocompatibilità con i vecchi binari. Ad esempio, l'hardware x86 moderno contiene ancora il supporto per l'esecuzione di codice a 16 bit in modo nativo. Inoltre, esistono diversi modelli di indirizzamento della memoria per consentire l'interoperabilità del codice precedente sullo stesso processore, come la modalità reale, la modalità protetta, la modalità 8086 virtuale e la modalità lunga (amd64). Questo può creare confusione per alcuni.
3. x86 è una macchina CISC. Per molto tempo questo ha significato che era più lento delle macchine RISC come MIPS o ARM, perché le istruzioni hanno interdipendenza dei dati e flag che rendono difficile implementare la maggior parte delle forme di parallelismo a livello di istruzione. Le implementazioni moderne traducono le istruzioni x86 in istruzioni simili a RISC chiamate " micro-op " sotto le coperte per rendere questo tipo di ottimizzazioni pratiche da implementare nell'hardware.
4. Per alcuni aspetti, x86 non è inferiore, è solo diverso. Ad esempio, l'input / output viene gestito come mappatura della memoria nella stragrande maggioranza delle architetture, ma non in x86. (NB: Le moderne macchine x86 in genere hanno una qualche forma di supporto DMA e comunicano con altro hardware attraverso la mappatura della memoria; ma ISA ha ancora istruzioni I / O come INe OUT)
5. L' ISA x86 ha pochissimi registri architetturali, che possono forzare i programmi a fare il round trip nella memoria più frequentemente di quanto sarebbe altrimenti necessario. Le istruzioni aggiuntive necessarie per eseguire questa operazione richiedono risorse di esecuzione che potrebbero essere spese in un lavoro utile, sebbene in modo efficiente per l'inoltro del negoziomantiene bassa la latenza. Le implementazioni moderne con la ridenominazione dei registri su un file di registro fisico di grandi dimensioni possono mantenere molte istruzioni in volo, ma la mancanza di registri architettonici era ancora una debolezza significativa per x86 a 32 bit. L'aumento di x86-64 da 8 a 16 registri interi e vettoriali è uno dei maggiori fattori nel fatto che il codice a 64 bit è più veloce di 32 bit (insieme alla più efficiente chiamata di registro ABI), non l'aumento della larghezza di ciascun registro. Un ulteriore aumento da 16 a 32 registri interi aiuterebbe alcuni, ma non tanto. (AVX512 aumenta a 32 registri vettoriali, tuttavia, perché il codice a virgola mobile ha una latenza più elevata e spesso richiede più costanti.) ( Vedi commento )

6. Il codice assembly x86 è complicato perché x86 è un'architettura complicata con molte funzionalità. Un elenco di istruzioni per una tipica macchina MIPS si adatta a un singolo foglio di carta formato lettera. L'elenco equivalente per x86 occupa diverse pagine e le istruzioni fanno semplicemente di più, quindi spesso è necessaria una spiegazione più ampia di ciò che fanno di quanto un elenco possa fornire. Ad esempio, l' MOVSBistruzione necessita di un blocco relativamente grande di codice C per descrivere cosa fa:

   if (DF==0) 
     *(byte*)DI++ = *(byte*)SI++; 
   else 
     *(byte*)DI-- = *(byte*)SI--;
   

   Questa è una singola istruzione che esegue un caricamento, una memorizzazione e due addizioni o sottrazioni (controllate da un input flag), ciascuna delle quali sarebbe istruzioni separate su una macchina RISC.

   Anche se la semplicità di MIPS (e architetture simili) non li rende necessariamente superiori, per insegnare un'introduzione alla classe assembler ha senso iniziare con un ISA più semplice . Alcune classi di assembly insegnano un sottoinsieme ultra-semplificato di x86 chiamato y86 , che è semplificato oltre il punto da non essere utile per un uso reale (ad es. Nessuna istruzione di spostamento), o alcune insegnano solo le istruzioni x86 di base.

7. L'x86 utilizza codici operativi a lunghezza variabile, che aggiungono complessità hardware rispetto all'analisi delle istruzioni. Nell'era moderna questo costo sta diventando incredibilmente piccolo poiché le CPU diventano sempre più limitate dalla larghezza di banda della memoria che dal calcolo grezzo, ma molti articoli e atteggiamenti "x86 bashing" provengono da un'era in cui questo costo era relativamente molto più grande.
   Aggiornamento 2016: Anandtech ha pubblicato una discussione sulle dimensioni del codice operativo in x64 e AArch64 .

EDIT: Questo non dovrebbe essere un bash x86! festa. Non avevo altra scelta che fare un po 'di pestaggi visto il modo in cui era formulata la domanda. Ma ad eccezione di (1), tutte queste cose sono state fatte per buone ragioni (vedi commenti). I progettisti Intel non sono stupidi: volevano ottenere alcune cose con la loro architettura, e queste sono alcune delle tasse che hanno dovuto pagare per rendere queste cose una realtà.

Il principale impatto contro x86 nella mia mente sono le sue origini CISC: il set di istruzioni contiene molte interdipendenze implicite. Queste interdipendenze rendono difficile fare cose come il riordino delle istruzioni sul chip, perché gli artefatti e la semantica di queste interdipendenze devono essere preservati per ogni istruzione.

Ad esempio, la maggior parte delle istruzioni di aggiunta e sottrazione di interi x86 modificano il registro dei flag. Dopo aver eseguito un'addizione o una sottrazione, l'operazione successiva è spesso quella di guardare il registro dei flag per verificare la presenza di overflow, bit di segno, ecc. Se c'è un'altra aggiunta dopo, è molto difficile dire se è sicuro iniziare l'esecuzione della seconda aggiunta prima che si conosca il risultato della prima aggiunta.

Su un'architettura RISC, l'istruzione add specifica gli operandi di input e i registri di output e tutto ciò che riguarda l'operazione avverrebbe utilizzando solo quei registri. Questo rende molto più facile disaccoppiare le operazioni di aggiunta vicine l'una all'altra perché non ci sono registri dei flag di bloomin che costringono tutto ad allinearsi ed eseguire un singolo file.

Il chip DEC Alpha AXP, un progetto RISC in stile MIPS, era dolorosamente spartano nelle istruzioni disponibili, ma il set di istruzioni era progettato per evitare le dipendenze implicite dei registri tra le istruzioni. Non esisteva alcun registro dello stack definito dall'hardware. Non c'era alcun registro dei flag definiti dall'hardware. Anche il puntatore dell'istruzione era definito dal sistema operativo: se volevi tornare al chiamante, dovevi capire come il chiamante ti avrebbe fatto sapere a quale indirizzo tornare. Questo di solito era definito dalla convenzione di chiamata del sistema operativo. Su x86, però, è definito dall'hardware del chip.

Ad ogni modo, su 3 o 4 generazioni di progetti di chip Alpha AXP, l'hardware è passato dall'essere un'implementazione letterale del set di istruzioni spartano con 32 registri int e 32 registri float a un motore di esecuzione massicciamente fuori servizio con 80 registri interni, ridenominazione dei registri, inoltro dei risultati (in cui il risultato di un'istruzione precedente viene inoltrato a un'istruzione successiva che dipende dal valore) e tutti i tipi di booster di prestazioni folli e folli. E con tutte quelle campane e fischietti, il die del chip AXP era ancora notevolmente più piccolo del die chip Pentium comparabile di quel tempo, e l'AXP era molto più veloce.

Non si vedono quei tipi di esplosioni di prestazioni che aumentano le cose nell'albero genealogico x86 in gran parte perché la complessità del set di istruzioni x86 rende molti tipi di ottimizzazioni di esecuzione proibitivamente costose se non impossibili. Il colpo di genio di Intel è stato quello di rinunciare all'implementazione del set di istruzioni x86 nell'hardware: tutti i chip x86 moderni sono in realtà core RISC che in una certa misura interpretano le istruzioni x86, traducendole in microcodice interno che conserva tutta la semantica dell'originale x86 istruzioni, ma consente un po 'di quel RISC fuori servizio e altre ottimizzazioni sul microcodice.

Ho scritto molto per l'assembler x86 e posso apprezzare appieno la comodità delle sue radici CISC. Ma non ho apprezzato appieno quanto fosse complicato x86 fino a quando non ho passato un po 'di tempo a scrivere l'assembler Alpha AXP. Sono rimasto sbalordito dalla semplicità e dall'uniformità di AXP. Le differenze sono enormi e profonde.

L'architettura x86 risale al design del microprocessore 8008 e dei suoi parenti. Queste CPU sono state progettate in un'epoca in cui la memoria era lenta e se si poteva farlo sulla CPU morire, spesso era molto più veloce. Tuttavia, anche lo spazio della CPU era costoso. Questi due motivi sono perché ci sono solo un piccolo numero di registri che tendono ad avere scopi speciali e un insieme di istruzioni complicato con tutti i tipi di trucchi e limitazioni.

Anche altri processori della stessa epoca (ad esempio la famiglia 6502) hanno limitazioni e stranezze simili. È interessante notare che sia la serie 8008 che la serie 6502 erano intese come controller integrati. Anche allora, i controller integrati dovevano essere programmati in assembler e in molti modi si rivolgevano al programmatore di assembly piuttosto che a chi scriveva il compilatore. (Guarda il chip VAX per quello che succede quando ti occupi della scrittura del compilatore.) I progettisti non si aspettavano che diventassero piattaforme informatiche generiche; ecco a cosa servivano i predecessori dell'archicture POWER. La rivoluzione dell'Home Computer ha cambiato tutto, ovviamente.

Ho alcuni aspetti aggiuntivi qui:

Considera che l'operazione "a = b / c" x86 lo implementerebbe come

  mov eax,b
  xor edx,edx
  div dword ptr c
  mov a,eax

Come bonus aggiuntivo dell'istruzione div, edx conterrà il resto.

Un processore RISC richiederebbe prima il caricamento degli indirizzi di bec, il caricamento di bec dalla memoria ai registri, la divisione e il caricamento dell'indirizzo di a, quindi la memorizzazione del risultato. Dst, src sintassi:

  mov r5,addr b
  mov r5,[r5]
  mov r6,addr c
  mov r6,[r6]
  div r7,r5,r6
  mov r5,addr a
  mov [r5],r7

Qui di solito non ci sarà un resto.

Se qualsiasi variabile deve essere caricata tramite i puntatori, entrambe le sequenze possono diventare più lunghe sebbene ciò sia una possibilità minore per il RISC perché potrebbe avere uno o più puntatori già caricati in un altro registro. x86 ha meno registri, quindi la probabilità che il puntatore si trovi in ​​uno di essi è minore.

Pro e contro:

Le istruzioni RISC possono essere mescolate con il codice circostante per migliorare la pianificazione delle istruzioni, questa è una possibilità minore con x86 che invece fa questo lavoro (più o meno bene a seconda della sequenza) all'interno della CPU stessa. La sequenza RISC sopra sarà in genere lunga 28 byte (7 istruzioni di larghezza di 32 bit / 4 byte ciascuna) su un'architettura a 32 bit. Ciò farà sì che la memoria off-chip funzioni di più durante il recupero delle istruzioni (sette recuperi). La sequenza x86 più densa contiene meno istruzioni e anche se la loro larghezza varia, probabilmente stai osservando una media di 4 byte / istruzione anche lì. Anche se hai cache di istruzioni per accelerare questo sette recuperi significa che avrai un deficit di tre altrove da compensare rispetto a x86.

L'architettura x86 con meno registri da salvare / ripristinare significa che probabilmente eseguirà interruzioni di thread e gestirà gli interrupt più velocemente di RISC. Più registri da salvare e ripristinare richiedono più spazio temporaneo nello stack RAM per eseguire gli interrupt e più spazio nello stack permanente per memorizzare gli stati del thread. Questi aspetti dovrebbero rendere x86 un candidato migliore per eseguire RTOS puro.

Su una nota più personale trovo più difficile scrivere un assembly RISC rispetto a x86. Lo risolvo scrivendo la routine RISC in C, compilando e modificando il codice generato. Questo è più efficiente dal punto di vista della produzione del codice e probabilmente meno efficiente dal punto di vista dell'esecuzione. Tutti quei 32 registri di cui tenere traccia. Con x86 è il contrario: 6-8 registri con nomi "reali" rendono il problema più gestibile e infonde più fiducia che il codice prodotto funzionerà come previsto.

Brutta? È negli occhi di chi guarda. Preferisco "diverso".

Penso che questa domanda abbia un falso presupposto. Sono principalmente solo accademici ossessionati dai RISC che definiscono brutto x86. In realtà, l'ISA x86 può eseguire in una singola istruzione operazioni che richiederebbero 5-6 istruzioni su ISA RISC. I fan di RISC potrebbero ribattere che le moderne CPU x86 suddividono queste istruzioni "complesse" in microop; però:

1. In molti casi questo è solo parzialmente vero o non è affatto vero. Le istruzioni "complesse" più utili in x86 sono cose come ad mov %eax, 0x1c(%esp,%edi,4)esempio le modalità di indirizzamento, e queste non sono suddivise.
2. Ciò che spesso è più importante sulle macchine moderne non è il numero di cicli spesi (poiché la maggior parte delle attività non sono vincolate alla CPU) ma l'impatto del codice nella cache delle istruzioni. 5-6 istruzioni a dimensione fissa (di solito a 32 bit) avranno un impatto sulla cache molto più di un'istruzione complessa che raramente supera i 5 byte.

x86 ha veramente assorbito tutti gli aspetti positivi di RISC circa 10-15 anni fa, e le restanti qualità di RISC (in realtà quella che definisce - il set di istruzioni minimo) sono dannose e indesiderabili.

A parte il costo e la complessità della produzione di CPU e il loro fabbisogno energetico, x86 è il miglior ISA . Chiunque ti dica il contrario lascia che l'ideologia o l'agenda interferiscano con il loro ragionamento.

D'altra parte, se stai prendendo di mira dispositivi embedded in cui conta il costo della CPU, o dispositivi embedded / mobili in cui il consumo di energia è una delle principali preoccupazioni, ARM o MIPS probabilmente hanno più senso. Tieni presente, tuttavia, che dovrai comunque occuparti della ram aggiuntiva e della dimensione binaria necessaria per gestire codice che è facilmente 3-4 volte più grande e non sarai in grado di avvicinarti alle prestazioni. Se questo è importante dipende molto da ciò che dovrai eseguire.

Il linguaggio assembler x86 non è così male. È quando arrivi al codice macchina che inizia a diventare davvero brutto. Le codifiche delle istruzioni, le modalità di indirizzamento, ecc. Sono molto più complicate di quelle per la maggior parte delle CPU RISC. E c'è un divertimento extra integrato per scopi di compatibilità con le versioni precedenti: cose che si attivano solo quando il processore è in un certo stato.

Nelle modalità a 16 bit, ad esempio, l'indirizzamento può sembrare decisamente bizzarro; c'è una modalità di indirizzamento per [BX+SI], ma non per [AX+BX]. Cose del genere tendono a complicare l'utilizzo del registro, dal momento che è necessario assicurarsi che il proprio valore sia in un registro che è possibile utilizzare quando necessario.

(Fortunatamente, la modalità a 32 bit è molto più sana (anche se a volte è ancora un po 'strana, ad esempio la segmentazione) e il codice x86 a 16 bit è più in gran parte irrilevante al di fuori dei boot loader e di alcuni ambienti embedded.)

Ci sono anche gli avanzi dei vecchi tempi, quando Intel stava cercando di rendere x86 il processore definitivo. Istruzioni lunghe un paio di byte che eseguivano compiti che nessuno in realtà fa più, perché erano francamente troppo lente o complicate. Le istruzioni ENTER e LOOP , per due esempi - notare che il codice dello stack frame C è come "push ebp; mov ebp, esp" e non "enter" per la maggior parte dei compilatori.

Non sono un esperto, ma sembra che molte delle caratteristiche per cui alle persone non piacciono possano essere le ragioni per cui funziona bene. Diversi anni fa, avere registri (invece di uno stack), frame di registro, ecc. Erano visti come buone soluzioni per rendere l'architettura più semplice agli umani. Tuttavia, al giorno d'oggi, ciò che conta sono le prestazioni della cache e le parole di lunghezza variabile di x86 consentono di memorizzare più istruzioni nella cache. La "decodifica delle istruzioni", che credo gli avversari indicarono una volta che occupava metà del chip, non è più così tanto così.

Penso che il parallelismo sia uno dei fattori più importanti al giorno d'oggi, almeno per gli algoritmi che funzionano già abbastanza velocemente da essere utilizzabili. L'espressione di un elevato parallelismo nel software consente all'hardware di ammortizzare (o spesso nascondere completamente) le latenze di memoria. Naturalmente, il futuro dell'architettura più lontano è probabilmente in qualcosa come l'informatica quantistica.

Ho sentito da nVidia che uno degli errori di Intel era che tenevano i formati binari vicini all'hardware. Il PTX di CUDA esegue alcuni calcoli di utilizzo del registro veloce (colorazione del grafico), quindi nVidia può utilizzare una macchina di registrazione invece di una macchina di stack, ma ha ancora un percorso di aggiornamento che non interrompe tutto il vecchio software.

Oltre ai motivi che le persone hanno già menzionato:

• x86-16 aveva uno schema di indirizzamento della memoria piuttosto strano che consentiva di indirizzare una singola posizione di memoria in un massimo di 4096 modi diversi, limitava la RAM a 1 MB e costringeva i programmatori a gestire due diverse dimensioni di puntatori. Fortunatamente, il passaggio a 32 bit ha reso questa caratteristica non necessaria, ma i chip x86 portano ancora la cruft dei registri di segmento.
• Anche se non un difetto di x86 per sé , convenzioni di chiamata x86 non erano standardizzati come MIPS era (soprattutto perché MS-DOS non è venuto con qualsiasi compilatori), lasciandoci con il pasticcio di __cdecl, __stdcall, __fastcall, etc.

Penso che otterrai una parte della risposta se mai proverai a scrivere un compilatore che abbia come target x86, o se scrivi un emulatore di macchina x86, o anche se provi a implementare l'ISA in un progetto hardware.

Anche se capisco che "x86 è brutto!" argomenti, penso ancora che sia più divertente scrivere assembly x86 rispetto a MIPS (ad esempio) - quest'ultimo è semplicemente noioso. È sempre stato pensato per essere gentile con i compilatori piuttosto che con gli umani. Non sono sicuro che un chip potrebbe essere più ostile agli scrittori di compilatori se provasse ...

La parte più brutta per me è il modo in cui funziona la segmentazione (in modalità reale): qualsiasi indirizzo fisico ha 4096 segmenti: alias offset. Quando ne hai avuto bisogno l' ultima volta ? Le cose sarebbero state molto più semplici se la parte del segmento fosse strettamente bit di ordine superiore di un indirizzo a 32 bit.

1. x86 ha un insieme molto, molto limitato di registri per scopi generali

2. promuove uno stile di sviluppo molto inefficiente al livello più basso (inferno CISC) invece di una metodologia di caricamento / immagazzinamento efficiente

3. Intel ha preso la decisione orribile di introdurre il modello di indirizzamento della memoria chiaramente stupido di segmento / offset per rimanere compatibile con (in questo momento già!) Tecnologia obsoleta

4. In un momento in cui tutti andavano a 32 bit, l'x86 ha frenato il mondo dei PC mainstream essendo un misero 16 bit (la maggior parte di loro - l'8088 - anche solo con percorsi dati esterni a 8 bit, il che è ancora più spaventoso!) CPU

Per me (e sono un veterano del DOS che ha visto ogni generazione di PC dal punto di vista degli sviluppatori!) Il punto 3. era il peggiore.

Immagina la seguente situazione che abbiamo avuto all'inizio degli anni '90 (mainstream!):

a) Un sistema operativo che aveva limitazioni folli per motivi legacy (640kB di RAM facilmente accessibile) - DOS

b) Un'estensione del sistema operativo (Windows) che poteva fare di più in termini di RAM, ma era limitata quando si trattava di cose come giochi, ecc ... e non era la cosa più stabile sulla Terra (fortunatamente questo è cambiato in seguito, ma io sto parlando dei primi anni '90 qui)

c) La maggior parte del software era ancora DOS e dovevamo creare dischi di avvio spesso per software speciale, perché c'era questo EMM386.exe che alcuni programmi piacevano, altri odiavano (specialmente i giocatori - e io ero un giocatore AVID in questo momento - sai cosa ho sto parlando di qui)

d) Eravamo limitati a MCGA 320x200x8 bit (ok, c'era un po 'di più con trucchi speciali, 360x480x8 era possibile, ma solo senza il supporto della libreria runtime), tutto il resto era disordinato e orribile ("VESA" - lol)

e) Ma in termini di hardware avevamo macchine a 32 bit con pochi megabyte di RAM e schede VGA con supporto fino a 1024x768

Perché questa brutta situazione?

Una semplice decisione di progettazione da parte di Intel. Livello di istruzione macchina (NON livello binario!) Compatibilità con qualcosa che stava già morendo, credo fosse l'8085. Gli altri problemi apparentemente non correlati (modalità grafiche, ecc ...) erano legati per motivi tecnici e per via del architettura di mentalità che la piattaforma x86 ha portato con sé.

Oggi la situazione è diversa, ma chiedi a qualsiasi sviluppatore dell'assemblatore o alle persone che creano backend del compilatore per x86. Il numero follemente basso di registri di uso generale non è altro che un orribile killer delle prestazioni.