Link alla notizia: http://www.hwupgrade.it/news/cpu/architettura-arm-leader-nel-settore-mcu-per-il-2011_28903.html

Secondo alcune analisi di mercato le soluzioni Cortex-M3 e Cortex-M0 sono destinate a diffondersi in maniera consistente, superando le blasonate architetture Power ed x86

Click sul link per visualizzare la notizia.

Prevedo un certo numero di commenti spalaletame su x86

Prevedo un certo numero di commenti spalaletame su x86
E vorrei pure vedere... il fatto che l'architettura x86 sia assolutamente inefficiente e' un dato di fatto...

Beh gli x86 sono per PC non fatti per particolari ambiti come i microcontroller, non mi sebra chissà che notizia.

Si parla di microcontrollori...non di cpu general purpose. Credo sia bene chiarirlo.

Vedrete che anche nel campo dei netbook l'architettura ARM, con l'appoggio del pinguino (leggasi Android) si ritaglierà a breve una sua fetta di mercato considerevole:)

Uffa, android no....ma un bell'ubuntu classico su netbook arm è così difficile da fare? :muro:

Prevedo un certo numero di commenti spalaletame su x86

Sono 30 anni che spalano letame su x86 ma è sempre lì :asd:

Non solo, ma da architettatura prettamente "per PC" si è ritagliata un importante fetta nei server tant'è che si sta espandendo rapidamente anche in questo settore soprattutto grazie a linux (che è nato su x86) e ha fornito la disponibilità di un sistema UNIX robusto anche su x86 (piattaforma storicamente snobbata dagli unix commerciali) .

Di fatto bisognerebbe scindere un architettatura dal proprio ISA .

Che l'ISA che x86 mette a disposizione sia piuttosto arcaico (almeno quello base, non comprendendo tutte le estensioni che ci sono oggi) non c'è dubbio , ma dietro all'ISA ci sono architettature di tutto rispetto con il massimo della tecologia, infatti i chip più veloci in commercio sono x86.

Di fatto l'unica inefficienza delle architettature x86 è il decoder in testa al core RISC (perchè oramai è quello che sono le cpu x86 moderne), ma se è il prezzo da pagare per avere la retrocompatibilità con praticamente tutto il software esistente ... benvenga.

E vorrei pure vedere... il fatto che l'architettura x86 sia assolutamente inefficiente e' un dato di fatto...

un po' come dire che un boing 747 è inefficiente perchè consuma litri di carburante per ogni km... guardare il consumo e basta è piuttosto limitativo

devi vedere anche cosa fa, sinceramente non penso che se devi eseguire delle operazioni computazionalmente pesanti nel general purpose gli arm, i powerpc o chi altro riescano a far di meglio degli x86 a parità di wattora consumati

in altri termini: si, il netbook arm ha la batteria che dura 2 volte di più, ma se per fare gli stessi compiti ci impiega 8 volte tanto rispetto ad un atom allora c'è da rifletterci sopra

se parliamo di idle è un'altra storia però ripeto è come dire che un boing 747 con i motori accesi e fermo consuma di più di un ciao con il motore acceso fermo al semaforo. stiamo paragonando due cose diverse.

il dato di fatto imho è che gli x86 hanno dimostrato due cose nel corso degli anni:
- che pur essendo dati per obsoleti da 20 anni sono i processori di riferimento per diversi segmenti di mercato e in questi non si vede, nemmeno tra i figli di architetture più moderne, l'ombra di un competitor reale (una volta c'erano i 68000, i powerpc, eccetera, oggi morti tutti)
- che hanno dimostrato una flessibilità incredibile, dall'atom agli xeon / opteron sono stati in grado di finire dall'embedded / netbook ai serveroni

cosa che peraltro non hanno dimostrato gli altri

sono un po' lo unix dell'hardware, che è in giro dalla notte dei tempi e che nelle sue incarnazioni moderne è finito ovunque, dal microcontrollore al mainframe

solo che guarda caso nessuno si lamenta che unix è obsoleto, eppure lo è di più degli x86 ^^

che dire... Fx Pwna!!! xD

da ignorante in materia attendo e spero ansiosamente in una risposta a Fx xD

...rimpiango sempre di piu' i transmeta ed il loro code morphing software; si eliminavano a monte tutte le diatribe tra' efficenza e codice (anzi, si eliminava il concetto di codice nativo)...

ARM e' risc (32bit, tra' l'altro, ed e' per questo che e' un po' stretto per il futuro); a meno di superlativi compilatori, anche il miglior codice fa' poco se non programmato direttamente in linguaggio macchina... ora, per un microcontroller e' fattibile, ma anche per il piu' semplice sistema operativo, compilare qualche milione di righe in codice macchina diventa cosa per pochi eletti (sempre condizionato allo stato d'arte! se poi si esegue un salto in 20 righe, la questino degenera).

x86 ha dei compilatori ottimi, lo hanno anche le varie architetture ARM? (che non e' una sola ma diverse, e tutte l'una differente dall'altra).

un po' come dire che un boing 747 è inefficiente perchè consuma litri di carburante per ogni km... guardare il consumo e basta è piuttosto limitativo

devi vedere anche cosa fa, sinceramente non penso che se devi eseguire delle operazioni computazionalmente pesanti nel general purpose gli arm, i powerpc o chi altro riescano a far di meglio degli x86 a parità di wattora consumati

in altri termini: si, il netbook arm ha la batteria che dura 2 volte di più, ma se per fare gli stessi compiti ci impiega 8 volte tanto rispetto ad un atom allora c'è da rifletterci sopra

se parliamo di idle è un'altra storia però ripeto è come dire che un boing 747 con i motori accesi e fermo consuma di più di un ciao con il motore acceso fermo al semaforo. stiamo paragonando due cose diverse.

il dato di fatto imho è che gli x86 hanno dimostrato due cose nel corso degli anni:
- che pur essendo dati per obsoleti da 20 anni sono i processori di riferimento per diversi segmenti di mercato e in questi non si vede, nemmeno tra i figli di architetture più moderne, l'ombra di un competitor reale (una volta c'erano i 68000, i powerpc, eccetera, oggi morti tutti)
- che hanno dimostrato una flessibilità incredibile, dall'atom agli xeon / opteron sono stati in grado di finire dall'embedded / netbook ai serveroni

cosa che peraltro non hanno dimostrato gli altri

sono un po' lo unix dell'hardware, che è in giro dalla notte dei tempi e che nelle sue incarnazioni moderne è finito ovunque, dal microcontrollore al mainframe

solo che guarda caso nessuno si lamenta che unix è obsoleto, eppure lo è di più degli x86 ^^

Da ignorante in materia leggo che road runner è formato da 7.000 opteron (x86) e 13.000 cell (powerpc). Non direi che siano proprio tutti morti.

Anche se condivido il paragone tra boing e ciao devi vedere anche l'ambito di utilizzo. E' come andare a prendere il figlio a scuola con una utilitaria o con un hummer da 6 litri (stesso uso, vantaggi diversi). Magari per fare un rendering :sofico: un atom ci mette 1/3 del tempo di un cortex (e li atom avrebbe un senso), ma se per aprire una pagina web ci mette 1 secondo meno il gioco non vale la candela. I numeri li ho messi a caso ma servono per rendere il concetto (come il boing e il ciao).

Di fatto l'unica inefficienza delle architettature x86 è il decoder in testa al core RISC (perchè oramai è quello che sono le cpu x86 moderne), ma se è il prezzo da pagare per avere la retrocompatibilità con praticamente tutto il software esistente ... benvenga.

Però in certi ambiti questo prezzo a livello di complessità, consumo e costo è troppo alto. E più il focus si sposta sull'efficienza più gli x86 saranno penalizzati.
Come appunto nei dispositivi ultraportatili.

...rimpiango sempre di piu' i transmeta ed il loro code morphing software; si eliminavano a monte tutte le diatribe tra' efficenza e codice (anzi, si eliminava il concetto di codice nativo)...

Mah, Transmeta non l'ho mai capita!
Bello sfoggio di tecnologia, ok. Ma come potevano sperare EMULANDO un altro codice di competere con prodotti che eseguono codice NATIVAMENTE? Infatti non c'è mai stata competizione.
Appena Intel è stata un po' più attenta a limitare i consumi Transmeta è finita (prima di incominciare, in realtà).

Però in certi ambiti questo prezzo a livello di complessità, consumo e costo è troppo alto. E più il focus si sposta sull'efficienza più gli x86 saranno penalizzati.
Come appunto nei dispositivi ultraportatili.

L'ottimizzazione la si può perseguire anche da quel punto di vista.

Sull'atom il decoder è stato ottimizzato tantissimo tanto che il 96% delle istruzioni non viene spezzettata in micro-operazioni RISC (atom è più simile a un CISC che a un RISC) e sicuramente le iterazioni future dell'atom vedranno una ulteriore ottimizzazione sulla dimensione del decoder.

Ricordiamoci che ATOM è il primo processore x86 che ha come primo obiettivo l'efficienza, non può altro che migliorare da adesso in poi .

Ciao

Beh gli x86 sono per PC non fatti per particolari ambiti come i microcontroller, non mi sebra chissà che notizia.

IMHO
Un microcontroller non indirizza 3GB di ram e non viaggia a 1Ghz!
Gli ARM sono tutto forche dei semplici microcontroller e lì sta il suo successo!

L'ottimizzazione la si può perseguire anche da quel punto di vista.

Sull'atom il decoder è stato ottimizzato tantissimo tanto che il 96% delle istruzioni non viene spezzettata in micro-operazioni RISC (atom è più simile a un CISC che a un RISC) e sicuramente le iterazioni future dell'atom vedranno una ulteriore ottimizzazione sulla dimensione del decoder.

Ricordiamoci che ATOM è il primo processore x86 che ha come primo obiettivo l'efficienza, non può altro che migliorare da adesso in poi .

Ciao


Mi puoi dire la tua fonte ... non mi torna quello che stai dicendo!
Scusa la curiosità ma mi è sempre interessato questo argomento!

Mi puoi dire la tua fonte ... non mi torna quello che stai dicendo!
Scusa la curiosità ma mi è sempre interessato questo argomento!

E' un articolo su Anandtech . Purtroppo non ho più il link , ma è un analisi molto dettagliata dell'architettatura di Atom.

Credo che ti basti cercare "Anandtech Atom" su google e dovrebbe essere uno dei primi risultati.

Ciao

Se vogliono rilasciare netbook con ARM sarà un flop colossale, che preparassero la vaselina. Faranno lo stesso errore dei netbook con linux.
Non hanno capito che l'utente non vede un eeepc come netbook = pc per andare su internet, lo vede come ultraportatile sul quale mettere i programmi a cui è abituato, senza scazzi. Per questo serve windows.

Ora, i netbook con linux alla fine non se la sono cavata troppo male dal momento che comunque si poteva mettere xp crackato... con arm non sarà così. Prepararsi al fail... :doh:

L'efficienza energetica forse...non certo quella di esecuzione. Se non sbaglio sono addirittura in-order...

L'efficienza energetica forse...non certo quella di esecuzione. Se non sbaglio sono addirittura in-order...

Se stai parlando di ATOM (quotare cosa si sta commentando please :ciapet: ) l'obiettivo di intel è ottimizzare il rapporto prestazioni/consumo.

Atom è in-order, ma oltre ad usare alcuni "trucchi" out-of-order su un ristretto set di istruzioni di uso comune usa anche l'hyper-threading per non lasciare in idle la sua seconda unità di esecuzione.

Vedremo come sarà l'evoluzione della cosa. Per me anche ATOM un giorno vedrà o una estensione dei trucchetti "out-of-order" a un maggior numero di istruzioni o una completa implementazione di un core out-of-order.

Intanto con il netbook atom che ho a casa su Mplayer-MT riesco a riprodurre video 1080p in H264 fino a 7-8 Mbps che non è male per una cpu in-order :)

Ciao

Infatti anche Texas (che e' un gigante, e fornisce supporto per la produzione a lunghissimo termine) ha da diverso tempo soluzioni ibride basate su ARM (dal 9 fino al piu' recente Cortex-A8), di solito affiancate ad un DSP per il lavoro sporco.
Quello che riesce a sorprendermi di queste soluzioni ARM e' sempre l'ottimo rapporto Consumo/Prestazioni, mentre dal punto di vista prestazionale puro credo che i PowerPC possano ancora dire la loro.
Riguardo agli x86, dato che scaldano gli animi, nulla da dire, gli ultimi hanno quasi un rendimento di 3 istruzioni per ciclo di clock, ma dal punto di vista dei consumi nel mercato embedded/conduction cooled nel quale lavoro fatichiamo un po' ad adottarli.

Se stai parlando di ATOM (quotare cosa si sta commentando please :ciapet: ) l'obiettivo di intel è ottimizzare il rapporto prestazioni/consumo.

Atom è in-order, ma oltre ad usare alcuni "trucchi" out-of-order su un ristretto set di istruzioni di uso comune usa anche l'hyper-threading per non lasciare in idle la sua seconda unità di esecuzione.

Vedremo come sarà l'evoluzione della cosa. Per me anche ATOM un giorno vedrà o una estensione dei trucchetti "out-of-order" a un maggior numero di istruzioni o una completa implementazione di un core out-of-order.

Intanto con il netbook atom che ho a casa su Mplayer-MT riesco a riprodurre video 1080p in H264 fino a 7-8 Mbps che non è male per una cpu in-order :)

Ciao

scusami, ma mi ha incuriosito una cosa: come fai a vedere fluido un mkv 1080p con cpu Atom se io con un ULV a 1.2 (2Mb di cache) - che è molto più prestante - riesco a vedere fluidi solo quelli a 720p (e con CoreAvc 1.9) ? Se sfrutti anche una gpu è un altro discorso (io no perchè ho una vecchia intel integrata). inoltre, se puoi, puoi dirmi la tua configurazione ? grazie

che dire... Fx Pwna!!! xD

da ignorante in materia attendo e spero ansiosamente in una risposta a Fx xD
Eccomi!
L'architettura x86 non e' inefficiente rispetto agli ARM, e' inefficiente e basta.
E' ovvio che un ARM vada piu' lento (e parecchio) di un x86: e' pensato per soluzioni embedded e punta molto sul risparmio energetico e altre features che su un PC non servono a niente. I processori Intel e AMD, d'altra parte, sono sviluppati con tecnologia allo stato dell'arte e sono incredibilmente ottimizzati con soluzioni hardware all'avanguardia. Inoltre lo sviluppo di compilatori x86 e' decisamente avanzato in confronto a quelli per altre architetture.
Il fatto e' che l'ISA x86 e' vecchio, inadeguato e incredibilmente complesso. I processori x86, per mantenere la retrocompatibilita', sono costretti a implementare in hardware strutture capaci di eseguire tutte le istruzioni dell'ISA (oltre a quelle MMX, SSE, SSE2, SSE3...). "Questo i tecnici della Intel lo sanno benissimo e getterebbero volentieri il set di istruzioni x86 nella baia di San Francisco, se non fosse per le stringenti leggi anti-inquinamento in vigore in California"[1]. Gli stessi programmi, facendo uso di un ISA piu' snello e moderno, consentirebbero di liberarsi di molti "pezzi" del processore, rendendolo piu' piccolo, meno costoso e piu' efficiente.
Tutto il discorso si traduce nel fatto che esistono miliardi di applicazioni "legacy" che nessuno vuole (o sa) riscrivere, quindi cambiare architettura su PC e' semplicemente impossibile in questo momento. Questo comporta che sull'x86 siano stati investiti una quantita' di soldi inimmaginabile, portando i processori Intel compatibili a essere i piu' veloci sul mercato nonostante un ISA pessimo. Su dispositivi embedded questa necessita' di retrocompatibilita' e' di gran lunga ridotta, quindi e' ovvio che qui possano prendere piede anche soluzioni alternative come ARM.
[1] Andrew S. Tanenbaum, Structured Computer Organization, Prentice Hall, 2006

gondsman: sicuramente l'architettura x86 è un legame scomodo per i progettisti di CPU, ma questo legame non crea più problemi come li creava una volta (suddivisione fra istruzioni wired e istruzioni eseguite in microcodice). Attualmente la CPU internamente non esegue più istruzioni x86 e questo per Intel dal P4 e per AMD dal K7. Tutte le istruzioni eseguite sono a lunghezza fissa.
Gli x86 sono al giorno d'oggi anche più evoluti dei Risc. Chiaro che si debba pagare pegno sulla moteplicità, complessità e occupazione di die delle unità di decodifica, ma pagato questo dazio le CPU x86 sono quanto di più avanzato ci sia sul mercato.

Ovvio che molte istruzioni vengano "emulate" o tradotte in combinazioni di altre istruzioni direttamente dal processore, ma se Intel, con le tecnologie che possiede, decidesse di creare un processore con un set di istruzioni "nuovo" sicuramente potrebbe creare qualcosa di molto piu' performante dei suoi attuali x86. Certo il software (specie i compilatori) non ci sarebbe o sarebbe meno sviluppato, cosa che di fatto taglia le gambe ad un'idea del genere...

Ovvio che molte istruzioni vengano "emulate" o tradotte in combinazioni di altre istruzioni direttamente dal processore, ma se Intel, con le tecnologie che possiede, decidesse di creare un processore con un set di istruzioni "nuovo" sicuramente potrebbe creare qualcosa di molto piu' performante dei suoi attuali x86. Certo il software (specie i compilatori) non ci sarebbe o sarebbe meno sviluppato, cosa che di fatto taglia le gambe ad un'idea del genere...
E IA64 ?
Comunque tutte le istruzioni x86 vengono tradotte, spezzettate, unite in istruzioni a lunghezza fissa...questo era appunto uno dei vantaggi delle architetture Risc, che grazie a questo si potevano permettere di adottare soluzioni sicuramente più fantasiose ed efficienti.
Ora questo problema non si sente più, o comunque molto meno.

E IA64 ?
Comunque tutte le istruzioni x86 vengono tradotte, spezzettate, unite in istruzioni a lunghezza fissa...questo era appunto uno dei vantaggi delle architetture Risc, che grazie a questo si potevano permettere di adottare soluzioni sicuramente più fantasiose ed efficienti.
Ora questo problema non si sente più, o comunque molto meno.

Però questo transcoding in istruzioni RISC non è una cosa semplice. E' molto complessa. Anche se sono riusciti dal punto di vista prestazionale a non essere più di tanto penalizzati (e questo era semplicemente impensabile qualche anno fà quando, ad esempio, Apple-Motorola e IBM hanno deciso di sviluppare il PowerPC) comunque si portano appresso una complessità impressionante.

E se questa complessità può essere abbastanza mascherata avendo un "budget" di transistor gigantesco (come hanno ora i processori per PC), non lo è quando si ricerca l'efficienza pura sia in termini di costi (n. di transistor) che di consumo.

Per questo per me l'x86 non ha CHANCE nei dispositivi ultraportatili. E più l'efficienza sarà importante e meno gli x86 saranno competitivi (e ormai la gente compra i notebook o addirittura i netbook, non i desktop). Quindi c'è una piccola speranza che prima o poi FINALMENTE gli x86 scompariranno!!

Per questo per me l'x86 non ha CHANCE nei dispositivi ultraportatili. E più l'efficienza sarà importante e meno gli x86 saranno competitivi (e ormai la gente compra i notebook o addirittura i netbook, non i desktop).
Dal punto di vista energetico hai ragione, porta sicuramente a consumi più alti, ma il vantaggio tecnologico che ha Intel (e qualche anno fa AMD) rispetto alle altre fonderie è tale da mascherare questa carenza.

Dal punto di vista energetico hai ragione, porta sicuramente a consumi più alti, ma il vantaggio tecnologico che ha Intel (e qualche anno fa AMD) rispetto alle altre fonderie è tale da mascherare questa carenza.

Questa è una grande verità .

Quando i propri processori stanno a 32nm e quelli degli altri a 65 o di più la differenza si sente ...

Ricordiamoci che ATOM è il primo processore x86 che ha come primo obiettivo l'efficienza, non può altro che migliorare da adesso in poi .


Puo si migliorare, ma non oltre certi limiti, piu si cerca di migliorare l'efficienza e piu il set d'istruzioni comincia a pesare.

Infatti per reggere la concorrenza nel settore embedded la ARM Ltd. ha introdotto le varianti -M3 ed -M0 dei Cortex che supportano solo le istruzioni Thumb 2 (un sottoinsieme delle istruzioni supportate dagli ARM Cortex "completi") in modo da ridurre drasticamente i consumi "riducendo i transistor"
e "riducendo la lunghezza media delle istruzioni in un programma tipico".

Un approccio del genere con gli x86 non sarebbe conveniente proprio a causa dell'architettura "troppo contorta" che hanno.

Eccomi!
L'architettura x86 non e' inefficiente rispetto agli ARM, e' inefficiente e basta.
E' ovvio che un ARM vada piu' lento (e parecchio) di un x86: e' pensato per soluzioni embedded e punta molto sul risparmio energetico e altre features che su un PC non servono a niente. I processori Intel e AMD, d'altra parte, sono sviluppati con tecnologia allo stato dell'arte e sono incredibilmente ottimizzati con soluzioni hardware all'avanguardia. Inoltre lo sviluppo di compilatori x86 e' decisamente avanzato in confronto a quelli per altre architetture.
Il fatto e' che l'ISA x86 e' vecchio, inadeguato e incredibilmente complesso. I processori x86, per mantenere la retrocompatibilita', sono costretti a implementare in hardware strutture capaci di eseguire tutte le istruzioni dell'ISA (oltre a quelle MMX, SSE, SSE2, SSE3...). "Questo i tecnici della Intel lo sanno benissimo e getterebbero volentieri il set di istruzioni x86 nella baia di San Francisco, se non fosse per le stringenti leggi anti-inquinamento in vigore in California"[1]. Gli stessi programmi, facendo uso di un ISA piu' snello e moderno, consentirebbero di liberarsi di molti "pezzi" del processore, rendendolo piu' piccolo, meno costoso e piu' efficiente.
Tutto il discorso si traduce nel fatto che esistono miliardi di applicazioni "legacy" che nessuno vuole (o sa) riscrivere, quindi cambiare architettura su PC e' semplicemente impossibile in questo momento. Questo comporta che sull'x86 siano stati investiti una quantita' di soldi inimmaginabile, portando i processori Intel compatibili a essere i piu' veloci sul mercato nonostante un ISA pessimo. Su dispositivi embedded questa necessita' di retrocompatibilita' e' di gran lunga ridotta, quindi e' ovvio che qui possano prendere piede anche soluzioni alternative come ARM.
[1] Andrew S. Tanenbaum, Structured Computer Organization, Prentice Hall, 2006

Ciao,
capisco quello che vuoi dire e condivido il fatto che ARM ha un netto margine di vantaggio per quanto riguarda i consumi, ma credo che stai trascurando alcuni aspetti:
1) se è vero che l'ISA x86 non è il massimo, è anche vero che i maggiori grattacapi vengono dati dalle istruzioni x87. Queste istruzioni ormai possono essere in gran parte abbandonate, in quanto le SSE2 permettono di sostituire quasi completamente le istruzioni x87 (per esempio, su tutte le architetture x86-64 il GCC 4.x sfrutta di default le SSE2 al posto delle istruzioni x87);
2) con l'introduzione del set x86-64, AMD ha rimosso diverse istruzioni e opcode raramente utilizzati e ha uniformato in diversi modi le altre istruzioni. Tanto per fare un esempio, è stata rimosso l'opcode di incremento (INC) in quanto c'era già quello di addizione (ADD) che faceva egregiamente il suo lavoro. Altro esempio: è stata rimossa la modalità virtual-386; è questo il motivo per cui i sistemi Windows x64 _non_ fanno girare diversi programmi DOS;
3) è vero che il deconding delle istruzioni CISC nelle micro/macro ops RISC interne porta via spazio sul silicio e un aumento del consumo, ma a livello prestazionale non incide più di tanto in quanto i decoder sono calibrati per alimentare in maniera adeguata il back-end di elaborazione. Oltre a questo, considera che avere un'ISA esterna di tipo CISC comporta un migliore uso della RAM e della cache, in quanto le istruzioni sono più "dense". Uno dei motivi per cui i processori RISC sono stati i primi a usare cache di una certa dimensione (l'Alpha aveva 96 KB di L2 on-die) è proprio perchè le loro istruzioni occupavano, mediamente, più memoria;
4) se parliamo di Atom, i processori ARM sono tutto sommato comparabili in quanto a velocità/capacità. Se però tiriamo in ballo genericamente tutta la famiglia x86, il paragone non regge: seppur in qualche modo penalizzate dalla loro ISA esterna, i processi x86 hanno mostrato una densità di potenza notevole, e si sono fatti strada anche nel mercato dei supercomputer. Ovvio che, oltre una certa soglia, aumentare la velocità del processore sia inefficiente da un punto di vista energetico, ma questo è il prezzo da pagare per avere le migliori prestazioni in assoluto. Per esempio, un'archiettura out-of-order consuma sicuramente di più di una in-order, ma nel codice con molti salti e/o accessi alla memoria è incontestabilmente più veloce.

Detto questo, come giustamente hai fatto notare, anche i progettisti Intel vorrebbero girare pagina e ripartire con un'ISA e un'architettura completamente nuova, e in realtà lo hanno già fatto con ITANIUM. Hanno adottato un'architettura in-order e un ISA VLIW supportati da un back-end di prim'ordine, dando così a quei processori un'efficienza niente male. Nel normale codice applicativo, però, spesso un x86 è più veloce in quanto il codice delle normali applicazioni spesso è poco parallelizzabile ed è pieno di salti condizionali. Nelle applicazioni in cui il core VLIW può stendere la gambe, però, ITANIUM è un missile! ;)

Comunque siamo finito abbastanza off-topic... :D

Ciao. :)

Oltre a questo, considera che avere un'ISA esterna di tipo CISC comporta un migliore uso della RAM e della cache, in quanto le istruzioni sono più "dense". Uno dei motivi per cui i processori RISC sono stati i primi a usare cache di una certa dimensione (l'Alpha aveva 96 KB di L2 on-die) è proprio perchè le loro istruzioni occupavano, mediamente, più memoria;)

Gli ARM sono (credo) gli unici tra i processori RISC ad avere una versione delle istruzioni "compattata", le THUMB-2 (http://en.wikipedia.org/wiki/ARM_architecture#Thumb-2). Questo annulla praticamente l'unico vantaggio teorico dell'architettura CISC rispetto ai RISC.

Ovvio che, oltre una certa soglia, aumentare la velocità del processore sia inefficiente da un punto di vista energetico, ma questo è il prezzo da pagare per avere le migliori prestazioni in assoluto. Per esempio, un'archiettura out-of-order consuma sicuramente di più di una in-order, ma nel codice con molti salti e/o accessi alla memoria è incontestabilmente più veloce

Non è un'esclusiva degli x86 l'architettura Out-of-order. Anzi credo sia nata sui Power IBM (ovviamente RISC). La cosa interessante è che ora IBM l'ha abbandonata nei suoi processori di ultima generazione come i Cell e i Power 6.

Comunque leggevo sull'articolo di wikipedia che una caratteristica "simpatica" dell'ISA degli ARM che è tutte le istruzioni possono essere eseguite condizionalmente. Questo un po' compensa la mancanza della branch-prediction e rende il codice ulteriormente compatto.

Gli ARM sono (credo) gli unici tra i processori RISC ad avere una versione delle istruzioni "compattata", le THUMB-2 (http://en.wikipedia.org/wiki/ARM_architecture#Thumb-2). Questo annulla praticamente l'unico vantaggio teorico dell'architettura CISC rispetto ai RISC.

Vero, ma il set di istruzioni THUMB non è ricco come quello ARM nativo. Da quanto ho letto, è da usare in certe determinate situazioni, spesso in accoppiata al codice ARM. Dato che parliamo di microcontroller, però, il set THUMB è un vantaggio non da poco, dato che è stato inventato proprio per questo spettro di utilizzo.

Non è un'esclusiva degli x86 l'architettura Out-of-order. Anzi credo sia nata sui Power IBM (ovviamente RISC). La cosa interessante è che ora IBM l'ha abbandonata nei suoi processori di ultima generazione come i Cell e i Power 6.

Assolutamente si, l'ooo non è nata su x86. Al momento, però, gli x86 ne sono forse i massimi rappresentanti in quanto ogni iterazione dal K5/P6 in poi ha cercato di aumentare il numero di istruzioni on the fly in un determinato momento.

Riguardo al Cell/Power6: l'utilizzo di uno schema in-order permette di risparmiare parecchi transistor rispetto a un ooo, transistor che possono essere dedicati a "rinforzare" il back-end con un numero maggiore di porte/execution unit. Di conseguenza i processori in-order mostrano spesso performance di picco molto elevate, ma è più difficile mantene elevato il livello di performance medio. La verità, probabilmente, è che tutto dipende dalla tipologia di applicazione che si intende usare: se questa ha pochi salti e accessi alla memoria e, magari, è facilmente parallelizzabile, i core in-order si troveranno a loro agio (non a caso Labaree dovrebbe essere in-order). Viceversa, nell'uso comune di un PC, i processi ooo sono nettamente più veloci.

Comunque leggevo sull'articolo di wikipedia che una caratteristica "simpatica" dell'ISA degli ARM che è tutte le istruzioni possono essere eseguite condizionalmente. Questo un po' compensa la mancanza della branch-prediction e rende il codice ulteriormente compatto.
Questa non la sapevo... grazie dell'interessante info ;)