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

cdimauro

02-08-2014, 07:26

e impedire che la concorrenza, alias amd, faccia lo stesso.:rolleyes:
Da quando AMD è concorrente di Intel in questo campo?
Forse se Intel oltre ad aver azzerato il proprio margine su questi chip pagasse anche per ogni pezzo venduto riuscirà a raggiungere la quota di 40 milioni di pezzi.
Il problema è che il buco in bilancio da 4 miliardi l'anno che questo tentativo di entrare nel mercato dei SoC le procura potrebbe ulteriormente aumentare. Non so quanto possa fare contenti gli investitori e non so cosa può mai significare: piazzare sul mercato 40 milioni di SoC x86 gratis o quasi che impatto può mai avere in un mercato che smercia quasi un milardo di SoC ARM l'anno?
Evidentemente sì.
Non è che i costruttori, a meno di altre minacce, si affezionano a un fornitore piuttorsto che ad un altro. Il cambio dei componenti nei prodotti mobile è altissimo (basta vedere Sony che ha messo un po' di tutto in questi anni nei propri). Appena Intel sfora il prezzo rispetto alla concorrenza viene lasciata a piedi in un battibaleno (come detto a meno di altro tipo di intimidazioni che Intel può portare in altri campi dove è monopolista).
Intel ha già avuto problemi in passato, e non credo che le piacerebbe averne altri. Per cui l'ipotesi di minacce et similia rimane soltanto una fantasia.

Per il resto non è più monopolista già da quando ha ceduto la licenza della sua architettura IA-32.
E dove non ha concorrenza (tablet Windows) il prezzo deve rimanere concorrenziale ai tablet ARM, e quindi non c'è storia che tenga. Se Intel non riesce a fare profitti oggi non li riuscirà a fare neanche l'anno prossimo o tra 10, sopratutto ora che il vantaggio del processo produttivo sta venendo meno.
Diversificare ha i suoi costi. Ma a lungo termine credo che porterà i suoi vantaggi.
Ed i chip LTE, Wifi, GPS non sono a buon mercato, insieme costano più del soc stesso.

Il problema maggiore di Intel è che deve affrontare un mercato, quello mobile, che è molto concorrenziale e non è abituata.
Se uno guarda alla storia d'Intel, è evidente che hanno operato sempre in settori dove sono stati leader.
Laddove non lo erano, penso ad esempio alle cpu mainframe (Itanium), gpu (Larrabee/Phi) o soc mobile (Atom), hanno avuto sempre molte più difficoltà.

Se Intel vuole vendere "a costo" contro le soluzioni Mediatek, Rockchip o Allwinner e batterli sul fronte prezzi, penso che avrà vita difficile.
Basti vedere quante difficoltà stanno incontrando Qualcomm e Samsung nell'affrontare il mercato low cost.
Non credo che l'obiettivo di Intel sia quello di competere coi produttori cinesi. Personalmente penso che siano Qualcomm e Samsung i concorrenti di riferimento per lei.

Anche se Samsung è veramente strana come azienda, perché si affida anche a Qualcomm, e a volte pure a Intel, per i suoi prodotti.
Il dumping è vietato dalle regole internazionali del commercio.
Vendere sotto costo per lungo periodo è dumping.
A meno che l'USA non ora faccia più parte del WTO, direi che le regole si applicano anche a lei.
Infatti non si parla di dumping: basta leggere il pezzo, e si capisce subito come stiano le cose.
Più passa il tempo e più le fonderie stanno diventando un'arma a doppio taglio: in passato è stato sicuramente un grande vantaggio, oggi forse non è più così.
Guardando le spese attuali e le previsioni per aggiornare gl'impianti:

http://www.pcb007.com/articlefiles/99205-26-Mar-14-ICInsights.jpg

sarà sempre più difficile. http://www.pcb007.com/articlefiles/99205-26-Mar-14-ICInsights.jpg
Vedo ad esempio che Samsung ha difficoltà nel proporre Exynos in fascia bassa a scapito di Mediatek.

P.S.: Preso da qui:
http://www.pcb007.com/pages/zone.cgi?a=99205
Sbaglio o, da quella tabella, Intel e Samsung investono all'incirca allo stesso modo, mentre sono gli altri ad avere problemi d'investimento per le loro fabbriche?
Certo il dumping, cioe' vendere un bene al di sotto del costo di produzione, e questo non e' assolutamente il caso, qui si parla di marginare molto poco e di sopperire ad alcune mancanze "tecniche" con i costi di supporto.

Premesso che di problemi ne state parlando voi e che di azioni legali in quest'ambito non c'e' ombra, ma Intel non e' assolutamente in posizione dominante in questo campo, quindi problemi non ne esistono.
Concordo in toto.
Per ora non ci sono azioni legali, ma non è detto che non arriveranno denunce.

Del resto il comportamento che hai descritto nella frase precedente è lo stesso che ha portato alla multa dell'UE.

Ma bisogna sempre vedere cosa penserà l'antitrust nel caso arrivi una denuncia da AMD ( non vedo chi altri potrebbe denunciare Intel ). Personalmente non ho mai capito come ad identificare i casi in cui multare.
Forse perché NON sussistono le condizioni? Ma puoi sempre dimostrare che non sia così.
AMD non si abbasserà a queste meschinità (che oltretutto non sono nel suo stile), semplicemente perchè non ne avrà bisogno: infatti sarebbe nei suoi piani entrare nel mobile sfruttando i soc ARM in partnership com ARM stessa ... sempre ammesso che tale progetto prenda piede, perchè ormai comincia ad essere tardi, per lei come per Intel, e poi non ha da buttare i fiumi di soldi e di risorse che Intel sta bruciando allo scopo, ne' gode delle ingenti sovvenzioni statali e dei favoritismi della stessa.
Di quali sovvenzioni e favoritismi parli? Potresti riportare le fonti, cortesemente? Grazie.
Per l'ineffabile Intel sfondare nel mobile con i suoi accrocchi X86 del tutto inadatti allo scopo
Che siano inadatti chi l'ha stabilito? Tu? Su quali basi? Spiega pure, perché sono molto curioso.

Nel frattempo forse potresti dare un'occhiata ai prodotti basati su SoC Intel, e vedere come si comportano a livello di prestazioni e consumi. Magari è un bel pezzo che non lo fai, e ti saranno sfuggiti parecchi cambiamenti.
oltrechè carenti di TUTTE le funzioni che caratterizzano le piattaforme mobili,
Anche altri competitori non offrono tutte le funzioni su singolo SoC. Mi pare che Qualcomm sia l'unico produttore a offrire un SoC unico per tutto, incluso il model LTE, mentre tutti gli altri hanno bisogno di chip esterni.

Per cui Intel non è messa bene da questo punto di vista, certamente, ma non è l'unica. Inoltre ha ampi margini di recupero che porteranno a chip ancora più competitivi quando quelle funzionalità saranno integrati sui suoi SoC.
è solo e soltanto una questione di mero puntiglio per mostrare al mondo la sua assoluta potenza in terra, in cielo ed in ogni luogo, un'operazione (a perdere) che solo lei, nel suo delirio di onnipotenza, può ritenere una mossa di strategia vincente (bah,,,?)
Perché non dovrebbe? E' un mercato interessante e con parecchi numeri.
che la porterebbe a dominare un settore, quello mobile, dove lei, sotto tutti gli aspetti, proprio non ci azzecca per niente....
Su questo attendo le tue informazioni.
Che faccia pure, somo in tanti seduti sulla sponda del fiume ad aspettare il transito del cadavere Wintel (si, Wintel, non solo Intel, e non per gufare, ma per puro desiderio di un po' di giustizia in questo mondo).
Sarà da una trentina d'anni che lo sento ripetere, ma Intel è ancora lì...
Rispetto al passato (quando i margini di guadagno erano più alti) possiedere una fonderia è vantaggioso solo se riesci a gestirla molto bene
(produzione al massimo possibile, avere una "strategia di rottamazione" sul medio-lungo termine per passarla ad altre produzioni o almeno rivenderla ad altri che non ti facciano poi concorrenza, ecc.).

Intel con i margini di guadagno che aveva sulle cpu si poteva permettere di essere meno efficiente sul lato fab (specialmente nella fase iniziale di messa in produzione di nuovi chip) ed al tempo stesso investire con largo anticipo su nuove fab ancora più avanzate.
Ora si è ritrovata a ridurre i piani per nuove fab perchè si è ritrovata con fab sottoutilizzate e si è messa ad offrire le sue capacità di produzione a terzi pur di limitare i danni ed avere sufficiente produzione da non trasformare le sue fab in un buco nero di soldi.
Purtroppo è calato il mercato desktop, e parte dell'utenza s'è trasferita su tablet et similia: è questo il nocciolo della questione.

Lato desktop l'emorragia è finalmente rallentata, e addirittura nell'ultimo quarto c'è stato un'inversione di tendenza.

Viceversa il mercato tablet sta subendo un rallentamento, mentre gli Ultrabook hanno riguadagnato terreno e si stanno facendo avanti le soluzioni 2:1.

A mio avviso si stanno delineando le condizioni per una ripresa, nonché ritorno a tempi migliori.

Fermo restando che una fabbrica costa certamente più adesso rispetto al passato, ma investire in nuovi processi produttivi rimane ancora conveniente (infatti, pur con tutti i problemi, anche la concorrenza ci si sta buttando).
L'eventuale denuncia verrà da chi opera nel mercato mobile, quindi non tanto o non solo da parta AMD ma sopratutto da parte ARM, Samsung, ecc... e da chi di denunce ci vive, Apple...
Questo ha ancora meno senso rispetto a quello che diceva pabloski.

Ribadisco: su quale base? Potresti mostrare le fondamenta di un tale ricorso?

Ares17

02-08-2014, 10:19

Certo il dumping, cioe' vendere un bene al di sotto del costo di produzione, e questo non e' assolutamente il caso, qui si parla di marginare molto poco e di sopperire ad alcune mancanze "tecniche" con i costi di supporto.

Premesso che di problemi ne state parlando voi e che di azioni legali in quest'ambito non c'e' ombra, ma Intel non e' assolutamente in posizione dominante in questo campo, quindi problemi non ne esistono.

La maggiorparte dei costi sono dovuti a ricerca-sviluppo-infrastrutture tutte cose che non ricadono nel cosidetto prezzo di produzione.
Un soc a stento costerà 2€ produrlo (materia prima, manodopera, costi energetici), la bilancia del rendiconto finanziario può essere in estremo rosso, ma non si tratta di dumping.

pabloski

02-08-2014, 11:15

Un soc a stento costerà 2€ produrlo (materia prima, manodopera, costi energetici), la bilancia del rendiconto finanziario può essere in estremo rosso, ma non si tratta di dumping.

Questo è vero ed è indice che i prezzi delle cpu x86 sono parecchio gonfiati ( considerando che le economie di scala ci sono ).

cdimauro

02-08-2014, 11:53

Questo è vero ed è indice che i prezzi delle cpu x86 sono parecchio gonfiati ( considerando che le economie di scala ci sono ).
Gonfiati? Intel non naviga nell'oro, ma le cose vanno abbastanza bene fortunatamente. Cosa vorresti, che i prodotti le regalasse? Poi il bilancio lo fai quadrare tu, però.

Ma tu guarda che mi tocca sentire da questi geni improvvisati della finanza...

pabloski

02-08-2014, 12:00

Gonfiati? Intel non naviga nell'oro, ma le cose vanno abbastanza bene fortunatamente. Cosa vorresti, che i prodotti le regalasse? Poi il bilancio lo fai quadrare tu, però.

Ma tu guarda che mi tocca sentire da questi geni improvvisati della finanza...

Dovresti leggere il post di Ares17 ed integrarlo col mio, prima di criticare a vanvera.

cdimauro

02-08-2014, 12:11

Li ho letti entrambi. Sei tu che hai tagliato la parte più importante del suo commento...

Littlesnitch

02-08-2014, 12:30

L'eventuale denuncia verrà da chi opera nel mercato mobile, quindi non tanto o non solo da parta AMD ma sopratutto da parte ARM, Samsung, ecc... e da chi di denunce ci vive, Apple...

La scemenza quotidiana non può ami mancare. Sarebbe interessante sapere su che base Apple potrebbe far causa a intel? Poi tra tutti quelli che hai citato Apple è quella che avrebbe meno interesse a mettersi contro intel. Anzi se un domani intel dovesse fornire Soc a buon mercato con prestazioni superiori ad Arm Apple sarebbe trai i primi ad adottarli....

pabloski

02-08-2014, 14:53

Li ho letti entrambi. Sei tu che hai tagliato la parte più importante del suo commento...

Ma ne ho tenuto conto. Il punto è che la ricerca e sviluppo è quella che incide maggiormente sul costo del prodotto ( penso si possa essere d'accordo su questo punto ). La produzione, invece, ha una bassa incidenza grazie alle economie di scala.

Considerando che così come Intel e AMD fanno R&D, vale lo stesso per ARM e i vari produttori di SoC ARM. Ed è lecito supporre che i costi di ricerca siano più o meno dello stesso ordine di grandezza. Dunque il maggior costo delle cpu x86 è imputabile a:

1. produzione ( ma vorrebbe dire che le economie di scala nella produzione x86 sono inferiori rispetto alla concorrenza )
2. marketing
3. sconti

Il terzo punto è quello che può far infuriare il cliente retail, il quale non gode di tale sconti ma paga per gli sconti che vengono fatti agli OEM e ad altri soggetti.

E' un qualcosa su cui riflettere.

cdimauro

02-08-2014, 15:52

ARM si ferma alla sola ricerca & sviluppo dell'ISA del processore, mentre Intel si occupa della produzione, e possiede anche delle fabbriche. Per cui non possono essere messe sullo stesso piano.

La realtà che più si avvicina a Intel è Samsung, che però prende in licenza proprio da ARM i processori, e non è nota per avere una grande creatività per lo sviluppo dell'architettura.

Oltre al fatto che hanno anche attività diversificate: Samsung opera anche nel campo dei display, degli hard disk, stampanti, ecc. ecc., mentre il core business di Intel è il silicio, con focus sui processori (e GPU).

A parte questo, se Intel guadagnasse 10 volte (per sparare un numero) rispetto a quanto spende, avresti anche ragione a lamentarti, ma siamo ben sotto.

Ci sono multinazionali che guadagnano molto di più, e di cui però non t'ho mai visto lamentarti. Al contrario...

Ares17

02-08-2014, 15:57

Ma ne ho tenuto conto. Il punto è che la ricerca e sviluppo è quella che incide maggiormente sul costo del prodotto ( penso si possa essere d'accordo su questo punto ). La produzione, invece, ha una bassa incidenza grazie alle economie di scala.

Considerando che così come Intel e AMD fanno R&D, vale lo stesso per ARM e i vari produttori di SoC ARM. Ed è lecito supporre che i costi di ricerca siano più o meno dello stesso ordine di grandezza. Dunque il maggior costo delle cpu x86 è imputabile a:

1. produzione ( ma vorrebbe dire che le economie di scala nella produzione x86 sono inferiori rispetto alla concorrenza )
2. marketing
3. sconti

Il terzo punto è quello che può far infuriare il cliente retail, il quale non gode di tale sconti ma paga per gli sconti che vengono fatti agli OEM e ad altri soggetti.

E' un qualcosa su cui riflettere.
Mettiamola così:
Secondo la tua opinione tagliare un asse di legno costa la manodopera necessaria ed il costo energetico, e questi sono i costi di produzione propriamente detti.
Invece il costo effettivo è dato dal costo della trocatrice, da quella dell'affilatura, da quello di manuntenzione, da quella di cambiare la lama ogni tot ora, dai magazzini e dai carrelli per stipare il materiale, dal costo del capannone, dal costo della logistica, dal costo del marketing, dal costo della raggiatrice e del cavo per raggiare, ecc ecc.
Quindi il costo di produzione di un asse tagliato è di fatto un millesimo del costo di vendita, ma a stento l'utile arriverà al 40%.
Idem per i semiconduttori.
Quando viene fatta una linea si prevede che questa verrà ammortizzata in tot tempo producendo tot pezzi all'anno.
Se la richiesta è troppo bassa hai due possibilità o mettere tutto il progetto in passivo e chiuderlo, oppure ridurre i margini lordi a pezzo e ammortizzare i costi o azzerando gli utili, oppure allungando il piano di rientro.
Ps su larga scala vendere sotto il prezzo di pareggio programmato è più soddisfacente che non rientrare affatto dei capitali.
Ed il CDA di qualsiasi multinazionale lo sa benissimo.
Bada bene che il prezzo di pareggio programmato è molto più alto che quello di produzione.

Pat77

02-08-2014, 22:55

Sii discute sul nulla:

1- Intel non e' monopolista
2- AMD non e' sua antagonista in questo mercato
3- Non sta facendo Dumping
4- Nessuno ha intentato cause

LMCH

03-08-2014, 00:01

Fermo restando che una fabbrica costa certamente più adesso rispetto al passato, ma investire in nuovi processi produttivi rimane ancora conveniente (infatti, pur con tutti i problemi, anche la concorrenza ci si sta buttando).

La concorrenza è molto più flessibile ed ha maggiori sbocchi per la sua capacità produttiva.

Una delle idiozie più grandi fatte recentemente da Intel è stata proporsi come produttore per conto terzi ma cercando il più possibile di spingere i core x86 anche quando i potenziali clienti non li volevano.

Sembra che si siano scordati che negli anni '90 erano loro tra i maggiori produttori di SoC ARM (gli strongarm e gli xscale) e fu proprio per mancanza di flessibilità ed eccessivo x86-centrismo che persero quel mercato proprio quando stava per decollare alla grande.

cdimauro

03-08-2014, 08:12

La concorrenza è molto più flessibile ed ha maggiori sbocchi per la sua capacità produttiva.
A giudicare dai ritardi nei loro piani, non mi sembra che la situazione sia delle migliori.
Una delle idiozie più grandi fatte recentemente da Intel è stata proporsi come produttore per conto terzi ma cercando il più possibile di spingere i core x86 anche quando i potenziali clienti non li volevano.
Aprire a conti terzi serve a sfruttare l'eccessiva capacità produttiva, per cui è tutt'altro che un'idiozia.

Idem sullo spingere il suo core business, x86.

Cosa dovrebbe Intel, altrimenti?
Sembra che si siano scordati che negli anni '90 erano loro tra i maggiori produttori di SoC ARM (gli strongarm e gli xscale) e fu proprio per mancanza di flessibilità ed eccessivo x86-centrismo che persero quel mercato proprio quando stava per decollare alla grande.
Credo che tu ti sia scordato come siano andate le cose. Il comparto StrongARM Intel lo ricevette a seguito della chiusura di una causa con Digital. Per cui non è che, tutto a un tratto, Intel sia stata folgorata sulla via di Cambridge, e abbia deciso di abbracciare ARM.

Tant'è che la "sposalizio" è durato un po' di anni, e Intel ha deciso di liberarsi di ARM e puntare su quello che ha sempre fatto.

LMCH

03-08-2014, 19:14

A giudicare dai ritardi nei loro piani, non mi sembra che la situazione sia delle migliori.

Aprire a conti terzi serve a sfruttare l'eccessiva capacità produttiva, per cui è tutt'altro che un'idiozia.

Idem sullo spingere il suo core business, x86.

Cosa dovrebbe Intel, altrimenti?

Presentarsi come un "vero" produttore per conto terzi, ricordati che i primi approcci li ha fatti proponendosi come produttore per conto terzi ... a patto che usassero core x86.

Credo che tu ti sia scordato come siano andate le cose. Il comparto StrongARM Intel lo ricevette a seguito della chiusura di una causa con Digital. Per cui non è che, tutto a un tratto, Intel sia stata folgorata sulla via di Cambridge, e abbia deciso di abbracciare ARM.

Tant'è che la "sposalizio" è durato un po' di anni, e Intel ha deciso di liberarsi di ARM e puntare su quello che ha sempre fatto.

Non ha avuto a livello di management la flessibilità mentale necessaria per comprendere l'enormità della botta di cu:ciapet:o che gli era capitata e quando con gli xscale sbagliarono il posizionamento del prodotto (non avevano capito che dai pda ci si stava spostando verso gli smarphone) invece di rilanciare e rientrare in forze ... abbandonarono completamente la partita cedendo tutto a Marvell.
Se fossero rimasti (dedicando alla cosa una frazione insignificante delle loro risorse) ora sarebbero uno dei maggiori produttori per quel che riguarda gli ARM e gli sarebbe pure molto più facile spingere gli x86 nelle stesse nicchie.

tuttodigitale

03-08-2014, 19:30

quello che è successo anni fa con AMD è un "poco" differente:
Intel, sfruttando la sua posizione dominante, praticava forti sconti agli assemblatori se questi ritardavano o annullavano del tutto la vendita di PC con cpu AMD. O se volete leggere in un altro modo, faceva pagare più del dovuto le cpu ai produttori che appoggiavano AMD, visto che i PC più venduti erano quelli di Intel (siamo negli anni del mito dei GHz), Dell, HP e Company accettarono la "strana" (e illegale) offerta. Certamente in quegli anni Intel ha registrato guadagni da capogiro: il dumping non c'entra niente.

Oggi, una strategia del genere nel mobile è impraticabile: lo vedete Mediamondo rinunciare alla vendita di iphone e samsung S5, per vendere ESCLUSIVAMENTE smartphone con cpu Intel?
Dovresti leggere il post di Ares17 ed integrarlo col mio, prima di criticare a vanvera.
ares17 parlava di dumping e probabilmente la legge si riferisce ai soli costi variabili, che sono notoriamente bassi, basti pensare alla tecnica 3D per impilare più celle di memoria.
Con la produzione devi comunque coprire i costi (fissi)di allestimento della fab e visto che si possono produrre solo un numero limitato di wafer al giorno è evidente che il costo di produzione deve tener conto dei costi fissi degli impianti.
Certamente quando TMSC tratta con AMD e nvidia, non tira un prezzo di poco superiore ai costi di produzione variabili. Piuttosto gli dice che ogni wafer (che di per sé costa poco) te lo vendo a 6000 euro (le cifre in gioco sono grosso modo queste), dovendomi comunque ripagarmi dei miliardi spesi e magari mettere qualche soldino nello sviluppo di un nuovo impianto. Ora non mi risulta che in un wafer ci siano più di 3000 SoC di fascia alta e pure funzionanti.

cdimauro

03-08-2014, 19:42

Presentarsi come un "vero" produttore per conto terzi, ricordati che i primi approcci li ha fatti proponendosi come produttore per conto terzi ... a patto che usassero core x86.
Appunto: è sempre legata al suo core business, come vedi.
Non ha avuto a livello di management la flessibilità mentale necessaria per comprendere l'enormità della botta di cu:ciapet:o che gli era capitata e quando con gli xscale sbagliarono il posizionamento del prodotto (non avevano capito che dai pda ci si stava spostando verso gli smarphone) invece di rilanciare e rientrare in forze ... abbandonarono completamente la partita cedendo tutto a Marvell.
Ti manca un pezzo della storia: Intel stava lavorando all'Atom, ed è questo IMO il motivo per cui s'è sbarazzata degli XScale. Si sarebbe creata una sovrapposizione, addirittura dentro casa.
Se fossero rimasti (dedicando alla cosa una frazione insignificante delle loro risorse) ora sarebbero uno dei maggiori produttori per quel che riguarda gli ARM e gli sarebbe pure molto più facile spingere gli x86 nelle stesse nicchie.
Non sappiamo cosa sarebbe potuto succedere. Intel, come hai già detto, ha sbagliato il posizionamento dei suoi prodotti sul mercato, e questo è successo a prescindere dall'architettura. Anche Otellini, peraltro, ha riconosciuto di aver sbagliato con Apple per l'iPhone.

tuttodigitale

03-08-2014, 19:57

Non ha avuto a livello di management la flessibilità mentale necessaria per comprendere l'enormità della botta di cu:ciapet:o che gli era capitata e quando con gli xscale sbagliarono il posizionamento del prodotto (non avevano capito che dai pda ci si stava spostando verso gli smarphone) invece di rilanciare e rientrare in forze ... abbandonarono completamente la partita cedendo tutto a Marvell.
Se fossero rimasti (dedicando alla cosa una frazione insignificante delle loro risorse) ora sarebbero uno dei maggiori produttori per quel che riguarda gli ARM e gli sarebbe pure molto più facile spingere gli x86 nelle stesse nicchie.
nel 2008 quando iphone era una realtà più che consolidata e i primi terminali Android videro la luce, AMD fece pure peggio, vendendo a Qualcomm il frutto del lavoro fatto da ATI technologies per la modica cifra di 65 milioni di dollari (ATI fu acquistata alla cifra folle di 4 MILIARDI).
http://www.businessmagazine.it/news/la-divisione-handheld-di-amd-passa-a-qualcomm_27768.html
spassosi, con il senno di poi, i commenti che parlavano di ramo inutile..
AMD era già dentro al mercato smartphone con una soluzione grafica all'avanguardia all'epoca.

LMCH

03-08-2014, 20:54

nel 2008 quando iphone era una realtà più che consolidata e i primi terminali Android videro la luce, AMD fece pure peggio, vendendo a Qualcomm il frutto del lavoro fatto da ATI technologies per la modica cifra di 65 milioni di dollari (ATI fu acquistata alla cifra folle di 4 MILIARDI).
http://www.businessmagazine.it/news/la-divisione-handheld-di-amd-passa-a-qualcomm_27768.html
spassosi, con il senno di poi, i commenti che parlavano di ramo inutile..
AMD era già dentro al mercato smartphone con una soluzione grafica all'avanguardia all'epoca.

Li si trattava solo di una GPU per dispositivi mobili e Qualcomm produceva già SoC per telefoni e smartphone.
Intel invece aveva già un prodotto completo che vendeva bene.

LMCH

03-08-2014, 21:09

Appunto: è sempre legata al suo core business, come vedi.

Un conto è essere legati al proprio core business, un altro è auto-sabotarsi mettendo a rischio pure il proprio core business.
Quel che contava era tenere le fab occupate, non cercare di "vendere" core x86 a clienti che potevano essere interessati a produrre su quelle fab.
Considerano poi i precedenti di Intel era ovvio che appena cominciavano certi discorsi certi clienti cominciavano a cercare altrove.

Ti manca un pezzo della storia: Intel stava lavorando all'Atom, ed è questo IMO il motivo per cui s'è sbarazzata degli XScale. Si sarebbe creata una sovrapposizione, addirittura dentro casa.

Ma hai presente su cosa giravano gli xscale e con quali requisiti ?
Non c'era sovrapposizione, in quel periodo gli x86 non potevano manco sognarsi di occupare le nicchie degli xscale e degli ARM e non ci riescono neppure ora se non in fascia alta e con consumi complessivi ancora troppo elevati per sperare di scendere di più.

Non sappiamo cosa sarebbe potuto succedere. Intel, come hai già detto, ha sbagliato il posizionamento dei suoi prodotti sul mercato, e questo è successo a prescindere dall'architettura. Anche Otellini, peraltro, ha riconosciuto di aver sbagliato con Apple per l'iPhone.

In quel periodo l'architettura utilizzata era ancora importante, ora lo è meno ma non così tanto come vorrebbe Intel.

cdimauro

03-08-2014, 21:59

Li si trattava solo di una GPU per dispositivi mobili e Qualcomm produceva già SoC per telefoni e smartphone.
Intel invece aveva già un prodotto completo che vendeva bene.
Si trattava di un'ottima GPU, e sai bene quanto sia importante da un po' di anni a questa parte.
Un conto è essere legati al proprio core business, un altro è auto-sabotarsi mettendo a rischio pure il proprio core business.
Quel che contava era tenere le fab occupate, non cercare di "vendere" core x86 a clienti che potevano essere interessati a produrre su quelle fab.
Considerano poi i precedenti di Intel era ovvio che appena cominciavano certi discorsi certi clienti cominciavano a cercare altrove.
A Intel non interessa farsi concorrenza in casa, lo sai. Le fab le tiene occupate col suo business oppure con altri che non le sono concorrenti; se rimane capacità produttiva inutilizzata... amen.
Ma hai presente su cosa giravano gli xscale e con quali requisiti ?
Non c'era sovrapposizione, in quel periodo gli x86 non potevano manco sognarsi di occupare le nicchie degli xscale e degli ARM e non ci riescono neppure ora se non in fascia alta e con consumi complessivi ancora troppo elevati per sperare di scendere di più.

In quel periodo l'architettura utilizzata era ancora importante, ora lo è meno ma non così tanto come vorrebbe Intel.
Perché guardi soltanto a quel periodo? Quella di Atom è una strategia a lungo termine.

Riguardo ai consumi, mi sembra che da un po' di tempo gli Atom sia competitivi con gli ARM di "pari livello" (stesso segmento di mercato).

D'altra parte con chip da qualche miliardo di transistor la cosiddetta "x86-tax" è diventata una piccolissima parte affogata in grande SoC (di cui la CPU, a sua volta, è una piccola parte).

LMCH

04-08-2014, 00:21

Perché guardi soltanto a quel periodo? Quella di Atom è una strategia a lungo termine.

Perchè quel che è avvenuto ha avuto conseguenze pesanti a lungo termine.

Riguardo ai consumi, mi sembra che da un po' di tempo gli Atom sia competitivi con gli ARM di "pari livello" (stesso segmento di mercato).
Dipende da cosa si intende per competitivi e per pari livello.
Il vantaggio degli ARM è che i core "base" coprono un sacco di nicchie ed i vari produttori a loro volta propongono SoC per tutte le esigenze e fascie di prezzo.
Intel non riesce a fare altrettanto e non sembra in grado di farlo.

D'altra parte con chip da qualche miliardo di transistor la cosiddetta "x86-tax" è diventata una piccolissima parte affogata in grande SoC (di cui la CPU, a sua volta, è una piccola parte).

Con ARM si può scegliere tra un sacco di core diversi in base alle proprie esigenze, tra un sacco di SoC con differenti caratteristiche e se necessario "si può far da se".
Con gli x86 non è possibile fare altrettanto e specialmente se si cerca di ridurre i consumi o la complessità circuitale, la "x86-tax" pesa eccome.

Poi per quanto sia "piccola", la cpu rimane un elemento critico di tutto il SoC visto che l'esecuzione del software avviene principalmente li, quindi la sua efficienza ha ripercussioni su tutto il resto degli elementi del SoC.

Per il software vale la regola che non serve ottimizzare tutto il codice per migliorare le prestazioni, ma giusto i punti caldi che vengono eseguiti più frequentemente e più a lungo.
Una regola analoga vale per i SoC e la "x86-tax" va a colpire uno dei punti caldi dei SoC con conseguenze più ampie e profonde di quanto appaia guardando solo al numero di gate o all'area del chip.

cdimauro

04-08-2014, 06:50

Perchè quel che è avvenuto ha avuto conseguenze pesanti a lungo termine.
E ne ha ancora, ma non persarci sarebbe stato anche peggio.
Dipende da cosa si intende per competitivi e per pari livello.
Il vantaggio degli ARM è che i core "base" coprono un sacco di nicchie ed i vari produttori a loro volta propongono SoC per tutte le esigenze e fascie di prezzo.
Intel non riesce a fare altrettanto e non sembra in grado di farlo.
Nemmeno aziende come Qualcomm, ad esempio, sono interessate a coprire tutti i segmenti, e si rivolgono alla fascia medio-alta.

Nella fascia bassa è estremamente difficile competere coi cinesi. Per chiunque.

Intel ha dalla sua il vantaggio delle fabbriche, per cui rispetto agli altri produttori può sfruttare questo vantaggio, ma la sua storia dimostra che non le interessa correre per i centesimi.
Con ARM si può scegliere tra un sacco di core diversi in base alle proprie esigenze, tra un sacco di SoC con differenti caratteristiche e se necessario "si può far da se".
Con gli x86 non è possibile fare altrettanto e specialmente se si cerca di ridurre i consumi o la complessità circuitale, la "x86-tax" pesa eccome.
Hai mai provato a vedere su siti come Chip Architect la dimensione del core della CPU, e quella dell'unità di decodifica x86 (che è la principale imputata della x86-tax) e della sua FPU (molto, molto meno rispetto al decoder)?

Fallo e avrai un'idea quanto incida una CPU in un SoC, e quelle unità sulla CPU e, di conseguenza, sul SoC.

Io ho numeri molto precisi sia sulla dimensione dell'area impegnata sia sul consumo a runtime, ma non posso divulgarli. Un'idea, comunque, la si può fare lo stesso con quanto suggerito sopra.
Poi per quanto sia "piccola", la cpu rimane un elemento critico di tutto il SoC visto che l'esecuzione del software avviene principalmente li, quindi la sua efficienza ha ripercussioni su tutto il resto degli elementi del SoC.
Mi spiace, ma non è così. I numeri sono importanti, e continui a non volerne tenere conto.

Un core da un po' di decine di milioni di transistor su un SoC da un miliardo di transistor ha un peso molto basso sul totale. E un'unità di decodifica da un milione di transistor su un po' di decine di milioni ne ha un altro, tanto per fare un altro esempio. Facendo le debite proporzioni puoi comprendere da te l'incidenza della parte legacy dei core x86 sul totale di un SoC.

Se fai qualche ricerca magari riesci a ottenere dei numeri più precisi, ma il concetto che ho esposto è quello.
Per il software vale la regola che non serve ottimizzare tutto il codice per migliorare le prestazioni, ma giusto i punti caldi che vengono eseguiti più frequentemente e più a lungo.
Hai mai visto lo spettro termico di un SoC? Ecco, questo ti può fornire un'altra misura / prova di quello che ho scritto sopra.
Una regola analoga vale per i SoC e la "x86-tax" va a colpire uno dei punti caldi dei SoC con conseguenze più ampie e profonde di quanto appaia guardando solo al numero di gate o all'area del chip.
Vedi sopra. E aggiungo che siamo ormai molto lontani da quando la complessità di un core CISC aveva un enorme peso rispetto a un core RISC. Finché si parlava di centinaia di migliaia e milioni di transistor un confronto aveva senso. Ma da quando la parte del leone la fanno le cache e le unità SIMD, tutto si è notevolmente ridimensionato. A maggior ragione quando un core è immerso in un SoC di cui lui stesso è una piccola parte.

T'invito a documentarti in merito. Puoi anche chiedere informazioni sul newsgroup comp.arc, che è frequentato da parecchi esperi in materia.

LMCH

04-08-2014, 16:08

Hai mai visto lo spettro termico di un SoC? Ecco, questo ti può fornire un'altra misura / prova di quello che ho scritto sopra.

Per punto caldo intendevo nel senso di utilizzo estensivo ed intensivo, non di calore sviluppato.
Come in un software intervenendo sulle sequenze di codice più frequentemente utilizzate si possono migliorare (o peggiorare) in modo notevole le prestazioni, altrettanto avviene a livello di architetture.
Puoi avere cache enormi, ma se il core che esegue il codice ha "un piccolo svantaggio" rispetto ad un altro core, a parità di dimensionamento di cache e del resto del SoC la cosa si nota.
Di solito eventuali svantaggi intrinseci nel core si possono compensare con bus più ampi/veloci, cache più ampie ecc. ma questa comporta pagare un altro prezzo su altre caratteristiche.

Altrimenti, se fosse vero che "la x86-tax non conta più", come mai Intel ha avuto così grandi difficoltà a contenere i costi ed consumi a livelli accettabili rispetto alla concorrenza che usava ARM ?
In teoria hanno il personale ed il know-how per produrre dispositivi fatti come si deve e l'unica differenza rilevante rispetto alla concorrenza ARM è guardacaso la cpu.

cdimauro

04-08-2014, 18:48

Per punto caldo intendevo nel senso di utilizzo estensivo ed intensivo, non di calore sviluppato.
OK, parlavi di hot spot.
Come in un software intervenendo sulle sequenze di codice più frequentemente utilizzate si possono migliorare (o peggiorare) in modo notevole le prestazioni, altrettanto avviene a livello di architetture.
Indubbiamente, ma quanto della "x86-tax" incide su tutto ciò?
Ho scritto una serie di articoli un paio d'anni fa sull'argomento, di cui trovi qui (http://www.appuntidigitali.it/17712/il-legacy-di-x86-x64-parte-9-conclusioni/) l'ultimo. Un'altra serie di articoli l'ho scritta circa un anno fa riguardo alle statistiche relative alle istruzioni eseguite, di cui trovi l'ultimo qui (http://www.appuntidigitali.it/18371/statistiche-su-x86-x64-parte-9-legacy-e-conclusioni/).

Con questo materiale puoi vedere in che modo incide l'aspetto legacy di x86 sia a livello di funzionamento interno sia per quanto riguarda il codice effettivamente eseguito. Per quest'ultimo è bene notare che la stragrandissima maggioranza di istruzioni eseguite NON sono roba vecchia & datata, ma istruzioni di gran lunga più semplici, che in genere sono mappate 1:1 con le cosiddette uop "RISC". Niente "legacy", insomma.

A ciò aggiungiamo il fatto che già da parecchi anni proprio negli hot spot viene attivato il cosiddetto Loop Stream Detector (http://www.anandtech.com/show/2594/4) (LSD), che consente di disabilitare i decoder ed eseguire direttamente le uop da questa piccola cache interna, consentendo un notevole risparmio di energia (con Haswell mi pare che mediamente l'80% del tempo la CPU lavora coi decoder spenti grazie a questa tecnologia).

Il quadro adesso dovrebbe essere più chiaro e completo.
Puoi avere cache enormi, ma se il core che esegue il codice ha "un piccolo svantaggio" rispetto ad un altro core, a parità di dimensionamento di cache e del resto del SoC la cosa si nota.
Di solito eventuali svantaggi intrinseci nel core si possono compensare con bus più ampi/veloci, cache più ampie ecc. ma questa comporta pagare un altro prezzo su altre caratteristiche.
E viceversa, ci sono anche vantaggi dal fatto di avere istruzioni più complesse e a lunghezza variabile.

Questo significa, ad esempio, che il codice è più denso, quindi:
- meno spazio occupato
- tutta la gerarchia di memoria (cache L1/L2/L3, memoria) è meno stressata;
- più TLB hit e meno flush
Questo comporta un minor consumo per tutte queste componenti.

Altro esempio, con istruzioni più complesse è possibile eseguire meno istruzioni per implementare un particolare algoritmo. Anche qui vale quanto scritto sopra, a cui si aggiunge il risparmio di energia dovuto all'esecuzione di meno istruzioni.

Per cui è vero che l'aspetto legacy di x86 porta problemi, ma è anche vero che porta pure vantaggi, e non di poco conto, che incidono sulla bilancia energetica.
Altrimenti, se fosse vero che "la x86-tax non conta più",
Con questi numeri in gioco, è praticamente trascurabile. Anche questo l'avevo scritto in un altro articolo (http://www.appuntidigitali.it/4375/arm-vs-intel-i-cut-the-power/) ancora più vecchio, di 5 anni fa, dove trovi le mie riflessioni in merito verso la metà del pezzo. Da notare che ho parlato anche della cessione della divisione XScale.

La situazione, come dicevo, è cambiata, e un core Atom non è più solo, ma si trova all'interno di SoC da miliardi di transistor...
come mai Intel ha avuto così grandi difficoltà a contenere i costi ed consumi a livelli accettabili rispetto alla concorrenza che usava ARM ?
In teoria hanno il personale ed il know-how per produrre dispositivi fatti come si deve e l'unica differenza rilevante rispetto alla concorrenza ARM è guardacaso la cpu.
Perché la CPU è soltanto un piccolo pezzo del SoC, come già detto. Intel non ha tutto il personale e know-how necessario in questo campo: infatti è anche per questo che non integra ancora alcun modem LTE, tanto per fare l'esempio più noto e di notevole importanza (anche per i consumi). Ovviamente ci sta lavorando, ma la concorrenza è in vantaggio, essendo partita molto prima.

Ci sono altri pezzi integrati in un SoC, su cui è possibile fare lo stesso ragionamento. Qualcomm è famosa per avere realizzato e integrato un DSP particolarmente efficiente (http://en.wikipedia.org/wiki/Qualcomm_Hexagon) a cui demandare parecchie delle operazioni relative ai modem e al multimedia.

Infine, un altro esempio lampante è dato dalle GPU. Come sai, quelle Intel non eccellono rispetto alle controparti, e penso che la situazione sia la stessa anche in ambito mobile: probabilmente non sono efficienti, sia a livello prestazionale sia di consumi, rispetto alla concorrenza.

Si tratta di una situazione non idilliaca, dunque, ma nemmeno così malvagia, a giudicare dai risultati raggiunti da qualche tempo. E la cosa interessante è che ci sono ampii margini di miglioramento per Intel...

Ricapitolando, se una CPU oggi occupa circa il 10% dell'area di un SoC, puoi facilmente immaginare perché il rimanente 90% sia così importante e quanto incida a livello di consumi.

Purtroppo, essendo i componenti del SoC totalmente diversi non solo a livello di CPU, non è possibile fare dei confronti diretti, e bisogna accontentarsi delle misure dell'intero SoC. Ma anche senza i dati a disposizione relativi ai singoli pezzi, puoi comunque farti un'idea del peso che ha oggi una CPU incastonata in un SoC da miliardi di transistor, e trarre da solo le tue conclusioni.

P.S. Al solito le mie sono soltanto opinioni personali: non riporto informazioni aziendali, ma soltanto ciò che in giro può trovare chiunque.

LMCH

07-08-2014, 01:58

Indubbiamente, ma quanto della "x86-tax" incide su tutto ciò?
Ho scritto una serie di articoli un paio d'anni fa sull'argomento, di cui trovi qui (http://www.appuntidigitali.it/17712/il-legacy-di-x86-x64-parte-9-conclusioni/) l'ultimo. Un'altra serie di articoli l'ho scritta circa un anno fa riguardo alle statistiche relative alle istruzioni eseguite, di cui trovi l'ultimo qui (http://www.appuntidigitali.it/18371/statistiche-su-x86-x64-parte-9-legacy-e-conclusioni/).

Ti ricordi la prima versione della cpu SPARC che non aveva moltiplicatore/divisore implementato in hardware perche secondo i tipi di Sun "statistiche alla mano" erano istruzioni poco utilizzate e non influivano più di tanto sulle prestazioni ? ;)
Ecco, la x86-tax è uguale, crea piccoli problemi che fanno pendere l'ago della bilancia verso altre direzioni nei settori in cui gli x86 non dominano già e la retrocompatibilità con software per x86 non è sufficientemente rilevante.

Con questo materiale puoi vedere in che modo incide l'aspetto legacy di x86 sia a livello di funzionamento interno sia per quanto riguarda il codice effettivamente eseguito. Per quest'ultimo è bene notare che la stragrandissima maggioranza di istruzioni eseguite NON sono roba vecchia & datata, ma istruzioni di gran lunga più semplici, che in genere sono mappate 1:1 con le cosiddette uop "RISC". Niente "legacy", insomma.

A ciò aggiungiamo il fatto che già da parecchi anni proprio negli hot spot viene attivato il cosiddetto Loop Stream Detector (http://www.anandtech.com/show/2594/4) (LSD), che consente di disabilitare i decoder ed eseguire direttamente le uop da questa piccola cache interna, consentendo un notevole risparmio di energia (con Haswell mi pare che mediamente l'80% del tempo la CPU lavora coi decoder spenti grazie a questa tecnologia).

Il quadro adesso dovrebbe essere più chiaro e completo.

Il problema è che ad esempio un risc senza loop stream detector può essere altrettanto efficiente nell'eseguire codice di un x86 con conseguenti benefici
nell'implementazione e nelle prestazioni.

E viceversa, ci sono anche vantaggi dal fatto di avere istruzioni più complesse e a lunghezza variabile.

Questo significa, ad esempio, che il codice è più denso, quindi:
- meno spazio occupato
- tutta la gerarchia di memoria (cache L1/L2/L3, memoria) è meno stressata;
- più TLB hit e meno flush
Questo comporta un minor consumo per tutte queste componenti.

Solo che ora i compilatori ottimizzano in modo più efficiente e sopratutto il grosso del carico computazionale è legato al leggere e scrivere dati e non a caricare codice in cache.
Quindi tali vantaggi non sono più rilevanti come un tempo e per le applicazioni in cui lo sono gli ARM possono usare le estensioni THUMB che sono molto più efficienti su quel lato anche rispetto alle istruzioni x86.

La situazione, come dicevo, è cambiata, e un core Atom non è più solo, ma si trova all'interno di SoC da miliardi di transistor...

Perché la CPU è soltanto un piccolo pezzo del SoC, come già detto. Intel non ha tutto il personale e know-how necessario in questo campo: infatti è anche per questo che non integra ancora alcun modem LTE, tanto per fare l'esempio più noto e di notevole importanza (anche per i consumi). Ovviamente ci sta lavorando, ma la concorrenza è in vantaggio, essendo partita molto prima.

Ci sono altri pezzi integrati in un SoC, su cui è possibile fare lo stesso ragionamento. Qualcomm è famosa per avere realizzato e integrato un DSP particolarmente efficiente (http://en.wikipedia.org/wiki/Qualcomm_Hexagon) a cui demandare parecchie delle operazioni relative ai modem e al multimedia.

Infine, un altro esempio lampante è dato dalle GPU. Come sai, quelle Intel non eccellono rispetto alle controparti, e penso che la situazione sia la stessa anche in ambito mobile: probabilmente non sono efficienti, sia a livello prestazionale sia di consumi, rispetto alla concorrenza.

Si tratta di una situazione non idilliaca, dunque, ma nemmeno così malvagia, a giudicare dai risultati raggiunti da qualche tempo. E la cosa interessante è che ci sono ampii margini di miglioramento per Intel...

Ricapitolando, se una CPU oggi occupa circa il 10% dell'area di un SoC, puoi facilmente immaginare perché il rimanente 90% sia così importante e quanto incida a livello di consumi.

Purtroppo, essendo i componenti del SoC totalmente diversi non solo a livello di CPU, non è possibile fare dei confronti diretti, e bisogna accontentarsi delle misure dell'intero SoC. Ma anche senza i dati a disposizione relativi ai singoli pezzi, puoi comunque farti un'idea del peso che ha oggi una CPU incastonata in un SoC da miliardi di transistor, e trarre da solo le tue conclusioni.

P.S. Al solito le mie sono soltanto opinioni personali: non riporto informazioni aziendali, ma soltanto ciò che in giro può trovare chiunque.

Il problema è che se si trattasse solo delle altre componenti del SoC, Intel dovrebbe vendere alla grande almeno nel settore dei tablet "non Windows 8", ma così non è.
Il grosso problema per Intel è la componente radio/modem, ma per tutto il resto (inclusa la GPU) non ha svantaggi significativi se non maggiori consumi legati al voler avere per forza maggiori prestazioni anche quando sarebbe il caso di pensare di più a ridurre i consumi.

cdimauro

07-08-2014, 07:45

Ti ricordi la prima versione della cpu SPARC che non aveva moltiplicatore/divisore implementato in hardware perche secondo i tipi di Sun "statistiche alla mano" erano istruzioni poco utilizzate e non influivano più di tanto sulle prestazioni ? ;)
Ecco, la x86-tax è uguale, crea piccoli problemi che fanno pendere l'ago della bilancia verso altre direzioni nei settori in cui gli x86 non dominano già e la retrocompatibilità con software per x86 non è sufficientemente rilevante.
Ma qui parlavamo di consumi. Se quelle vecchie istruzioni non le esegui, non incidono sulla bilancia energetica. Disassembla pure qualunque applicazioni, e te ne renderai conto da solo.

Il fatto che citi riguardo Sun è corretto, ma oggi i processori, anche RISC, includono CENTINAIA di istruzioni perché tendono a coprire particolari casi che però sono molto importanti. Vedi, ad esempio, il supporto al CRC32, all'AES, e allo SHA, che di recente è stato aggiunto su praticamente tutti i processori.

Ma questo non c'entra nulla con le vecchie istruzioni legacy x86. Dimmi, secondo te, che utilità può avere una AAD, ad esempio? Infatti vorrei vedere il compilatore che riesce a riconoscere il contesto e a emetterla correttamente.

Poi che siano presenti in vecchissimo codice e, dunque, eseguite, nulla da dire. Ma chi esegue quel codice? Rispetto alle centinaia e centinaia di milioni di PC che eseguono codice, sarà una sparuta minoranza di aziende che eseguono applicazioni DOS-based (magari "portate" su Windows con la classica... CUI).

Viceversa, disassembla qualunque gioco o applicazione da un bel po' di anni a questa parte, e vedrai che i loro compilatori, come pure eventuali parti in assembly, non abbiano fatto uso di quelle istruzioni.
Il problema è che ad esempio un risc senza loop stream detector può essere altrettanto efficiente nell'eseguire codice di un x86 con conseguenti benefici nell'implementazione e nelle prestazioni.
I RISC generalmente non hanno il problema di tradurre le istruzioni, ma alcuni lo fanno. Vedi i PowerPC e gli ARM che hanno istruzioni molto complesse, come quelle di Load/Store multiple sui registri, e qui, se non erro, ricorrono pure loro al microcodice (bloccando la pipeline). Si tratta di istruzioni utili (Motorola 68K docet: una goduria da usare), ma che... ti complicano la vita se devi implementarle ed eseguirle. Non è un caso che ARM abbia buttato un po' di roba legacy con la nuova architettura a 64 bit, incluse queste istruzioni ovviamente, avvicinandosi ad architetture come MIPS o Alpha. Ma in ogni caso se le porta sul groppone perché rimane compatibile con la "vecchia" architettura a 64-bit.

Riguardo all'efficienza dei RISC, immagino riguardi l'implementazione / facilità di esecuzione (a parte le eccezioni di cui sopra) e i relativi consumi. Quindi non a livello prestazionale (qui l'ISA incide, come già detto).
Solo che ora i compilatori ottimizzano in modo più efficiente e sopratutto il grosso del carico computazionale è legato al leggere e scrivere dati e non a caricare codice in cache.
Permettimi: i compilatori non posso superare i limiti dell'ISA, ma devono per forza conviverci. Se, ad esempio, hai da caricare un costante "grande" a 32-bit, puoi piangere in aramaico: o la costruisci con una serie di MOV con dati immediati più piccoli + shift + ADD / OR (oppure ricorrerendo ad approsite istruzioni di MOV che coinvolgono la parte alta del registro, per le ISA che ce l'hanno), oppure la carichi direttamente dalla memoria (e qui devi scomodare una ben più costosa LOAD dalla memoria, con tutto ciò che comporta).
Per cui, ricapitolando: se prediligi le prestazioni ricorri a una serie di istruzioni ma espandi il codice (e stressi molto la cache codice & relativa banda di memoria). Se, invece, prediligi lo spazio, ricorri alla load e stressi la cache dati (e il memory controller). Ovviamente quest'ultimo caso vale solo se risulta semplice raggiungere la costante in memoria usando il piccolo offset che una LOAD mette a disposizione, altrimenti è facile che ti convenga la prima soluzione.

Questo esposto è un caso molto comune in ambito RISC (e in generale di programmazione, ma i CISC hanno, in genere, la possibilità di specificare direttamente un valore immediato, anche lungo, per cui non si pongono tutti questi problemi), e coi quali i compilatori possono combattere quanto vogliono, ma le problematiche rimangono.
Quindi tali vantaggi non sono più rilevanti come un tempo e per le applicazioni in cui lo sono gli ARM possono usare le estensioni THUMB che sono molto più efficienti su quel lato anche rispetto alle istruzioni x86.
Indubbiamente con THUMB la densità di codice degli ARM è nettamente migliorata (e compete con x86), ma... a che prezzo? THUMB è un'ISA CISC, a lunghezza variabile, per cui il decoder si complica, e viene introdotto un ulteriore stadio nella pipeline per la "decompressione" dell'istruzione nell'equivalente ARM.

Dulcis in fundo, funziona soltanto a 32-bit: non ne è stata presentata una versione a 64-bit, ed è difficile che accada (perché si perderebbero i vantaggi dei 32 registri introdotti), anche se non impossibile (leggi: con molti più compromessi rispetto alla versione a 32-bit).

Ma a parte questo, rimangono i problemi tipici dei RISC di cui ho discusso prima.
Il problema è che se si trattasse solo delle altre componenti del SoC, Intel dovrebbe vendere alla grande almeno nel settore dei tablet "non Windows 8", ma così non è.
Qui penso che il problema sia dovuto ai ritardi e a una strategia commerciale coi partner che non è stata azzeccata.
Il grosso problema per Intel è la componente radio/modem, ma per tutto il resto (inclusa la GPU) non ha svantaggi significativi se non maggiori consumi legati al voler avere per forza maggiori prestazioni anche quando sarebbe il caso di pensare di più a ridurre i consumi.
Appunto. Il problema è nei consumi, ma di tutto il resto del SoC. Ci vorrà tempo per aggiustare pure quelli (lato CPU ritengo che abbiano fatto un ottimo lavoro, e comunque la CPU incide poco sul totale, come già detto). Inoltre la GPU non brilla certo per le prestazioni. E per il modem, l'hai già detto tu...

LMCH

07-08-2014, 12:35

Ma qui parlavamo di consumi. Se quelle vecchie istruzioni non le esegui, non incidono sulla bilancia energetica. Disassembla pure qualunque applicazioni, e te ne renderai conto da solo.

Incidono comunque nell'efficienza del decoder, costringendo a ricorrere a soluzioni circuitali più complesse che hanno conseguenze sulla frequenza massima raggiungibile, latenze, ecc.

Il fatto che citi riguardo Sun è corretto, ma oggi i processori, anche RISC, includono CENTINAIA di istruzioni perché tendono a coprire particolari casi che però sono molto importanti. Vedi, ad esempio, il supporto al CRC32, all'AES, e allo SHA, che di recente è stato aggiunto su praticamente tutti i processori.

Ma questo non c'entra nulla con le vecchie istruzioni legacy x86. Dimmi, secondo te, che utilità può avere una AAD, ad esempio? Infatti vorrei vedere il compilatore che riesce a riconoscere il contesto e a emetterla correttamente.

Il mio punto era che avevano sottostimato gli effetti negativi di decisioni progettuali che sulla carta sembravano non essere sufficientemente rilevanti.

Poi che siano presenti in vecchissimo codice e, dunque, eseguite, nulla da dire. Ma chi esegue quel codice? Rispetto alle centinaia e centinaia di milioni di PC che eseguono codice, sarà una sparuta minoranza di aziende che eseguono applicazioni DOS-based (magari "portate" su Windows con la classica... CUI).

Viceversa, disassembla qualunque gioco o applicazione da un bel po' di anni a questa parte, e vedrai che i loro compilatori, come pure eventuali parti in assembly, non abbiano fatto uso di quelle istruzioni.

Ma a causa della loro presenza il set d'istruzioni presenta molti più casi speciali da gestire ad hoc (tipo dove usare prefissi quando si usano certi registri o certe modalità di indirizzamento, ecc. ecc.), mentre sui RISC le estensioni di solito vengono fatte ad un set d'istruzioni che spesso "nasce" per essere decodificato in modo efficiente e lo stesso vale per le estensioni.

I RISC generalmente non hanno il problema di tradurre le istruzioni, ma alcuni lo fanno. Vedi i PowerPC e gli ARM che hanno istruzioni molto complesse, come quelle di Load/Store multiple sui registri, e qui, se non erro, ricorrono pure loro al microcodice (bloccando la pipeline). Si tratta di istruzioni utili (Motorola 68K docet: una goduria da usare), ma che... ti complicano la vita se devi implementarle ed eseguirle. Non è un caso che ARM abbia buttato un po' di roba legacy con la nuova architettura a 64 bit, incluse queste istruzioni ovviamente, avvicinandosi ad architetture come MIPS o Alpha. Ma in ogni caso se le porta sul groppone perché rimane compatibile con la "vecchia" architettura a 64-bit.

Ma trattandosi di set d'istruzioni molto più regolari e simmetrici (nel senso di pochi casi particolari nello schema di decodifica) il costo della retrocompatibilità è di gran lunga inferiore.
Infatti per esempio a parità di processo produttivo un core Cortex A53 (64bit armv8) occupa il 40% in meno di un core Cortex A9 (32bit armv7) ed in modalità a 64bit ha le stesse prestazioni in termini di capacità di elaborazione.
L'A53 non ha le ottimizzazioni circuitali dell'A9 ma in modalità a 64bit se la gioca alla pari in termini di potenza i calcolo (suppongo nel senso di quando si elaborano dati in unita da 64bit).
Insomma anche con l'aumento di complessità dovuto ai 64bit ed al supporto della modalità a 32bit si sono potuti permettere di togliere roba ed avere qualcosa di più "leggero" in termini di implementazione.

Permettimi: i compilatori non posso superare i limiti dell'ISA, ma devono per forza conviverci. Se, ad esempio, hai da caricare un costante "grande" a 32-bit, puoi piangere in aramaico: o la costruisci con una serie di MOV con dati immediati più piccoli + shift + ADD / OR (oppure ricorrerendo ad approsite istruzioni di MOV che coinvolgono la parte alta del registro, per le ISA che ce l'hanno), oppure la carichi direttamente dalla memoria (e qui devi scomodare una ben più costosa LOAD dalla memoria, con tutto ciò che comporta).
Per cui, ricapitolando: se prediligi le prestazioni ricorri a una serie di istruzioni ma espandi il codice (e stressi molto la cache codice & relativa banda di memoria). Se, invece, prediligi lo spazio, ricorri alla load e stressi la cache dati (e il memory controller). Ovviamente quest'ultimo caso vale solo se risulta semplice raggiungere la costante in memoria usando il piccolo offset che una LOAD mette a disposizione, altrimenti è facile che ti convenga la prima soluzione.

Questo esposto è un caso molto comune in ambito RISC (e in generale di programmazione, ma i CISC hanno, in genere, la possibilità di specificare direttamente un valore immediato, anche lungo, per cui non si pongono tutti questi problemi), e coi quali i compilatori possono combattere quanto vogliono, ma le problematiche rimangono.

[QUOTE=cdimauro;41386945]Indubbiamente con THUMB la densità di codice degli ARM è nettamente migliorata (e compete con x86), ma... a che prezzo? THUMB è un'ISA CISC, a lunghezza variabile, per cui il decoder si complica, e viene introdotto un ulteriore stadio nella pipeline per la "decompressione" dell'istruzione nell'equivalente ARM.

La decodifica da istruzioni THUMB ad istruzioni ARM è 1:1 quindi il "decoder thumb" è un singolo stadio con espansione "a schema fisso" degli opcode THUMB in opcode ARM "classici" (ed eventualmente bypass della word successiva se contiene un valore costante).
Quando si eseguono istruzioni ARM quello stadio viene semplicemente bypassato.
Insomma, il supporto di THUMB non pesa sulla decodifica ed esecuzione delle istruzioni ARM a 32bit e quando viene attivato l'incremento di densità delle istruzioni compensa ampiamente gli svantaggi ... presenti solo in modalità THUMB.

Dulcis in fundo, funziona soltanto a 32-bit: non ne è stata presentata una versione a 64-bit, ed è difficile che accada (perché si perderebbero i vantaggi dei 32 registri introdotti), anche se non impossibile (leggi: con molti più compromessi rispetto alla versione a 32-bit).

Questo perche se si sta usando una cpu a 64bit significa che si dispone di molta ram e bus dati molto ampi, senza contare che usando le istruzioni a 64bit si ha nel caso peggiore circa la stessa densità di codice che si avrebbe usando codice ARM a 32bit senza THUMB.
Se poi consideri che THUMB è stato introdotto essenzialmente per dare il compo di grazia alla concorrenza che per roba embedded proponeva cpu a 16bit o anche ad 8bit ...

Poi sarebbe il caso di ricordare che il vantaggio di compattezza del codice "asimmetrico ed irregolare" degli x86 non è stato decisivo nei confronto degli altri RISC ... ma nei confronti degli Itanium. :read:

cdimauro

07-08-2014, 23:25

Incidono comunque nell'efficienza del decoder, costringendo a ricorrere a soluzioni circuitali più complesse che hanno conseguenze sulla frequenza massima raggiungibile, latenze, ecc.
Certamente, e sappiamo che i decoder x86/x64 sono nettamente più complessi rispetto a quelli dei RISC. Su questo non ci piove.
Il mio punto era che avevano sottostimato gli effetti negativi di decisioni progettuali che sulla carta sembravano non essere sufficientemente rilevanti.
Purtroppo errori del genere li può fare chiunque. Ad esempio le prime versioni degli ARM potevano indirizzare al massimo 64MB di memoria (26 bit d'indirizzamento), e se pensi che sono usciti nel 1985, direi che è stata una decisione folle. Rimanendo su x86, nessuno dei progettisti dell'8086 poteva pensare a dove sarebbe arrivata quest'architettura, e quali problemi avrebbero creato certe scelte che, però, all'epoca erano assolutamente sensate e molto vantaggiose.
Ma a causa della loro presenza il set d'istruzioni presenta molti più casi speciali da gestire ad hoc (tipo dove usare prefissi quando si usano certi registri o certe modalità di indirizzamento, ecc. ecc.), mentre sui RISC le estensioni di solito vengono fatte ad un set d'istruzioni che spesso "nasce" per essere decodificato in modo efficiente e lo stesso vale per le estensioni.
Tranne per i RISC che... diventano CISC introducendo ISA con opcode a lunghezza variabile, o che magari fanno uso di prefissi. ;) Il problema è sempre lo stesso: le esigenze cambiano col tempo, e bisogna mettere delle pezze a quanto già realizzato.

A parte questo, la realtà di x86 (e x64) è che la stragrande maggioranza delle istruzioni si mappa 1:1 con le uop, perché... si tratta di istruzioni semplici. Dunque non serve un decoder enormemente complesso per gestire il caso peggiore, con istruzioni molto lunghe (che sono una rarità) o che fanno uso di tanti prefissi (al più se ne usa uno, e questo avviene o per indirizzare memoria locale del thread, oppure quella del s.o., oppure per mappare le istruzioni SIMD). Difatti già da parecchi anni esiste UN solo decoder complesso per gestire tutti i casi possibili, che è affiancato da 2 o 3 (nei processori degli ultimi anni) decoder molto più semplici (ed efficienti / parchi di energia & transistor) che si smazzano le istruzioni molto più comunemente usate.

Ecco qui (http://abinstein.blogspot.de/2007/05/decoding-x86-from-p6-to-core-2-and.html) un link a un articolo interessante in merito, di cui riporto alcune parti significative:

"In a typical x86 program, more than 2/3 of the instructions are simple enough to be represented by a single (non-fused) micro-op. Most of the other 1/3 can be decoded into 4 micro-ops or less, with a (very) few taking more to execute. Recognizing these facts, especially the 2:1 simple-to-complex ratio, the P6 design divides its decoders into the well-known 4-1-1 structure, giving only one decoder full capability:
[...]
By differentiating the decoders and put performance emphasis on the common simple-instruction cases, instruction decode and issue complexity can be minimized, and higher clock rate can be reached. RISC design rule #1: Make the common-case fast."

Mi sembra sia abbastanza eloquente. ;)

Per informazioni più dettagliate sui decoder delle varie micro-architetture, c'è il solito Agner Fog e il suo omnio manuale (www.agner.org/optimize/microarchitecture.pdf). ;)
Ma trattandosi di set d'istruzioni molto più regolari e simmetrici (nel senso di pochi casi particolari nello schema di decodifica) il costo della retrocompatibilità è di gran lunga inferiore.
Certamente, ma ARM si trascina ARM32, Thumb-2, Thumb-EE, e adesso ARM64, che sono abbastanza diverse (solo le due Thumb sono molto simili), quindi servono decoder ad hoc per ognuna, e questo ha certo costo, soprattutto per Thumb.
Infatti per esempio a parità di processo produttivo un core Cortex A53 (64bit armv8) occupa il 40% in meno di un core Cortex A9 (32bit armv7) ed in modalità a 64bit ha le stesse prestazioni in termini di capacità di elaborazione.
L'A53 non ha le ottimizzazioni circuitali dell'A9 ma in modalità a 64bit se la gioca alla pari in termini di potenza i calcolo (suppongo nel senso di quando si elaborano dati in unita da 64bit).
Le prestazioni per ARMv8 sono migliori perché sono stati raddoppiati i registri general purpose e quelli di FPU/SIMD, portandoli da 16 a 32 (30, in realtà; mi pare che 2 siano riservati per particolari scopi).
Insomma anche con l'aumento di complessità dovuto ai 64bit ed al supporto della modalità a 32bit si sono potuti permettere di togliere roba ed avere qualcosa di più "leggero" in termini di implementazione.
La roba "pesante" l'hanno tolta soltanto dall'ISA a 64-bit, ma rimane nelle altre ISA, dove continua ad avere il suo peso.

Ha senso parlare di zavorra eliminata soltanto per processori che implementino esclusivamente ARMv8 come architettura.
La decodifica da istruzioni THUMB ad istruzioni ARM è 1:1 quindi il "decoder thumb" è un singolo stadio con espansione "a schema fisso" degli opcode THUMB in opcode ARM "classici" (ed eventualmente bypass della word successiva se contiene un valore costante).
Quando si eseguono istruzioni ARM quello stadio viene semplicemente bypassato.
Sì, lo so, ma questo stadio in più incide sulle prestazioni di Thumb.
Insomma, il supporto di THUMB non pesa sulla decodifica ed esecuzione delle istruzioni ARM a 32bit e quando viene attivato l'incremento di densità delle istruzioni compensa ampiamente gli svantaggi ... presenti solo in modalità THUMB.
Per la densità nulla da dire. Ma Thumb rimane una macchina LOAD/STORE, per cui si porta dietro gli stessi problemi dell'architettura ARM32 di cui ho parlato prima... allungati di uno stadio.
Questo perche se si sta usando una cpu a 64bit significa che si dispone di molta ram e bus dati molto ampi,
Vada per la RAM, che è in continuo aumento, ma non per la dimensione del bus, che può rimanere la stessa. Anzi, vedere bus dati ampii su architetture mobile è difficile a prescindere, per ovvi motivi (di spazio & layout & consumi).
senza contare che usando le istruzioni a 64bit si ha nel caso peggiore circa la stessa densità di codice che si avrebbe usando codice ARM a 32bit senza THUMB.
Assolutamente no. Dipende dal codice, ovviamente, ma a naso direi che mediamente il codice dovrebbe essere meno denso. Ricorda che da ARMv8 sono state rimosse istruzioni, sì, pesanti, ma anche molto utili e che incidono non poco sulla densità di codice.

Non ho dati in merito, e mi piacerebbe vederne qualcuno, ma per quello che ho visto delle due ISA la mia esperienza mi porta a dedurre che sia così.
Se poi consideri che THUMB è stato introdotto essenzialmente per dare il compo di grazia alla concorrenza che per roba embedded proponeva cpu a 16bit o anche ad 8bit ...
E' un problema che hanno avuto anche altre ISA. Anche MIPS, se non ricordo male, ha una sua versione "compatta" con opcode a 16-bit. Forse anche SPARC ha qualcosa di simile, ma in generale è un trend ben noto per i processori RISC.

Checché se ne dica, la densità di codice rimane molto importante a prescindere, perché non impatta soltanto sullo spazio occupato, ma anche sulla banda di memoria e sulle cache TLB.

Ecco perché tanti produttori di RISC alla fine sono stati costretti a calare le corna, e adottare un'ISA a lunghezza variabile (e, dunque, CISC; questo era uno dei punti fermi e distintivi fra le due macro-famiglie).
Poi sarebbe il caso di ricordare che il vantaggio di compattezza del codice "asimmetrico ed irregolare" degli x86 non è stato decisivo nei confronto degli altri RISC ... ma nei confronti degli Itanium. :read:
Ma anche no: Itanium è stata una vittima illustre, in quanto si tratta di un'architettura "di famiglia", ma x86 aveva già fatto fuori tanti altri RISC.

LMCH

08-08-2014, 00:28

Certamente, e sappiamo che i decoder x86/x64 sono nettamente più complessi rispetto a quelli dei RISC. Su questo non ci piove.

Purtroppo errori del genere li può fare chiunque. Ad esempio le prime versioni degli ARM potevano indirizzare al massimo 64MB di memoria (26 bit d'indirizzamento), e se pensi che sono usciti nel 1985, direi che è stata una decisione folle. Rimanendo su x86, nessuno dei progettisti dell'8086 poteva pensare a dove sarebbe arrivata quest'architettura, e quali problemi avrebbero creato certe scelte che, però, all'epoca erano assolutamente sensate e molto vantaggiose.

Considerando che nel 1995 (10 anni dopo) il grosso dei pc era tanto se avevano 16MB non è stata una scelta così insensata e la cosa fu risolta mantendo la retrocompatibilità a livello di set d'istruzioni senza dover introdurre modalità totalmente diverse.

Tranne per i RISC che... diventano CISC introducendo ISA con opcode a lunghezza variabile, o che magari fanno uso di prefissi. ;) Il problema è sempre lo stesso: le esigenze cambiano col tempo, e bisogna mettere delle pezze a quanto già realizzato.

RISC o CISC sono più modelli generici di riferimento che delle religioni.

Non a caso gli ARM erano i "meno RISC" tra le cpu uscite negli anni '80 e '90
(quasi tutte le istruzioni erano condizionali con cose tipo addizioni a tre operanti e barrel shifter bidirezionale sul terzo operando).

Ad esempio, il seguente statement in C:
a = b + (c << 2);
Corrisponde ad un singola istruzione ARM se a,b e c sono già caricati in registri:
ADD Ra, Rb, Rc, LSL #2

Ma anche le altre cpu RISC avevano le loro particolarità (i set di registri "a finestre" degli SPARC, l'execution slot dopo i jump dei MIPS, ecc.).

A parte questo, la realtà di x86 (e x64) è che la stragrande maggioranza delle istruzioni si mappa 1:1 con le uop, perché... si tratta di istruzioni semplici. Dunque non serve un decoder enormemente complesso per gestire il caso peggiore, con istruzioni molto lunghe (che sono una rarità) o che fanno uso di tanti prefissi (al più se ne usa uno, e questo avviene o per indirizzare memoria locale del thread, oppure quella del s.o., oppure per mappare le istruzioni SIMD). Difatti già da parecchi anni esiste UN solo decoder complesso per gestire tutti i casi possibili, che è affiancato da 2 o 3 (nei processori degli ultimi anni) decoder molto più semplici (ed efficienti / parchi di energia & transistor) che si smazzano le istruzioni molto più comunemente usate.

A voler essere pignoli ci sono decoder "semplici" ed il decoder "complesso" da un lato, mentre dall'altro si hanno decoder "molto più semplici" e basta.

Certamente, ma ARM si trascina ARM32, Thumb-2, Thumb-EE, e adesso ARM64, che sono abbastanza diverse (solo le due Thumb sono molto simili), quindi servono decoder ad hoc per ognuna, e questo ha certo costo, soprattutto per Thumb.

Ma tutti i vari decoder sono a livello di quelli "semplici" x86 se non più semplici.
Nel caso dei Thumb si possono pure implementare come "uno stadio in più" su un decoder ARM32 con costi ridottissimi in termini di implementazione rispetto ad un decoder "completo".
Senza contare lo schema di estensioni basato sui coprocessori.

Le prestazioni per ARMv8 sono migliori perché sono stati raddoppiati i registri general purpose e quelli di FPU/SIMD, portandoli da 16 a 32 (30, in realtà; mi pare che 2 siano riservati per particolari scopi).

La roba "pesante" l'hanno tolta soltanto dall'ISA a 64-bit, ma rimane nelle altre ISA, dove continua ad avere il suo peso.

Ma proprio per la "leggerezza" e semplicità dello schema di decodifica
per ARM è stato possibile realizzare il Cortex A53 (la versione "economica" ed a basso consumo della prima generazione ARMv8) in modo da renderlo competitivo a parità di tecnologia di implementazione con un Cortex A9 sia in termini di prestazioni che di area su chip.

Ma anche no: Itanium è stata una vittima illustre, in quanto si tratta di un'architettura "di famiglia", ma x86 aveva già fatto fuori tanti altri RISC.

Il vantaggio del "set d'istruzioni più compatto" degli x86 è stato davvero rilevante solo nei confronti dell'Itanium.

I RISC furono davvero battuti a livello di prestazioni per quel che riguarda desktop e server solo quando Intel cominciò a produrre cpu con 1..2 step di scala d'integrazione di vantaggio sulla concorrenza RISC.
Mentre per tutto il resto del tempo fu la retrocompatibilità con il software x86 già in circolazione a fare la fortuna di Intel.
Senza contare che a far fuori definitivamente MIPS ed Alpha nel settore server furono gli accordi commerciali in vista dell' "inevitabile" successo degli Itanium.

cdimauro

08-08-2014, 08:08

Considerando che nel 1995 (10 anni dopo) il grosso dei pc era tanto se avevano 16MB non è stata una scelta così insensata
Lo era perché avevano posto un grosso limite all'ISA, e l'hanno fatto soltanto per cercare di risparmiare transistor pur di non avere un registro dedicato per lo stato / flag. Fondere PC e flag è stata una scelta infelice sia per il limite della memoria indirizzabile sia per avere messo assieme due cose che dovrebbero stare in posti diversi.

Non mi possono raccontare che fosse una buona scelta all'epoca, perché la tendenza dei 32-bit era già ben delineata, coi maggiori produttori di CPU che avevano sfornato o stavano per sfornare ISA pienamente a 32-bit.
e la cosa fu risolta mantendo la retrocompatibilità a livello di set d'istruzioni senza dover introdurre modalità totalmente diverse.
No, le due ISA, 26 e 32 bit, non sono compatibili. Lo sono largamente le istruzioni, ma c'è il nuovo registro di stato per quella a 32-bit (con apposite istruzioni) in tutte le modalità d'esecuzione (sono presenti le copie shadow). In generale non c'è compatibilità a livello di s.o. (perché la presenza del registro di stato fa gestire interrupt ed eccezioni diversamente) e applicativo (se le istruzioni manipolano direttamente i flag oppure il PC).

Le applicazioni andavano ricompilate, oppure riscritte nelle parti in assembly che manipolavano il PC (e relativi flag).
RISC o CISC sono più modelli generici di riferimento che delle religioni.

Non a caso gli ARM erano i "meno RISC" tra le cpu uscite negli anni '80 e '90
(quasi tutte le istruzioni erano condizionali con cose tipo addizioni a tre operanti e barrel shifter bidirezionale sul terzo operando).

Ad esempio, il seguente statement in C:
a = b + (c << 2);
Corrisponde ad un singola istruzione ARM se a,b e c sono già caricati in registri:
ADD Ra, Rb, Rc, LSL #2

Ma anche le altre cpu RISC avevano le loro particolarità (i set di registri "a finestre" degli SPARC, l'execution slot dopo i jump dei MIPS, ecc.).
Sì, lo so, e aggiungiamo pure che il set d'istruzioni già da anni non è più così ridotto, ma qualunque ISA RISC conta centinaia di istruzioni. E alcuni adottano pure microcodice (che prima era di dominio esclusivo dei CISC e visto come fumo negli occhi dai progettisti RISC).

Ma almeno un paio di punti per discernere se un'ISA è RISC o CISC dovrebbero essere rimasti: esclusivo modello load/store per l'accesso alla memoria e opcode a lunghezza fissa, mentre viceversa possibilità per (la maggior parte del)le istruzioni di accedere direttamente alla memoria e opcode a lunghezza variabile.

Il tutto IMO, ovviamente, ma qualcosa serve per distinguere le due famiglie, altrimenti parliamo soltanto di processori e ISA senza tenere conto di queste due etichette. ;)
A voler essere pignoli ci sono decoder "semplici" ed il decoder "complesso" da un lato, mentre dall'altro si hanno decoder "molto più semplici" e basta.
Mi sembra che su questo siamo d'accordissimo, e l'avevo pure scritto. Ma andava chiarito cosa succede realmente a runtime / "real life", perché incide anche nei consumi di cui abbiamo parlato. Un decoder più semplice occupa molti meno transistor e consuma molto meno rispetto a quello più complicato che gestisce qualunque caso.
Ma tutti i vari decoder sono a livello di quelli "semplici" x86 se non più semplici.
Nel caso dei Thumb si possono pure implementare come "uno stadio in più" su un decoder ARM32 con costi ridottissimi in termini di implementazione rispetto ad un decoder "completo".
Aspetta. Quello serve per semplificare l'esecuzione delle istruzioni Thumb, in modo da "darle in pasto" alla circuiteria già esistente per ARM32. Ma il decoder Thumb non è così semplice come quello ARM32, per cui hai di fatto più che duplicato l'esistente circuiteria, visto che devi decodificare un'ISA abbastanza diversa, e pure a lunghezza variabile.
Senza contare lo schema di estensioni basato sui coprocessori.
Che è stato rimosso da ARMv8. ;) Anche questo faceva parte del retaggio del passato, dove esisteva il concetto di coprocessore esterno al chip. Ormai la tendenza è di avere tutto on-die, per cui ARM ha pensato giustamente di recuperare spazio negli opcode sfruttando quella parte per organizzare meglio la opcode table (32-bit sembrano tanti, ma finiscono molto presto).
Ma proprio per la "leggerezza" e semplicità dello schema di decodifica
per ARM è stato possibile realizzare il Cortex A53 (la versione "economica" ed a basso consumo della prima generazione ARMv8) in modo da renderlo competitivo a parità di tecnologia di implementazione con un Cortex A9 sia in termini di prestazioni che di area su chip.
Ma nulla da dire su questo. Infatti ARMv8 è votato alla maggior semplicità e velocità d'esecuzione. Non sembra nemmeno un ARM, dati i cambiamenti radicali, ma un MIPS o un Alpha...
Il vantaggio del "set d'istruzioni più compatto" degli x86 è stato davvero rilevante solo nei confronti dell'Itanium.

I RISC furono davvero battuti a livello di prestazioni per quel che riguarda desktop e server solo quando Intel cominciò a produrre cpu con 1..2 step di scala d'integrazione di vantaggio sulla concorrenza RISC.
Mentre per tutto il resto del tempo fu la retrocompatibilità con il software x86 già in circolazione a fare la fortuna di Intel.
Senza contare che a far fuori definitivamente MIPS ed Alpha nel settore server furono gli accordi commerciali in vista dell' "inevitabile" successo degli Itanium.
Quando Itanium è stato introdotto x86 aveva già messo alla corda i RISC più rinomati. Persino Apple, nel 2000, voleva dare il benservito ai PowerPC, ma fu convinta a rimanere da un manager di IBM con la promessa del futuro G5, che però ha soltanto tardato il passaggio a x86...

Non è stata questione di processo produttivo, ma di prestazioni.

Poi sei ci fossero anche accordi commerciali, questo non lo so, ma non cambia nulla dal punto di vista prestazionale.

LMCH

09-08-2014, 00:31

Lo era perché avevano posto un grosso limite all'ISA, e l'hanno fatto soltanto per cercare di risparmiare transistor pur di non avere un registro dedicato per lo stato / flag. Fondere PC e flag è stata una scelta infelice sia per il limite della memoria indirizzabile sia per avere messo assieme due cose che dovrebbero stare in posti diversi.

Ricorda che ARM è nato come successore spirituale del 6502, per questo aveva così tante "stranezze" rispetto agli altri RISC.
Si voleva una cpu molto efficiente su hardware che non fosse troppo costoso, con una gestione degli interrupt molto rapida ecc. ecc.
da usare su un home computer non su dei server.
Per questo mentre gli altri RISC debuttavano sui server e poi tentavano la "discesa" negli altri settori, ARM nacque già ad un passo dal settore embedded.

Non mi possono raccontare che fosse una buona scelta all'epoca, perché la tendenza dei 32-bit era già ben delineata, coi maggiori produttori di CPU che avevano sfornato o stavano per sfornare ISA pienamente a 32-bit.

In quel settore (home computer e poi dopo embedded) 26bit di indirizzamento erano uno spazio di memoria enorme
(e lo sono stati molto a lungo) e si pensava di usarlo su prodotti che non avrebbero richiesto grandi quantità di ram prevedibilmente molto più a lungo di quanto serviva sui server e simili.

Poi combinare program counter e status register in un unica word a 32bit eliminava 1 load ed 1 store ad ogni chiamata di funzione C ed assembly, non era una cosa da poco; faceva parte delle tante piccole migliorie che rendevano gli ARM così performanti.

No, le due ISA, 26 e 32 bit, non sono compatibili. Lo sono largamente le istruzioni, ma c'è il nuovo registro di stato per quella a 32-bit (con apposite istruzioni) in tutte le modalità d'esecuzione (sono presenti le copie shadow). In generale non c'è compatibilità a livello di s.o. (perché la presenza del registro di stato fa gestire interrupt ed eccezioni diversamente) e applicativo (se le istruzioni manipolano direttamente i flag oppure il PC).

Le applicazioni andavano ricompilate, oppure riscritte nelle parti in assembly che manipolavano il PC (e relativi flag).

In ambito embedded (il mercato dominante quando ormai il problema andava affrontato) non era un gran problema, senza contare che per le parti in assembly di solito si usavano le macro per "incapsulare" le sequenze ripetute più di frequente (ad esempio, che si trattasse di x86, di mc68000 o altro io usavo sempre delle macro PROLOG ed EPILOG che dove necessario incapsulavano il grosso delle convenzioni di chiamata per interfacciarsi con questo o quel compilatore o questo o quel modello di memoria).
Il "problema" del passagio di codice "a 26bit" verso i 32bit non era così differente da quello che avveniva con gli x86 a 16 bit (modello "small" a 64KB di dati, "large" a segmenti con limite di 64KB per una singola struct o array e "huge" con segment+offset gestiti emulando un puntatore con indirizzamento lineare).

Aspetta. Quello serve per semplificare l'esecuzione delle istruzioni Thumb, in modo da "darle in pasto" alla circuiteria già esistente per ARM32. Ma il decoder Thumb non è così semplice come quello ARM32, per cui hai di fatto più che duplicato l'esistente circuiteria, visto che devi decodificare un'ISA abbastanza diversa, e pure a lunghezza variabile.

Nelle architetture ARM32+THUMB si usa un unico decoder (con lo "stadio aggiuntivo" THUMB) perché quando si usano le istruzioni THUMB si vuole principalmente maggior compattezza del codice, mentre nelle architetture THUMB-only ( ARM M0 ed M1) si usa un decoder ancora più semplice
(perche lo si può ottimizzare ulteriormente).

Che è stato rimosso da ARMv8. ;) Anche questo faceva parte del retaggio del passato, dove esisteva il concetto di coprocessore esterno al chip. Ormai la tendenza è di avere tutto on-die, per cui ARM ha pensato giustamente di recuperare spazio negli opcode sfruttando quella parte per organizzare meglio la opcode table (32-bit sembrano tanti, ma finiscono molto presto).

Ma nulla da dire su questo. Infatti ARMv8 è votato alla maggior semplicità e velocità d'esecuzione. Non sembra nemmeno un ARM, dati i cambiamenti radicali, ma un MIPS o un Alpha...

Infatti e non è un caso.
La transizione verso i 64bit degli ARM sta avvenendo in un contesto totalmente diverso da quando Intel tentò il "suo" passaggio ai 64bit ... con gli Itanium ed ARM non si fa problemi a seguire la strada tracciata dagli Alpha (letteralmente nati per essere cpu a 64bit "tutte prestazioni ed efficienza").

Quando Itanium è stato introdotto x86 aveva già messo alla corda i RISC più rinomati. Persino Apple, nel 2000, voleva dare il benservito ai PowerPC, ma fu convinta a rimanere da un manager di IBM con la promessa del futuro G5, che però ha soltanto tardato il passaggio a x86...

Non è stata questione di processo produttivo, ma di prestazioni.

Poi sei ci fossero anche accordi commerciali, questo non lo so, ma non cambia nulla dal punto di vista prestazionale.

Gli Alpha, ovvero cpu ormai letteralmente morte per accordi commerciali, con un ultimo shrink e qualche ritocco (Alpha EV7z) continuarono a spaccare il cu:ciapet:lo agli Itanium per molti anni pure nell'ambito in cui questi erano più forti e superiori alle cpu x86 del periodo.
Furono letteralmente uccisi dall'accordo tra HP ed Intel, non perche non riuscissero a reggere il confronto.

Mentre SGI fu pure costretta a prolungare di due generazioni lo sviluppo di cpu MIPS "da server/workstation" a causa dei problemi di prestazioni degli Itanium.

cdimauro

09-08-2014, 08:54

Ricorda che ARM è nato come successore spirituale del 6502, per questo aveva così tante "stranezze" rispetto agli altri RISC.
Si voleva una cpu molto efficiente su hardware che non fosse troppo costoso, con una gestione degli interrupt molto rapida ecc. ecc.
da usare su un home computer non su dei server.
Per questo mentre gli altri RISC debuttavano sui server e poi tentavano la "discesa" negli altri settori, ARM nacque già ad un passo dal settore embedded.
Ricordo molto bene la storia di ARM/Acorn, e l'obiettivo era competere coi personal computer. ARM si riciclerà nell'embedded molto dopo, non avendo trovato spazio nel mercato dei PC (l'Acorn Archimedes ebbe un buon successo in Gran Bretagna, ma non riuscì a sfondare a livello globale).
In quel settore (home computer e poi dopo embedded) 26bit di indirizzamento erano uno spazio di memoria enorme
(e lo sono stati molto a lungo) e si pensava di usarlo su prodotti che non avrebbero richiesto grandi quantità di ram prevedibilmente molto più a lungo di quanto serviva sui server e simili.
Persino il Motorola 68012, che non era certo pensato per server (non aveva MMU), aveva 31 bit di spazio d'indirizzamento e poteva indirizzare 2GB di memoria (8GB suddividendo lo spazio d'indirizzamento in supervisor / utente e in codice / dati).
Nell'84 Intel presentò l'80386, che rese disponibile nell'85. L'80386 consentiva 46 bit d'indirizzamento virtuale e 32 bit d'indirizzamento per la memoria fisica.
Lo stesso anno Motorola presentò e commercializzò il 68020, che era dotato di bus esterno a 32-bit, e si poteva indirizzare fino a 4GB di memoria (o 16GB; vedi sopra per il 68012).
Nell'84 era arrivato il Macintosh che montava un 68000, il quale poteva già indirizzare 16MB e fino a 64MB (idem come sopra per il 68012), ma queste limitazioni erano esclusivamente dovute alla dimensione del bus esterno: internamente l'architettura era 32-bit era lo spazio d'indirizzamento era 32-bit. Era Motorola che, per meglio differenziare il suo catalogo e i target di mercato, offriva processori con bus esterni (indirizzo e/o dati) castrati (vedi anche 68008: bus indirizzi a 20 e dati a 8, ma i registri dati e indirizzi erano sempre a 32-bit, come per tutta la famiglia di processori 68K fin dal day 1).
Nell'85 arrivano Atari ST prima e Amiga dopo, che montavano entrambi il 68000.
Il primo modello di ARM fu presentato nell'85 (quindi un anno dopo la presentazione del 386 e dello 020, e di cui Acorn era sicuramente a conoscenza), ma il primo prodotto arrivò soltanto l'anno dopo. Il primo Archimedes arrivò soltanto nell'87, per competere finalmente nel mercato dei personal computer.

Con ciò voglio dire che Acorn, a mio avviso, sbagliò completamente il design dell'architettura ARM, con quel limite invalicabile dei 26 bit di spazio d'indirizzamento. Il trend dell'industry era ben noto e consolidato, come ho mostrato. Il fatto che all'epoca non esistessero personal computer con 64MB o più di memoria fisica non vuol dire che non si potessero realizzare: era estremamente costoso farlo, senz'altro, e aveva poco senso all'epoca. Ma non c'era alcun limite fisico in ciò, che invece era presente negli ARM.
E stiamo parlando della sola memoria fisica, ma più di 64MB di memoria virtuale avevano perfettamente senso già all'epoca.
Poi combinare program counter e status register in un unica word a 32bit eliminava 1 load ed 1 store ad ogni chiamata di funzione C ed assembly, non era una cosa da poco; faceva parte delle tante piccole migliorie che rendevano gli ARM così performanti.
Nelle chiamate a funzioni non serve assolutamente conservare anche i flag. Serve soltanto conservare l'indirizzo dell'istruzione successiva alla chiamata.
In ambito embedded (il mercato dominante quando ormai il problema andava affrontato) non era un gran problema,
ARM passò alla versione full 32-bit soltanto 7 anni dopo la presentazione del primo ARM, nel'92, ma nel settore embedded non c'era alcun motivo per estendere lo spazio d'indirizzamento a 32-bit: 26-bit erano perfettamente sufficienti.
senza contare che per le parti in assembly di solito si usavano le macro per "incapsulare" le sequenze ripetute più di frequente (ad esempio, che si trattasse di x86, di mc68000 o altro io usavo sempre delle macro PROLOG ed EPILOG che dove necessario incapsulavano il grosso delle convenzioni di chiamata per interfacciarsi con questo o quel compilatore o questo o quel modello di memoria).
Io ho programmato abbondantemente entrambi i processori, ma quasi mai ho avuto bisogno di macro di prologo o epilogo nelle routine che scrivevo. Raramente ho avuto bisogno di più registri di quelli a disposizione e, dunque, di mettere qualche parametro o variabile locale sullo stack (dunque di creare uno stack-frame). Anche perché le istruzioni ENTER/LEAVE e LINK/UNLINK erano decisamente pesanti, per cui in genere evitavo (o, al limite, ricorrevo a qualche "push" / "pop"). In ogni caso si trattava di singole scelte che facevo direttamente, senza ricorrere a macro.
Il "problema" del passagio di codice "a 26bit" verso i 32bit non era così differente da quello che avveniva con gli x86 a 16 bit (modello "small" a 64KB di dati, "large" a segmenti con limite di 64KB per una singola struct o array e "huge" con segment+offset gestiti emulando un puntatore con indirizzamento lineare).
No, sono due cose completamente diverse. I modelli "huge" e "small" per 8086 e 80286 prevedevano l'uso o meno di segmenti/selettori per indirizzare la memoria, e dunque i puntatori erano a 16 o 32-bit (16 bit per segmento/selettore e 16 bit per offset). Con l'80386 si aggiunse il modello a 48-bit (16 + 32-bit), che però ebbe poca diffusione (la dimensione del puntatore è decisamente strana, non essendo una potenza del 2).

Per le architetture ARM a 26 e 32-bit, invece, i puntatori erano sempre della stessa dimensione: 32-bit. L'unica differenza è che nel primo caso alcuni bit erano a zero / inutilizzati, e che se si salvava il PC ci si trascinava dietro anche il registro di stato & flag (idem per il ripristino).

Dunque le applicazioni non andavano cambiate per quanto riguarda l'indirizzamento della memoria (i puntatori rimanevano gli stessi), ma soltanto nelle parti di codice che manipolavano il PC e/o i flag.
Nelle architetture ARM32+THUMB si usa un unico decoder (con lo "stadio aggiuntivo" THUMB) perché quando si usano le istruzioni THUMB si vuole principalmente maggior compattezza del codice, mentre nelle architetture THUMB-only ( ARM M0 ed M1) si usa un decoder ancora più semplice (perche lo si può ottimizzare ulteriormente).
Lo stadio in più di cui parli fa uso di un apposito decoder che riconosce soltanto le istruzioni THUMB, e produce il corrispettivo opcode / istruzione ARM da eseguire. E', a tutti gli effetti, un nuovo, diverso decoder che è stato inserito nel processore.

Puoi vederlo come un decoder semplice di x86, che traduce un'istruzione x86 in un uop RISC: sarà quest'ultima a essere poi decodificata ed eseguita.

Le versioni THUMB-only non hanno bisogno di questa traduzione, ovviamente, per cui non è necessario avere entrambi il decoder: ce n'è soltanto uno, più grosso di quello ARM ma inferiore alla somma dei decoder THUMB + ARM.
Infatti e non è un caso.
La transizione verso i 64bit degli ARM sta avvenendo in un contesto totalmente diverso da quando Intel tentò il "suo" passaggio ai 64bit ... con gli Itanium ed ARM non si fa problemi a seguire la strada tracciata dagli Alpha (letteralmente nati per essere cpu a 64bit "tutte prestazioni ed efficienza").
Certamente, ma ha avuto tutto il tempo e se l'è presa comoda: era l'unica architettura "di spicco" a essere rimasta a 32-bit. ;)
Gli Alpha, ovvero cpu ormai letteralmente morte per accordi commerciali, con un ultimo shrink e qualche ritocco (Alpha EV7z) continuarono a spaccare il cu:ciapet:lo agli Itanium per molti anni pure nell'ambito in cui questi erano più forti e superiori alle cpu x86 del periodo.
Furono letteralmente uccisi dall'accordo tra HP ed Intel, non perche non riuscissero a reggere il confronto.

Mentre SGI fu pure costretta a prolungare di due generazioni lo sviluppo di cpu MIPS "da server/workstation" a causa dei problemi di prestazioni degli Itanium.
Ma io ho sempre parlato di x86. Itanium è stato un fallimento, e lo sappiamo tutti, anche se sul codice in virgola mobile (NON SIMD) aveva delle ottime prestazioni.

Per quanto riguarda x86, già verso la fine degli anni '90 aveva prestazioni sugli "interi" comparabili a quelle dei migliori RISC, Alpha incluso. Peccava nei calcoli in virgola mobile, complice la vecchia FPU x87. La musica, però, è cambiata con l'introduzione delle SSE, che con apposito codice consentivano prestazioni mediamente superiori anche all'Alpha.

Alpha è una bella architettura, senz'altro, ma era votata esclusivamente alle prestazioni, e il codice era tutt'altro che denso. Oltre al fatto che la opcode table era già abbastanza inflazionata, e c'era ben poco spazio per aggiunte come una nuova unità SIMD. Con l'esplosione dei SIMD dubito che sarebbe rimasta competitiva. In ogni caso il suo target era esclusivamente quello dei server / workstation.

LMCH

10-08-2014, 02:06

Io ho programmato abbondantemente entrambi i processori, ma quasi mai ho avuto bisogno di macro di prologo o epilogo nelle routine che scrivevo. Raramente ho avuto bisogno di più registri di quelli a disposizione e, dunque, di mettere qualche parametro o variabile locale sullo stack (dunque di creare uno stack-frame). Anche perché le istruzioni ENTER/LEAVE e LINK/UNLINK erano decisamente pesanti, per cui in genere evitavo (o, al limite, ricorrevo a qualche "push" / "pop"). In ogni caso si trattava di singole scelte che facevo direttamente, senza ricorrere a macro.

Se hai programmato in assembly senza far uso di macro, specialmente di quelle di prologo ed epilogo significa che hai scritto roba ad-hoc (tipo: ottimizzazione in assembly di singole funzioni precedentemente scritte in C), io ho scritto roba un pochino differente (tipo generatori di codice assemby a partire da bytecode di plc) in cui il codice assembly generato chiamava o veniva chiamato da funzioni scritte in C (con conseguente necessità di supportare l'ABI usata dal compilatore C).
Visto che con certi compilatori l'ABI può variare anche in base alle opzioni di compilazione (uso oppure no di registri come base pointer, numero degli scratch register, ecc.), usare macro (in modo da cambiare il codice in un solo punto invece che ad ogni entry point o punto di chiamata) era una scelta quasi obbligata.

Insomma, le modifiche richieste per il passaggio dal modello a 26bit a quello a 32bit con un ISA come quella degli ARM non mi sembrano così problematiche.

LMCH

10-08-2014, 02:15

ARM passò alla versione full 32-bit soltanto 7 anni dopo la presentazione del primo ARM, nel'92, ma nel settore embedded non c'era alcun motivo per estendere lo spazio d'indirizzamento a 32-bit: 26-bit erano perfettamente sufficienti.

Perche 7 anni dopo le cose erano cambiate parecchie, ARM era stato sviluppato da Acorn Computers in primo luogo per il suo home computer, ma 5 anni dopo la IP di ARM era sotto il controllo di ARM Holdings e questa cercava di proporlo anche in altri settori (non necessariamente quello embedded) e quindi iniziarono a rimuovere cose che potevano essere percepite come limitazioni per i nuovi possibili utilizzi.
Insomma, 7 anni dopo la presentazione, ma 2 anni dopo il passaggio ad ARM Holdings che aveva idee differenti riguardo i possibili campi d'impiego.

LMCH

10-08-2014, 02:21

Puoi vederlo come un decoder semplice di x86, che traduce un'istruzione x86 in un uop RISC: sarà quest'ultima a essere poi decodificata ed eseguita.

Le versioni THUMB-only non hanno bisogno di questa traduzione, ovviamente, per cui non è necessario avere entrambi il decoder: ce n'è soltanto uno, più grosso di quello ARM ma inferiore alla somma dei decoder THUMB + ARM.

Ma nei casi in cui si usa un decoder THUMB-only la cosa non è un problema perche l'obiettivo principale è la densità del codice e la riduzione globale di complessità del core.

LMCH

10-08-2014, 03:06

Alpha è una bella architettura, senz'altro, ma era votata esclusivamente alle prestazioni, e il codice era tutt'altro che denso. Oltre al fatto che la opcode table era già abbastanza inflazionata, e c'era ben poco spazio per aggiunte come una nuova unità SIMD. Con l'esplosione dei SIMD dubito che sarebbe rimasta competitiva. In ogni caso il suo target era esclusivamente quello dei server / workstation.

Scusa, ma hai presente la parte riguardo "architettura nata a 64bit" ? ;)

Era ovvio che aveva codice poco "denso" rispetto ad un x86 nato come cpu a 16bit, ma era anche vero che nasceva con un set di 64 registri a 64bit
(32 interi e 32 fp) e che la direttiva primaria era avere il massimo delle prestazioni ottenibili con un architettura a 64bit.

Tra le altre cose aveva istruzioni SIMD (le MVI) ma i suoi progettisti per EV8 avevano già previsto di implementare un "vero" multithreading (non quella roba assurdamente mal dimensionata dei Pentium 4).

Per rendere l'idea EV8 doveva avere 4 thread per core con sino ad 8 istruzioni per ciclo per thread (il numero di thread era dimensionato in modo tale che nel caso peggiore le pipeline funzionassero comunque a pieno regime o quasi).

Roba che avrebbe prodotto prestazioni "da ottimizzazioni SIMD" anche eseguendo codice normale o che non poteva essere parallelizzato in modo efficiente con istruzioni SIMD.

Roba che non si poteva fare con gli x86 senza modifiche radicali al loro set d'istruzioni (e per cui per essi l'unica strada percorribile era introdurre le SIMD e nuovi registri).

SOLO DOPO EV8 era prevista l'aggiunta di estensioni SIMD "stile SSE2" per continuare a salire di prestazioni, guardacaso si trattava di registri a 128bit
(non a 256bit o 512bit come per gli x86) perche per come era strutturata l'architettura conveniva di più "aggiungere thread" invece che "allargare troppo i registri".

Il fatto che anche gli ARM (inclusi gli ARMv8) abbiano registri "SIMD" che sono "solo" a 128bit non è casuale.
Il set d'istruzioni non è così irrilevante, ha influenzato l'evoluzione stessa degli x86 ed ora con ARMv8 forse si potrà verificare se la roadmap dei progettisti di Alpha influenza anche da un differente set d'istruzioni era valida oppure no.

cdimauro

10-08-2014, 09:30

Se hai programmato in assembly senza far uso di macro, specialmente di quelle di prologo ed epilogo significa che hai scritto roba ad-hoc (tipo: ottimizzazione in assembly di singole funzioni precedentemente scritte in C), io ho scritto roba un pochino differente (tipo generatori di codice assemby a partire da bytecode di plc) in cui il codice assembly generato chiamava o veniva chiamato da funzioni scritte in C (con conseguente necessità di supportare l'ABI usata dal compilatore C).
Visto che con certi compilatori l'ABI può variare anche in base alle opzioni di compilazione (uso oppure no di registri come base pointer, numero degli scratch register, ecc.), usare macro (in modo da cambiare il codice in un solo punto invece che ad ogni entry point o punto di chiamata) era una scelta quasi obbligata.
Le tue, però, non sono le esigenze comuni di chi deve rimpiazzare una funzione (o parte di essa) con un'equivalente in assembly. Come nel mio caso.
Insomma, le modifiche richieste per il passaggio dal modello a 26bit a quello a 32bit con un ISA come quella degli ARM non mi sembrano così problematiche.
Non ho mai detto questo, infatti. Ho sottolineato soltanto che le due ISA erano incompatibili, e l'errore progettuale nella scelta di Acorn per la prima.
Perche 7 anni dopo le cose erano cambiate parecchie, ARM era stato sviluppato da Acorn Computers in primo luogo per il suo home computer, ma 5 anni dopo la IP di ARM era sotto il controllo di ARM Holdings e questa cercava di proporlo anche in altri settori (non necessariamente quello embedded) e quindi iniziarono a rimuovere cose che potevano essere percepite come limitazioni per i nuovi possibili utilizzi.
Insomma, 7 anni dopo la presentazione, ma 2 anni dopo il passaggio ad ARM Holdings che aveva idee differenti riguardo i possibili campi d'impiego.
Senz'altro, ma visto che l'orientamento era verso il settore embedded ormai, aveva poco senso un passaggio dall'architettura a 26 a quella a 32 bit, viste le esigenze tipiche del settore embedded, specialmente in quel periodo.

Voglio dire, è paradossale che per i personal computer (e pure i server; infatti Acorn cercò di inserirsi anche nel mercato Unix) abbia proposto un'architettura castrata, salvo poi, diverso tempo dopo, riprogettarla in maniera più pulita quando si stava buttando sul settore embedded (che aveva, e spesso ha pure oggi, esigenze di gran lunga minori).
Ma nei casi in cui si usa un decoder THUMB-only la cosa non è un problema perche l'obiettivo principale è la densità del codice e la riduzione globale di complessità del core.
Assolutamente d'accordo su questo.
Scusa, ma hai presente la parte riguardo "architettura nata a 64bit" ? ;)
Certamente. :)
Era ovvio che aveva codice poco "denso" rispetto ad un x86 nato come cpu a 16bit, ma era anche vero che nasceva con un set di 64 registri a 64bit
(32 interi e 32 fp) e che la direttiva primaria era avere il massimo delle prestazioni ottenibili con un architettura a 64bit.
Nulla da dire su questo, infatti.
Tra le altre cose aveva istruzioni SIMD (le MVI)
Le MVI erano una piccola pezza, ben più piccola di quella che ARM aveva introdotto nella sua ISA (http://www.appuntidigitali.it/4670/lapproccio-di-arm-allelaborazione-simd/) per cercare di sfruttare qualche vantaggio del paradigma SIMD, sfruttando la stessa tecnica (utilizzare i registri interi per conservare i dati "impacchettati").
ma i suoi progettisti per EV8 avevano già previsto di implementare un "vero" multithreading (non quella roba assurdamente mal dimensionata dei Pentium 4).
L'Hyperthreading per il Pentium 4 nasce per ben altre esigenze. ;)
Per rendere l'idea EV8 doveva avere 4 thread per core con sino ad 8 istruzioni per ciclo per thread (il numero di thread era dimensionato in modo tale che nel caso peggiore le pipeline funzionassero comunque a pieno regime o quasi).
Da quel che ho trovato qui (http://en.wikipedia.org/wiki/Alpha_21464) sembra che il frontend fosse in grado di inviare fino a 8 istruzioni intere e fino a 4 in virgola mobile alle rispettive unità di calcolo per ciclo di clock; ovviamente per 4 thread hardware.
Roba che avrebbe prodotto prestazioni "da ottimizzazioni SIMD" anche eseguendo codice normale o che non poteva essere parallelizzato in modo efficiente con istruzioni SIMD.
Vedi sopra. Se ci pensi bene, non è molto come dato complessivo. Un Pentium 3 con la sua unità SIMD riesce a macinare 4 istruzioni in virgola mobile per ciclo di clock, con un'architettura di gran lunga più semplice. Ovviamente sono due processori pensati per ambiti completamente diversi, ma se guardi ai numeri grezzi (per il calcolo in virgola mobile) l'EV8 non è così impressionante.

Per essere chiari, pensare di competere con un'unità SIMD con un'architettura come quella di EV8 è come sparare a una mosca con un cannone: hai messo in campo enormi risorse quando la problematica ne richiede molte meno per essere risolta. Comunque ne parlo meglio dopo.
Roba che non si poteva fare con gli x86 senza modifiche radicali al loro set d'istruzioni (e per cui per essi l'unica strada percorribile era introdurre le SIMD e nuovi registri).
Questo come fai a dedurlo, scusa? EV8 non introduce istruzioni particolari o qualche modalità d'esecuzione speciale. Si tratta di una particolare micro-implementazione di Alpha.

Non c'è nulla che impedisca di fare lo stesso con x86. Non lo si fa perché i vantaggi non sono commisurati all'implementazione troppo complicata. Oggi ci sono altre vie per ottenere prestazioni anche migliori; vedi sotto.
SOLO DOPO EV8 era prevista l'aggiunta di estensioni SIMD "stile SSE2" per continuare a salire di prestazioni,
Non ho trovato notizie di ciò. Comunque secondo te perché avrebbero scelto l'approccio SIMD anziché continuare sulla strada del modello EV8? :fiufiu:
guardacaso si trattava di registri a 128bit
(non a 256bit o 512bit come per gli x86)
Veramente le SSE erano e sono a 128 bit (e le MMX erano addirittura a 64-bit). Soltanto di recente con AVX i registri SIMD sono diventati a 256-bit (e diventeranno a 512-bit con AVX-512), mentre Larrabee/Xeon Phi offre dall'inizio registri SIMD a 512-bit.
perche per come era strutturata l'architettura conveniva di più "aggiungere thread" invece che "allargare troppo i registri".
Beh, se ti vai a vedere i dettagli di EV8 i registri li hanno comunque allargati molto, in termini numerici, e questo ha influenzato pesantemente l'architettura.

E se Alpha aveva deciso di introdurre un'unità SIMD dopo EV8, sarà stato sicuramente a causa dell'enorme complessità dell'implementazione di EV8 per gestire tutta quella roba, che invece con un modello SIMD è di gran lunga più semplice (i registri "larghi" servono anche a questo: a "spalmare" la complessità di gestione dei registri sulla loro ampiezza. Meno registri ma più larghi -> molta meno logica per gestire il tutto).
Il fatto che anche gli ARM (inclusi gli ARMv8) abbiano registri "SIMD" che sono "solo" a 128bit non è casuale.
Potrebbero averli anche a 256, 512, o più bit: non è prerogativa di x86 avere registri SIMD "ampii". Tra l'altro ARM non ha micro-architetture fortemente multi-thread come EV8. Dunque vorrei capire cos'è che volevi esprimere in questa parte della discussione, riguardo alla necessità / convenienza di avere o meno registri a 128 o più bit, perché non mi è chiaro.
Il set d'istruzioni non è così irrilevante, ha influenzato l'evoluzione stessa degli x86 ed ora con ARMv8 forse si potrà verificare se la roadmap dei progettisti di Alpha influenza anche da un differente set d'istruzioni era valida oppure no.
Senz'altro. Io sono un forte sostenitore che l'ISA abbia un suo ruolo, anche forte. :cool:

Stamattina mi sono divertito a smazzarmi un po' di documentazione sugli Alpha, inclusa la opcode table. Le istruzioni load/store e di salto si mangiano più di metà dello spazio, ma ho visto che ci sono diversi buchi che potrebbero essere tranquillamente utilizzati per implementare le istruzioni di load/store per l'unità SIMD, come pure le istruzioni necessarie; con un'opportuna codifica ci sarebbe anche spazio per istruzioni quaternarie (con 4 registri; molto utili per particolari istruzioni come FMAC & FMA).

Altra cosa interessante è il fatto che Alpha è comunque abbastanza complessa come ISA, contando qualche centinaia di istruzioni (fra cui alcune per il "legacy" che si porta dietro dai VAX), di cui alcune abbastanza complicate. La ricordavo molto più semplicemente, ma evidentemente anche Digital ha pensato di allinearsi alla tendenza ormai delineata, inserendo istruzioni specializzate nella sua ISA.

Rimane sempre una "bella" architettura, anche se scarsamente densa per il codice. Ma gli obiettivi, appunto, erano ben altri.

LMCH

10-08-2014, 17:22

Non ho trovato notizie di ciò. Comunque secondo te perché avrebbero scelto l'approccio SIMD anziché continuare sulla strada del modello EV8? :fiufiu:

Perche grazie al set d'istruzioni utilizzato aggiungevano (ricorda che lo avevano già fatto) nuove istruzioni e nuovi registri in modo più flessibile.

Il motivo per cui intendevano aggiungere istruzioni SIMD con registri a 128bit era perche con essi avrebbero aggiunto nche il supporto in hardware dei float a 128bit (con "gratis" altre istruzioni SIMD che tornavano utili).

Non si erano spinti oltre perche se si esagera con l'ampiezza dei registri si hanno maggiori limitazioni sulla frequenza operativa massima (per tener sotto controllo il clock skew) e su quanti thread si possono eseguire in simultanea.

I progettisti di Alpha privilegiavano il multithreading perchè il software che facevano girare traeva più vantaggio senza dover ricompilare dal multithreading che dalle istruzioni SIMD, inoltre questo permettera di scalare maggiormente di prestazioni senza dover cambiare il set d'istruzioni per accomodare registri SIMD più grandi in mancanza di alternative migliori come attualmente fa Intel.

Inoltre con il multithreading si possono aggiungere ulteriori thread o rimuoverli completamente dall'implementazione mantenendo la retrocompatibilita totale con il software già sviluppato, mentre è più complicato "tornare indietro" se si cambia il set d'istruzioni (e diventa sempre più complicato "andare avanti" aggiungendo nuove istruzioni).

Non si risolve tutto a colpi di registri SIMD sempre più ampi.

Intel segue una certa strada perche le sono precluse altre opzioni che invece erano disponibili per gli Alpha.

cdimauro

11-08-2014, 08:22

Perche grazie al set d'istruzioni utilizzato aggiungevano (ricorda che lo avevano già fatto) nuove istruzioni e nuovi registri in modo più flessibile.
Le nuove, ma pochissime, istruzioni vettoriali facevano uso dei registri interi.
Il motivo per cui intendevano aggiungere istruzioni SIMD con registri a 128bit era perche con essi avrebbero aggiunto nche il supporto in hardware dei float a 128bit (con "gratis" altre istruzioni SIMD che tornavano utili).
Per cui probabilmente avrebbero esteso i registri dell'FPU a 128-bit, anziché aggiungere un banco di nuovi registri a 128-bit.
Non si erano spinti oltre perche se si esagera con l'ampiezza dei registri si hanno maggiori limitazioni sulla frequenza operativa massima (per tener sotto controllo il clock skew) e su quanti thread si possono eseguire in simultanea.
Il passaggio da SSE (128-bit) ad AVX (256-bit) non ha visto una diminuzione della frequenza massima dei processori (anzi, è leggermente migliorata; ovviamente mi riferisco a parità di processo produttivo utilizzato dalle rispettive famiglie di processori). Per quello da AVX ad AVX-512 (512-bit) si dovrà attendere l'arrivo di Broadwell prima, e Skylake dopo (in modo da confrontare le frequenze a parità di processo produttivo utilizzato) per controllare (ma sono fiducioso che non ci saranno sorprese).

Riguardo al numero di thread, l'unica famiglia di processori x86 che ne adotta 4 per core è Xeon Phi, che ha registri SIMD a 512-bit, ma frequenze ridotte per contenere i consumi. Per cui non si può prendere a campione per analizzare l'impatto della lunghezza dei registri SIMD sul numero di thread.
I progettisti di Alpha privilegiavano il multithreading perchè il software che facevano girare traeva più vantaggio senza dover ricompilare dal multithreading che dalle istruzioni SIMD, inoltre questo permettera di scalare maggiormente di prestazioni senza dover cambiare il set d'istruzioni per accomodare registri SIMD più grandi in mancanza di alternative migliori come attualmente fa Intel.

Inoltre con il multithreading si possono aggiungere ulteriori thread o rimuoverli completamente dall'implementazione mantenendo la retrocompatibilita totale con il software già sviluppato, mentre è più complicato "tornare indietro" se si cambia il set d'istruzioni (e diventa sempre più complicato "andare avanti" aggiungendo nuove istruzioni).
Eppure l'approccio multithreading spinto di EV8 non ha attecchito, e molte famiglie di processori non l'hanno adottato, preferendo, invece, ricorrere all'integrazione di un'unità SIMD. Evidentemente il primo porta molti più problemi rispetto al secondo.
Non si risolve tutto a colpi di registri SIMD sempre più ampi.
I numeri al momento dimostrano che danno una grande mano. ;)
Intel segue una certa strada perche le sono precluse altre opzioni che invece erano disponibili per gli Alpha.
Anche altri produttori di processori non hanno seguito la strada di Alpha, preferendo passare dalla via dell'unità SIMD. E Alpha stesso avrebbe adottato quest'ultima.

Finora aumentare l'ampiezza dei registri SIMD ha dato ragione a Intel, come pure l'assenza di implementazioni multithreading estremamente aggressive da parte di altri vendor (eccetto IBM con POWER8 che dovrebbe essere confrontabile con EV8, se non ricordo male, ma presenta consumi elevatissimi ed è pensato per ambiti molto specializzati).

La microelettronica non è il mio campo, ma a naso direi che quest'ultima soluzione crea decisamente più problemi rispetto alla prima, ed è il motivo per cui sia praticamente scomparsa a favore della prima soluzione. ;)

LMCH

11-08-2014, 17:13

Le nuove, ma pochissime, istruzioni vettoriali facevano uso dei registri interi.

Le MVI furono introdotte nel 1997, mentre EV8 con il SMT era inizialmente previsto per il 2003 e le nuove istruzioni SIMD ed i nuovi registri a 128bit erano pianificati per dopo EV8.
Non erano "nuove" ed evidentemente non c'era tutta quell'urgenza di introdurre nuove istruzioni SIMD.

Per cui probabilmente avrebbero esteso i registri dell'FPU a 128-bit, anziché aggiungere un banco di nuovi registri a 128-bit.

Era una delle opzioni in teoria possibili, ma probabilmente avrebbero aggiunto dei registri distinti in modo da aver maggior libertà nelle ottimizzazioni a livello di implementazione (es: unita di esecuzione separate con più alta latenza ma con maggior throughput complessivo nella manipolazione di vettori).

Il passaggio da SSE (128-bit) ad AVX (256-bit) non ha visto una diminuzione della frequenza massima dei processori (anzi, è leggermente migliorata; ovviamente mi riferisco a parità di processo produttivo utilizzato dalle rispettive famiglie di processori). Per quello da AVX ad AVX-512 (512-bit) si dovrà attendere l'arrivo di Broadwell prima, e Skylake dopo (in modo da confrontare le frequenze a parità di processo produttivo utilizzato) per controllare (ma sono fiducioso che non ci saranno sorprese).

Riguardo al numero di thread, l'unica famiglia di processori x86 che ne adotta 4 per core è Xeon Phi, che ha registri SIMD a 512-bit, ma frequenze ridotte per contenere i consumi. Per cui non si può prendere a campione per analizzare l'impatto della lunghezza dei registri SIMD sul numero di thread.

Ma negli x86 il decoder e gli altri colli di bottiglia sono differenti, senza contare che da anni una volta venuta meno la "minaccia" di AMD non spinge più di tanto il clock delle sue cpu.

Finora aumentare l'ampiezza dei registri SIMD ha dato ragione a Intel, come pure l'assenza di implementazioni multithreading estremamente aggressive da parte di altri vendor (eccetto IBM con POWER8 che dovrebbe essere confrontabile con EV8, se non ricordo male, ma presenta consumi elevatissimi ed è pensato per ambiti molto specializzati).

La microelettronica non è il mio campo, ma a naso direi che quest'ultima soluzione crea decisamente più problemi rispetto alla prima, ed è il motivo per cui sia praticamente scomparsa a favore della prima soluzione. ;)

Con l' aumentare della scala d'integrazione e l'enfasi sulla riduzione dei consumi, l'approccio multithreading si è trasformato in un approccio multicore
(vedi le soluzioni multi-core ARM).
Ma come tu stesso hai notato, dove sono le prestazioni il requisito primario e dove il set d'istruzioni lo permette (i POWER di IBM) si segue un approccio multi-thread e multi-core.

L'approccio SIMD "modalità smodata" è un "successo" (per gli x86) perchè Intel è ritornata a dettar legge riguardo i set d'istruzioni x86 (dopo che AMD per una volta riuscì ad imporre come standard di fatto x86-64, ma ci riuscì solo per il supporto di Microsoft che si rifiutò di supportare un altro standard a 64bit per x86 come Intel era disposta a fare).

Tutti gli altri hanno introdotto nel tempo istruzioni SIMD ma "guardacaso" si sono limitati a registri a 128bit (Altivec, NEON, e MIPS SIMD) e se servivano maggiori prestazioni hanno aumentato il numero di core.

cdimauro

12-08-2014, 08:24

Le MVI furono introdotte nel 1997, mentre EV8 con il SMT era inizialmente previsto per il 2003 e le nuove istruzioni SIMD ed i nuovi registri a 128bit erano pianificati per dopo EV8.
Non erano "nuove" ed evidentemente non c'era tutta quell'urgenza di introdurre nuove istruzioni SIMD.
O non c'erano risorse, visti i tempi di sviluppo molto lunghi di EV8? ;)
Era una delle opzioni in teoria possibili, ma probabilmente avrebbero aggiunto dei registri distinti in modo da aver maggior libertà nelle ottimizzazioni a livello di implementazione (es: unita di esecuzione separate con più alta latenza ma con maggior throughput complessivo nella manipolazione di vettori).
Avere registri distinti è comodo se hai una vecchia ISA come x87 che è troppo diversa dall'unità SIMD (SSE, nel caso di x86), per cui o usi l'una oppure l'altra anche se devi usare codice scalare. Infatti le SSE supportano sia codice scalare sia vettoriale, per cui ha senso usare x87 soltanto per la precisione estesa (80-bit).

In ogni caso le applicazioni eseguono in genere soltanto codice scalare (per l'FPU, intendo) o vettoriale. Per cui riutilizzare lo stesso register set per entrambi è una gran comodità.

Specialmente nel caso dell'introduzione dei float a 128-bit, visto che si tratta di codice scalare e Alpha ha già un'FPU molto veloce e potente, sarebbe stato meglio estenderne i registri a 128-bit e aggiungere il supporto questo nuovo tipo di dato. D'altra parte l'FPU supporta pure il formato floating point VAX (per questioni legacy, ovviamente), e dunque gestire un altro tipo non sarebbe certo un problema.

A questo punto avendo esteso l'FPU con registri a 128-bit, si sarebbero potuti aggiungere gli opcode opportuni (e distinti) per i calcoli vettoriali SIMD.
Ma negli x86 il decoder e gli altri colli di bottiglia sono differenti,
Scusami, ma il decoder che c'entra qui? AVX, peraltro, è un formato molto più compatto e di gran lunga più semplice da decodificare rispetto alle istruzioni "intere" ed SSE.

Voglio dire: non è certo un problema per il decoder gestire le nuove istruzioni SIMD che operano su 256-bit. Non è certamente questo che limiterebbe la frequenza massima raggiungibile dal processore.

La tua tesi era che l'aumento della dimensione dei registri SIMD portasse a problemi nello scalare in frequenza. L'introduzione delle AVX con registri a 256-bit (tock) non ha mostrato nulla di ciò, pur usando lo stesso processo produttivo della precedente famiglia di processori (tick). Vedremo poi fra Broadwell (AVX2, 256-bit) e Skylake (AVX-512, 512-bit) cosa succederà, nelle medesime condizioni.
senza contare che da anni una volta venuta meno la "minaccia" di AMD non spinge più di tanto il clock delle sue cpu.
Magari fosse quello! Purtroppo, come ben sai, scalare in frequenza col silicio è diventato estremamente difficile da una dozzina d'anni a questa parte. Ci sono voluti circa 10 anni per tornare nuovamente a raggiungere i 4Ghz, dopo il capitolo Pentium 4, e si procede ormai a incrementi di qualche centinaio di Mhz ogni tanto.
Con l' aumentare della scala d'integrazione e l'enfasi sulla riduzione dei consumi, l'approccio multithreading si è trasformato in un approccio multicore (vedi le soluzioni multi-core ARM).
E' quello che fanno tutti, Intel inclusa. Il multithreading, quando implementato da Intel, non è mai stato votato alle prestazioni estreme, infatti, ma per tenere impegnate le unità di calcolo esistenti cercando di ottimizzarne l'uso.
Ma come tu stesso hai notato, dove sono le prestazioni il requisito primario e dove il set d'istruzioni lo permette (i POWER di IBM) si segue un approccio multi-thread e multi-core.
Non è questione di ISA: POWER8 non ha nulla di particolare per l'aggressiva implementazione multi-threaded. E' che IBM con questa ISA ha deciso di spingere su questo fronte, ma il prezzo da pagare sono i consumi elevatissimi. Adesso non ricordo di preciso perché è passato tempo, ma mi sembra che un POWER8 a 3Ghz con 4 core consumasse qualcosa come 500W o più. Se vuole continuare su questa strada, faccia pure, ma a mio avviso è un segnale che stanno ormai alla canna del gas...
L'approccio SIMD "modalità smodata" è un "successo" (per gli x86) perchè Intel è ritornata a dettar legge riguardo i set d'istruzioni x86 (dopo che AMD per una volta riuscì ad imporre come standard di fatto x86-64, ma ci riuscì solo per il supporto di Microsoft che si rifiutò di supportare un altro standard a 64bit per x86 come Intel era disposta a fare).
Beh, ne è passato di tempo fra l'introduzione di x86-64 e quella di AVX.

Comunque cosa doveva fare Intel? Continuare a mettere pezze all'ISA per le SSE? Se dai un'occhiata alla struttura degli opcode di AVX, ti renderai conto da solo che rappresenta il classico uovo di Colombo per quest'architettura: opcode molto semplici da decodificare (nessun prefisso!), che consentono codice molto denso, supporto alle operazioni ternarie, estensione dei registri a 256-bit, e una schema pensato per future estensioni senza mettere pezze.
Tutti gli altri hanno introdotto nel tempo istruzioni SIMD ma "guardacaso" si sono limitati a registri a 128bit (Altivec, NEON, e MIPS SIMD) e se servivano maggiori prestazioni hanno aumentato il numero di core.
Stai parlando di scelte fatte quando le AVX non c'erano ancora. Intel ha introdotto le AVX da qualche anno. Può darsi che in futuro anche i produttori di processori RISC faranno qualche scelta del genere, ma ci vorrà tempo per innovazioni di questo tipo, come c'è voluto tempo per passare dalle SSE ad AVX.

Nel frattempo Intel continuerà per la sua strada, allargando i registri SIMD, raddoppiando le prestazioni in maniera più economica rispetto all'aggiunta di core (una sola istruzione da decodificare, ma molte più operazioni eseguite: SIMD docet), e offrendo anche un supporto migliore alla doppia precisione.

Sì, perché dimentichi anche è ormai possibile eseguire 4 operazioni a doppia precisione per ciclo di clock con le AVX, grazie al fatto che in 256-bit è possibile impacchettare 4 dati di questo tipo. Se in futuro verrà aggiunto il supporto a precisione quadrupla a 128-bit, con le AVX-512 sarà possibile fare lo stesso.

Gli altri RISC potranno pure continuare a usare registri a 128-bit, e offrire prestazioni castrate per questi tipi di dati, che perà sono sempre più utilizzati.

LMCH

12-08-2014, 16:14

O non c'erano risorse, visti i tempi di sviluppo molto lunghi di EV8? ;)

Erano cose che era state pianificate da molto prima che sorgessero problemi di risorse dedicate al progetto e che tutto venisse bloccato dalla cessione a CompaQ seguita dalla vendita di CompaQ ad HP con Intel che acquisiva tutte le IP relative all'Alpha.

Avere registri distinti è comodo se hai una vecchia ISA come x87 che è troppo diversa dall'unità SIMD (SSE, nel caso di x86), per cui o usi l'una oppure l'altra anche se devi usare codice scalare. Infatti le SSE supportano sia codice scalare sia vettoriale, per cui ha senso usare x87 soltanto per la precisione estesa (80-bit).

Suvvia, non essere così x86-centrico. ;)
Vi sono molteplici ragioni per cui si può decidere di introdurre registri distinti.
Una di queste è rendere accessibili ai pogrammatori ed ai compilatori un maggior numero di registri in modo da poter aumentare il numero di istruzioni eseguite out-of-order ed al tempo stesso aver maggior mano libera nelle ottimizzazioni a livello di implementazione.

In ogni caso le applicazioni eseguono in genere soltanto codice scalare (per l'FPU, intendo) o vettoriale. Per cui riutilizzare lo stesso register set per entrambi è una gran comodità.

Non sempre, se hai variabili di controllo del loop ed altro su un set di registri ed i dati vettoriali su un altro set vi sono maggiori possibilità di ottimizzazione.

Specialmente nel caso dell'introduzione dei float a 128-bit, visto che si tratta di codice scalare e Alpha ha già un'FPU molto veloce e potente, sarebbe stato meglio estenderne i registri a 128-bit e aggiungere il supporto questo nuovo tipo di dato. D'altra parte l'FPU supporta pure il formato floating point VAX (per questioni legacy, ovviamente), e dunque gestire un altro tipo non sarebbe certo un problema.

I float a 128bit erano solo una delle ragioni dell'introduzione di ulteriori istruzioni SIMD e di registri dedicati.

A questo punto avendo esteso l'FPU con registri a 128-bit, si sarebbero potuti aggiungere gli opcode opportuni (e distinti) per i calcoli vettoriali SIMD.

Ma se le istruzioni SIMD stavano per essere aggiunte in ogni caso, era più semplice inserire il supporto per i float a 128bit direttamente in esse visto che introducevano anche registri di dimensioni adeguate.

Scusami, ma il decoder che c'entra qui? AVX, peraltro, è un formato molto più compatto e di gran lunga più semplice da decodificare rispetto alle istruzioni "intere" ed SSE.

Ehm! La documentazione tecnica di Intel racconta tutta un altra storia.
Si risparmiano sino a tre prefissi (nel caso peggiore), ma contemporanemante si usa un prefisso più lungo e di lunghezza variabile.
Il prefisso VEX (che denota le AVX) ha lunghezza variabile (2 oppure 3 byte) , viene seguito dall'opcode del tipo di istruzione (1 byte) e dopo di esso c'e' il caro vecchio descrittore "mod r/m" (1 altro byte) seguito dal descrittore SIB (1 byte, opzionale), dall'offset/displacement (1..4 byte, opzionale) e/o da un valore immediato (1 byte, opzionale).
Insomma, si parla di istruzioni a lunghezza variabile da (minimo) 4 byte ad un massimo di 11 byte.

Voglio dire: non è certo un problema per il decoder gestire le nuove istruzioni SIMD che operano su 256-bit. Non è certamente questo che limiterebbe la frequenza massima raggiungibile dal processore.

Il problema che creano registri troppo ampi non è a livello di decoder ma di unida di esecuzione e di bus interni.
Il clock skew non è un opinione.

La tua tesi era che l'aumento della dimensione dei registri SIMD portasse a problemi nello scalare in frequenza. L'introduzione delle AVX con registri a 256-bit (tock) non ha mostrato nulla di ciò, pur usando lo stesso processo produttivo della precedente famiglia di processori (tick). Vedremo poi fra Broadwell (AVX2, 256-bit) e Skylake (AVX-512, 512-bit) cosa succederà, nelle medesime condizioni.

Limita la frequenza massima raggiungibile e porta a dover ricorrere a soluzioni più sofisticate per tener sotto controllo il clock skew, ma se per altre ragioni non ci si spinge alla frequenza massima o si accettano le complicazioni a livello di implementazione è ovvio che il problema non appare evidente.

Magari fosse quello! Purtroppo, come ben sai, scalare in frequenza col silicio è diventato estremamente difficile da una dozzina d'anni a questa parte. Ci sono voluti circa 10 anni per tornare nuovamente a raggiungere i 4Ghz, dopo il capitolo Pentium 4, e si procede ormai a incrementi di qualche centinaio di Mhz ogni tanto.

Questo per quel che riguarda gli x86, guardacaso.
Questo perchè dopo la debacle tecnologica rappresentata dal Pentium 4
in Intel non hanno avuto altra scelta che puntare sull'aumentare il parallelismo interno a colpi di core e di registri sempre più ampi.

E' quello che fanno tutti, Intel inclusa. Il multithreading, quando implementato da Intel, non è mai stato votato alle prestazioni estreme, infatti, ma per tenere impegnate le unità di calcolo esistenti cercando di ottimizzarne l'uso.

Ovvero per avere maggiori prestazioni nonostante il set di istruzioni x86
non fosse l'ideale per il multithreading.
C'era un buon motivo se con Alpha EV4 l'idea era di arrivare a 4 thread per core. ;)

Non è questione di ISA: POWER8 non ha nulla di particolare per l'aggressiva implementazione multi-threaded. E' che IBM con questa ISA ha deciso di spingere su questo fronte, ma il prezzo da pagare sono i consumi elevatissimi. Adesso non ricordo di preciso perché è passato tempo, ma mi sembra che un POWER8 a 3Ghz con 4 core consumasse qualcosa come 500W o più. Se vuole continuare su questa strada, faccia pure, ma a mio avviso è un segnale che stanno ormai alla canna del gas...

I chip POWER8 sono 6-core oppure 12-core (attualmente DCM ovvero dual module su un unico package, in futuro su singolo chip), ogni singolo core esegue simultanemente 8 thread, per un totale di 96 thread e tutto questo con un consumo sui 250Watt quando un 12-core è clockato a 4.5Ghz.
http://www.extremetech.com/computing/181102-ibm-power8-openpower-x86-server-monopoly
Non è che magari ti confondi con un sistema a 4 socket precedente ?

Comunque per server di fascia alta i consumi elevati non sono un problema se ad essi sono associate prestazioni adeguate.

cdimauro

13-08-2014, 08:15

Erano cose che era state pianificate da molto prima che sorgessero problemi di risorse dedicate al progetto e che tutto venisse bloccato dalla cessione a CompaQ seguita dalla vendita di CompaQ ad HP con Intel che acquisiva tutte le IP relative all'Alpha.
Sì, ma voglio dire che Digital era troppo lenta con lo sviluppo, visti i tempi di rilascio dei suoi prodotti. Probabilmente non aveva abbastanza risorse.
Suvvia, non essere così x86-centrico. ;)
Sono CISC-centrico da quando sono nato informaticamente parlando. :D
Vi sono molteplici ragioni per cui si può decidere di introdurre registri distinti.
Una di queste è rendere accessibili ai pogrammatori ed ai compilatori un maggior numero di registri in modo da poter aumentare il numero di istruzioni eseguite out-of-order ed al tempo stesso aver maggior mano libera nelle ottimizzazioni a livello di implementazione.
I RISC sono messi molto bene, perché hanno in genere molti registri. Diciamo che un'esigenza del genere è più sentita dove c'è più scarsità di registri.
Non sempre, se hai variabili di controllo del loop ed altro su un set di registri ed i dati vettoriali su un altro set vi sono maggiori possibilità di ottimizzazione.
Hum. Per i loop in genere il codice eseguito è quello "general-purpose" / intero, per cui utilizzi già un set di registri diversi.

Posso pensare a casi in cui il compilatore eseguendo l'unrolling del loop finisca per utilizzare tutti i registri SIMD, non lasciandone alcuno libero per variabili scalari / di appoggio per risultati temporanei (non vettoriali).

Non so quanto possa essere utile avere un set di registri dedicati soltanto per questi casi. Ci vorrebbero delle statistiche per decidere se ne valga concretamente la pena.
I float a 128bit erano solo una delle ragioni dell'introduzione di ulteriori istruzioni SIMD e di registri dedicati.

Ma se le istruzioni SIMD stavano per essere aggiunte in ogni caso, era più semplice inserire il supporto per i float a 128bit direttamente in esse visto che introducevano anche registri di dimensioni adeguate.
Ma i float a 128-bit occupano l'intero registro. Di SIMD, insomma, non hanno nulla, perché li usi come dati scalari, esattamente come faresti con l'FPU.
Ehm! La documentazione tecnica di Intel racconta tutta un altra storia.
Si risparmiano sino a tre prefissi (nel caso peggiore), ma contemporanemante si usa un prefisso più lungo e di lunghezza variabile.
Il prefisso VEX (che denota le AVX) ha lunghezza variabile (2 oppure 3 byte) , viene seguito dall'opcode del tipo di istruzione (1 byte) e dopo di esso c'e' il caro vecchio descrittore "mod r/m" (1 altro byte) seguito dal descrittore SIB (1 byte, opzionale), dall'offset/displacement (1..4 byte, opzionale) e/o da un valore immediato (1 byte, opzionale).
Insomma, si parla di istruzioni a lunghezza variabile da (minimo) 4 byte ad un massimo di 11 byte.
Certamente, ma prendiamo il caso reale. Se vuoi utilizzare le istruzioni SSE l'opcode parte da un minimo di 2 byte (prefisso 0F + byte per l'opcode vero e proprio), e 3 per le istruzioni più nuove (0F + 38 + opcode, ad esempio, se ricordo bene il codice dell'opcode di una delle due estensioni). Poi segue il byte di mod r/m, eventualmente accompagnato dal SIB, e dall'offset se presente. In alcuni casi hai anche un valore immediato a 8-bit, quindi un altro byte. Mediamente con l'SSE si fa uso di un prefisso che "qualifica" se l'istruzione è scalare / vettoriale, e se deve agire sulla singola o doppia precisione, e quindi aggiungiamo un altro byte. Se devi utilizzare i registri alti (per x64) o forzare un registro intero a 64-bit (sempre x64) ti serve il famigerato prefisso REX, e abbiamo un altro byte.

Già soltanto prendendo le istruzioni SSE e codificandole coi due prefissi AVX copri tutti questi casi mediamente ottieni un codice o simile (x86) o più denso (x64), col netto vantaggio di avere una decodifica di gran lunga più semplice. Aggiungiamo poi che hai il supporto ai dati a 256-bit (che non puoi avere con le SSE), ma soprattutto che con entrambi i prefissi puoi specificare un terzo registro usato come seconda sorgente, e questo consente di aumentare ulteriormente la densità del codice (nonché le prestazioni).
Il problema che creano registri troppo ampi non è a livello di decoder ma di unida di esecuzione e di bus interni.
Il clock skew non è un opinione.

Limita la frequenza massima raggiungibile e porta a dover ricorrere a soluzioni più sofisticate per tener sotto controllo il clock skew, ma se per altre ragioni non ci si spinge alla frequenza massima o si accettano le complicazioni a livello di implementazione è ovvio che il problema non appare evidente.
Hai detto bene: ci sono anche i bus interni, e questi in genere sono molto ampi, perché in questo modo è facile aumentare molto la bandwidth a disposizione. Oggi è facile avere bus che consentono di trasferire 32 o 64 byte per ciclo di clock -> 256 o 512-bit: "casualmente" la stessa dimensione dei registri SIMD AVX e AVX-512 rispettivamente.

Per cui l'ampiezza elevata dei registri SIMD ha un'importanza relativa al contesto, ed è il motivo per cui gli effetti del clock skew sono contenuti.
Questo per quel che riguarda gli x86, guardacaso.
No, riguarda tutti i chip su silicio: la fisica vale per tutti allo stesso. Infatti non è che ci siano stati RISC con frequenze elevatissime.
Questo perchè dopo la debacle tecnologica rappresentata dal Pentium 4
in Intel non hanno avuto altra scelta che puntare sull'aumentare il parallelismo interno a colpi di core e di registri sempre più ampi.
Veramente questa è roba recente, e casualmente sul multi-core ci si sono buttati tutti, all'incirca nello stesso periodo, perché il trend dell'IT è quello. Come dicevo sopra, la fisica del silicio si comporta allo stesso modo per tutti, e tutti si riversano nell'uso di soluzioni simili. ;)
Ovvero per avere maggiori prestazioni nonostante il set di istruzioni x86
Chiaro che si fa per le prestazioni: sfruttare le unità d'esecuzione inutilizzate porta dei vantaggi.
non fosse l'ideale per il multithreading.
Perché non sarebbe l'ideale? Per i problemi di decodifica? Questo si risolve a monte, nei primi stadi della pipeline.
C'era un buon motivo se con Alpha EV4 l'idea era di arrivare a 4 thread per core. ;)
L'EV8, immagino. Beh, con 4 thread per core ci sono arrivati anche Larrabee/Xeon Phi, ma per altri motivi (vedi sopra). ;)
I chip POWER8 sono 6-core oppure 12-core (attualmente DCM ovvero dual module su un unico package, in futuro su singolo chip), ogni singolo core esegue simultanemente 8 thread, per un totale di 96 thread e tutto questo con un consumo sui 250Watt quando un 12-core è clockato a 4.5Ghz.
http://www.extremetech.com/computing/181102-ibm-power8-openpower-x86-server-monopoly
Non è che magari ti confondi con un sistema a 4 socket precedente ?
Hai ragione. Forse erano i sistemi a 2 socket.
Comunque per server di fascia alta i consumi elevati non sono un problema se ad essi sono associate prestazioni adeguate.
Assolutamente. Comunque dall'articolo che hai linkato:

"In terms of performance per watt, though, the Xeon (~150W TDP) is probably just ahead of the Power8 — but in general, when you’re talking servers, power consumption generally plays second fiddle to performance density (how many gigaflops you can squeeze out of a single server)."

Non male per la vecchia, decrepita architettura x86... ;)

LMCH

14-08-2014, 01:02

Certamente, ma prendiamo il caso reale. Se vuoi utilizzare le istruzioni SSE l'opcode parte da un minimo di 2 byte (prefisso 0F + byte per l'opcode vero e proprio), e 3 per le istruzioni più nuove (0F + 38 + opcode, ad esempio, se ricordo bene il codice dell'opcode di una delle due estensioni). Poi segue il byte di mod r/m, eventualmente accompagnato dal SIB, e dall'offset se presente. In alcuni casi hai anche un valore immediato a 8-bit, quindi un altro byte. Mediamente con l'SSE si fa uso di un prefisso che "qualifica" se l'istruzione è scalare / vettoriale, e se deve agire sulla singola o doppia precisione, e quindi aggiungiamo un altro byte. Se devi utilizzare i registri alti (per x64) o forzare un registro intero a 64-bit (sempre x64) ti serve il famigerato prefisso REX, e abbiamo un altro byte.

Già soltanto prendendo le istruzioni SSE e codificandole coi due prefissi AVX copri tutti questi casi mediamente ottieni un codice o simile (x86) o più denso (x64), col netto vantaggio di avere una decodifica di gran lunga più semplice. Aggiungiamo poi che hai il supporto ai dati a 256-bit (che non puoi avere con le SSE), ma soprattutto che con entrambi i prefissi puoi specificare un terzo registro usato come seconda sorgente, e questo consente di aumentare ulteriormente la densità del codice (nonché le prestazioni).

Ah! Quindi ragionavi in termini di AVX vs. SSE, non in termini di AVX vs. RISC.

Hai detto bene: ci sono anche i bus interni, e questi in genere sono molto ampi, perché in questo modo è facile aumentare molto la bandwidth a disposizione. Oggi è facile avere bus che consentono di trasferire 32 o 64 byte per ciclo di clock -> 256 o 512-bit: "casualmente" la stessa dimensione dei registri SIMD AVX e AVX-512 rispettivamente.

Ma in tutti i casi in cui il bus diventa troppo ampio, ci si ritrova ad avere limitazioni sulla frequenza massima o a dover spendere risorse in vari accorgimenti per tener a bada il clock skew.

La cosa buffa è che Intel prima con gli Itanium fece una scelta esagerata riguardo il numero di registri direttamente accessibili (mi riferisco ai 128 interi e 128 float, i 64bit di predicati "pesavano" come un singolo registro intero)
ottenendo dei registri "veloci" i cui tempi di accesso erano quasi paragonabili a quelli che si avevano per la cache L1 su altre cpu. :eek:

Quando invece già dai primi anni '90 era chiaro che oltre 32 per set si andava solo a complicarsi la vita, loro scelsero una dimensione che era il quadruplo.

Ed ora ripetono lo stesso errore con i registri a AVX-512 con registri guardacaso ampi il quadruplo di quelli utilizzati su altre architetture.

E' vero che cose come il set d'istruzioni e valori "ottimali" non contano come una volta se si è uno o due step tecnologici in vantaggio sulla concorrenza e ci si può permettere di dedicare molte più risorse sull' R&D (tre "famiglie" di cpu x86 strutturalmente molto diverse tra loro sviluppate e prodotte in parallelo), ma non è vero che "non contano" e specialmente Intel dovrebbe ricordarsi delle debacle precedenti.

Per cui l'ampiezza elevata dei registri SIMD ha un'importanza relativa al contesto, ed è il motivo per cui gli effetti del clock skew sono contenuti.

Relativamente al contesto, perchè alla fine è il contesto che va considerato.

No, riguarda tutti i chip su silicio: la fisica vale per tutti allo stesso. Infatti non è che ci siano stati RISC con frequenze elevatissime.

Ma con quel Ghz in più che non guasta mai, si. ;)
Idem per versioni a basso numero di gate o a consumi ultra-ribassati.

Veramente questa è roba recente, e casualmente sul multi-core ci si sono buttati tutti, all'incirca nello stesso periodo, perché il trend dell'IT è quello. Come dicevo sopra, la fisica del silicio si comporta allo stesso modo per tutti, e tutti si riversano nell'uso di soluzioni simili. ;)

Uno dei motivi è anche perche se si hanno abbastanza gate e superficie disponibile le soluzioni multi-core sono meno dipendenti da uno specifico set d'istruzioni e sono possibili molte più opzioni per il risparmio energetico.

Il multithreading invece permette solo di avere prestazioni più elevate su un singolo core riducendo le "bolle" nelle varie pipeline grazie alla possibilità di poter eseguire 2 o più gruppi di istruzioni (quelli dei vari thread) senza interdipendenze tra i gruppi o con le interdipendenze gestite a livello del software.

Perché non sarebbe l'ideale? Per i problemi di decodifica? Questo si risolve a monte, nei primi stadi della pipeline.

Numero di registri per una singola categoria (interi, float, simd) ed interdipendenze tra le istruzioni.

L'EV8, immagino.

Già EV8, quando scrivo in fretta mi si incrociano le dita e se ricontrollo altrettanto velocemente ... :tapiro:

Beh, con 4 thread per core ci sono arrivati anche Larrabee/Xeon Phi, ma per altri motivi (vedi sopra). ;)

Ovvero perche si presuppone che saranno usati principalmente per eseguire istruzioni SIMD su registri a 512bit e con 32 registri ZMM visibili al programmatore/compilatore per thread.

Interessante come 32 spunti sempre fuori come dimensione ottimale di un set di registri. ;)

cdimauro

14-08-2014, 07:03

Ah! Quindi ragionavi in termini di AVX vs. SSE, non in termini di AVX vs. RISC.
Ehm... sì. :D Confrontavo il passato col presente di x86/x64.

Per quanto mi riguarda non credo ci siano paragoni fra AVX e RISC, perché i primi consentono di operare direttamente con un dato in memoria, risparmiando la classica load (che è "fusa" in tutte le istruzioni), e il tutto mantenendo una lunghezza dell'istruzione mediamente inferiore (prefisso da 2 o 3 byte + opcode + mod/rm + offset a 8-bit = 5 o 6 byte; un RISC con load + operazione richiede 8 byte, e il divario aumenta con offset più grandi). Quindi a fronte di codice più denso (che ha i suoi benefici in tutte le gerarchie di memoria) si hanno anche prestazioni migliori (due operazioni in una, con l'ulteriore beneficio che non c'è dipendenza da load + successivo utilizzo del dato).
Ma in tutti i casi in cui il bus diventa troppo ampio, ci si ritrova ad avere limitazioni sulla frequenza massima o a dover spendere risorse in vari accorgimenti per tener a bada il clock skew.
OK, ma se tutti adottano bus ampi, avranno tutti gli stessi problemi, giusto?
La cosa buffa è che Intel prima con gli Itanium fece una scelta esagerata riguardo il numero di registri direttamente accessibili (mi riferisco ai 128 interi e 128 float, i 64bit di predicati "pesavano" come un singolo registro intero)
ottenendo dei registri "veloci" i cui tempi di accesso erano quasi paragonabili a quelli che si avevano per la cache L1 su altre cpu. :eek:

Quando invece già dai primi anni '90 era chiaro che oltre 32 per set si andava solo a complicarsi la vita, loro scelsero una dimensione che era il quadruplo.
Non ho mai studiato l'architettura dell'Itanium, per cui non posso risponderti in maniera precisa. Mi pare di ricordare che soltanto 32 registri alla volta era visibili in un preciso momento, perché faceva uso di un meccanismo a finestre (tipo SPARC, se non erro). Questo per facilitare l'implementazione delle chiamate a funzioni con relativo passaggio di parametri, fino a una certa profondità (dopo immagino che una parte del register set andava per forza di cose salvato sullo stesso, e poi ripristinato al ritorno). L'idea mi sembra buona, perché con 128 registri avresti la possibilità di effettuare 4 chiamate a funzioni senza toccare lo stack. Poi, ripeto, bisogna vedere come funziona effettivamente e l'impatto che ha sul codice reale.
Ed ora ripetono lo stesso errore con i registri a AVX-512 con registri guardacaso ampi il quadruplo di quelli utilizzati su altre architetture.
Però sono due cose diverse. Itanium aveva 128 + 128 registri a 64 bit. Quindi accedevi a 64-bit di dati alla volta, esattamente come tutti gli altri processori a 64-bit. L'unico problema era la numerosità, per cui bisogna vedere l'impatto che aveva sull'accesso. Ma penso che fosse in buona compagnia: l'EV8 a quanto pare aveva ben 512 registri internamente. :D

AVX-512, invece, ha soltanto 32 registri, ma a 512-bit. Quindi accedi a 512-bit alla volta, e il problema che si porta dietro è il clock skew.
E' vero che cose come il set d'istruzioni e valori "ottimali" non contano come una volta se si è uno o due step tecnologici in vantaggio sulla concorrenza e ci si può permettere di dedicare molte più risorse sull' R&D (tre "famiglie" di cpu x86 strutturalmente molto diverse tra loro sviluppate e prodotte in parallelo), ma non è vero che "non contano" e specialmente Intel dovrebbe ricordarsi delle debacle precedenti.
Credo che ne abbiano fatto tesoro, e avranno avuto delle buone ragioni per certe scelte. AVX non nasce certo ieri, ma dopo anni di R&D. Per Larrabee, precursore di AVX-512, addirittura sono stati scomodati Michael Abrash e Tim Sweeney...
Relativamente al contesto, perchè alla fine è il contesto che va considerato.
Appunto. Il POWER8, che abbiamo citato prima, utilizza un bus da 64-byte per ciclo di clock, quindi trasferisce 512-bit alla volta. Sarebbe interessante conoscere i dati degli altri processori, ma credo che ormai almeno 32-byte per ciclo li trasferiscano. D'altra parte non c'è altro modo per ottenere bandwidth elevate, visto che la frequenza cresce ormai di poco.
Ma con quel Ghz in più che non guasta mai, si. ;)
Vorrei vederlo. :)
Idem per versioni a basso numero di gate o a consumi ultra-ribassati.
Senz'altro, questo è un vantaggio, ma ormai non più significativo, come abbiamo avuto modo di discutere un po' di giorni fa.
Numero di registri per una singola categoria (interi, float, simd)
Non dovrebbe essere un vantaggio questo? Devi duplicare meno risorse. Comunque con x64 ci sono 16 registri general-purpose e altrettanti per l'unità SIMD, come molti RISC.
ed interdipendenze tra le istruzioni.
Qui la questione è aperta, a mio avviso. I RISC, grazie alla possibilità di utilizzare 3 operandi, riducono le dipendenze che ci sono normalmente con le architetture che usano un operando sia come sorgente sia come destinazione.

Per contro CISC come x86 possono contare sul fatto che possono eseguire load + operazione direttamente, e questo elimina una dipendenza (che invece è presente nei RISC); inoltre possono anche operare direttamente sulla memoria senza nemmeno passare dai registri, e ciò elimina ancora altre dipendenze. Aggiungo che grazie ad AVX adesso è possibile utilizzare 3 operandi (anche per alcune istruzioni intere), per cui almeno per SIMD ed FPU (visto che ormai si usa l'unità SIMD anche per operazioni scalari) siamo esattamente nella stessa situazione dei RISC.

Complessivamente non mi pare che la situazione sia malvagia.
Ovvero perche si presuppone che saranno usati principalmente per eseguire istruzioni SIMD su registri a 512bit e con 32 registri ZMM visibili al programmatore/compilatore per thread.
Esattamente.
Interessante come 32 spunti sempre fuori come dimensione ottimale di un set di registri. ;)
Per il codice SIMD sicuramente, perché si presta molto alla parallelizzazione e l'unrolling dei loop.

Per il codice general purpose si sente molto meno quest'esigenza. 16 registri coprono la stragrande maggioranza dei casi.
Certamente con 32 registri si riesce a fare molto di più e coprire molti più casi, ma il prezzo da pagare è lo spazio nella opcode table che impatta sulle scelte e infine sulla densità di codice.
Comunque ci sono anche soluzioni che consentono di utilizzare 32 registri o anche più (per l'unità SIMD) a costi molto contenuti a livello di codifica e, quindi, di densità di codice. :fagiano:

P.S. Non so a te, ma questa discussione mi sta piacendo molto. :D

Ares17

14-08-2014, 09:51

P.S. Non so a te, ma questa discussione mi sta piacendo molto. :D
Da parte mia è la prima notizia che leggo la mattina (certo non avete il tempo per scrivere articoli, ma da discussioni come queste ne escono fuori dei compendi, sopratutto perchè arrivate da due visioni diametralmente opposte ma senza mai scontrarvi su posizioni rigide).
E' un piacere leggervi

cdimauro

14-08-2014, 17:34

Grazie. :)
Come avrai intuito, sono argomenti di cui potrei parlare per ore, perché li adoro.
Poi devo dire che incontrando interlocutori con cui è possibile intavolare una discussione civile e onesta (sebbene ovviamente ognuno abbia le propria visione delle cose, per l'appunto), è anche più piacevole.

LMCH

15-08-2014, 01:35

OK, ma se tutti adottano bus ampi, avranno tutti gli stessi problemi, giusto?

Problemi simili su alcune cose, diversi su altre e con l'aumento dell'ampiezza del bus come parte delle soluzioni adottate.

Non ho mai studiato l'architettura dell'Itanium, per cui non posso risponderti in maniera precisa. Mi pare di ricordare che soltanto 32 registri alla volta era visibili in un preciso momento, perché faceva uso di un meccanismo a finestre (tipo SPARC, se non erro). Questo per facilitare l'implementazione delle chiamate a funzioni con relativo passaggio di parametri, fino a una certa profondità (dopo immagino che una parte del register set andava per forza di cose salvato sullo stesso, e poi ripristinato al ritorno). L'idea mi sembra buona, perché con 128 registri avresti la possibilità di effettuare 4 chiamate a funzioni senza toccare lo stack. Poi, ripeto, bisogna vedere come funziona effettivamente e l'impatto che ha sul codice reale.

Le istruzioni supportavano sia l'indirizzamento "diretto" di tutti i 128 registri interi o float (selettore di registro a 7 bit nelle istruzioni) e sia l'indirizzamento "indiretto" in modalita RSE (Register Stack Engine) in cui i primi 32 registri erano indirizzati "staticamente"/"direttamente" mentre gli altri 96 vengono gestiti come se fossero le prime 96 word a 64bit sulla cima dello stack.

In Intel erano partiti con l'idea di realizzare un architettura VLIW con "compressione" delle istruzioni e sono finiti con il realizzare un "coso" con così tante feature che si intralciavano reciprocamente da complicare a livelli demenziali l'implementazione.

Immagina un VLIW, un CISC, un RISC, un AS/400, una calcolatrice RPN della TI, una pascalina ed un abaco che entrano in una stanza buia dopo essersi bombati di cocaina, viagra e coca-cola con aspirina dentro.

Itanium è praticamente figlio di tale ammucchiata, ma nessuna delle architetture rivendica la paternita e sopratutto non si capisce quale/come/cosa potesse essere la madre. :sofico:

Però sono due cose diverse. Itanium aveva 128 + 128 registri a 64 bit. Quindi accedevi a 64-bit di dati alla volta, esattamente come tutti gli altri processori a 64-bit. L'unico problema era la numerosità, per cui bisogna vedere l'impatto che aveva sull'accesso. Ma penso che fosse in buona compagnia: l'EV8 a quanto pare aveva ben 512 registri internamente. :D

Si ma i registri "solo interni" li puoi togliere, aggiungere, partizionare ed in generale implementare ed interfacciare alle altre componenti interne come vuoi mentre per quelli "visibili al programmatore/compilatore" non permettono simili rimaneggiamenti.

AVX-512, invece, ha soltanto 32 registri, ma a 512-bit. Quindi accedi a 512-bit alla volta, e il problema che si porta dietro è il clock skew.

Credo che ne abbiano fatto tesoro, e avranno avuto delle buone ragioni per certe scelte. AVX non nasce certo ieri, ma dopo anni di R&D. Per Larrabee, precursore di AVX-512, addirittura sono stati scomodati Michael Abrash e Tim Sweeney...

Appunto. Il POWER8, che abbiamo citato prima, utilizza un bus da 64-byte per ciclo di clock, quindi trasferisce 512-bit alla volta. Sarebbe interessante conoscere i dati degli altri processori, ma credo che ormai almeno 32-byte per ciclo li trasferiscano. D'altra parte non c'è altro modo per ottenere bandwidth elevate, visto che la frequenza cresce ormai di poco.

Vorrei vederlo. :)

POWER6, venduto clockato "di serie" a 5Ghz.
Poi si sono resi conto che erano entrati in zona plaid (semitcit. "Spaceballs") ed hanno rallentato aggiungendo più core su moduli MCM
ma con POWER8 se non sbaglio c'e' nuovamente l'opzione per versioni a 5Ghz.

Se ricordo correttamente le versioni a clock "smodato" tornavano particolarmente utili nei casi in cui si doveva far girare vecchio codice binario
per altre architetture (tipo AS/400, ma anche roba vecchia per mainframe) in emulazione.

Senz'altro, questo è un vantaggio, ma ormai non più significativo, come abbiamo avuto modo di discutere un po' di giorni fa.

Dipende.
Dipende ad esempio da quanti core si vogliono implementare per chip e con quali obiettivi
Ad esempio per gli ARM ha senso un architettura tipo big.LITTLE mentre con gli x86 proprio non se ne parla.
E non è un caso se per roba embedded c'e' una marcata preferenza per soluzioni basate su cpu RISC o simil-RISC (maggiori opzioni disponibili in termini di potenza di calcolo e consumi).

Non dovrebbe essere un vantaggio questo? Devi duplicare meno risorse. Comunque con x64 ci sono 16 registri general-purpose e altrettanti per l'unità SIMD, come molti RISC.

Più registri sono visibili a livello di assembly (al programamtore o al compilatore) e maggiori sono le possibilità di ottimizzazione che si hanno mappando su registro gli operandi ecc.
Ma dall'altro lato più sono i registri visibili e più si allunga la lunghezza delle istruzioni e più si impongono vincoli all'implementazione dell'architettura.

Da anni e con un fottio di test e simulazione in supporto della cosa il numero ottimale è tra 16 e 32 per set di registri per cpu con word size ottimale a 32..64 bit (accessibili con istruzioni "semplici", senza prefissi ed altri barbatrucchi), con 32 la scelta ottimale per architetture a 64bit.
Per architetture a 16bit e word size ottimale 16bit invece il valore ottimale era 8..16 per set di registri.

x86 è nato come "evoluzione" a 16bit di un architettura (l'8080) ad 8 bit e si è portato la limitazione degli 8 registri molto a lungo, salendo a 16 con l'aggravio dei prefissi ma solo grazie ad AMD (che con x86-64 estese sia i registri GPR che quelli SSE a set di 16 registri) ed infine con l'ultima estensione a set di 32 registri solo per i registri SIMD di AVX.

Qui la questione è aperta, a mio avviso. I RISC, grazie alla possibilità di utilizzare 3 operandi, riducono le dipendenze che ci sono normalmente con le architetture che usano un operando sia come sorgente sia come destinazione.

Per contro CISC come x86 possono contare sul fatto che possono eseguire load + operazione direttamente, e questo elimina una dipendenza (che invece è presente nei RISC); inoltre possono anche operare direttamente sulla memoria senza nemmeno passare dai registri, e ciò elimina ancora altre dipendenze. Aggiungo che grazie ad AVX adesso è possibile utilizzare 3 operandi (anche per alcune istruzioni intere), per cui almeno per SIMD ed FPU (visto che ormai si usa l'unità SIMD anche per operazioni scalari) siamo esattamente nella stessa situazione dei RISC.

Complessivamente non mi pare che la situazione sia malvagia.

Malvagia no, ma più complicata del necessario si.
Nel senso che Intel incapace di sganciarsi dagli x86 (ci ha provato in grande stile almeno tre volte) ora sembra intenzionata a farli evolvere in una specie di appendice del set d'istruzioni AVX. :mbe:

P.S. Non so a te, ma questa discussione mi sta piacendo molto. :D

Anche a me. :)

Ma credo che tra qualche tempo ci sposteremo su altri thread, nel senso che i core ARMv8 "per dispositivi mobili" di prossima uscita sembrano parecchio aggressivi sul lato prestazioni e quindi sorgeranno discussioni a riguardo e contronti con i-core-precedentemente-noti-come-Atom ecc. ecc.

Senza contare gli atti di necromanzia di Nvidia ...
che a quanto sembra con il Tegra K1 a 64bit
(pin compatibile con il Tegra K1 a 32 bit basato su core A15, ma
con core Denver ed architettura interna molto diversa)
sta usando con risultati interessanti un approccio simile a quello delle cpu Transmeta:
http://www.extremetech.com/computing/187862-nvidia-details-64-bit-denver-tegra-k1-claims-haswell-class-performance-for-first-64-bit-android-chip
(ovviamente credo che quei numeri siano gonfiati rispetto a quello che si otterrà nella realtà con un tablet con quel SoC, se non altro per evitare di mangiarsi viva la batteria :stordita: )

cdimauro

15-08-2014, 08:59

Le istruzioni supportavano sia l'indirizzamento "diretto" di tutti i 128 registri interi o float (selettore di registro a 7 bit nelle istruzioni) e sia l'indirizzamento "indiretto" in modalita RSE (Register Stack Engine) in cui i primi 32 registri erano indirizzati "staticamente"/"direttamente" mentre gli altri 96 vengono gestiti come se fossero le prime 96 word a 64bit sulla cima dello stack.

In Intel erano partiti con l'idea di realizzare un architettura VLIW con "compressione" delle istruzioni e sono finiti con il realizzare un "coso" con così tante feature che si intralciavano reciprocamente da complicare a livelli demenziali l'implementazione.

Immagina un VLIW, un CISC, un RISC, un AS/400, una calcolatrice RPN della TI, una pascalina ed un abaco che entrano in una stanza buia dopo essersi bombati di cocaina, viagra e coca-cola con aspirina dentro.

Itanium è praticamente figlio di tale ammucchiata, ma nessuna delle architetture rivendica la paternita e sopratutto non si capisce quale/come/cosa potesse essere la madre. :sofico:
Itanium dovrebbe essere anche figlio di HP. ;) Comunque prima o poi dovrò decidermi ad approfondirne la conoscenza dell'ISA, primo perché sono dannatamente curioso per natura riguardo a questi argomenti, e secondo perché vorrei capire meglio quali scelte siano state corrette e quali sbagliate (a parte il fatto che sia un processore VLIW e in-order). Ma al momento ho ben altro da fare. :p
POWER6, venduto clockato "di serie" a 5Ghz.
Poi si sono resi conto che erano entrati in zona plaid (semitcit. "Spaceballs") ed hanno rallentato aggiungendo più core su moduli MCM
ma con POWER8 se non sbaglio c'e' nuovamente l'opzione per versioni a 5Ghz.
Più che altro perché a quelle frequenze il consumo diventa troppo elevato. IBM con la sua serie POWER non ha una storia di consumi contenuti; tutt'altro. Ma, come dicevamo anche prima, opera in un segmento in cui questo parametro non ha un peso così importante come in altri ambiti.

Tolto questo, è difficile vedere altri RISC arrivare a frequenze così elevate mantenendo consumi comparabili con quelli che ritroviamo in ambito desktop o mobile.
Se ricordo correttamente le versioni a clock "smodato" tornavano particolarmente utili nei casi in cui si doveva far girare vecchio codice binario
per altre architetture (tipo AS/400, ma anche roba vecchia per mainframe) in emulazione.
Non penso, perché POWER6 era un processore in-order, proprio in ambito emulazione non poteva eccellere.
Dipende.
Dipende ad esempio da quanti core si vogliono implementare per chip e con quali obiettivi
Ad esempio per gli ARM ha senso un architettura tipo big.LITTLE mentre con gli x86 proprio non se ne parla.
Ci sono diverse implementazioni ARM che non usano il modello big.LITTLE, perché preferiscono ricorrere ad altre soluzioni. Vedi Apple con l'A7, o l'appena arrivato Tegra K1 a 64-bit. Questo perché potresti aver sviluppato le tecnologie necessarie per ridurre ugualmente i consumi.
E non è un caso se per roba embedded c'e' una marcata preferenza per soluzioni basate su cpu RISC o simil-RISC (maggiori opzioni disponibili in termini di potenza di calcolo e consumi).
Senz'altro. Più piccoli sono i chip, e più si fa sentire il peso di qualche milione di transistor attivi. In certi settori non si può competere, se non con architetture adeguate.

Fortunatamente anche il settore embedded sta diventando sempre più esigente, per cui i chip diventano sempre più grossi per tutti, per cui si aprono degli spazi anche per x86.
Più registri sono visibili a livello di assembly (al programamtore o al compilatore) e maggiori sono le possibilità di ottimizzazione che si hanno mappando su registro gli operandi ecc.
Ma dall'altro lato più sono i registri visibili e più si allunga la lunghezza delle istruzioni e più si impongono vincoli all'implementazione dell'architettura.

Da anni e con un fottio di test e simulazione in supporto della cosa il numero ottimale è tra 16 e 32 per set di registri per cpu con word size ottimale a 32..64 bit (accessibili con istruzioni "semplici", senza prefissi ed altri barbatrucchi), con 32 la scelta ottimale per architetture a 64bit.
Per architetture a 16bit e word size ottimale 16bit invece il valore ottimale era 8..16 per set di registri.
Infatti. Un solo piccolo appunto: quel che conta è poter accedere ai registri. Se poi lo si fa con prefissi (x86) o altro (vedi THUMB, ad esempio), l'importanza è relativa, purché si mantenga una buona densità ed esecuzione del codice.
x86 è nato come "evoluzione" a 16bit di un architettura (l'8080) ad 8 bit e si è portato la limitazione degli 8 registri molto a lungo, salendo a 16 con l'aggravio dei prefissi ma solo grazie ad AMD (che con x86-64 estese sia i registri GPR che quelli SSE a set di 16 registri) ed infine con l'ultima estensione a set di 32 registri solo per i registri SIMD di AVX.
Perché è l'unità SIMD l'elemento su cui ruotano, da anni, le modifiche all'ISA e gli incrementi prestazionali. Per questo aveva senso mettere ordine e una solida base per il futuro, con AVX prima e soprattutto con AVX-512 in futuro. Non credo proprio che ci saranno esperimenti riguardo alle classiche istruzioni general purpose.

A parte questo, l'ISA CISC ha i suoi pregi, di cui ho già parlato prima, e che le consentono di richiedere un minor numero di registri per effettuare le stesse operazioni. Se disassembli un eseguibile x86 o x64, troverai tante istruzioni tipo MOV Memoria,ValoreImmediato, ADD Memoria,ValoreImmediato, e così via, che oltre a essere molto veloci, non sporcano alcun registro.
Malvagia no, ma più complicata del necessario si.
Nel senso che Intel incapace di sganciarsi dagli x86 (ci ha provato in grande stile almeno tre volte)
Io ricordo soltanto Itanium. :p
ora sembra intenzionata a farli evolvere in una specie di appendice del set d'istruzioni AVX. :mbe:
Vedi sopra: solo per l'unità SIMD, per la quale ha certamente senso tutto ciò (troppi casini coi prefissi).
Anche a me. :)

Ma credo che tra qualche tempo ci sposteremo su altri thread, nel senso che i core ARMv8 "per dispositivi mobili" di prossima uscita sembrano parecchio aggressivi sul lato prestazioni e quindi sorgeranno discussioni a riguardo e contronti con i-core-precedentemente-noti-come-Atom ecc. ecc.

Senza contare gli atti di necromanzia di Nvidia ...
che a quanto sembra con il Tegra K1 a 64bit
(pin compatibile con il Tegra K1 a 32 bit basato su core A15, ma
con core Denver ed architettura interna molto diversa)
sta usando con risultati interessanti un approccio simile a quello delle cpu Transmeta:
http://www.extremetech.com/computing/187862-nvidia-details-64-bit-denver-tegra-k1-claims-haswell-class-performance-for-first-64-bit-android-chip
(ovviamente credo che quei numeri siano gonfiati rispetto a quello che si otterrà nella realtà con un tablet con quel SoC, se non altro per evitare di mangiarsi viva la batteria :stordita: )
Esattamente. D'altra parte a una veloce occhiata si notano le seguenti cose:
- cache L1 codice quadruplicata (128KB) rispetto alla media (32KB) e cache dati raddoppiata (64KB), necessarie per sfamare questo mostro;
- architettura nativa incompatibile con ARM; le istruzioni ARMv8 (e immagino anche ARM32, Thumb, ecc.) vengono prima decodificate nell'ISA nativa, e soltanto dopo eseguite. Eventualmente possono essere memorizzate nella speciale cache in memoria;
- design VLIW in-order;
- design votato all'esecuzione single-thread (anche se questo fa a pugni con l'architettura in-order; anch'io voglio vedere i benchmark reali). Infatti nei pochi benchmark (sintetici, per lo più) presentati "casualmente" dominano quelli single-thread (con quelli multi-thread la musica sarebbe stata diversa, specialmente per BayTrail, che ha 4 core a disposizione);
- soltanto due massicci core a disposizione (rispetto ai 4 di K1 a 32-bit) che si sono fregati tutto lo spazio. E' pure sparito il mini-core da usare per risparmiare corrente quando c'è poco carico di lavoro;
- frequenze molto elevate (e anche per questo vorrei vedere i consumi reali). Decisamente più elevate rispetto ai processori x86 che sono stati inclusi nei benchmark.

A primo acchito direi che il reparto marketing abbia fatto un ottimo lavoro. :D Comunque aspetto qualche recensione da tecnici di terze parti per appurare come stiano realmente le cose. ;)

Di questo nuovo progetto penso ci sarà di che parlare in qualche futura notizia a riguardo.

LMCH

15-08-2014, 17:49

Non penso, perché POWER6 era un processore in-order, proprio in ambito emulazione non poteva eccellere.
Se si tratta il codice binario da emulare come se fosse codice sorgente
(quindi con compilazione offline seguita da uso di tecniche JIT solo nei casi in cui si rileva codice automodificante) anche un processore in-order va bene (perche il "ricompilatore" di fatto è in grado di riordinare le istruzioni e di eseguire un interleave di sequenze di istruzioni native che corrispondono alle istruzioni "originali") ed avere un clock elevato torna utile per alzare le prestazioni quando si esegue il codice ricompilato, ristrutturato & riordinato.

Ci sono diverse implementazioni ARM che non usano il modello big.LITTLE, perché preferiscono ricorrere ad altre soluzioni. Vedi Apple con l'A7, o l'appena arrivato Tegra K1 a 64-bit. Questo perché potresti aver sviluppato le tecnologie necessarie per ridurre ugualmente i consumi.

E tutte traggono vantaggio dall'avere un set d'istruzioni relativamente semplice a livello decodifica.

Esattamente. D'altra parte a una veloce occhiata si notano le seguenti cose:
- cache L1 codice quadruplicata (128KB) rispetto alla media (32KB) e cache dati raddoppiata (64KB), necessarie per sfamare questo mostro;
- architettura nativa incompatibile con ARM; le istruzioni ARMv8 (e immagino anche ARM32, Thumb, ecc.) vengono prima decodificate nell'ISA nativa, e soltanto dopo eseguite. Eventualmente possono essere memorizzate nella speciale cache in memoria;
- design VLIW in-order;
- design votato all'esecuzione single-thread (anche se questo fa a pugni con l'architettura in-order; anch'io voglio vedere i benchmark reali). Infatti nei pochi benchmark (sintetici, per lo più) presentati "casualmente" dominano quelli single-thread (con quelli multi-thread la musica sarebbe stata diversa, specialmente per BayTrail, che ha 4 core a disposizione);
- soltanto due massicci core a disposizione (rispetto ai 4 di K1 a 32-bit) che si sono fregati tutto lo spazio. E' pure sparito il mini-core da usare per risparmiare corrente quando c'è poco carico di lavoro;
- frequenze molto elevate (e anche per questo vorrei vedere i consumi reali). Decisamente più elevate rispetto ai processori x86 che sono stati inclusi nei benchmark.

A primo acchito direi che il reparto marketing abbia fatto un ottimo lavoro. :D Comunque aspetto qualche recensione da tecnici di terze parti per appurare come stiano realmente le cose. ;)

Di questo nuovo progetto penso ci sarà di che parlare in qualche futura notizia a riguardo.

Già. :)
E' ovvio che NVidia pensa che se riesce a mettere a punto il sistema completo (hardware VLIW + "ottimizzatore" hardware/software) poi lo sviluppo successivo sarà un sistema multicore VLIW che in base al carico ed alle esigente opera sia come cpu multicore che come GPU.
Insomma, è un altra interpretazione de "il set d'istruzioni non è più rilevante"
(a patto che sia sufficientemente semplice ed ben ottimizzabile tramite ricompilazione, suppongo).

cdimauro

16-08-2014, 07:56

Se si tratta il codice binario da emulare come se fosse codice sorgente
(quindi con compilazione offline seguita da uso di tecniche JIT solo nei casi in cui si rileva codice automodificante) anche un processore in-order va bene (perche il "ricompilatore" di fatto è in grado di riordinare le istruzioni e di eseguire un interleave di sequenze di istruzioni native che corrispondono alle istruzioni "originali") ed avere un clock elevato torna utile per alzare le prestazioni quando si esegue il codice ricompilato, ristrutturato & riordinato.
Purtroppo anche così non risolvi col codice di un emulatore che è troppo intricato e strapieno di dipendenze. Ho scritto un emulatore 80186 per Amiga (68020+; interamente in assembly) e uno 65C02 (assembly 8086 per l'esecuzione delle istruzion 65C02; Turbo Pascal per tutto il resto), per cui conosco molto bene le problematiche che ci sono dietro.

Con questo tipo di codice puoi ricompilare come vuoi, ma un'architettura in-order darà sempre risultati peggiori rispetto a una OoO.
E tutte traggono vantaggio dall'avere un set d'istruzioni relativamente semplice a livello decodifica.
Non credo. Roba come il power-gating, ad esempio, non ha nulla a che vedere con la semplicità di decodifica. Era a questo che mi riferivo quanto parlavo di tecnologie per la riduzione dei consumi.

Ogni produttore di CPU ha nel suo portfolio di brevetti chissà quanta roba sull'argomento. Sicuramente Transmeta ne aveva sviluppata parecchia, e adesso è parte di nVidia (che l'ha acquisita un po' di anni fa), ma se non erro le licenze relative alla riduzione dei consumi sono state cedute o licenziate anche a Intel.

La semplicità delle istruzioni aiuta sicuramente nella decodifica, e di questo ne abbiamo parlato: i RISC hanno un vantaggio, ma questo vantaggio non ha impedito che uscissero fuori architetture come big.LITTLE, che risolvono ben altri problemi. Però Apple A7 e Tegra K1 64-bit... non ne fanno uso. E Intel può contare sul Loop Stream Detection. ;)
Già. :)
E' ovvio che NVidia pensa che se riesce a mettere a punto il sistema completo (hardware VLIW + "ottimizzatore" hardware/software) poi lo sviluppo successivo sarà un sistema multicore VLIW che in base al carico ed alle esigente opera sia come cpu multicore che come GPU.
Francamente non lo vedo proprio. VLIW per le GPU è un modello architetturale che è stato sostanzialmente abbandonato. Ciò che le GPU implementano oggi è il modello SIMD, o comunque ci sono molto vicini.

Inoltre nVidia ha dichiarato (mi pare di averlo letto sul loro blog) che ciò che lei vede è l'accoppiata CPU per calcolo "general purpose" e GPU per il calcolo (massicciamente) parallelo.

D'altra parte è anche logico che sia così: la GPU non è fatta per soppiantare il lavoro in cui una CPU semplicemente eccelle.

La cosa che a mio avviso cozza tremendemente è l'aver scelto un modello VLIW per la CPU, che si è dimostrato sempre poco performante per il calcolo "general purpose". Esempi illustri ne abbiamo avuti in passato: Itanium e... proprio Transmeta.

Per questo voglio vedere (tant)i benchmark eseguiti con codice variegato.
Insomma, è un altra interpretazione de "il set d'istruzioni non è più rilevante"
(a patto che sia sufficientemente semplice ed ben ottimizzabile tramite ricompilazione, suppongo).
Invece proprio Project Denver continua a dimostrare che l'ISA è più che mai importante. Infatti ARM, inclusa ARMv8, era così bella e rinomata che hanno pensato bene di "buttarla" e soppiantarla con una loro architettura VLIW. :D

I risultati concreti sono di là da vedersi, come già detto, ma è un segnale significativo sull'argomento "ISA = importante". ;)

cdimauro

16-08-2014, 09:03

I chip POWER8 sono 6-core oppure 12-core (attualmente DCM ovvero dual module su un unico package, in futuro su singolo chip), ogni singolo core esegue simultanemente 8 thread, per un totale di 96 thread e tutto questo con un consumo sui 250Watt quando un 12-core è clockato a 4.5Ghz.
http://www.extremetech.com/computing/181102-ibm-power8-openpower-x86-server-monopoly
Non è che magari ti confondi con un sistema a 4 socket precedente ?
Casualmente ho ritrovato il thread (http://amigaworld.net/modules/newbb/viewtopic.php?topic_id=39203&forum=33#737012) in cui avevo letto il dato che avevo riportato in precedenza.

Questo (http://www-03.ibm.com/systems/power/hardware/s814/specs.html)è il sistema POWER 8 in oggetto: singolo socket, con supporto a CPU con 4/6/8 core.

Riporto di seguito l'immagine, da quel thread, riguardo al consumo:

http://i.imgur.com/cf8UbK3.png

Sono 500W, ma credo si riferisca all'intera piattaforma (quindi non soltanto alla CPU). Comunque è un sistema con soli 4 core a 3Ghz, e il consumo mi pare molto elevato.

LMCH

16-08-2014, 18:44

Riporto di seguito l'immagine, da quel thread, riguardo al consumo:

http://i.imgur.com/cf8UbK3.png

Sono 500W, ma credo si riferisca all'intera piattaforma (quindi non soltanto alla CPU). Comunque è un sistema con soli 4 core a 3Ghz, e il consumo mi pare molto elevato.

Si, il dato è riferito al sistema completo
( S814-8286-41A ovvero IBM Power System S814)
http://www-01.ibm.com/common/ssi/ShowDoc.wss?docURL=/common/ssi/rep_ca/2/897/ENUS114-062/index.html&lang=en&request_locale=null

E' un server con socket dual-chip module (DCM)
in formato 4U rack-mount oppure desk-side
con un fottio di roba oltre alla cpu
(fino a 512GB di ram, fino a 18 unita di memoria "formato DVD bay"
espansioni slot PCIe hot-swap, doppio alimentatore hot-plug
4 porte USB 3.0, 2 USB 2.0, 2 link HMC 1Gbit, ecc. ecc. ).

LMCH

16-08-2014, 23:52

Purtroppo anche così non risolvi col codice di un emulatore che è troppo intricato e strapieno di dipendenze. Ho scritto un emulatore 80186 per Amiga (68020+; interamente in assembly) e uno 65C02 (assembly 8086 per l'esecuzione delle istruzion 65C02; Turbo Pascal per tutto il resto), per cui conosco molto bene le problematiche che ci sono dietro.

Ma nel caso del software che si deve far girare in emulazione sui POWER, si tratta di emulare solo il lato "user mode", non "tutta la cpu" e tutto l'hardware di basso livello, la cosa fa una differenza notevole e per questo è più semplice riordinare e fare l'interleave delle sequenze di istruzioni "native" che implementano le sequenze di istruzioni "emulate".

Non credo. Roba come il power-gating, ad esempio, non ha nulla a che vedere con la semplicità di decodifica. Era a questo che mi riferivo quanto parlavo di tecnologie per la riduzione dei consumi.

Ma resta il fatto che un set d'istruzioni "semplice" è vantaggioso perché semplifica le cose a livello implementativo, semplificando indirettamente anche la circuiteria di gestione energia.

Francamente non lo vedo proprio. VLIW per le GPU è un modello architetturale che è stato sostanzialmente abbandonato. Ciò che le GPU implementano oggi è il modello SIMD, o comunque ci sono molto vicini.

E' una questione di corsi e ricorsi tecnologici, nel senso che in base alle tecnologie ed al background teorico disponibile certe soluzioni sembrano più promettenti nel contesto di certe applicazioni, poi parametri e e contesto cambiano e si ripescano e rielaborano soluzioni che erano state abbandonate ma che nel nuovo contesto sembrano offrire dei vantaggi interessanti, ecc. ecc.

Ad esempio i CISC sono stati il risultato di successivi sviluppi tecnologici che permettevano di aggiungere sempre più funzionalità in hardware ed il termine CISC è nato per indicare il "problema" che si era venuto a creare e che l'approccio RISC si proponeva di risolvere (con architetture più snelle e con compilatori più avanzati).
Poi VLIW e TTA (Transport Triggered Architecture) sono stati un ulteriore tentativo di semplificare l'hardware spostando più oneri di ottimizzazione sui compilatori, anche se già le prime architetture di quel tipo resero chiaro che esistevano limiti riguardo quanto si poteva scaricare sul software e di quanto certi approcci potevano essere scalati in hardware (sempre nei limiti di tecnologie e background teorico disponibile).

Come del resto successe con l'approccio multicore del Cell con IBM che scommise troppo su quello che poteva fare il compilatore ... e perse.

Inoltre nVidia ha dichiarato (mi pare di averlo letto sul loro blog) che ciò che lei vede è l'accoppiata CPU per calcolo "general purpose" e GPU per il calcolo (massicciamente) parallelo.

D'altra parte è anche logico che sia così: la GPU non è fatta per soppiantare il lavoro in cui una CPU semplicemente eccelle.

Quella è la versione ufficiale per i non addetti ai lavori, se cammin facendo vedranno opportunità migliori le seguiranno (o le stanno già seguendo).

Ad esempio, le GPU attuali eccellono in problemi in cui in genere l'approccio SIMD è quello ottimale.
Quindi cosa comporta per l'enfasi eccessiva che Intel pone sul lato SIMD delle sue cpu ? ;)

La cosa che a mio avviso cozza tremendemente è l'aver scelto un modello VLIW per la CPU, che si è dimostrato sempre poco performante per il calcolo "general purpose". Esempi illustri ne abbiamo avuti in passato: Itanium e... proprio Transmeta.

VLIW è solo un caso particolare di sistema MIMD in cui si espone esplicitamente il parallelismo interno a livello di unita funzionali.
In un certo senso "si delega al compilatore" il riordinamento e l'appaiamento delle istruzioni che in una cpu superscalare con esecuzione out-of-order viene gestito internamente.

Il modello VLIW "puro" usa istruzioni "larghe", senza "compilazione" a partire da un set d'istruzioni differente, ovviamente questo crea problemi in termini di dimensioni del codice, ecc. ecc.
Ed infatti i VLIW "reali" di solito implementano un formato più "compatto" che viene espanso in modo molto efficiente dal decoder delle istruzioni.

Per questo poi anche nell'Itanium si seguì l'approccio EPIC che tra le altre cose si basava su istruzioni "compatte" ottimizzate per essere "espanse" in istruzioni VLIW "interne" dal decoder (cosa che permetteva pure di aggiungere o togliere unita funzionali, entro certi limiti).

Nel caso dell'Itanium il vero problema non era tanto il lato VLIW/EPIC ma tutta la roba che avevano aggiunto a livello di funzionalità accessorie
e le poche ALU dedicate agli interi (nella prima implementazione) rispetto alle esigenze reali.

Nel caso di Transmeta invece il problema era il set d'istruzioni "compresso" utilizzato ed il codice che veniva eseguito (ottimizzato per un architettura decisamente non-VLIW ;) e con relativamente pochi registri, visto che si trattava del set d'istruzioni x86 a 32bit.

Ma non era malaccio, il Crusoe a 700Mhz aveva le prestazioni di un Pentium III a 500Mhz ed aveva consumi relativamente bassi, solo che in quel periodo Intel poteva uscire per prima con i processi di produzione più avanzati (ed anche grazie a questo salire di prestazioni più rapidamente) e forniva incentivi a chi usava le sue cpu ed i suoi chipset in primo luogo in funzione anti-AMD (ma con Transmeta presa in mezzo dallo scontro allora in atto tra i due).

Invece proprio Project Denver continua a dimostrare che l'ISA è più che mai importante. Infatti ARM, inclusa ARMv8, era così bella e rinomata che hanno pensato bene di "buttarla" e soppiantarla con una loro architettura VLIW. :D

Oppure ARMv8 è fatta così bene che si presta bene anche ad implementazioni VLIW, mentre altrettanto non si può dire di un altro set d'istruzioni.
In altre parole è più versatile. ;)

L'implementazione "interna" è VLIW, ma l'architettura visibile al programmatore è ARMv8.

Guardacaso il set d'istruzioni scelto ha una decodifica semplice, molti registri "di uso generale" e molte più possibilità di parallelizzazione e riordino per esecuzione in-order grazie ad un modello logico che permette di ottenere un miglior parallelismo interno in fase di esecuzione. :D

cdimauro

17-08-2014, 10:14

Si, il dato è riferito al sistema completo
( S814-8286-41A ovvero IBM Power System S814)
http://www-01.ibm.com/common/ssi/ShowDoc.wss?docURL=/common/ssi/rep_ca/2/897/ENUS114-062/index.html&lang=en&request_locale=null

E' un server con socket dual-chip module (DCM)
in formato 4U rack-mount oppure desk-side
con un fottio di roba oltre alla cpu
(fino a 512GB di ram, fino a 18 unita di memoria "formato DVD bay"
espansioni slot PCIe hot-swap, doppio alimentatore hot-plug
4 porte USB 3.0, 2 USB 2.0, 2 link HMC 1Gbit, ecc. ecc. ).
OK, ma come il tizio del thread diceva, non c'erano montati nemmeno i dischi, e aveva soltanto 16GB di memoria installati. Quindi non penso che il consumo fosse dovuto al sistema stracarico di roba, ma al sistema quasi vuoto.

E' un peccato non avere altri dati per poter capire quanto incida realmente la CPU sul consumo.
Ma nel caso del software che si deve far girare in emulazione sui POWER, si tratta di emulare solo il lato "user mode", non "tutta la cpu" e tutto l'hardware di basso livello, la cosa fa una differenza notevole e per questo è più semplice riordinare e fare l'interleave delle sequenze di istruzioni "native" che implementano le sequenze di istruzioni "emulate".
Anch'io mi riferivo esclusivamente all'emulazione delle singole istruzioni, peraltro soltanto in user-space (negli 80186 e 65C02 non esiste il concetto di kernel-space: è tutto user :D).

Purtroppo al momento non ho sotto mano il codice dei miei emulatori, ma appena lo recupero posto qualche spezzone, così sarà facile capire quali dipendenze ci sono in gioco e perché non posso essere eliminate riordinando il codice.
Ma resta il fatto che un set d'istruzioni "semplice" è vantaggioso perché semplifica le cose a livello implementativo, semplificando indirettamente anche la circuiteria di gestione energia.
Alla fine i decoder sono unità funzionali come le altre: blocchi di logica che puoi decidere di spegnere o accendere come faresti con una ALU, ad esempio. Io non vedo problemi dovuti alla complessità delle istruzioni, che è racchiusa nell'unità stessa. In ogni caso la micro-elettronica non è il mio campo, per cui mi fermo qui con le ipotesi.
E' una questione di corsi e ricorsi tecnologici, nel senso che in base alle tecnologie ed al background teorico disponibile certe soluzioni sembrano più promettenti nel contesto di certe applicazioni, poi parametri e e contesto cambiano e si ripescano e rielaborano soluzioni che erano state abbandonate ma che nel nuovo contesto sembrano offrire dei vantaggi interessanti, ecc. ecc.

Ad esempio i CISC sono stati il risultato di successivi sviluppi tecnologici che permettevano di aggiungere sempre più funzionalità in hardware ed il termine CISC è nato per indicare il "problema" che si era venuto a creare e che l'approccio RISC si proponeva di risolvere (con architetture più snelle e con compilatori più avanzati).
Hai ragione. Nulla vieta che in futuro certi concetti "dismessi" possano essere ripresi nuovamente.
Poi VLIW e TTA (Transport Triggered Architecture) sono stati un ulteriore tentativo di semplificare l'hardware spostando più oneri di ottimizzazione sui compilatori, anche se già le prime architetture di quel tipo resero chiaro che esistevano limiti riguardo quanto si poteva scaricare sul software e di quanto certi approcci potevano essere scalati in hardware (sempre nei limiti di tecnologie e background teorico disponibile).

Come del resto successe con l'approccio multicore del Cell con IBM che scommise troppo su quello che poteva fare il compilatore ... e perse.
Ecco, appunto: il nocciolo della questione sta tutto lì. Ed è il motivo per cui parecchio tempo fa si è passati da architetture in-order a OoO. ;)

Non conoscevo l'esistenza delle architetture TTA. Immagino che si trovino in ambiti altamente specializzati.
Quella è la versione ufficiale per i non addetti ai lavori, se cammin facendo vedranno opportunità migliori le seguiranno (o le stanno già seguendo).
Senz'altro. E avendo nascosto la reale architettura, possono decidere di cambiare tutto quando e come vogliono.
Ad esempio, le GPU attuali eccellono in problemi in cui in genere l'approccio SIMD è quello ottimale.
Quindi cosa comporta per l'enfasi eccessiva che Intel pone sul lato SIMD delle sue cpu ? ;)
Proprio perché Intel ha puntato tutto sul modello SIMD, e da ben prima che c'arrivassero le GPU: sono quasi 20 anni che le SIMD sono sbarcate su x86. ;) E' un modello che si sposa molto bene con la sua architettura, visto che devi decodificare una sola istruzione, e poi replicare le operazioni diverse volte.

Le GPU ci sono arrivate adesso, e quindi s'è creata questa sovrapposizione / conflittualità.

Ovviamente ognuno spinge per la sua strada, ma alla fine, come per tutte le cose, contano i numeri commisurati ai costi per ottenerli. Ci sono ambiti in cui il modello SIMD di Intel si presta meglio di quello delle GPU, e viceversa. ISA, microarchitettura, e piattaforma hanno il loro peso in tutto ciò.

E' difficile affermare quale modello sia migliore in assoluto rispetto all'altro, e per questo è anche difficile prevedere quale s'imporrà alla fine.

Aggiungo, però, un'osservazione. Al momento se devi far eseguire un certo calcolo alla GPU, devi mettere in piedi un protocollo di offloading e condivisione delle risorse che penalizza molto le prestazioni complessive che si potrebbero ottenere se si potesse eseguire immediatamente il codice.
HSA di AMD & ARM nasce per migliorare molto quest'aspetto, ma non lo risolve del tutto, oltre al fatto, assolutamente non di poco conto, che risulta necessario riscrivere in parte il codice per poterne trarre beneficio.

Una CPU, invece, potrà sempre "partire subito" senza aspettare niente e nessuno per eseguire i calcoli, e questo ha e manterrà un suo vantaggio. Il problema, per la CPU, è di avere a disposizione un'unità SIMD abbastanza "massiccia" a cui smistare il lavoro. La direzione che Intel intrapreso è ovviamente proprio questa, vedi AVX e, soprattutto, il prossimo AVX-512.
VLIW è solo un caso particolare di sistema MIMD in cui si espone esplicitamente il parallelismo interno a livello di unita funzionali.
In un certo senso "si delega al compilatore" il riordinamento e l'appaiamento delle istruzioni che in una cpu superscalare con esecuzione out-of-order viene gestito internamente.

Il modello VLIW "puro" usa istruzioni "larghe", senza "compilazione" a partire da un set d'istruzioni differente, ovviamente questo crea problemi in termini di dimensioni del codice, ecc. ecc.
Ed infatti i VLIW "reali" di solito implementano un formato più "compatto" che viene espanso in modo molto efficiente dal decoder delle istruzioni.
Infatti. Ma immagino che l'architettura VLIW adottata da nVidia non faccia uso di alcuna compressione (come penso facesse anche Transmeta, coi suoi enormi bundle), visto l'enorme cache codice L1 adottata, come pure i ben 128MB di memoria che riserva solo per la cache di traduzione (per confronto, Transmeta ne usava 16MB).
Per questo poi anche nell'Itanium si seguì l'approccio EPIC che tra le altre cose si basava su istruzioni "compatte" ottimizzate per essere "espanse" in istruzioni VLIW "interne" dal decoder (cosa che permetteva pure di aggiungere o togliere unita funzionali, entro certi limiti).

Nel caso dell'Itanium il vero problema non era tanto il lato VLIW/EPIC ma tutta la roba che avevano aggiunto a livello di funzionalità accessorie
e le poche ALU dedicate agli interi (nella prima implementazione) rispetto alle esigenze reali.
Ma anche dopo la prima implementazione, non è che abbia brillato a livello prestazionale sul codice general purpose. La questione, a mio avviso, rimane sempre la stessa, che peraltro hai citato tu all'inizio: delegare parte della complessità del chip al software (compilatore in primis) non paga.
Nel caso di Transmeta invece il problema era il set d'istruzioni "compresso" utilizzato ed il codice che veniva eseguito (ottimizzato per un architettura decisamente non-VLIW ;) e con relativamente pochi registri, visto che si trattava del set d'istruzioni x86 a 32bit.
A mio avviso l'ISA x86 non c'entra, perché non credo che siano partiti con un'architettura VLIW che non tenesse conto di quello che avrebbe dovuto fare principalmente (emulare x86, appunto). Sono convinto che il problema principale sia dovuto proprio all'architettura VLIW e ai suoi limiti intrinseci dovuti all'esecuzione in-order e all'impossibilità di poter gestire in scioltezza tutte le dipendenze.

Un'ISA come x86 ha pochi registri, ma li sfrutta parecchio, per cui si fa ampio uso di tecniche di register-renaming nelle microimplementazioni. Tutto ciò può facilmente venire implementato da un'ISA VLIW che ha parecchi registri a disposizione e può sfruttarli proprio per il renaming tracciando opportunamente il loro utilizzo.

Altra cosa, x86 ha una modalità d'indirizzamento della memoria molto complesso per un RISC (tranne per ARM, che ne mette a disposizione alcuni simili): Base + Indice * Scala (da 1 a 8) + Offset a 32 bit. Le micro-implementazioni x86 ne traggono vantaggio mettendo a disposizioni AGU dedicate soltanto a questo scopo, ottenendo ottimi risultati. Un'ISA VLIW immagino che abbia modalità d'indirizzamento estremamente semplici, ma dovendo emulare quelle di x86 e avendo a disposizione parecchi registri, può facilmente spalmare tutti questi calcoli nei suoi bundle & registri usati, magari intervallando i calcoli di più istruzioni x86.

Infine, x86 ha pure alcune istruzioni abbastanza complicate (ma che da tempo non si trovano più o sono molto rare) da richiedere l'esecuzione di parecchi calcoli che magari fanno uso di registri temporanei per i calcoli intermedi.

In sostanza, e per concludere il discorso, anche se x86 ha pochi registri, un'ISA VLIW potrebbe benissimo usare i suoi molti registri interni per accelerarne l'emulazione. Il problema rimane il solito: le dipendenze del codice sono comunque abbastanza rilevanti nel codice general-purpose, da mettere un freno alle prestazioni raggiungibili.
Ma non era malaccio, il Crusoe a 700Mhz aveva le prestazioni di un Pentium III a 500Mhz ed aveva consumi relativamente bassi, solo che in quel periodo Intel poteva uscire per prima con i processi di produzione più avanzati (ed anche grazie a questo salire di prestazioni più rapidamente) e forniva incentivi a chi usava le sue cpu ed i suoi chipset in primo luogo in funzione anti-AMD (ma con Transmeta presa in mezzo dallo scontro allora in atto tra i due).
E' vero che a causa di ciò anche Transmeta potrebbe essere rimasta coinvolta, ma all'epoca di quegli avvenimenti non era messa molto bene, per cui dubito che possa essere stata questa la causa. Intel e AMD avevano già intrapreso la strada del contenimento dei consumi, e a mio avviso Transmeta è rimasta strangolata da questo nuovo corso.

Quei dati delle prestazioni a mio avviso sono gonfiati tanto quanto quelli di nVidia per Project Denver. ;) Ho recuperato gli estensivi test effettuati da Van's all'epoca, sia per Crusoe (http://www.vanshardware.com/articles/2003/07/030715_Transmeta/030715_Transmeta.htm) sia per Efficeon (http://www.vanshardware.com/reviews/2004/04/040405_efficeon/040405_efficeon.htm): mi pare che i risultati siano eloquenti (gli articoli sono pure molto tecnici, per cui consiglio di leggerli per l'analisi che viene fatta). Non soltanto le prestazioni reali sono decisamente scarse, ponendosi al di sotto del più scarso x86 (di Via), ma il risparmio sui transistor sostanzialmente non c'è, in particolare a causa dell'elevata quantità di cache L1 e L2 integrate, tant'è che le dimensioni del die di Efficeon sono superiori a tutte le altre soluzioni x86, a eccezione del P4. Altra cosa interessante, è che il clock è fermo inchiodato a 1Ghz: da un RISC, soprattutto VLIW, ci si sarebbe aspettati frequenze di gran lunga più elevate, no? :p

Last but not least, già il primo Crusoe aveva una cache L2 con linee di ben 128 byte = ben 1024 bit. Probabilmente è questo che ha frenato il clock, causa problematiche di clock skew.

Direi che almeno sull'approccio VLIW di Transmeta potremmo anche metterci sopra una bella pietra tombale. :D
Oppure ARMv8 è fatta così bene che si presta bene anche ad implementazioni VLIW, mentre altrettanto non si può dire di un altro set d'istruzioni.
In altre parole è più versatile. ;)

L'implementazione "interna" è VLIW, ma l'architettura visibile al programmatore è ARMv8.

Guardacaso il set d'istruzioni scelto ha una decodifica semplice, molti registri "di uso generale" e molte più possibilità di parallelizzazione e riordino per esecuzione in-order grazie ad un modello logico che permette di ottenere un miglior parallelismo interno in fase di esecuzione. :D
Project Denver deve emulare anche ARM32 e Thumb-2 come minimo (penso anche ThumbEE), che non hanno assolutamente gli stessi pregi di ARMv8. ;)

Certamente per l'ISA VLIW interna avranno tenuto conto di tutto ciò (non avranno realizzato un'ISA VLIW fine a se stessa), ma le 3 ISA ARM da emulare sono abbastanza diverse, sia a livello di decodifica sia d'esecuzione.

Per cui continuo a rimanere scettico, soprattutto per l'approccio VLIW adottato.

LMCH

18-08-2014, 01:39

OK, ma come il tizio del thread diceva, non c'erano montati nemmeno i dischi, e aveva soltanto 16GB di memoria installati. Quindi non penso che il consumo fosse dovuto al sistema stracarico di roba, ma al sistema quasi vuoto.

E' un peccato non avere altri dati per poter capire quanto incida realmente la CPU sul consumo.

Nel thread a cui ti riferivi si parlava del consumo del sistema completo:
http://amigaworld.net/modules/newbb/viewtopic.php?topic_id=39203&forum=33#737012

Non dei core, non della mainboard, ma del sistema completo.
Anche con "solo" 16GB di ram installata e nessun disco montato hai un sacco di roba oltre i core (tipo due alimentatori capaci di reggere il sistema in configurazione massima e che supportano l'hot-swap, da soli nella pura e semplice parte switching si mangiano almeno un 8% circa del consumo totale).

Anch'io mi riferivo esclusivamente all'emulazione delle singole istruzioni, peraltro soltanto in user-space (negli 80186 e 65C02 non esiste il concetto di kernel-space: è tutto user :D).

Purtroppo al momento non ho sotto mano il codice dei miei emulatori, ma appena lo recupero posto qualche spezzone, così sarà facile capire quali dipendenze ci sono in gioco e perché non posso essere eliminate riordinando il codice.

Ricorda che presupponendo che il codice binario venga eseguito su un S.O. "completo" e con processore che supporta la separazione tra user-space e kernel-space, paradossalmente l'emulazione lato user-mode diventa molto più semplice. ;)
Niente ISR, niente istruzioni che su un 80186 o su un 6502 permettono di manipolare porte di I/O ed altra roba che sarebbero normalmente vietata in user-space, ecc.

Un'ISA come x86 ha pochi registri, ma li sfrutta parecchio, per cui si fa ampio uso di tecniche di register-renaming nelle microimplementazioni. Tutto ciò può facilmente venire implementato da un'ISA VLIW che ha parecchi registri a disposizione e può sfruttarli proprio per il renaming tracciando opportunamente il loro utilizzo.

Ma in quel modo si carica di molto più lavoro il decoder misto hardware/software dell'architettura VLIW "con set d'istruzioni esterno non-VLIW".
Mentre invece con più registri (ma non troppi) visibili al compilatore è esso a svolgere il grosso dell'ottimizzazione e quindi la decodifica verso istruzioni VLIW è più semplice ed efficiente.

Per questo il set d'istruzioni ha ancora una discreta influenza sulle prestazioni ottenibili.

Last but not least, già il primo Crusoe aveva una cache L2 con linee di ben 128 byte = ben 1024 bit. Probabilmente è questo che ha frenato il clock, causa problematiche di clock skew.

La cache L2 è due gerarchie di memoria al di sotto dei registri interni, quindi le ragioni per scegliere una certa dimensione non sono gli stessi dei registri interni. ;)

La dimensione delle linee di cache L2 ed L3 viene cambiata di generazione in generazione in base all'ampiezza dei bus verso la ram e della frequenza massima di lavoro della cpu e della ram.

Attualmente negli x86 di Intel è stabile sui 64byte.
Il motivo principale dell'attuale "standardizzazione" a 64byte è legato alla tecnologia dei moduli di ram.
Le DDR hanno un canale che trasferisce 64bit per fronte (8byte), ma danno il massimo di prestazioni quando sono in burst mode, ovvero trasferiscono 4 gruppi di 8 byte consecutivamente (32byte totali).

A questo punto considera che la configurazione comune è avere DUE canali DDR e questo spiega la "standardizzazione" attuale su linee da 64byte.

Ma ad esempio in passato gli Itanium mcKinley avevano una L2 line size di 128byte ed i Pentium 4 avevano una L2 line size di 64byte ma con un opzione per leggere/scrivere due cache line consecutive (nel caso fossero stati abbinati ad un northbridge con memory controller con più di due canali o che supportasse una tipologia di ram con una banda di I/O più elevata).

cdimauro

18-08-2014, 07:07

Ricorda che presupponendo che il codice binario venga eseguito su un S.O. "completo" e con processore che supporta la separazione tra user-space e kernel-space, paradossalmente l'emulazione lato user-mode diventa molto più semplice. ;)
Niente ISR,
Che problema ti porta dover gestire gli interrupt in user-space? Dovrebbe pure essere più semplice (niente registro di stato da aggiornare con la nuova modalità d'esecuzione).
niente istruzioni che su un 80186 o su un 6502 permettono di manipolare porte di I/O ed altra roba che sarebbero normalmente vietata in user-space, ecc.
Il 6502 ha tutto memory-mapped: niente porte di I/O. :)

Ma posso dirti che con l'80186 era una grandissima comodità il fatto che le periferiche fossero mappate quasi tutte nelle porte di I/O. In questo modo intercettare le scritture e letture alle varie periferiche era di gran lunga più efficente rispetto a fare la stessa cosa su un sistema che è interamente memory-mapped. Questo perché le porte sono di meno, e con una piccola jump-table riuscivo a gestire il tutto. Ma soprattutto per le letture e scritture non dovevo assolutamente mettermi lì a controllare se per caso l'indirizzo da leggere/scrivere andava a toccare una certa zona di memoria; puoi immaginare quanto lento possa essere tutto ciò, e quanto incida sulle prestazioni.

All'epoca mi ero dedicato esclusivamente all'emulazione della scheda grafica CGA, per cui l'emulazione era molto veloce proprio perché tutti i suoi registri erano mappati su porte di I/O e il suo framebuffer era mappato su 32K di memoria ma non c'erano cose strane da controllare (bastava leggere e scrivere).
EGA e VGA, invece, mi avrebbero costretto a effettuare il classico controllo per vedere se l'indirizzo di memoria rientrava fra $A0000 e $AFFFF, in quanto la memoria mappata per il framebuffer faceva uso di una sorta di bank switching per gestire la grafica a bitplane (il mode 13 a 256 colori, invece, era perfetto: 320x200 e accesso a singolo byte).

Emulare un sistema memory-mapped è un bagno di sangue a livello prestazionale...
Ma in quel modo si carica di molto più lavoro il decoder misto hardware/software dell'architettura VLIW "con set d'istruzioni esterno non-VLIW".
Mentre invece con più registri (ma non troppi) visibili al compilatore è esso a svolgere il grosso dell'ottimizzazione e quindi la decodifica verso istruzioni VLIW è più semplice ed efficiente.

Per questo il set d'istruzioni ha ancora una discreta influenza sulle prestazioni ottenibili.
Sì, me ne rendo conto, ma senza implementare nemmeno il register renaming perdi i vantaggi di intercettare i cambiamenti d'uso di un registro e generare codice ottimizzato. Tra l'altro anche RISC come PowerPC, se non ricordo male, usano il register renaming per migliorare un po' le prestazioni.

A questo punto se è difficile tenere traccia del register renaming, sarà relativamente difficile gestire anche le dipendenze delle istruzioni, che ha problematiche simili da risolvere.

Ricadiamo sempre sullo stesso punto: spostare sul software ciò che puoi fare in hardware rimane una pessima idea per l'impatto negativo che ha sulle prestazioni, visto che non si può ottimizzare il codice più di tanto.
La cache L2 è due gerarchie di memoria al di sotto dei registri interni, quindi le ragioni per scegliere una certa dimensione non sono gli stessi dei registri interni. ;)
Vero, ma con la cache L2 non ti devi comunque interfacciare tramite la cache L1? Se trasferisci la stessa quantità di dati per ciclo di clock, anche la L1 avrà gli stessi problemi di clock skew, e così via anche per il resto dell'architettura.

Al solito, sai che questo non è il mio campo: le mie sono soltanto osservazioni da esterno alla materia. :p
La dimensione delle linee di cache L2 ed L3 viene cambiata di generazione in generazione in base all'ampiezza dei bus verso la ram e della frequenza massima di lavoro della cpu e della ram.

Attualmente negli x86 di Intel è stabile sui 64byte.
Il motivo principale dell'attuale "standardizzazione" a 64byte è legato alla tecnologia dei moduli di ram.
Le DDR hanno un canale che trasferisce 64bit per fronte (8byte), ma danno il massimo di prestazioni quando sono in burst mode, ovvero trasferiscono 4 gruppi di 8 byte consecutivamente (32byte totali).

A questo punto considera che la configurazione comune è avere DUE canali DDR e questo spiega la "standardizzazione" attuale su linee da 64byte.
E con le DDR4 che stanno arrivando i dati raddoppieranno. :D
Ma ad esempio in passato gli Itanium mcKinley avevano una L2 line size di 128byte ed i Pentium 4 avevano una L2 line size di 64byte ma con un opzione per leggere/scrivere due cache line consecutive (nel caso fossero stati abbinati ad un northbridge con memory controller con più di due canali o che supportasse una tipologia di ram con una banda di I/O più elevata).
Entrambi avevano l'esigenza di poter riempire velocemente le loro cache. Il primo quella del codice a causa dell'elevata dimensione dei suoi bundle e della scarsa densità di codice. Il secondo per la piccolissima cache dati L1 (era più orientato a macinare numeri grazie a clock elevato e SSE).

Comunque bene o male oggi tutti i sistemi hanno un'interfaccia con la memoria simile, perché poter contare su una banda elevata è diventata un'esigenza da soddisfare necessariamente, specialmente avendo una GPU integrata che va sfamata e ha parecchia fame di banda.

Secondo te tutto ciò non incide nel famigerato clock skew di cui abbiamo parlato? Voglio dire: le problematiche del memory controller si dovrebbero riversare sulla prima cache che incontra, ad esempio la L3, da questa alla L2, e alla L1. Non so che impatto potrebbe avere, poi, riguardo all'interfacciamento coi registri.

LMCH

19-08-2014, 01:21

Il 6502 ha tutto memory-mapped: niente porte di I/O. :)

Emulare un sistema memory-mapped è un bagno di sangue a livello prestazionale...

Solo se le aree di memoria corrispondenti a registri di I/O, memoria video, ecc.
sono accessibili in user-mode (o non esiste differenziazione tra user-mode e kernel-mode).

Sì, me ne rendo conto, ma senza implementare nemmeno il register renaming perdi i vantaggi di intercettare i cambiamenti d'uso di un registro e generare codice ottimizzato. Tra l'altro anche RISC come PowerPC, se non ricordo male, usano il register renaming per migliorare un po' le prestazioni.

E' un corso e ricorso storico, nel senso che a fasi alterne si pensa di poter eseguire in software (ahead-of-time e/o just-in-time) parte delle operazioni in precedenza non possibili o gestite in modo più rudimentale dall'hardware, poi con più gate disponibili ecc. ecc. si ritorna ad implementare in hardware una versione più evoluta di quello che si faceva prima, poi i gate aumentano ancora e sembra più conveniente aumentare le unita di esecuzione e ri-spostare a livello software certe cose, ecc. ecc.

L'esecuzione in-order oppure out-of-order sono scollegate concettualmente dalle architetture RISC,CISC, SIMD o MIMD che siano, ma il momento in cui conviene passare ad una delle due o ritornare all'altra dipende dalle tecnologie di implementazione disponibili e dall'architettura.

Nulla ad esempio vieta di realizzare una cpu VLIW con esecuzione out-of-order
(VLIW è un caso particolare di architettura MIMD), solo che di solito ci si aspetta che in un architettura VLIW sia il compilatore (ahead-of-time oppure just-in-time) a risequenziare il codice in modo da non rendere necessario o sufficientemente conveniente aggiugere il supporto per esecuzione out-of-order.
Inoltre se il set d'istruzioni "visibile al programmatore" non è vincolato ad un architettura VLIW, quando il ritorno in termini di costro/prestazioni di tale approccio non è più conveniente, diventa più facile passare ad altre architetture che usano lo stesso set d'istruzioni invece che avere un VLIW "out-of-order".

Mentre invece per i RISC ,grazie alle maggiori ottimizzazioni gestibili dal compilatore, solo dopo un certo punto è diventato conveniente aggiungere il supporto per il renaming ed esecuzione out-of-order e visto che avevano un loro set d'istruzioni, non si è parlato di "abbandono" dei RISC ma semplicemente di loro implementazione out-of-order, ecc.

cdimauro

19-08-2014, 06:53

Solo se le aree di memoria corrispondenti a registri di I/O, memoria video, ecc.
sono accessibili in user-mode (o non esiste differenziazione tra user-mode e kernel-mode).
Esattamente. Ed è, purtroppo, quello che capita spesso con un emulatore.

Tornando all'emulazione di software per i POWER, se ci si limita esclusivamente al caso che hai esposto, le prestazioni saranno buone.
Nulla ad esempio vieta di realizzare una cpu VLIW con esecuzione out-of-order
(VLIW è un caso particolare di architettura MIMD), solo che di solito ci si aspetta che in un architettura VLIW sia il compilatore (ahead-of-time oppure just-in-time) a risequenziare il codice in modo da non rendere necessario o sufficientemente conveniente aggiugere il supporto per esecuzione out-of-order.
Inoltre se il set d'istruzioni "visibile al programmatore" non è vincolato ad un architettura VLIW, quando il ritorno in termini di costro/prestazioni di tale approccio non è più conveniente, diventa più facile passare ad altre architetture che usano lo stesso set d'istruzioni invece che avere un VLIW "out-of-order".
Esattamente. Se devi realizzare un VLIW OoO la cui codifica delle istruzioni nel bundle non è compatta, ma ad esempio ognuna occupa "casualmente" 32-bit, ti ritrovi sostanzialmente con un RISC.

Io da un VLIW mi aspetto che sia in-order (riguardo alle istruzioni contenute nel bundle) e di trarre vantaggio dalla lunghezza del bundle per ottimizzare la codifica delle istruzioni.
Mentre invece per i RISC ,grazie alle maggiori ottimizzazioni gestibili dal compilatore, solo dopo un certo punto è diventato conveniente aggiungere il supporto per il renaming ed esecuzione out-of-order e visto che avevano un loro set d'istruzioni, non si è parlato di "abbandono" dei RISC ma semplicemente di loro implementazione out-of-order, ecc.
Idem per i CISC. :)

LMCH

19-08-2014, 19:25

Idem per i CISC. :)

Ma con molti più problemi. ;)
Non a caso ultimi "CISC" ancora in circolazione ed in evoluzione sono gli x86.

cdimauro

20-08-2014, 06:56

Sicuramente. C'erano pure luminari che avevano predetto che i CISC non avrebbero potuto avere una pipeline (immagino si riferissero a una superpipeline).

Intel col Pentium e Motorola col 68060 li smentirono. :D E prima ancora 80486 e 68040 avevano agguantato i RISC con prestazioni eccezionali su singola pipeline. ;)

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.

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. ;)

LMCH

21-08-2014, 01:44

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).

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

21-08-2014, 06:49

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:
http://lowendmac.com/ed/fox/08ff/art/mac-unit-sales.gif
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

24-08-2014, 01:59

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.

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.

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

24-08-2014, 06:43

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. :D

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

24-08-2014, 23:38

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

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.

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

25-08-2014, 07:02

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

25-08-2014, 20:19

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.

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.

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

26-08-2014, 07:01

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). :fagiano:
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 (http://www.appuntidigitali.it/18362/statistiche-su-x86-x64-parte-8-istruzioni-mnemonici/), 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.