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

[LMCH]

Originariamente inviato da cdimauro

Purtroppo Motorola decise di mollare i CISC e buttarsi nell'impresa PowerPC, che però, a conti fatti, non so quanto le sia convenuto, visto come sono messi questi processori.

Il problema di Motorola era che negli anni '90 mentre gli x86 anche se più lenti dei RISC, avevano dalla loro la retrocompatibilità con tutto il software per MS-DOS e Windows, mentre per gli MC68xxx non c'era qualcosa di analogo.

C'erano i Mac con quote di mercato in calo, c'erano i vari home computer e poi il settore embedded (infatti è li che gli MC68xxx hanno resistito più a lungo) ma niente di davvero comparabile alla mole di software per x86 (specialmente la tanta roba "aziendale" o "per ufficio") con un utenza così vasta e per cui la retrocompatibilità era più importante di quasi tutto il resto.

Basta pensare ad esempio al' i386 che fu introdotto nel 1985 e che sui desktop computer fu essenzialmente utilizzato per tutta la sua vita come un "8086 più veloce" su cui far girare MS-DOS e poi Windows 3.1
(o al massimo Windows 95 quando ormai era alla fine del suo uso sui dekstop anche se ha continuato ad essere utilizzato molto a lungo su sistemi embedded).

Originariamente inviato da cdimauro

E' vero che oggi rimane soltanto Intel in grado di competere a tutti i livelli con un'architettura CISC. Fortunatamente. Ma anche i RISC si stanno sempre più focalizzando verso una sola architettura: ARM. Ne resteranno soltanto due.

Attualmente ci sono PowerPC ed i POWER, i MIPS, gli ARM, gli Atmel AVR32, i Renesas (ex-Hitachi) SH ed i Renesas RX (anche se in un certo senso sono un ibrido RISC-CISC).
Insomma, c'è ancora una certa varietà.

Per quel che riguarda i dispositivi tipo smartphone e tablet gli ARM dominano, ma nel settore embedded se la devono giocare con gli altri anche se piano piano stanno dominando pure li (principalmente perche "tutti" possono produrre degli ARM risparmiandosi un sacco di costi di R&D e potendo appoggiarsi sull'ecosistema di tool e macrocelle per core periferiche già esistente riducono ulteriormente i costi complessivi).

[cdimauro]

Originariamente inviato da LMCH

Il problema di Motorola era che negli anni '90 mentre gli x86 anche se più lenti dei RISC, avevano dalla loro la retrocompatibilità con tutto il software per MS-DOS e Windows, mentre per gli MC68xxx non c'era qualcosa di analogo.

C'erano i Mac con quote di mercato in calo, c'erano i vari home computer e poi il settore embedded (infatti è li che gli MC68xxx hanno resistito più a lungo) ma niente di davvero comparabile alla mole di software per x86 (specialmente la tanta roba "aziendale" o "per ufficio") con un utenza così vasta e per cui la retrocompatibilità era più importante di quasi tutto il resto.

All'epoca del passaggio a PowerPC Apple aveva una buona quota di mercato, e lo stesso Commodore (Atari, invece, era in declino ormai). Per cui la famiglia 68K poteva ancora continuare, ed era quanto si aspettavano gli amighisti e macisti dell'epoca.

Ecco qui un grafico per Apple:

Apple annunciò il passaggio ai PowerPC nel '94.

Basta pensare ad esempio al' i386 che fu introdotto nel 1985 e che sui desktop computer fu essenzialmente utilizzato per tutta la sua vita come un "8086 più veloce" su cui far girare MS-DOS e poi Windows 3.1
(o al massimo Windows 95 quando ormai era alla fine del suo uso sui dekstop anche se ha continuato ad essere utilizzato molto a lungo su sistemi embedded).

Beh, il modo di usare i 32-bit e la maggior quantità di memoria c'era anche all'epoca del DOS, e infatti si sfruttava. Ci furono i cosiddetti DOS Extender, con un sacco di giochi che giravano, ad esempio.

Attualmente ci sono PowerPC ed i POWER, i MIPS, gli ARM, gli Atmel AVR32, i Renesas (ex-Hitachi) SH ed i Renesas RX (anche se in un certo senso sono un ibrido RISC-CISC).
Insomma, c'è ancora una certa varietà.

Per quel che riguarda i dispositivi tipo smartphone e tablet gli ARM dominano, ma nel settore embedded se la devono giocare con gli altri anche se piano piano stanno dominando pure li (principalmente perche "tutti" possono produrre degli ARM risparmiandosi un sacco di costi di R&D e potendo appoggiarsi sull'ecosistema di tool e macrocelle per core periferiche già esistente riducono ulteriormente i costi complessivi).

Infatti è proprio di questo che parlavo: ormai c'è una convergenza verso ARM. Freescale, ex Motorola, già da anni propone SoC ARM. L'ultimo report POWER parla di perdite di quote di mercato in favore di ARM e x86. Non so come siano messe le altre realtà, ma credo che la situazione non sia molto diversa.

[LMCH]

Originariamente inviato da cdimauro

All'epoca del passaggio a PowerPC Apple aveva una buona quota di mercato, e lo stesso Commodore (Atari, invece, era in declino ormai). Per cui la famiglia 68K poteva ancora continuare, ed era quanto si aspettavano gli amighisti e macisti dell'epoca.

Ma i quantitativi di chip prodotti erano inferiori a quelli che invece macinavano i produttori di cpu x86, come pure i margini di guadagno.
Inoltre se la retrocompatibilita fosse stata così importante come negli x86, avrebbero continuato a far evolvere gli MC68000.

Originariamente inviato da cdimauro

Beh, il modo di usare i 32-bit e la maggior quantità di memoria c'era anche all'epoca del DOS, e infatti si sfruttava. Ci furono i cosiddetti DOS Extender, con un sacco di giochi che giravano, ad esempio..

Ma il grosso del software per cui esisteva il requisito della retrocompatibilità non era così.
Solo con Windows 95 è iniziata la vera transizone verso i 32bit delle applicazioni per x86.

Originariamente inviato da cdimauro

Infatti è proprio di questo che parlavo: ormai c'è una convergenza verso ARM. Freescale, ex Motorola, già da anni propone SoC ARM. L'ultimo report POWER parla di perdite di quote di mercato in favore di ARM e x86. Non so come siano messe le altre realtà, ma credo che la situazione non sia molto diversa.

La tendenza è tutta a favore di ARM principalmente perche ARM Ltd viene vista come un fornitore "neutrale" che non favorisce nessuno ed offre una gamma di opzioni di licenza e di IP adatte a gran parte del mercato.
Ma ad esempio Renesas continua a spingere il suo RX nella fascia bassa dei 32bit (specialmente nel settore automotive, se ricordo bene).
Anche MIPS non è così spacciato come alcuni pensano ed Immagination Technologies li sta rilanciando con nuovi core sia per il settore embedded che per dispositivi mobili.

[cdimauro]

Originariamente inviato da LMCH

Ma i quantitativi di chip prodotti erano inferiori a quelli che invece macinavano i produttori di cpu x86, come pure i margini di guadagno.

I PC vendevano di più, senz'altro, ma erano anche più cari. Questo anche perché Intel aveva sostanzialmente il dominio: lei faceva uscire fuori i nuovi processori, e soltanto tempo dopo i concorrenti proponevano prodotti competitivi (ma nel frattempo Intel si faceva pagare).

Inoltre se la retrocompatibilita fosse stata così importante come negli x86, avrebbero continuato a far evolvere gli MC68000.

La retrocompatibilità era molto importante, ma il problema più grosso qui era Motorola, che se ne sbatteva altamente e rilasciava processori incompatibili in supervisor mode, e addirittura in user mode.

Questo costringeva le aziende che facevano uso dei suoi processori a mettere delle pezze ad hoc, ma ciò non era sempre possibile (vedi alcuni giochi Amiga, che non funzionavano sul 68060 proprio perché mancavano delle istruzioni, e alcune realmente utili, come la moltiplicazione 32x32->64 bit).

Siccome non c'erano altri produttori di CPU 68K, si doveva sottostare ai capricci di Motorola.

Ma il grosso del software per cui esisteva il requisito della retrocompatibilità non era così.

Immagino che ti riferisca alle applicazioni, e non ai giochi qui, giusto?

Penso di sì. Non ne ricordo tanti che fossero approdati ai 32-bit.

Per i giochi, invece, il discorso era ben diverso: hanno fatto presto uso di DOS-Extender, e mi pare ovvio che così fosse. Inoltre i giochi sono soggetti a una rapida obsolescenza, per cui la retrocompatibilità in questo caso non è così importante, anche se veniva mantenuta ugualmente (sia dalla CPU, sia dalle schede video).

Solo con Windows 95 è iniziata la vera transizone verso i 32bit delle applicazioni per x86.

Senz'altro. D'altra parte Windows 3 aveva fatto il suo tempo, e i processori a 32-bit erano molto diffusi e decisamente più economici.

La tendenza è tutta a favore di ARM principalmente perche ARM Ltd viene vista come un fornitore "neutrale" che non favorisce nessuno ed offre una gamma di opzioni di licenza e di IP adatte a gran parte del mercato.

Esattamente. Questo consente anche di eliminare i costi di R&D per il processore, se si vuole.

Ma ad esempio Renesas continua a spingere il suo RX nella fascia bassa dei 32bit (specialmente nel settore automotive, se ricordo bene).

Ho dato un'occhiata, e ha sviluppato un microntroller CISC ad alte prestazioni allo scopo. Molto interessante.

Purtroppo ho visto pure che non ha più sviluppato l'architettura RX, ma offre microcontroller basati su ARM, SuperH, e un'altra architettura RISC che mi sembra proprietaria. E' su quest'ultima che sembra stia spingendo molto.

Anche MIPS non è così spacciato come alcuni pensano ed Immagination Technologies li sta rilanciando con nuovi core sia per il settore embedded che per dispositivi mobili.

Hum... Si leggono poche notizie in merito. Ma nel settore mobile è già molto dura per Intel, per cui non so quanto spazio possa trovare.

[LMCH]

Originariamente inviato da cdimauro

Ho dato un'occhiata, e ha sviluppato un microntroller CISC ad alte prestazioni allo scopo. Molto interessante.

No, semmai si potrebbe dire che è più simile ad un ARM, nel senso che anche esso aveva sin dal principio certe caratteristiche "da CISC", ma il parametro di riferimento è l'efficienza di esecuzione ed il supporto delle istruzioni ritenute importanti per raggiungere quell'obiettivo.

Originariamente inviato da cdimauro

Purtroppo ho visto pure che non ha più sviluppato l'architettura RX, ma offre microcontroller basati su ARM, SuperH, e un'altra architettura RISC che mi sembra proprietaria. E' su quest'ultima che sembra stia spingendo molto.

Se ti riferisci all' RH850 è un evoluzione del V850 ex-NEC, solo per il settore automotive.

L'architettura RX continua ad essere sviluppata, solo che il set d'istruzioni non cambia più di tanto, recentemente hanno introdotto RXv2 per le due nuove linee di fascia più alta (il primo prodotto di quel tipo dovrebbe essere il SoC RX64M), visto che si concentrano su applicazioni embedded tipo controllo di motori/azionamenti e macchinari industriali in generale l'enfasi e produrre nuovi SoC con il giusto mix di periferiche/ram/flash con giusto la potenza di calcolo che serve (e semmai consumi bassi, ecc. ecc.).

Ma "si tengono bassi" perche l'RX non è fatto per dare battaglia nelle fascie più alte.

[cdimauro]

Originariamente inviato da LMCH

No, semmai si potrebbe dire che è più simile ad un ARM, nel senso che anche esso aveva sin dal principio certe caratteristiche "da CISC", ma il parametro di riferimento è l'efficienza di esecuzione ed il supporto delle istruzioni ritenute importanti per raggiungere quell'obiettivo.

Tengono molto alla densità del codice e al fatto di privilegiare le istruzioni più corte, così possono anche eseguire il fetch di più istruzioni con una sola lettura dalla memoria.

Comunque è un design propriamente CISC: le istruzioni arrivano fino a 8 byte di lunghezza, e consentono di specificare immediati a 32 bit, eseguire operazioni in memoria con eventuale immediato, e pure istruzioni di copia memoria-memoria.

ARM ha preso alcune caratteristiche dei CISC (LDM/STM in primis, e modalità d'indirizzamento più complesse), ma tolto questo rimane un design rigorosamente RISC.

Se ti riferisci all' RH850 è un evoluzione del V850 ex-NEC, solo per il settore automotive.

Sì, è quello.

L'architettura RX continua ad essere sviluppata, solo che il set d'istruzioni non cambia più di tanto, recentemente hanno introdotto RXv2 per le due nuove linee di fascia più alta (il primo prodotto di quel tipo dovrebbe essere il SoC RX64M), visto che si concentrano su applicazioni embedded tipo controllo di motori/azionamenti e macchinari industriali in generale l'enfasi e produrre nuovi SoC con il giusto mix di periferiche/ram/flash con giusto la potenza di calcolo che serve (e semmai consumi bassi, ecc. ecc.).

Sì, esatto: non vedo cambiamenti all'ISA da un pezzo.

Ma "si tengono bassi" perche l'RX non è fatto per dare battaglia nelle fascie più alte.

Perché non vogliono o perché ci sono dei limiti intrinseci dell'archiettura RX? Voglio dire, col processo a 40nm che usano potrebbero superare i 100Mhz a cui sono fermi adesso, oppure implementare un design superscalare.

[LMCH]

Originariamente inviato da cdimauro

Tengono molto alla densità del codice e al fatto di privilegiare le istruzioni più corte, così possono anche eseguire il fetch di più istruzioni con una sola lettura dalla memoria.

Comunque è un design propriamente CISC: le istruzioni arrivano fino a 8 byte di lunghezza, e consentono di specificare immediati a 32 bit, eseguire operazioni in memoria con eventuale immediato, e pure istruzioni di copia memoria-memoria.

Le apparenze ingannano.
L'allocazione degli opcode e delle modalita di indirizzamento, come nello sviluppo dei RISC sono state basate su un analisi molto approfondita del codice generato dai compilatori delle cpu tipicamente usate in ambito embedded.
Le istruzioni di indirizzamento "complesse" sono eseguite in un singolo ciclo da un unita dedicata e se non sbaglio non vi è uso di microcodice.
Solo le DIV ed istruzioni "lunghe" che richiedono il fetch di più word e quelle che leggono/scrivono dalla memoria o richiedono lo svuotamento della pipeline (i branch se vengono eseguiti) richiedono più di un ciclo.
In pratica è un "RISC con priorità alla compattezza del codice" (seguita dall'efficienza) per applicazioni embedded.

Per questo ad esempio ci sono più istruzioni dedicate per manipolare i singoli bit (cosa molto più frequente con roba embedded che manipola registri di I/O e cose simili) e nelle modalita di indirizzamento si usano indici (il valore viene "implicitamente moltiplicato" per la dimensione del tipo di dato a cui si accede) invece che "semplici" offset.

Originariamente inviato da cdimauro

ARM ha preso alcune caratteristiche dei CISC (LDM/STM in primis, e modalità d'indirizzamento più complesse), ma tolto questo rimane un design rigorosamente RISC.

E l'esecuzione condizionale di quasi tutte le istruzioni, una cosa che per la "filosofia RISC" è un vero anatema visto che moltissime istruzioni verranno per forza eseguite molto raramente, ma che permette di avere l'equivalente di "jump brevi" ultra-efficienti senza usare la branch prediction e senza i casini di uno svuotamento completo delle pipeline.

Originariamente inviato da cdimauro

Perché non vogliono o perché ci sono dei limiti intrinseci dell'archiettura RX? Voglio dire, col processo a 40nm che usano potrebbero superare i 100Mhz a cui sono fermi adesso, oppure implementare un design superscalare.

RX nasce per sostituire tutta una serie di cpu/microcontroller "ereditate" dalle aziende di produzione di dispositivi per semiconduttori che sono confluite in Renesas (gli M32 ecc. della Mitsubishi e gli H8/300H, H8/S, H8/RX di Hitachi).
Per roba che richiede più potenza o funzionalità "multimediali" hanno gli SH e gli ARM.
Per l'automotive hanno i V850 (ed ora RH850).
Per roba "più piccola" hanno gli R8 ed RL78.

In pratica è nato per evitare di dover continuare a sviluppare due linee di prodotto che praticamente avevano le stesse tipologie d'uso (facendo confluire verso di esso chi le utilizzava) e che non si potevano far evolvere più di tanto.
Non salgono di clock perche per le tipologie d'uso e per i quantitativi prodotti spesso contano di più i consumi bassi ed il costo ridotto (per questo la compattezza del codice ed anche il non dover pagare un centesimo per IP altrui aiuta in tal senso) e la potenza di calcolo è già piu che buona.
La nuova versione di punta arriva a 240Mhz, ma il grosso di quelli venduti probabilmente continueranno ad essere quelli da 100Mhz o da 50Mhz (che vanno a rimpiazzare roba spesso molto più lenta e con minor efficienza di esecuzione).

[cdimauro]

Originariamente inviato da LMCH

Le apparenze ingannano.
L'allocazione degli opcode e delle modalita di indirizzamento, come nello sviluppo dei RISC sono state basate su un analisi molto approfondita del codice generato dai compilatori delle cpu tipicamente usate in ambito embedded.

Questa è una cosa che mi aspetto da un'architettura nuova, e col tempo necessario per studiare questi aspetti, usando gli strumenti già a disposizione.

Anch'io ho eseguito un approccio simile per le ISA che ho inventato, ma le mie architetture rimangono rigorosamente CISC (una ispirata al 68K, e un'altra a x64).

Le istruzioni di indirizzamento "complesse" sono eseguite in un singolo ciclo da un unita dedicata e se non sbaglio non vi è uso di microcodice.

Un'AGU generalmente non fa uso di microcodice, per quanto complessa sia la modalità d'indirizzamento. L'unica eccezione potrebbe essere forse il 68020+, con le sue modalità a doppia indirezione della memoria, ma magari si risolve con qualche altro stadio della pipeline.

Solo le DIV ed istruzioni "lunghe" che richiedono il fetch di più word e quelle che leggono/scrivono dalla memoria o richiedono lo svuotamento della pipeline (i branch se vengono eseguiti) richiedono più di un ciclo.

Questo è normale: anche un RISC ha istruzioni più complesse o che dipendono da dati in memoria, e che richiedono più cicli di clock per essere eseguite.

In pratica è un "RISC con priorità alla compattezza del codice" (seguita dall'efficienza) per applicazioni embedded.

Per questo ad esempio ci sono più istruzioni dedicate per manipolare i singoli bit (cosa molto più frequente con roba embedded che manipola registri di I/O e cose simili)

Certamente, questo me lo sarei aspettato.

e nelle modalita di indirizzamento si usano indici (il valore viene "implicitamente moltiplicato" per la dimensione del tipo di dato a cui si accede) invece che "semplici" offset.

E' un'ottima soluzione per migliorare la compatezza del codice. Intel l'ha introdotta con Larrabee / Xeon Phi, per l'estensione SIMD.

Tornando a RX, è chiaro che abbiano privilegiato l'esecuzione in un solo ciclo di clock delle istruzioni più comuni e compatte. Però la presenza di istruzioni a lunghezza variabile, con immediati "lunghi" (fino a 32-bit), operazioni su dati in memoria e copia memoria-memoria sono segni distintivi di un'architettura CISC.

D'altra parte oggi molti CISC, anche non pensati appositamente allo scopo, eseguono istruzioni in un ciclo di clock, e sono quelle più comuni / semplici.

E l'esecuzione condizionale di quasi tutte le istruzioni, una cosa che per la "filosofia RISC" è un vero anatema visto che moltissime istruzioni verranno per forza eseguite molto raramente, ma che permette di avere l'equivalente di "jump brevi" ultra-efficienti senza usare la branch prediction e senza i casini di uno svuotamento completo delle pipeline.

Credo che sia stata introdotta proprio per evitare di inserire nel processore tecniche come queste, mantenendo dunque il core (e soprattutto la pipeline) molto piccolo e semplice. Oggi sei in ogni caso costretto a utilizzare unità di branch prediction, per cui a posteriori la scelta non è stata buona e diventa un fardello da portarsi dietro (eliminato con ARMv8, comunque).

Non so, però, se questa funzionalità si possa classificare come contraria alla filosofia RISC. In fin dei conti i RISC sono nati per avere poche, semplici, istruzioni da eseguire in un ciclo di clock (cosa che non è più vera da un pezzo per i RISC), ma le istruzioni non sono tutte simili e la loro frequenza è strettamente legata all'ambito di utilizzo.

Per fare un esempio, l'istruzione ADD è un must-have ovviamente, ma rispetto a una MOVE o una LOAD/STORE si tratta di un'istruzione decisamente rara. Ancora peggio per istruzioni come AND, OR, XOR, e NOT, che pure sono fra le più usate. Qui, in un mio pezzo su x86 & x64, trovi qualche numero che, pur essendo legato strettamente a queste architetture, può comunque fornire qualche dato anche per altre architetture, e dove spicca in particolare la frequenza delle istruzioni di salto condizionale.

Per concludere, se dovessimo prendere a modello di riferimento soltanto la frequenza per decidere dell'implementazione o meno di qualcosa, credo che l'esecuzione condizionale delle istruzioni possa trovare un posto privilegiato rispetto a tante istruzioni ben più note.

RX nasce per sostituire tutta una serie di cpu/microcontroller "ereditate" dalle aziende di produzione di dispositivi per semiconduttori che sono confluite in Renesas (gli M32 ecc. della Mitsubishi e gli H8/300H, H8/S, H8/RX di Hitachi).
Per roba che richiede più potenza o funzionalità "multimediali" hanno gli SH e gli ARM.
Per l'automotive hanno i V850 (ed ora RH850).
Per roba "più piccola" hanno gli R8 ed RL78.

In pratica è nato per evitare di dover continuare a sviluppare due linee di prodotto che praticamente avevano le stesse tipologie d'uso (facendo confluire verso di esso chi le utilizzava) e che non si potevano far evolvere più di tanto.
Non salgono di clock perche per le tipologie d'uso e per i quantitativi prodotti spesso contano di più i consumi bassi ed il costo ridotto (per questo la compattezza del codice ed anche il non dover pagare un centesimo per IP altrui aiuta in tal senso) e la potenza di calcolo è già piu che buona.
La nuova versione di punta arriva a 240Mhz, ma il grosso di quelli venduti probabilmente continueranno ad essere quelli da 100Mhz o da 50Mhz (che vanno a rimpiazzare roba spesso molto più lenta e con minor efficienza di esecuzione).

Capito. Tra l'altro non avevo visto che il modello di punta arriva a 240Mhz, che consente prestazioni abbastanza elevate per l'ambito di utilizzo.