di  -  giovedì 19 luglio 2012

Sentiamo spesso ripetere che l’architettura x86 sia un pastrocchio e che si porti dietro una pesante eredità dal primogenito, l’8086 di cui abbiamo già discusso in un vecchio articolo che ha evidenziato alcune bizzarrie.

Legacy è il termine che viene generalmente utilizzato per definire l’insieme di queste caratteristiche vecchie e “contorte”, che nell’immaginario collettivo rappresentano delle catene che bloccano o castrano i processori che implementano quest’architettura, e persino la sua più giovane evoluzione, l’x64 di AMD (nota anche come x86-64, AMD64, o l’EM64T coniato da Intel, infine divenuto Intel 64) a 64 bit.

Parlare genericamente di limitazioni senza comprendere di quali elementi si tratti e delle implicazioni che ne derivano, non giova però a molto, se non ad alimentare le classiche leggende metropolitane o a far pesare un fardello magari molto più del dovuto.

Partendo proprio da quello che, per molti, rappresenta l’origine di tutti i mali, l’8086, possiamo delineare tre grosse categorie in cui inquadrare tutto ciò che classifichiamo come legacy: la mappatura degli opcode delle istruzioni, le istruzioni più complesse e raramente utilizzate (in cui potrebbe rientrarci anche l’FPU x87, di cui discuteremo appositamente), e i famigerati segmenti.

Il primo rappresenta, a mio modesto avviso, il principale responsabile della complessità di quest’architettura e che, dunque, ha creato più problemi a Intel, AMD, e in generale a chi si sia posto il problema di realizzare un’implementazione che risultasse non soltanto veloce, ma anche parca nei consumi e, magari, poco costosa (in termini di silicio impiegato).

In realtà è molto difficile poter conciliare tutti i desiderata, e l’ultimo in particolar modo, poiché per raggiungere elevati livelli prestazionali si è fatto ampio uso di transistor. Ne abbiamo già parlato in passato in due articoli, che trovate qui e qui, in cui vengono analizzate tutte queste problematiche e affrontato, quindi, il primo degli aspetti legacy di x86 e x64.

Le istruzioni più “contorte” alla fine non sono poi molte, e possiamo facilmente elencarle: IN, OUT, CBW, CWD, LAHF, SAHF, AAA, AAD, AAM, AAS, DAA, DAS, XLAT, INT, INT3, INTO, IRET.

Si occupano di gestire l’I/O (ma da parecchio si preferisce mappare le relative “porte” direttamente in memoria), estendere un valore da byte a word (16 bit) o da word a double word (32 bit), leggere e scrivere il byte dei flag, eseguire operazioni con valori BCD (obsoleto è il termine più appropriato), convertire un byte in un altro byte facendo uso di un’apposita tabella, e infine di richiamare (e ritornare da) un interrupt (da tempo sono state introdotte apposite coppie di istruzioni per richiamare velocemente API del sistema operativo).

Non molte, come dicevo, ma che creano problemi a un processore che ha bisogno di eseguire velocemente le istruzioni nella sua pipeline. La decodifica non è complicata, trattandosi di istruzioni di un solo byte (due in pochissimi casi; comunque il secondo byte è costituito sempre da un valore immediato), ma l’esecuzione richiede l’uso di microcodice, anche se non per tutti i casi.

Trattandosi di roba estremamente vecchia, è ormai inutilizzata o usata molto raramente, quindi si può sostanzialmente ignorare la loro esistenza, ma chi progetta un processore x86 o x64 non può certo farlo. Non mi occupo di microarchitetture, per cui non posso valutare l’impatto che possono avere a livello implementativo (anche perché le implementazioni possono essere diverse), ma francamente non credo che possano rappresentare un enorme collo di bottiglia che tarpi le ali alle prestazioni e/o ai consumi del processore.

Avendo sviluppato emulatori in passato, mi sento in dovere di spezzare una (piccola) lancia in favore delle istruzioni LAHF e SAHF, poiché poter accedere velocemente ai flag del processore risulta un’operazione di vitale importanza per le prestazioni generali dell’emulazione.

Purtroppo queste istruzioni presentano due pecche; la prima è che non si tratta di un’istruzione generale, in quanto fa uso del solo registro AH allo scopo, che tra l’altro è uno dei registri high (soltanto con quattro degli 8 registri a 16 bit di 8086 è possibile accedere al loro byte alto) che rappresentano il più grosso elemento di asimmetria / non ortogonalità dell’ISA 8086, dopo l’uso speciale dell’accumulatore.

La seconda, che poi è anche la pecca più grossa, è che non consentono di accedere a un flag particolarmente importante, quello di overflow, che i progettisti dell’8086 hanno pensato bene di inserire nel dodicesimo bit (l’11) del registro dei flag (EFLAGS), tagliandolo completamente fuori dalle istruzioni LAHF e SAHF, che operano esclusivamente col byte basso e, quindi, coi primi 8 bit (i più bassi).

Il risultato di questa scelta (che personalmente trovo assolutamente insensata; in genere i flag “aritmetici” di un processore sono raggruppati / vicini) è che per accedere a tutti i flag utili si deve far ricorso alla classica coppia di istruzioni PUSHF e POP Registro, che consentono di recuperare l’intero contenuto del registro dei flag, per poi mascherare i bit inutili e infine estrarre quelli che servono. No comment…

I più attenti si saranno accorti che all’appello mancano le cosiddette istruzioni di stringa (LODS, STOS, MOVS, CMPS, SCAS), quelle di loop (LOOP, LOOPNE/Z, LOOPE/Z) e l’unica di salto se il registro CX è zero (JCXZ). Si tratta di istruzioni più o meno complesse, ma la cui valutazione è abbastanza controversa.

Posto che le istruzioni di stringa nelle loro incarnazioni con ripetizione (facendo uso dei prefissi REPNE/Z e REPE/Z) complicano il decoder del processore, come analizzato in uno dei due già citati articoli, alcune di queste rimangono oggettivamente utili. Mi riferisco, in particolare, alle istruzioni MOVS e STOS, che permettono rispettivamente di spostare (copiare, in realtà) un blocco di memoria, e di riempirlo con un determinato valore.

Da programmatore assembly di vecchia data le ho usate non poche volte, ma con l’introduzione del Pentium il loro uso è stato deprecato in quanto, trattandosi di istruzioni molto complesse (mi riferisco sempre all’incarnazione dotata di ripetizione), la loro esecuzione creava parecchi problemi alla pipeline, che sostanzialmente rimaneva bloccata eseguendo microcodice.

Infatti al loro posto Intel ha suggerito di convertirle nelle equivalenti istruzioni x86 più semplici che assolvono allo stesso compito, ma che sono molto più facilmente “digeribili” dalla pipeline del processore.

In realtà, e come vedremo in un futuro articolo, queste istruzioni non sono mai scomparse del tutto e, anzi, si ritrovano persino all’interno di codice a 64 bit, quindi compilato per x64, che riserva anche altre sorprese.

Tornando a queste istruzioni, l’interesse nei loro confronti è ritornato negli ultimi tempi, per due motivazioni sostanzialmente. La prima è ovvia: queste istruzioni sono ancora utilizzate e, trattandosi di operazioni con ripetizione, vengono eseguite “internamente” (lasciatemi semplificare il discorso) molte volte.

La seconda è che, pur non essendo molto generali (si deve far ricorso a specifici registri per impostare puntatori, valore, e contatore), in ogni caso eseguono dei compiti molto utili e molto comuni nell’ambito della programmazione. Copiare memoria e riempirla con un certo valore (in particolare lo zero) non credo che abbiano bisogno di presentazioni: sono compiti arcinoti per un programmatore.

Dunque si è posta molta più attenzione nel cercare di velocizzarne il più possibile l’esecuzione, com’è giusto che sia. Alla fine se la pipeline del processore risulta sostanzialmente bloccata, ma in quel preciso momento si sta copiando o riempendo memoria molto più velocemente di qualunque sequenza di istruzioni equivalenti (e magari bloccando quasi completamente le altre unità funzionali e, quindi, risparmiando corrente)… why not? Tra l’altro quest’approccio permette ottimizzazioni impossibili o molto difficilmente ottenibili altrimenti.

Un discorso analogo si può fare per le istruzioni LOOP, che consentono di decrementare un contatore, controllando eventualmente anche il flag Z (di zero) del processore, e saltando se la condizione (o le condizioni, nel caso dell’uso del flag Z) risulta soddisfatta, permettono alcune ottimizzazioni (nessuna modifica del registro dei flag, ad esempio, per l’operazione di decremento) oltre a una maggior compattezza del codice.

L’unica pecca è data dalla loro non generalità, poiché per il contatore fanno uso del solo registro CX, e in questo il giudizio è comune a quello dell’istruzione JCXZ, che opera sempre e solo su CX.

Il tempo, insomma, ha un po’ ribaltato il lapidario giudizio di obsolescenza riguardo ad alcune istruzioni che in passato sono sempre state tacciate di essere un grosso peso che l’architettura x86 si trascina da tempo. Sebbene pecchino di generalità, alcune rimangono ancora utili e utilizzate, come abbiamo visto e come approfondiremo in futuro.

Nel prossimo articolo verrà analizzata l’eredità, in termini di istruzioni legacy, dei successori dell’8086, a cui seguirà un altro pezzo sull’FPU x87, e un altro sui segmenti (che si sono trasformati in selettori nelle evoluzioni più complesse, ma anche più interessanti, di questa famiglia), che dovrebbe idealmente chiudere questo ciclo… per poi aprirne un altro.

43 Commenti »

I commenti inseriti dai lettori di AppuntiDigitali non sono oggetto di moderazione preventiva, ma solo di eventuale filtro antispam. Qualora si ravvisi un contenuto non consono (offensivo o diffamatorio) si prega di contattare l'amministrazione di Appunti Digitali all'indirizzo info@appuntidigitali.it, specificando quale sia il commento in oggetto.

  • # 1
    Giorgio Dabemo
     scrive: 

    L’eredità x86 non è un problema di programmazione ma di hardware.
    Non è solo che i programmatori oggigiorno di assemblee ne vedono ben poco, è il fatto che ormai l’ottimizzazione in hardware delle istruzioni x86 e l’ottimizzazione software del backend dei compilatori ha raggiunto livelli tali da non comportare penalizzazione rilevanti in esecuzione.
    Il problema oggi è che il supporto in hardware delle complesse istruzioni x86 comporta un eccessivo consumo dei processori. Questo non ha nessuna importanza nei computer desktop ma è invece cruciale nel mobile.
    Nel vendere i processori oggi conta più la potenza dissipata che la potenza di calcolo e nel mercato mobile intel è praticamente assente non per un problema di prestazioni ma di consumo di energia elettrica troppo alto dovuto al supporto di istruzioni pensate con necessità troppo diverse dalle attuali.

  • # 2
    [D]
     scrive: 

    Idea banale. Non sarebbe più logico prendere tutta sta roba vecchia, isolarla nel processore in una zona a parte, addirittura un core se non un chip esterno sulla scheda madre e lasciare che il tempo ed il mercato facciano il loro corso eliminandola fisicamente ?
    Chiaro che fin quando saranno incluse nella cpu, per la legge di murphy ci sarà sempre qualche genio (umano o informatico) che troverà furbo utilizzare della roba legacy.

  • # 3
    Alex
     scrive: 

    Invece per quanto riguarda la gestione della memoria? I segmenti di memoria vengono ancora usati? Da programmatore 68000 ricordo che quando passai all’8086 la gestione della memoria mi sembrava assurda ed inutilmente complessa.

  • # 4
    Cesare Di Mauro (Autore del post)
     scrive: 

    @Alex: ne parlerò nell’ultimo articolo dei quattro previsti. ;)

    @Giorgio: sui consumi, che sono legati alla complessità / organizzazione dell’ISA, ne ho già parlato nei due articoli che ho citato all’inizio.

    Comunque i compilatori non possono fare miracoli, e al momento la tendenza è quella di cercare di autovettorizzare il codice per sfruttare unità SIMD.

    Di assembly, sono d’accordo con te, se ne vede veramente pochissimo ormai. Però se certe istruzioni legacy me le ritrovo persino un eseguibile x64, la cosa mi lascia pensare…

    @[D]: se parliamo di architettura x86 o x64, non puoi rimuovere alcunché e i programmatori sono autorizzati a utilizzare quello che vogliono. Altrimenti staremmo parlando di un’altra architettura.

    Io, produttore di processori x86 o x64, posso, però, dirti che se usi quel vecchiume non ti garantisco una velocità d’esecuzione comparabile con tutto il resto. E tu, cliente, puoi anche dirmi: tieniti il tuo processore; mi rivolgo ad ARM, che mi offre un emulatore x86 che su queste cose è più veloce.

    Questo soltanto per farti capire che la questione non è affatto semplice, e la situazione attuale è frutto di compromessi.

    Comunque attualmente una parte del legacy la trovi già relegata in un angolino: il microcodice. Altra roba non si può togliere (decoder) o comunque non è così invasiva (segmenti).

  • # 5
    homero
     scrive: 

    ci hanno provato Itanium ma con scarsi risultati prestazionali per quanto riguarda il codice x86, infatti credo che alla fine lo abbiano tolto del tutto……

    credo che 2 siano le rivoluzioni di questo decennio la prima è la calvacata inesorabile dell’architettura arm….
    la seconda è la strutturazione di un micro kernel OS QNX style…

  • # 6
    massimo
     scrive: 

    Le singole istruzioni alla fine non sono un problema così grosso: quelle meno usate non si ottimizzano e amen. il VERO problema è il modo in cui sono codificate: la lunghezza di una istruzione x86 varia da 1 solo byte fino a 9-10, contando i quattro prefissi di segmento… che poi possono arrivare in qualunque ordine! E poi c’è il byte r/m facoltativo ecc.

    Io ho lavorato un pò al disassembler di NASM, anni fa, e ti assicuro che la decodifica è un vero casino. Rabbrividisco a pensare di farla in hardware… ma credo che di questo ne parlerà Cesare nei prossimi articoli :-)

  • # 7
    massimo
     scrive: 

    @homero:
    i microkernel sono lenti. QNX è un SO per sistemi embedded, e quindi semplice. I SO microkernel di classe enterprise, tipo Windows per intenderci, sono stati sviluppati ma hanno mostrato prestazioni decisamente scarse… il microkernel è piccolo e semplice, OK, ma per compensazione è il sistema nel suo insieme a diventare ancora più complesso.

  • # 8
    Cesare Di Mauro (Autore del post)
     scrive: 

    Hai centrato la questione Massimo: il problema principe di x86 e x64 è rappresentato dalla codifica delle istruzioni. Infatti decodificarle è un compito estremamente oneroso, come ho anche scritto negli altri due pezzi.

    Penso comunque di ritornare sull’argomento, anche perché ho trovato non pochi esempi di istruzioni lunghe ben 15 byte. O:-)

    P.S. I prefissi di segmento sono 6. Ma poi ci sono gli altri prefissi ad “allietare” la de/codifica :P

    @homero: sì, dalla seconda versione di Itanium l’emulazione hardware x86 dovrebbe essere stata rimossa, e sostituita da una software che… sembra andare molto più veloce.

    Comunque ARM è una bella architettura, ma fra i RISC penso sia fra le più complesse.

  • # 9
    massimo
     scrive: 

    E ti credo: ci hanno messo dentro Thumb, Jazelle, le accelerazioni per emulare gli x86, di tutto… ARM ha avuto successo perché ha saputo tagliare e cucire i suoi processori su misura di chi glieli chiedeva, come un abito di sartoria. Ma questo ha avuto un prezzo. Gli si è imbastardito il processore :-D

    Dopotutto è la stessa storia di Intel 30 anni fa: anche lei fece l’8086 su misura di quelli che glielo chiedevano ed ebbe un gran successo proprio per questo.

    Leggo che nell’articolo su 8086 ti chiedevi perché mai Intel decise di sommare segmenti e offset invece di metterli in fila come parte alta e parte bassa, buttando via gli ultimi bit: ti posso dire che pesò l’esperienza di IBM con i sistemi 360 (poi divenuti Sistema36 e poi AS400): quelli avevano dei registri indirizzo a 32 bit di cui però usavano solo gli ultimi 24, perché l’architettura prevedeva al massimo 16MB.
    Così i programmatori di allora sui 360 cominciarono a usare gli 8 bit alti per metterci dati, invece di doverli leggere da RAM. Questo causò guai a non finire qualche anno dopo, quando l’architettura venne espansa e i 32 bit dei registri indirizzo furono usati tutti: una marea di software esistente divenne di colpo incompatibile con le nuove macchine :-D

  • # 10
    Davide Costantini
     scrive: 

    I tuoi post sulle ISA e il loro impatto sullo sviluppo e le prestazioni sono sempre molto interessanti.

    Seguo con attenzione.

  • # 11
    iva
     scrive: 

    Visto che lavoro in assembly costantemente
    quest’articolo e’ molto interessante per me, aspetto gli altri Cesare!

    Una nota: adesso per Intel l’architettura a 64 bit si chiama ufficialmente “Intel 64″ (dopo essere passati per IA-32e e EM64T che sono ora deprecati).

  • # 12
    Giacomo
     scrive: 

    Ribaltando la questione: supponendo di creare oggi un processore x86 che getti alle ortiche tutte le istruzioni precedenti al Pentium, si noterebbe una differenza prestazionale o di consumi?

  • # 13
    Riccardo
     scrive: 

    @massimo

    ARM comunque è una azienda completamente fabless…ergo progetta i suoi processori non dà il prodotto completo e finito come fa Intel. Pertanto i vari “imbastardimenti” sono inseribili a richiesta e poi i vari produttori fabbricano la CPU.

  • # 14
    Cesare Di Mauro (Autore del post)
     scrive: 

    Esatto. Ma anche Intel e AMD hanno le loro colpe. Ne riparleremo…

    @massimo: sì, ARM ha introdotto tante cose (ho scritto tanti articoli su ARM, e proprio sulle cose che hai citato), ma anche Intel e AMD si sono date da fare. Forse sarebbe il caso di parlarne in un apposito articolo.

    Riguardo ai segmenti di 8086, non è quello a cui mi riferivo con quegli esempi. La mia idea è che Intel avrebbe dovuto/potuto utilizzare quella che in altri processori a 8/16 bit viene chiamata banking per mappare altra memoria usando puntatori a 16 bit.

    L’esempio che hai fatto riguardo agli IBM 360 è esattamente lo stesso che hanno fatto i programmatori Amiga col 68000: usare gli 8 bit alti dei puntatori a 32 bit, sfruttando il fatto che il bus indirizzi esterno di questo processore era a 24 bit.

    Un eminente esempio fu l’AmigaBASIC di Microsoft… O:-)

    @iva: sei uno dei pochi che la fortuna o la sfortuna (dipende dai gusti e dai punti di vista :P) di lavorare in assembly, ma questo è un periodo in cui posso condividere la tua esperienza. :)

    Ricordavo EM64T perché è il nome che ho trovato negli splendidi manuali che Intel mi ha spedito qualche anno fa, e non credevo che lo avesse poi cambiato nuovamente. Aggiorno l’articolo…

    @Giacomo: La risposta è no, sostanzialmente per quanto avevo già scritto nell’articolo.

    La motivazione è la stessa per entrambe le cose. Le prestazioni non vengono intaccate perché nella pipeline non finiranno mai quelle istruzioni complesse, perché… non sono a disposizione. Idem per i consumi.

    Il tallone d’Achille di x86 e x64 rimane la mappatura “contorta” degli opcode delle istruzioni. Si tratta di una scelta che era senza dubbio felice e, non mi vergogno a dirlo, molto intelligente quando 8086 è stato concepito, ma che col tempo s’è scontrata con le esigenze di scalabilità delle prestazioni.

    Tutto ciò intacca i consumi e anche le prestazioni (pipeline più lunghe, unità di branch prediction più complesse).

    Col senno di poi si sarebbe fatto molto meglio. Ma nessuno, e mi metto in prima fila, ha una sfera di cristallo per vedere cosa sarebbe successo. Per cui, sì, gli opcode OGGI possiamo dire che sono stati progettati da schifo, ma non mi sento di infilare il dito nella piaga, perché sarebbe intellettualmente disonesto (ed è un errore che ho commesso tante volte anch’io, causa scarsa conoscenza e mancanza di contestualizzazione dei fatti).

  • # 15
    Giorgio Dabemo
     scrive: 

    @Cesare
    x86 non era un gran progetto, c’era di meglio nella concorrenza, come estetica del progetto potremmo dire (modi di indirizzamento, istruzioni etc..)
    Come sempre non vince il migliore, quindi nessuno stupore.
    Il brutto è stato quello di avere voluto a tutti i costi mantenere una compatibilità con il passato che ha imbastardito i processori moderni Intel 64 fino a renderli non competitivi nel settore ora più redditizio del mobile.
    La scelta miope è stata quella di non ringiovanire l’architettura. Intel e microsoft forti del predominio assoluto hanno voluto navigare sul sicuro e mantenere la scomodissima compatibilità x86 senza preoccuparsi, tanto erano in regime di monopolio e programmavano di restarci.
    Si sono limitati a cercare di ottimizzare sempre di più una architettura obsoleta, con risultati anche notevoli, senza però poter fare il salto di qualità di un moderno processore con istruzioni pensate anche per il contenimento dei consumi, come quelle ARM.
    Lo sviluppo del mobile, la necessità di prestazioni energetiche efficienti hanno sconvolto i loro piani e ora intel si ritrova con una compatibilità scomoda che non può eliminare e con una concorrente ARM che domina dove la crescita ed i guadagni sono maggiori.
    La soluzione, sviluppare un nuovo processore moderno e orientato al contenimento dei consumi non è affatto semplice. Il costo di sviluppo è mostruoso, il tempo per avere una soluzione affidabile e ottimizzata è lunghissimo, microsoft poi dovrebbe fornire il nuovo s.o. e il jit per la compatibilità e ora come ora ha altro per la testa, insomma vedremo x86 ancora per molto tempo.

  • # 16
    Crick
     scrive: 

    Mamma che ricordi…uno dei più grossi difetti secondo me (rimasto immutato fino all’era x64) era l’eccessiva scarsità di registri e di ortogonalità degli stessi. I loro nomi infatti erano quando più specifico poteva essere: Accumulator (AX), Base, Counter, Data, Source Idx (SI), Dest Idx, Base Pointer, ecc… e molte istruzioni erano “lockate” su determinati registri e toccava sempre impazzirsi a rimodulare il codice o a fare tonnellate di push/pop (o peggio di pusha/popa)! Concordo su tutto quanto detto e ricordo quando aprivo il debugger certi opcode andavano a capo!
    L’architettura EPIC dell’Itanium risolveva molti di questi problemi di design di base ma sappiamo com’è andata…

  • # 17
    Cesare Di Mauro (Autore del post)
     scrive: 

    Forse li risolveva nella maniera sbagliata… O:-)

    Sul resto, nulla da dire. x64 ha, in parte, migliorato l’ortogonalità dell’ISA, ma rimangono evidenti punti di disomogeneità.

    @Giorgio: rispondo per punti, vista la varietà di argomenti trattati.

    @Cesare
    x86 non era un gran progetto, c’era di meglio nella concorrenza, come estetica del progetto potremmo dire (modi di indirizzamento, istruzioni etc..)

    La progettazione dell’8086 è iniziata nel 1976: quali altri microprocessori esistevano con un’ISA migliore e che potessero anche vantare una compatibilità (a livello di sorgente, non binaria) con 8008, 8080 e 8085? Quest’ultimo era un fattore chiave, poiché sui processori elencati girava il CP/M.

    Come sempre non vince il migliore, quindi nessuno stupore.

    Capita, purtroppo, ma nello specifico sarebbe interessante andare a vedere cosa offrisse di meglio il mercato…

    Il brutto è stato quello di avere voluto a tutti i costi mantenere una compatibilità con il passato che ha imbastardito i processori moderni Intel 64 fino a renderli non competitivi nel settore ora più redditizio del mobile.
    La scelta miope è stata quella di non ringiovanire l’architettura. Intel e microsoft forti del predominio assoluto hanno voluto navigare sul sicuro e mantenere la scomodissima compatibilità x86 senza preoccuparsi, tanto erano in regime di monopolio e programmavano di restarci.

    In realtà l’architettura è ringiovanita, poiché ha subito parecchie, anche pesanti, modifiche. 80286, 80386 e AMD64 rappresentano degli autentici punti di svolta.

    Purtroppo è rimasta la struttura degli opcode che ben conosciamo, che ha richiesto ingenti risorse e lo sviluppo di idee vincenti per migliorare le prestazioni.

    Questo, comunque, riguarda soltanto la microarchitettura, cioè l’implementazione dell’ISA x86.

    Si sono limitati a cercare di ottimizzare sempre di più una architettura obsoleta, con risultati anche notevoli, senza però poter fare il salto di qualità di un moderno processore con istruzioni pensate anche per il contenimento dei consumi, come quelle ARM.

    Non mi risulta che le istruzioni degli ARM siano state pensate appositamente per contenere i consumi. Hai informazioni in merito?

    Lo sviluppo del mobile, la necessità di prestazioni energetiche efficienti hanno sconvolto i loro piani e ora intel si ritrova con una compatibilità scomoda che non può eliminare e con una concorrente ARM che domina dove la crescita ed i guadagni sono maggiori.

    Si tratta di un’eredità scomoda per tutti i player che si sono affidati ai CISC. Motorola con la sua meravigliosa famiglia 68000 non era messa meglio di Intel, a causa di alcune scelte particolarmente nefaste.

    ARM ha un vantaggio non trascurabile: è un RISC, per cui la decodifica delle sue istruzioni è (generalmente) molto semplice. Per contro, non ha prestazioni paragonabili a x86.

    Non si può avere tutto dalla vita…

    La soluzione, sviluppare un nuovo processore moderno e orientato al contenimento dei consumi non è affatto semplice. Il costo di sviluppo è mostruoso, il tempo per avere una soluzione affidabile e ottimizzata è lunghissimo,

    Non sono assolutamente d’accordo.

    microsoft poi dovrebbe fornire il nuovo s.o. e il jit per la compatibilità

    Non sarebbe difficile.

    e ora come ora ha altro per la testa

    Vero, e infatti s’è dovuta piegare anche lei ad ARM.

    insomma vedremo x86 ancora per molto tempo.

    E’ possibile, ma nella vita ci può aspettare di tutto.

    AMD ha innovato con x64, rompendo la compatibilità binaria (e non solo) con x86.

    ARM innoverà con ARM64, rompendo la compatibilità binaria con ARM & Thumb.

    Chissà cos’altro potrebbe riservare il futuro per x86 e, soprattutto, x64 (visto che il futuro è rappresentato dai sistemi a 64 bit).

  • # 18
    sergio
     scrive: 

    grazie per l’interessante discussione

  • # 19
    Davide Costantini
     scrive: 

    @giorgio @cesare, personalmente ho l’impressione che ci sia una certa ultra-valutazione dell’ISA rispetto alle altre componenti della CPU.

    Il buon Jon Stokes di Ars Technica mi pare abbia scritto molti anni or sono un lunghissimo editoriale sul perché l’ISA non nasce per ottimizzare i consumi e le prestazioni ma per far girare il software. Smentitemi pure se sbaglio, non sono un ingegnere ne uno sviluppatore.

    Per cui si spendono tante parole (che leggo con grande interesse) sulla x86 tax ma poi all’atto pratico i processori Intel le danno in testa più o meno a tutti, comparto GPU a parte. E questo lo so perché sono stato recensore a lungo e anche Medfield si dimostra quantomeno competitivo nel comparto CPU rispetto ad uno Snapdragon S4. E usa un processo produttivo (32nm) non cutting edge, almeno per Intel.

    Quindi mi sembra pacifico affermare che l’azienda ha puntato a migliorare i propri prodotti mantenendo la compatibilità legacy un obiettivo fondamentale. Questo ha sicuramente portato a compromessi e da adito a queste discussioni. Ma all’atto pratico (da economista quale sono), se l’anno prossimo la casa facesse uscire un Atom 22nm trigate per smartphone che pialla ogni ARM in commercio, a chi fregherebbe di x86?

    E oggi, siamo davvero sicuri che x86 sia un limite così pesanti dati i vantaggi competitivi che Intel ha in altre aree? Probabilmente AMD non potrà mai fare quello che ci fa la casa di Santa Clara, problemi suoi, ma per Intel la strategia sembra coerente.

    Magari un giorno x86 diventerà un peso insormontabile, potranno sempre comprare una licenza ARM e sviluppare in proprio i processori come fa Qualcomm.

  • # 20
    Davide Costantini
     scrive: 

    Ah chiaramente il fatto che l’ISA non nasca principalmente per motivi prestazionali non vuol dire che non vengano presi in considerazione.

  • # 21
    iva
     scrive: 

    Mi ritengo fortunato, piu’ posso andare “low level” e piu’ mi piace :)

    Anche perche’, soprattutto per le nuove istruzioni/estensioni, se vuoi vedere cosa succede veramente devi andare a leggere e interpretare l’assembly (quando c’e’, senno’ devi interpreatare/editare gli opcode a mano in memoria…)

    Per chi e’ interessato agli opcodes questo pdf e’ fatto molto bene:
    http://net.cs.uni-bonn.de/fileadmin/user_upload/plohmann/x86_opcode_structure_and_instruction_overview.pdf

  • # 22
    Cesare Di Mauro (Autore del post)
     scrive: 

    @Davide Costantini: è vero ciò che dici, ma aggiungiamo pure che Intel sfrutta il nodo litografico che ha di vantaggio rispetto alla concorrenza. E’ sempre almeno un anno avanti a tutti. Poi gli altri arrivano ugualmente, ma nel frattempo ha avuto modo di affinare ulteriormente il processo, e si sta già preparando a passare al successivo. E’ un aspetto che non si può certo trascurare quando parliamo di consumi (ma non dimentichiamoci anche dei costi).

    Jon Stokes ha ragione quando afferma che un’ISA non nasce per ottimizzare i consumi. Ma è senz’altro vero che, a seconda degli obiettivi che ci si è prefissi, l’organizzazione di un’ISA può benissimo incidere sui consumi (come pure sui costi e le prestazioni). Su questo ho scritto un apposito articolo, il primo dei due link che ho inserito all’inizio.

    Non si può, insomma, ignorare il fatto che l’organizzazione pseudo-casuale degli opcode x86, unita alla loro intrinseca struttura interna, richieda decoder enormemente più complessi e molto più affamati di corrente rispetto ad ARM & compagnia bella. Questo è un costo fisso che si porta dietro quest’architettura (che incide anche sulle prestazioni: servono pipeline più lunghe soltanto per la fase di decodifica).

    Poi io non metto in dubbio che contino anche altre variabili, e si possano ricercare altre soluzioni che mitighino questa piaga.

    Ad esempio Intel ha affermato che col prossimo core Haswell mediamente l’80% del tempo i decoder saranno inutilizzati (non credo spenti; comunque non è materia mia e non so di preciso cos’abbiano intenzione di fare). Rimarrebbe il 20% sul quale, però, si continuerà a pagare la “tassa x86″…

    Sul resto concordo. Alla fine contano i risultati, e Intel, pur con tutte queste elucubrazioni, sta tirando fuori prodotti che finalmente (questo bisogna sottolinearlo: prima non era così) sono competitivi con ARM anche sul fronte dei consumi.

    Certo, si potrebbe fare di più. La compatibilità binaria con x86 è un grosso impedimento, ma, come dicevo prima, AMD con x64 ha dimostrato che si può anche osare e cambiare l’ISA. Infatti x64 non è affatto compatibile con x86.

    E se ha avuto la forza lei, non vedo perché non si potrebbe fare ancora una volta. Non è necessario essere Intel per portare al successo idee radicali e vincenti. O:-)

    @iva: io sono combattuto fra il bass(issim)o e l’alto livello. :P

    Diciamo che normalmente lavoro con quest’ultimo, ma per le mie ricerche scendo a un livello molto basso (anche se i tool che mi servivano li ho sviluppati tutti in Python; altrimenti avrei impiegato una vita per toccare i primi risultati). Questa serie di articoli ne è una (molto) parziale dimostrazione.

    D’altra parte, come dici tu, certe cose difficilmente si capiscono se non si fa così. Però anche con l’assembly arrivi a un certo punto; per capire certi aspetti e le relative implicazioni bisogna scendere al livello macchina.

    Il link che hai postato è buono come overview generale. L’ho trovato tempo fa ed è comodo per avere una visione globale molto velocemente. Lo consiglio per chi vuole cominciare ad addentrarsi sull’argomento opcode table.

    Per chi vuol approfondire di più consiglio questo: http://ref.x86asm.net/geek64.html che è un’ottima e precisa reference. Lo uso, in particolare, quando dal binario (la sequenza di byte in esadecimale di un’istruzione) devo risalire velocemente all’istruzione e/o per analizzare alcune informazioni di massima.

    Per chi non s’accontenta :D è meglio aprire il manualazzo di Intel: “Intel® 64 and IA-32 Architectures Software Developer’s Manual – Combined Volumes: 1, 2A, 2B, 2C, 3A, 3B and 3C”. Sono circa 16MB per 4mila pagine, ma c’è tutto. Al limite è possibile scaricare i singoli volumi.

    Le mie ricerche le ho basate principalmente su questi e sui relativi manuali di AMD, che sono fatti bene anch’essi.

    Per chi vuol andare oltre c’è anche il nuovo manuale di Kights Corner (ex Larrabee), “Knights Corner Instruction Set Reference Manual”, che ho trovato molto illuminante e utile; soprattutto lo aspettavo da tempo, visto che di Larrabee avevo potuto leggere soltanto alcuni articoli o presentazioni.
    Nel frattempo ho visto che hanno finalmente inserito alcune istruzioni a mio avviso importantissime, che avevo ipotizzato e buttato giù qualche tempo fa O:-) , dopo aver studiato questa nuova ISA x86-based (ma incompatibile: hanno tolto alcune istruzioni legacy che comunque sono utilizzate da kernel e/o driver; eventualmente ne riparleremo).

  • # 23
    Giorgio Dabemo
     scrive: 

    @Cesare
    Avevo letto tempo un articolo del CEO di ARM che magnificava i propri prodotti proprio per il fatto che la loro progettazione era stata fatta pensando ai consumi, parlando anche di istruzioni pensate apposta per questo. Non è sceso nelle specifico e non so se era marketing o tecnica, comunque è vero che il settore di ARM non erano i computer fissi dominati da Intel ma il mercato mobile e quindi i consumi sono entrati in tutte le fasi della progettazione, al contrario di intel che ha iniziato a pensare ai consumi solo dopo che il settore mobile ha preso piede, più o meno.

    Sulle architetture migliori di 8086 c’è da scegliere, vedi Zilog o Motorola. Tu dici che non ce n’erano con compatibilità 8008, ma questa compatibilità non era necessaria per IBM. La fortuna del processore l’ha fatta IBM usandolo per il suo PC, poteva scegliere di meglio, ha scelto questo, il resto è storia.

    Per il resto nel commento 22 dici le stesse cose che dico io, la compatibilità x86 pesa sui consumi, quindi è un assurdo nel mondo mobile dove le app devono comunque essere riscritte vale la pena andare con un nuovo processore che non mantenga la compatibilità.
    Infatti anche MS ha abbandonato intel ed è andata con ARM, non l’avrebbe fatto se intel avesse avuto un processore competitivo, non per motivi di compatibilità ma per sinergie aziendali.
    Invece ha dovuto andare con ARM e in Intel non l’hanno presa affatto bene. Significa anche però che una qualche strategia in intel non ha funzionato, avrebbero dovuto avere una propria linea di processori stile arm non x86 ma parchi di consumi e non ce l’hanno.
    Ne intel ne ms si aspettavano una concorrenza tale da inpensierirli.
    Disruption.

  • # 24
    Cesare Di Mauro (Autore del post)
     scrive: 

    @Giorgio: rispondo sempre per punti.

    @Cesare
    Avevo letto tempo un articolo del CEO di ARM che magnificava i propri prodotti proprio per il fatto che la loro progettazione era stata fatta pensando ai consumi, parlando anche di istruzioni pensate apposta per questo. Non è sceso nelle specifico e non so se era marketing o tecnica,

    Affermazioni come queste si possono facilmente dimostrare: basta citare le istruzioni e perché sarebbero state pensate appositamente per i consumi.

    Conosco ARM da quando trapelavano le prime voci, attorno alla metà degli anni ’80, quando leggevo avidamente le pagine di MC MicroComputer per informarmi sul panorama IT, ma della Acorn Risc Machine ricordo, al contrario, che fu pensata appositamente per le prestazioni, in particolare quando si dovevano servire gli interrupt.

    Mi sono sempre interessato agli ARM, e a memoria non c’è nulla che possa avvalorare le dichiarazioni del CEO di ARM. Ho scritto una decina di articoli su quest’architettura, fra cui uno introduttivo ( http://www.appuntidigitali.it/4481/acorn-risc-machine-lorigine-della-specie/ ), ma come puoi vedere non parlo mai di decisioni prese da Acorn appositamente per i consumi.

    Per cui al 99,9999999% (periodico) il CEO di ARM si sarà sicuramente cimentato in una classica sparata di marketing.

    comunque è vero che il settore di ARM non erano i computer fissi dominati da Intel ma il mercato mobile e quindi i consumi sono entrati in tutte le fasi della progettazione, al contrario di intel che ha iniziato a pensare ai consumi solo dopo che il settore mobile ha preso piede, più o meno.

    Assolutamente non vero. Tant’è che la prima incarnazione di ARM (commercialmente parlando; la versione del processore fu, invece, la seconda) è stata l’Archimedes: http://www.appuntidigitali.it/1908/acorn-archimedes-risc-per-tutti/

    Sulle architetture migliori di 8086 c’è da scegliere, vedi Zilog o Motorola.

    Nel 1976 la prima commercializzò lo Z80 qualche mese dopo che il progetto 8086 aveva avuto inizio, mentre la seconda aveva già commercializzato il 6800 (non il 68000) un paio d’anni prima.

    In entrambi i casi erano processori a 8 bit, e non potevano competere con l’architettura a 16 bit che Intel stava sviluppando.

    Dunque da chi avrebbe dovuto trarre ispirazione Intel per realizzare l’8086?

    Tu dici che non ce n’erano con compatibilità 8008, ma questa compatibilità non era necessaria per IBM. La fortuna del processore l’ha fatta IBM usandolo per il suo PC, poteva scegliere di meglio, ha scelto questo, il resto è storia.

    Questo è un discorso completamente diverso, e riguarda una scelta di IBM. Intel era un fornitore come un altro.

    Per il resto nel commento 22 dici le stesse cose che dico io, la compatibilità x86 pesa sui consumi, quindi è un assurdo nel mondo mobile

    Non è un assurdo, perché, come dice giustamente Davide Costantini, i consumi non dipendono soltanto da questo, ma da tanti fattori. Posso avere una CPU che consuma troppo nelle sezioni di decodifica, ma se nelle altre sezioni consuma meno, il bilancio può essere tranquillamente positivo.

    dove le app devono comunque essere riscritte vale la pena andare con un nuovo processore che non mantenga la compatibilità.

    In realtà su mobile l’architettura dominante è divenuta ARM, e già da parecchi anni. Tant’è che con la sua versione di Android Intel ha dovuto integrare uno strato di emulazione ARM per le applicazioni che fanno uso dell’NDK.

    Comunque la situazione mobile è molto variegata. Su Android il 90% e passa delle applicazioni sono native Java, per cui l’architettura non conta; meno del 10% sono “native” ARM.
    Su iOS domina ARM causa compilazione del codice Objective-C/C++.
    Su Windows Phone 7+ si usa .NET, e quindi l’architettura non è importante (lo sarà con Windows Phone 8, che permetterà la scrittura di applicazioni in C/C++; dunque compilate per ARM).

    Infatti anche MS ha abbandonato intel ed è andata con ARM, non l’avrebbe fatto se intel avesse avuto un processore competitivo, non per motivi di compatibilità ma per sinergie aziendali.
    Invece ha dovuto andare con ARM e in Intel non l’hanno presa affatto bene. Significa anche però che una qualche strategia in intel non ha funzionato, avrebbero dovuto avere una propria linea di processori stile arm non x86 ma parchi di consumi e non ce l’hanno.
    Ne intel ne ms si aspettavano una concorrenza tale da inpensierirli.
    Disruption.

    Non è così. Microsoft s’è buttata su ARM perché ha la necessità di entrare nel mercato tablet, che sta erodendo quote di mercato alle soluzioni desktop, notebook e netbook, dove lei ha sempre dominato.

    Nel tablet, invece, dominano altri s.o.. Certamente non i suoi. E siccome come CPU domina ARM, per entrarci ha dovuto bussare alla sua porta.

    Idem per gli smartphone.

    Intel, come ha detto Davide prima, ha presentato una sua architettura x86 che non ha proprio nulla da invidiare ad ARM in termini di consumo e potenza di calcolo.

    Quindi non è per questo che Microsoft ha deciso di puntare su ARM, perché Intel ha le sue buone carte da giocare.

    Comunque stiamo divagando un po’ troppo dal tema dell’articolo. Preferirei che ci mantenessimo sul contenuto. Eventualmente per queste discussioni sono già stati scritti altri articoli sia da me che, soprattutto, Alessio. ;)

  • # 25
    Crick
     scrive: 

    @Cesare
    già…purtroppo il problema fondamentale era la scarsissima (per non dire ridicola) velocità di emulazione x86 e lo spostamento delle responsabilità di riorganizzare il codice per tenere occupate le pipeline dai circuiti al compilatore. Troppo azzardato per l’epoca. Per il resto non era realmente “malvagia”, una VLIW con 128+128 registri e istruzioni ad ortogonalità quasi totale non mi sarebbero dispiaciuti! ;)

  • # 26
    Cesare Di Mauro (Autore del post)
     scrive: 

    L’idea “malvagia”, in verità, è stata proprio l’architettura VLIW.

    Va bene quando puoi riuscire a raggruppare tante istruzioni, ma quando si verifica questo nel codice comune? Poche volte. Infatti chi ha lavorato con Itanium ha parlato di bundle che avevano spesso due o addirittura una sola istruzione, e il resto degli slot riempiti con NOP…

    Se ci pensi bene, i processori VLIW assomigliano concettualmente a quelli in-order. Basta immaginare le due (o più) istruzioni da eseguire per questi ultimi come se fossero “impacchettate” in un bundle.

    Però se dopo i processori in-order arrivarono quelli out-of-order, e le prestazioni decollarono, ci sarà stato un perché, e il motivo va ricercato nel fatto che soltanto a runtime, in un preciso momento, puoi sapere come sono allocate le risorse e decidere come utilizzarle.

    Un compilatore ha una visione statica del codice, per cui scaricargli sulle spalle la responsabilità di ottimizzare il codice, anziché provvedere a runtime, si è rivelata stata una scelta fallimentare.

    VLIW vanno bene in sistemi embedded, DSP, ecc., dove hai un sistema di vincoli ben definiti e puoi prevedere, e quindi utilizzare al meglio, l’uso delle risorse (incluse le latenze d’accesso alla memoria).

    Con codice abbastanza generico vengono meno i loro punti di forza.

    D’altra parte anche in ambito x86 abbiamo esempi di fallimento proprio delle architetture VLIW… ;)

  • # 27
    Giorgio Dabemo
     scrive: 

    @Cesare
    Ho cercato rapidamente con google, questo è un articolo che parla delle ottimizzazioni di ARM per per il consumo più che per la potenza di calcolo
    http://www.bdti.com/InsideDSP/2011/11/17/ARM
    Ho letto che pensi che MS abbia rotto la sua alleanza storica con intel (tanto che si parla di dominio wintel) passando ad arm non perché arm è meglio nei consumi (come è) ma perché nel mobile i concorrenti usavano arm??????????
    Come se cosa usano i concorrenti avesse importanza!!!!!!
    Sono sconcertato, scusa se ho insinuato che santa madre intel ha fatto qualcosa di sbagliato :-)

  • # 28
    Cesare Di Mauro (Autore del post)
     scrive: 

    Non mi pare di aver mai parlato da fanboy Intel, e il tuo “santa madre Intel” è del tutto fuori luogo. Non penso che Intel abbia bisogno di me per “difendersi”, e sono sicuro che chi mi conosce si starà facendo delle grasse risate dopo l’accusa che mi hai mosso…

    Comunque ARM prevede di arrivare al 20% circa del mercato PC entro il 2014, sempre secondo le recenti dichiarazioni del CEO.
    Poiché il mercato PC è dominato da Microsoft, non credo serva un nobel in economica per capire che è quest’ultima a ha bisogno di muoversi per NON perdere queste quote di mercato.

    Riguardo al link che hai postato, non c’entra proprio nulla con le dichiarazioni che avevi riportato prima. Ovviamente il mio invito è quello di leggerlo approfonditamente e confrontare i fatti che emergono con quelli che hai snocciolato prima.

    Per essere chiari, non emerge assolutamente niente riguardo alla progettazione dell’ISA (e, quindi, delle istruzioni) specificamente in ottica consumi.

    Parla, com’è ovvio che sia, della microarchitettura, cioè delle diverse implementazioni dell’ISA. Cosa normalissima, perché… lo fanno tutti. Intel inclusa. Atom, appunto, è un esempio eloquente. Ma nel link si parla anche di Pentium-M e Pentium4, come esempio di politica che aveva già seguito Intel. Casualmente.

    Nulla di nuovo sotto il sole, insomma…

  • # 29
    Giorgio Dabemo
     scrive: 

    @Cesare
    Se non è per fanatismo, come fai a sostenere che MS sia passata a ARM perché lo facevano gli altri e non perché ARM abbia prodotti migliori di intel nel settore mobile lo sai solo tu.
    Nell’articolo, come anche in wikipedia, parlano anche della semplicità delle istruzioni ARM decodificabili senza microcode che richiedono molta meno energia per essere eseguite e parlano di un design volto al contenimento dei consumi a scapito della potenza di calcolo, strada opposta a quella scelta da intel, dovuta a posizioni del mercato differenti certamente ma che ha portato alla situazione attuale dove i consumi contano di più della potenza e dove Intel è in difficoltà rispetto ad ARM.
    Ci sono anche altre cause strettamente di business, ma intel ha scelto la strada sbagliata.
    Qui una disamina interessante http://www.asymco.com/2011/01/10/who-killed-the-intel-microprocessor/
    Anche nei commenti ci sono spunti validi

  • # 30
    banryu
     scrive: 

    @Giorgio Dabemo

    @Cesare
    Se non è per fanatismo, come fai a sostenere che MS sia passata a ARM perché lo facevano gli altri e non perché ARM abbia prodotti migliori di intel nel settore mobile lo sai solo tu.

    Non per difendere Cesare (che non ne ha bisogno) ma solo perchè leggendo i vostri scambi non capisco la ratio dietro questa tua obiezione che gli opponi, mi pare che Cesare suia stato abbastanza chiaro quando ha scritto:

    Microsoft s’è buttata su ARM perché ha la necessità di entrare nel mercato tablet, che sta erodendo quote di mercato alle soluzioni desktop, notebook e netbook, dove lei ha sempre dominato.

    Nel tablet, invece, dominano altri s.o.. Certamente non i suoi. E siccome come CPU domina ARM, per entrarci ha dovuto bussare alla sua porta.

    Idem per gli smartphone.

    Cioè il concetto (o almeno quello che io capisco) è che ARM domina in un determinato settore; Microsoft da sempre partner di Intel, per avere una chance di entrare *subito* in quel dato settore ha dovuto fare i conti con questa realtà.

    In soldoni, è così oppure no?

  • # 31
    Giorgio Dabemo
     scrive: 

    @banryu
    Non capisco perché si voglia girare intorno ai fatti cercando di modificare la realtà.
    Cesare dice che microsoft ha usato arm perché arm domina il settore ma intel ha prodotti altrettanto validi.
    Infatti dopo la frase che riporti tu dice:
    “Intel, come ha detto Davide prima, ha presentato una sua architettura x86 che non ha proprio nulla da invidiare ad ARM in termini di consumo e potenza di calcolo.

    Quindi non è per questo che Microsoft ha deciso di puntare su ARM, perché Intel ha le sue buone carte da giocare.”

    Quindi intel ha prodotti validi nel settore mobile dominato chissà perché da ARM, ma MS pur storico partner di intel è passata ad ARM cosi, perchè lo usano gli altri o come dici tu per entrare *subito* nel settore.
    Che vuol dire subito? Che vuol dire siccome gli altri hanno arm allora anche ms lo usa?
    ARM domina perché ha fatto scelte strategiche diverse da intel e ora ha processori più competitivi nel settore mobile, tanto che anche MS ha dovuto cambiare e fare un s.o. per ARM.
    MS poteva scegliere Intel, certo e poteva fare un tablet Atom con gli stessi tempi con cui sta per fare un tablet ARM, solo che ha scelto ARM perché la durata della batteria conta e sicuramente non perché lo usano anche i competitor.

  • # 32
    banryu
     scrive: 

    @Giorgio Dabemo:
    Chiedo venia, forse c’è un quiproquo (per colpa mia) e non mi sono spiegato bene.
    La premessa è che io parlo da *assoluto* ignorante in materia, sia chiaro :D

    – Ho capito che ora anche Intel ha prodotti validi nel settore mobile.

    – Davo per scontato però che ARM dominasse il settore (come presenza). Non so quanto lo dominia in rapporto ad Intel però.

    Da qui il ragionamento ingenuo che ho fatto: se ARM domina tanto di più di Intel nel mobile (questa era la mia premessa) probabilmente Microsoft ha fatti i conti e ha verificato/deciso che le conviene di più fare “la puttana” con ARM, in questo caso.
    Tutto qua.

    Ora grazie a te scopro che

    MS poteva scegliere Intel, certo e poteva fare un tablet Atom con gli stessi tempi con cui sta per fare un tablet ARM, solo che ha scelto ARM perché la durata della batteria conta e sicuramente non perché lo usano anche i competitor.

    Messa giù così pare che questo aspetto abbia giocato un ruolo ben più che marginale, solo che adesso lo hai sottolineato chiaramente (oppure sono stanco e non mi sono accorto che lo avevi detto anche prima, in tal caso sorry).

  • # 33
    Z80Fan
     scrive: 

    @Giorgio Dabemo:

    Microsoft è un’azienda che fa software, quindi è ovvio che gli interessa sapere cosa usano i produttori di hardware.

    Successivamente ha visto che i produttori non la ascoltavano neanche di striscio e allora ha deciso di costruirsi il suo hardware, tale “Microsoft Surface” che, precisiamolo, è SIA x86, SIA ARM, ci sono 2 versioni del tablet, che si differenziano dal fatto che una fa girare Windows 8 “intero”, mentre l’altra fa girare Windows 8 RT per ARM, che non fornisce il desktop e quelle altre cose diciamo “legacy”.

    Poi visto che ARM è onnipresente nel settore, ha più senso usarla anche perchè ci sono centinaia di fornitori, migliaia di ingegneri che hanno lavorato con ARM e sanno tutti i “trucchi” del mestiere, per non parlare appunto dei dispositivi già esistenti, cosi che se un produttore vuole un tablet Windows 8, basta che prenda un suo prodotto e lo converta via software a una piattaforma comoda per quell’OS.

  • # 34
    Giovanni
     scrive: 

    Il ragionamento di @Z80Fan mi sembra di gran lunga più logico e ragionevole specialmente se sostenuto da un’azienda che deve vendere software e OS in particolare! Non é questione di consumi delle CPU, nemmeno di prestazioni e penso che, come succede nella realtà degli affari, il concetto pervasivo di “Winte”l sia soprattutto una ideologia per complottisti, ma nella realtà dei fatti ognuno é subito pronto a rompere accordi e contratti a fronte di un’opportunità commerciale succulenta!!!

    Volevo aggiungere, per qunto OT, che trovo di cattivo gusto l’esplicita espressione di luoghi comuni come:

    “x86 non era un gran progetto, c’era di meglio nella concorrenza, come estetica del progetto potremmo dire”…

    sono frasi costruite un po’ per dare a vedere di saperla lunga, ma senza fondamento: riportate sicuramente per “sentito dire” e che lasciano il tempo che trovano, ma contribuiscono ad alimentare polimeche e inesattezze.
    Il fatto é che risulta davvero difficile sostenerle oggettivamente senza contare che si tratta di considerazioni riferite ad eventi e situazioni di oltre 30 anni fa… quindi anche se ci fosse qualche ragione sarebbe meglio non sentenziare come se fosse un dato di fatto.

    Per il resto x86 non era assolutamente una pessima architettura e, non é un caso la scelta di IBM, aveva le potenzialità che poi ha dimostrato per diventare dominatrice di mercato. Intel aveva praticamente inventato i microprocessori ed era già allora avanti rispetto a tutti gli altri concorrenti. Nei 16 bit Zilog, che aveva migliorato i progetti analoghi Intel, non era riuscita a sfornare in tempo cpu altrettanto interessanti. Soprattutto Intel disponeva già allora di una vastissima rete di licenziatari e produttori esterni o di CPU compatibili (vedi NEC e la stessa AMD) che costituiva una realtà industriale di ordini di grandezza superiore a quella di tutti gli altri produttori di CPU. Guarda caso: IBM ha scelto un chip Intel per fare il proprio PC!

    Infine nelle prime reincarnazioni dell’architettura x86, a parte il rimpianto 80286, ma é superfluo riconoscere che 80386 (1985) e 486 che ne ricalca il profilo perfezionando ed esaltando le qualità, erano microprocessori quantomeno eccellenti e che non sofrivano di alcun problema “legacy”! Il vero problema di fondo é stato il vergognoso ritardo nel dare a questi prodotti del software (OS in primis) di adeguata capacità. Non solo Microsoft, ma anche il terribile ritardo di OS/2 con cui IBM, in un momento di caos, ha perso una grandiosa opportunità!

    Anche la questione della segmentazione della memoria, per quanto possa apparire oscura, consiste soprattutto in questione di uso e abitudine (é vero il collegamento con i leggendari System 360), in quanto una volta entrati nella logica di questo modo di indirizzamento e gestione della memoria. da parte del programmatore, non costituisce una problematica (anche perché in gran parte trasparente).
    Ritengo anch’io che la questione “legacy” per l’archiettura x86 sia in gran parte un (non del tutto) un argomento utile alla polemica più che una reale problematica tecnologica.

    Saluti

  • # 35
    Cesare Di Mauro (Autore del post)
     scrive: 

    @Giorgio: rispondo sempre per punti.

    @Cesare
    Se non è per fanatismo

    Si chiama fare corretta informazione, e ho risposto sempre a qualunque tua affermazione. Lo stesso non si può dire di te, che di tutto quello che hai scritto finora sei rimasto aggrappato soltanto a un paio di cose.

    Per cui, se permetti, fanatico è un termine che almeno a me non si addice di certo. Fatti un esame di coscienza.

    come fai a sostenere che MS sia passata a ARM perché lo facevano gli altri e non perché ARM abbia prodotti migliori di intel nel settore mobile lo sai solo tu.

    Che Microsoft sia passata ad ARM e che, come hai scritto in altri commenti, abbia addirittura abbandonato Intel è una notizia che arriva come un fulmine a ciel sereno. Mi sorprende che non sia stata ripresa da tutti i media, ma forse è perché, prendendo in prestito le tue parole, “lo sai solo tu”…

    Comunque ho visto che nel frattempo hai ricevuto numerose risposte, con le quali sono sostanzialmente d’accordo, ma cerco di spiegarti il concetto in altro modo.

    Intanto, come dicevo: http://www.businessmagazine.it/news/arm-arriveremo-al-20-del-mercato-pc_42213.html Leggilo bene.

    Adesso veniamo a Microsoft. E’ lei la dominatrice del mercato PC, col 90% di share.

    Supponiamo che le previsioni di East si avverino, e che fra 2-3 ARM deterrà il 20% di questo mercato. 100 – 20 = 80% è ciò che resta del mercato PC. Se la matematica non è un’opinione, Microsoft perderebbe il 10% del suo mercato. Il 10% è poco? E’ molto? Non so, ma credo che al suo posto ci rimarrei molto male.

    In che modo Microsoft potrebbe frenare o annullare quest’emorragia? Molto semplice. Com’è stato detto, Microsoft è un’azienda che produce software. ARM è un’azienda che, invece, è interessata all’hardware. Non si tratta di condizioni mutuamente esclusive.

    Infatti è già da PARECCHI anni che software Microsoft gira… su processori ARM: i PocketPC con Windows CE ne sono (stati) un chiaro esempio.

    Per cui, molto bovinamente, se Microsoft producesse software che girasse su hardware ARM, potrebbe anche riuscire a mantenere la sua quota di mercato.

    In tutto questo Intel non c’entra perché, anche se ADESSO ha una soluzione competitiva, nulla toglie al fatto che ARM sta acquisendo e acquisirà notevoli quote del mercato PC.

    Ho semplificato molto il discorso, ma il concetto penso sia chiaro. Per il resto, come già detto, condivido le osservazioni che sono state fatte dagli altri.

    Nell’articolo, come anche in wikipedia, parlano anche della semplicità delle istruzioni ARM decodificabili senza microcode che richiedono molta meno energia per essere eseguite e parlano di un design volto al contenimento dei consumi

    Ho già scritto, e non so quante altre volte devo ancora ripeterlo, che ciò non deriva da un design pensato appositamente in ottica di consumi, ma dal fatto che per un processore RISC generalmente la decodifica delle istruzioni è un processo semplice, che richiede poche risorse. Questo IMPLICA, cioè è una mera CONSEGUENZA, che anche i consumi saranno ridotti PER QUESTA PARTE DEL CHIP (lo sottolineo, perché NON è l’unica variabile; vedi il commento di Davide).

    Visto che hai citato Wikipedia, basta leggere attentamente quello che c’è scritto per arrivare alle stesse conclusioni. Ecco qui:

    “This simplicity led to its low power usage”

    Il significato (in particolare del verbo lead) mi sembra chiarissimo, e non fa che confermare quanto avevo già scritto sull’argomento.

    Al contrario, non c’è NESSUNA evidenza di quanto TU avevi scritto prima in proposito. Io aspetto ancora l’elenco delle istruzioni appositamente pensate per contenere i consumi…

    a scapito della potenza di calcolo

    Questa è una tua pura invenzione non suffragata da alcun fatto. Come trovi scritto anche su wikipedia nella sezione History e nella successiva sull’ARM2, l’obiettivo era proprio la potenza di calcolo.

    Quei paragrafi traboccano di “fast”, “speed”, “performance”, “efficiency”. E, manco a dirlo, non c’è NESSUNA traccia di “power”, se non quella che ho riportato sopra, ma che, come già detto, è una mera conseguenza (lo dice lo stesso verbo utilizzato) dell’essere una macchina RISC.

    D’altra parte è scritto a chiare lettere che l’obiettivo era entrare nel mercato PC e, sempre “casualmente”, si esaltano le PRESTAZIONI (chi l’avrebbe mai detto) rispetto all’80286 di Intel. Chissà perché…

    , strada opposta a quella scelta da intel

    Anche questa è una tua pura invenzione, non suffragata da fatto alcuno. Non v’è dubbio che anche a Intel interessassero le prestazioni, altrimenti non avrebbe sviluppato l’8086. Ma queste sono ovvietà perché, come già detto, interessavano anche ad ARM…

    I consumi NON erano l’oggetto del design. Né per Intel né per ARM né per gli altri. ALL’EPOCA.

    , dovuta a posizioni del mercato differenti certamente ma che ha portato alla situazione attuale dove i consumi contano di più della potenza e dove Intel è in difficoltà rispetto ad ARM.

    E che all’epoca non erano certo prevedibili né tanto meno importanti, avendo la microelettronica e il mercato ben altre problematiche ed esigenze.

    Non so tu, ma se fossi stato un ingegnere che avesse iniziato a lavorare al progetto dell’8086 nel 1976, avrei avuto NON POCHE difficoltà a prevedere cosa sarebbe successo 30 ANNI dopo…

    Come dice Giovanni, l’errore più grosso sta nel non contestualizzare i fatti. Ed è proprio quello che hai fatto e continui a fare tu, che mischi malamente la storia per arrivare a tesi che viste soltanto con gli occhi di OGGI portano a certe conclusioni che, però, sono del tutto prive di significato, per non dire false, poiché spogliate del loro ambito storico.

    Sono talmente grossolani i tuoi errori, che hai persino preteso di addossare la colpa a Intel per la scelta di IBM col suo PC, infilando anche Zilog e Motorola in mezzo, quando in quel discorso si parlava della PROGETTAZIONE dell’8086…

    Ci sono anche altre cause strettamente di business, ma intel ha scelto la strada sbagliata.

    E quali sarebbero? Cos’è che avrebbe sbagliato Intel nel… 1976? Ah, sì, avrebbe dovuto progettare lei un surrogato dell’ARM…

    Poi, vabbé, non avrebbe potuto far girare il CP/M, s.o. diffusissimo all’epoca, né tanto meno le applicazioni che vi giravano. Un dettaglio trascurabile per chi all’epoca era leader di mercato coi suoi 8008, 8080 e 8085, di cui l’8086 soltanto per puro caso era compatibile a livello di sorgente…

    Sì, non v’è dubbio che tu abbia ragione. Nel caso in cui volessimo riscrivere la storia a nostro piacimento…

    Qui una disamina interessante http://www.asymco.com/2011/01/10/who-killed-the-intel-microprocessor/
    Anche nei commenti ci sono spunti validi

    Spero che li abbia letti anche tu, perché dovresti esserti accorto che non portano acqua al tuo mulino e alle affermazioni che hai fatto nei tuoi precedenti commenti.

    Inoltre dovresti sapere sia tu che chi ha scritto quel pezzo che anche Intel sta puntando ai SoC. E non potrebbe essere altrimenti se vuol ritagliarsi una fetta nel mercato smartphone e tablet.

    Altra cosa, anche Intel si sta orientando a un design più modulare coi suoi processori, sia desktop che mobile. Ovviamente non è e non sarà mai ai livelli di ARM che, per quanto ricordato nel pezzo che hai citato, offre e offrirà sempre una personalizzazione molto più aggressiva dei suoi core.
    Ma mentre questo è molto importante in ambito embedded, lo è molto meno in quello mobile, dove in genere i produttori di dispositivi hanno bisogno di un SoC pronto all’uso (CPU, GPU, chipset per l’I/O, per il Wi-Fi e ovviamente per le telecomunicazioni, memoria FLASH e DRAM) e in cui la personalizzazione ha uno scarso valore.

    Ma queste, come già detto, dovrebbero essere cose ben note, specialmente quando si fanno certe affermazioni…

    E ripeto: manchi di contestualizzazione e di inquadramento storico dei fatti. Su queste basi puoi dire tutto quello che vuoi, ma non farà mai testo.

  • # 36
    Davide Costantini
     scrive: 

    Credo che qua ci stiamo scontrando troppo sui dettagli.

    Medfield è competitivo è vero, ma è l’unico prodotto di Intel in una fascia di mercato varia. E’ ovvio che non può coprire tutti i target.

    Tra l’altro gli S4 sono comunque superiori, se non tanto per CPU dove il divario è contenuto, per GPU.

    Se Microsoft avesse scelto di rimanere solo con Intel si sarebbe data la zappa sui piedi. Il mondo è cambiato, Intel entrerà nelle quote tradizionalmente di ARM e viceversa. E questo è un bene per la competizione.

    Credo che Intel non sia così vulnerabile come alcuni hanno puntualizzato, grazie al vantaggio sui processi produttivi e l’expertise nelle microarchitetture ad alte prestazioni.

    Rimane il fatto che allo stato attuale ARM, non tanto come azienda ma come “ecosistema”, è sicuramente superiore in ambito mobile. E’ più radicata, c’è da più tempo, entra in più prodotti per via di un modello versatile.

    Anche nel migliore dei mondi Intel non riuscirà a coprire la vastità del mercato ARM in ambito mobile. Perché il modello di business è differente e il numero di soluzioni che possono sviluppare non è orizzontalmente vasto. Insomma, non possono fare 6.000 SoC per tutti i gusti. Ma dare in licenza l’ISA e la microarchitettura come fa ARM consente di “fondere” multipli blocchi e creare SoC per tutti i gusti.

    Per cui credo che per quanto Intel possa andare bene, se non cambierà modello, nel mobile non potrà avere lo strapotere che ha negli altri settori.

    La scelta di Microsoft appare quindi coerente sia in ottica prospettica che nel breve periodo, perché sicuro Intel è nuova in questo segmento.

    Spero di aver fatto contenti tutti ;)

  • # 37
    Davide Costantini
     scrive: 

    Vedo tra l’altro che il link di Dabemo dice la stessa cosa puntualizzata da me ;)

  • # 38
    Cesare Di Mauro (Autore del post)
     scrive: 

    Già, e molto sinteticamente l’avevo riportato.

    Ma, sfortunatamente per lui, non conferma le affermazioni che aveva fatto in precedenza… :P

  • # 39
    homero
     scrive: 

    QNX è il futuro del kernel, l’ho testato ed è realmente semplice da programmare, mancano centinaia di interfacce, ma come kernel ha tutto quello serve e puo starci perfino in cache….senza dar droppi gratta capi, immaginate in sistemi con centinaia di cpu?

    ognuna con il suo kernel caricato….

    insomma linux va bene in produzione ma se devo sperimentare non sperimento piu’ su linux…ormai va riscritto da zero….qnx puo’ essere una soluzione….certo non su x86 che ormai ha fatto il suo tempo….a me basta un move, un jmp,cmp e contatore e poche altre istuzioni per programmare quaunque cosa….tutto il resto è digressione per tirar fuori brevetti….
    quindi non venitemi a parlare di architetura x86 perchè ormai per me è morta e sempolta dai tempi dell’amiga….
    per quanto riguarda as400 e il linguaggio RPC che caratterizza molte sue applicazioni, è un relitto umane che fa funzionare in sequenza: bartolini, tnt, rayan air e diverse banche….
    e poi dicono x86 è un forza….basta veramente poco per far andar avanti il mondo informatico, le poste che si basano su microsoft solo quest’anno hanno dovuto subire diversi blackout informatici quando tutto era ibm basatto su oS/2 tutto andava liscio come l’olio….insomma tutta sta come si fanno le cose per il momento sto percorrendo due strade la prima è quella html5+javascript e la seconda XILIX con FPGA….il tutto nella tristezza piu’ completa percheè si potrebbe produrre oggetti migliori, piu’ semplici ed efficenti, altro che parlare di un’architettura che merita ogni vituperio come quella X86-x86-64…..
    ma questa è un’altra storia….

  • # 40
    Giovanni
     scrive: 

    @homero (?) E` forse il caldo (?)

  • # 41
    Cesare Di Mauro (Autore del post)
     scrive: 

    No, purtroppo non è quello…

  • # 42
    Osvaldo
     scrive: 

    Io credo che la cosa piu’ importante in una cpu sia la
    tecnologia che sta’ alla base.
    Intel ha battuto tutti (68000 ,PPC ,AMD ….) nonostante gli
    errori commessi , perche’ aveva la migliore tecnologia.
    La migliore tecnologia Intel l’ha utilizzata nella serie
    x86 mettendo fuori gioco anche l’Itanium.
    Credo che con un po’ di buona volonta’ possa sfondare anche
    nel setttore Mobile (Inteso come palmari e simili).

  • # 43
    Cesare Di Mauro (Autore del post)
     scrive: 

    Credo anch’io che possa ritagliarsi una fetta di mercato nel mobile, ma deve rimboccarsi le maniche e partire dall’inizio proponendo prodotti competitivi, perché non può contare sull’egemonia che ha nel mondo desktop e server.

    Per essere chiari, la compatibilità binaria x86 nel settore mobile NON è un valore aggiunto. Tutt’altro. E’, anzi, una della catene che vincola troppo Intel. Se è furba, e come ho scritto in un altro commento sul secondo articolo di questa serie, può presentare una soluzione decisamente competitiva sia sul piano delle prestazioni che dei consumi.

    Per quanto riguarda la “tecnologia”, penso si possa parlare di “teste” e, soprattutto, tanti soldi da investire in ricerca. E anche un po’ di fortuna, perché la concorrenza, anche fatta da realtà molto più piccole come AMD, le ha dato parecchio filo da torcere, e tante volte l’ha messa al tappeto (intendo come bontà dei prodotti; poi sappiamo che nelle vendite ha sempre dominato).

    Infine su Itanium ha osato troppo e non s’è fatta i conti coi progressi della tecnologia.. L’idea di spostare sul software parte della complessità di un processore è buona, ma è la struttura (VLIW) della CPU che si è rivelata fallimentare per l’obiettivo prefisso.

    Personalmente sono più che convinto che si possano ottenere ben altri risultati con x86 e x64, mantenendo l’idea generale. ;)

Scrivi un commento!

Aggiungi il commento, oppure trackback dal tuo sito.

I commenti inseriti dai lettori di AppuntiDigitali non sono oggetto di moderazione preventiva, ma solo di eventuale filtro antispam. Qualora si ravvisi un contenuto non consono (offensivo o diffamatorio) si prega di contattare l'amministrazione di Appunti Digitali all'indirizzo info@appuntidigitali.it, specificando quale sia il commento in oggetto.