Apple vuole Merom e Woodcrest prima di quanto stabilito?

[cdimauro]

Originariamente inviato da scorpionkkk

Non esiste la frase "ha parecchio in comune"...

Guarda che non hai preso la frase, ma un pezzo della frase:

"a LIVELLO DI IMPLEMENTAZIONE [...] ha parecchio in comune"

l'avevo scritto anche a caratteri cubitali...

i processori in produzione attualmente(in realtà da 15 anni) sono RISC...e l'unica reminiscenza del cosiddetto CISC è solo il set d'istruzioni..

Al contrario, da questo punto di vista non ci sono molte differenze fra CISC e RISC moderni: hanno tutti un set d'istruzioni vasto e abbastanza "complesso".

La caratteristicha che ancora oggi distingue sicuramente un processore CISC da un RISC è la presenza di un set d'istruzioni con opcode a lunghezza variabile, al contrario di quello fisso usato da questi ultimi.

Poi ci sarebbe da considerare anche la presenza di modalità d'indirizzamento più complesse (i RISC ne hanno di molto semplici) e la presenza di istruzioni non di load/store che accedono direttamente alla memoria (i RISC hanno soltanto load/store per accedere alla memoria, e tutte le altre istruzioni fanno uso di registri).

Questo in generale e prendendo soltanto gli elementi più significativi (non ho parlato di istruzioni specifiche, come può essere una AAD in un x86, né di microcodice, ad esempio).

Tra l'altro i processori attuali (ma questo ragionamento è vero praticamente dal Pentium in poi a livello commerciale) sono una evoluzione del RISC essendo in realtà dei processori VLIW vettoriali e superscalari.

Bisogna vedere cosa intendi con ciò.

A livello implementativo i CISC hanno iniziato a utilizzare tecnologie prima apparse sui RISC (che sono stati il "fiore all'occhiello" della ricerca e sviluppo nel campo dei microprocessori) per migliorare le prestazioni: mi riferisco alla presenza della cache (L1 e poi L2 ed L3), della separazione fra cache codice e dati, l'uso di bus multipli, di superpipeline che permettevano di eseguire più istruzioni, di esecuzione fuori ordine, di politiche di aggiornamento / consistenza dei dati (write through, write-back, bus snooping, ecc.).
80386, 80486, Pentium, 68020, 68030, 68040, 68060, ecc. hanno fatto parecchio uso di tutto ciò, ma sono pur sempre rimasti dei CISC...

Soltanto a partire dal K5 di AMD (a cui ha fatto seguito Intel col PentiumPro) è stata integrata un'unità RISC-like per l'esecuzione delle istruzioni, per cui le istruzioni x86 veniva "tradotte" in una o più istruzioni "RISC-86" e poi eseguite.
Ma il K5 è rimasto sempre un CISC: non è diventato un RISC soltanto perché A LIVELLO IMPLEMENTATIVO (lo voglio sottolineare ancora una volta), si è fatto uso di un'architettura basata sulla "filosofia RISC".

E si badi bene: non a caso ho parlato di "filosofia". Questo perché arrivare alla conclusione che "i RISC sono migliori dei CISC perché ormai questi ultimi ne integrano uno" è quanto di più sbagliato si possa pensare di fare.
Quei "RISC" hanno motivo di esistere soltanto in seno all'architettura per cui sono stati pensati e utilizzati: non è possibile ipotizzare, ad esempio, che se fossero costruiti dei processori senza tutto "l'orpello" di cui sono circondati, e quindi con un'ISA "nativa" (verrebero eseguite direttamente le istruzioni RISC senza alcuna traduzione), avrebbero buone prestazioni e forse anche molto migliori; al contrario, il decadimento prestazionale sarebbe notevole.

Conclusione: i CISC continuano a rimanere sempre tali, e lo stesso vale per i RISC...

[scorpionkkk]

Originariamente inviato da cdimauro

Al contrario, da questo punto di vista non ci sono molte differenze fra CISC e RISC moderni: hanno tutti un set d'istruzioni vasto e abbastanza "complesso".

La caratteristicha che ancora oggi distingue sicuramente un processore CISC da un RISC è la presenza di un set d'istruzioni con opcode a lunghezza variabile, al contrario di quello fisso usato da questi ultimi.

Poi ci sarebbe da considerare anche la presenza di modalità d'indirizzamento più complesse (i RISC ne hanno di molto semplici) e la presenza di istruzioni non di load/store che accedono direttamente alla memoria (i RISC hanno soltanto load/store per accedere alla memoria, e tutte le altre istruzioni fanno uso di registri).

Questo in generale e prendendo soltanto gli elementi più significativi (non ho parlato di istruzioni specifiche, come può essere una AAD in un x86, né di microcodice, ad esempio).

1)l'opcode a lunghezza variabile non ha alcun senso..ciò che ha senso è solo l'opcode dell'istruzione effettivamente calcolata che poi è solo la microistruzione..non è un caso infatti che sia assolutamente impossibile progettare a livello hardware un processore senza definire il set d'istruzioni (e quindi la lunghezza in bit dell'opcode)..questo infatti comporta una minimizzazione e ottimizzazione dell'hardwrae sempre e comunque.
2)Modalità d'indirizzamento complesse sono tipiche solo dei DSP..che possono anche confondersi con processori "normali" ma non lo sono affatto..possono anche confondersi con processori CISC..ma anche in questo caso non lo sono affatto.
3)Ancora confusione con i DSP che non sono innaznitutto macchine CISC (e ci mancherebbe) ma sono solo macchine vettoriali con particolari istruzioni come la MAC che possono permettersi l'accesso in memoria.

Bisogna vedere cosa intendi con ciò.

A livello implementativo i CISC hanno iniziato a utilizzare tecnologie prima apparse sui RISC (che sono stati il "fiore all'occhiello" della ricerca e sviluppo nel campo dei microprocessori) per migliorare le prestazioni: mi riferisco alla presenza della cache (L1 e poi L2 ed L3), della separazione fra cache codice e dati, l'uso di bus multipli, di superpipeline che permettevano di eseguire più istruzioni, di esecuzione fuori ordine, di politiche di aggiornamento / consistenza dei dati (write through, write-back, bus snooping, ecc.).
80386, 80486, Pentium, 68020, 68030, 68040, 68060, ecc. hanno fatto parecchio uso di tutto ciò, ma sono pur sempre rimasti dei CISC...

Soltanto a partire dal K5 di AMD (a cui ha fatto seguito Intel col PentiumPro) è stata integrata un'unità RISC-like per l'esecuzione delle istruzioni, per cui le istruzioni x86 veniva "tradotte" in una o più istruzioni "RISC-86" e poi eseguite.
Ma il K5 è rimasto sempre un CISC: non è diventato un RISC soltanto perché A LIVELLO IMPLEMENTATIVO (lo voglio sottolineare ancora una volta), si è fatto uso di un'architettura basata sulla "filosofia RISC".

E si badi bene: non a caso ho parlato di "filosofia". Questo perché arrivare alla conclusione che "i RISC sono migliori dei CISC perché ormai questi ultimi ne integrano uno" è quanto di più sbagliato si possa pensare di fare.
Quei "RISC" hanno motivo di esistere soltanto in seno all'architettura per cui sono stati pensati e utilizzati: non è possibile ipotizzare, ad esempio, che se fossero costruiti dei processori senza tutto "l'orpello" di cui sono circondati, e quindi con un'ISA "nativa" (verrebero eseguite direttamente le istruzioni RISC senza alcuna traduzione), avrebbero buone prestazioni e forse anche molto migliori; al contrario, il decadimento prestazionale sarebbe notevole.

Conclusione: i CISC continuano a rimanere sempre tali, e lo stesso vale per i RISC...

Questa è una visione macroscopico-commerciale di un processore che comporta solo confusione.

A livello implementativo basta poco per definire una macchina RISC o comuqnue un approccio RISC:
1)Architettura Harvard
2)Architettura Load/store e operazioni registro/registro
3)formato istruzioni fisso (a livello ultimo)
4)durata fissa di una singola istruzione (1 ciclo o meno)
5)ISA modellato sulle applicazioni
6)istruzioni semplici e hardware esposto al compilatore..
7)Pipeline a più di 3 stadi.

ovvio che l'approccio esposto da questi punti si sia evoluto..ma l'evoluzione successiva è comuqnue partita da qui..e da qui non si è mossa.
Le macroistruzioni che sono rimaste ad essere spezzettate in microoperations non hanno alcun significato a livello progettuale se non quello di semplificare la comunicazione tra progettista ed hw...a livello progettuale tutto è partito da quio e da qui si è evoluto e da qui il "vero" CISC è morto.

PS:cache L1,L2,bus nooping,write back etc etc...sono cose macroscopiche a livello progettuale..non sono certo quelle che determinano la differenza tra architetture.Se si pensa infatti che il Pentium2 è stato il primo processore superscalare commerciale..eppure conteneva tutti questi elementi..senza parlare dell'evoluzione vliw o vettoriale.

[cdimauro]

Originariamente inviato da scorpionkkk

1)l'opcode a lunghezza variabile non ha alcun senso..

Ha senso perché è l'unico parametro (assieme al load/store) che è rimasto in piedi per discriminare le due diverse tipologie di architetture...

ciò che ha senso è solo l'opcode dell'istruzione effettivamente calcolata che poi è solo la microistruzione..

Non è mica detto: un'istruzione dell'ISA "nativo" può essere scomposta anche in più microistruzioni in un'architettura dotata di unità d'esecuzione interna RISC-like.

non è un caso infatti che sia assolutamente impossibile progettare a livello hardware un processore senza definire il set d'istruzioni (e quindi la lunghezza in bit dell'opcode)..

Questo concetto mi sembra a dir poco lapalissiano, ma non capisco cosa c'entra con quanto scritto sopra...

questo infatti comporta una minimizzazione e ottimizzazione dell'hardwrae sempre e comunque.

Cosa intendi con ciò?

2)Modalità d'indirizzamento complesse sono tipiche solo dei DSP..

Al contrario: i CISC sono noti proprio perché generalmente hanno modalità d'indirizzamento MOLTO complesse. Vedi, ad esempio, i Motorola 68020+.

che possono anche confondersi con processori "normali" ma non lo sono affatto..possono anche confondersi con processori CISC..ma anche in questo caso non lo sono affatto.

I DSP sono casi particolari, perché spesso implementano diversi tipi di istruzioni "specializzate" e modalità d'indirizzamento, ma hanno sempre un'architettura molto semplice e lineare, e sono dotati di opcode di dimensione fissa. Possiamo pensarli come a dei RISC molto specializzati.

3)Ancora confusione con i DSP che non sono innaznitutto macchine CISC (e ci mancherebbe)

Infatti non lo sono e sono tutt'altro che confuso: ho chiari i concetti.

ma sono solo macchine vettoriali con particolari istruzioni come la MAC che possono permettersi l'accesso in memoria.

Generalmente anche i DSP hanno delle istruzioni load / store. Il fatto che siano macchine "vettoriali" non dice niente che possa aiutare a inquadrarli nella categoria dei CISC o dei RISC.

Questa è una visione macroscopico-commerciale di un processore che comporta solo confusione.

Ah, e la tua sarebbe quella dettagliatamente scientifica? Vediamo...

A livello implementativo basta poco per definire una macchina RISC o comuqnue un approccio RISC:
1)Architettura Harvard

E' soltanto una tecnologia.

2)Architettura Load/store e operazioni registro/registro

Sì, e già detto anche prima.

3)formato istruzioni fisso (a livello ultimo)

Benissimo. Proprio quello che ho detto io all'inizio.

4)durata fissa di una singola istruzione (1 ciclo o meno)

Fammi un esempio di RISC che rientra in questa categoria, perché non ne conosco: in genere esistono istruzioni che vengono eseguite in un numero variabile di cicli di clock.

5)ISA modellato sulle applicazioni

Ad esempio?

6)istruzioni semplici

Non è detto. Vedi le istruzioni di load / store multiple registers, ad esempio, che sono presenti in tante architetture RISC.

PowerPC e ARM (sia in modalità ARM che Thumb) sono degli ottimi esempi.

e hardware esposto al compilatore..

Non capisco cosa tu voglia dire. Chi scrive i compilatori in genere è a conoscenza di tutti i dettagli del funzionamento dell'ISA dell'architettura target, e questo vale per QUALUNQUE tipo di processore: poi sta a lui/loro sfruttarne le peculiarità, se possibile.

7)Pipeline a più di 3 stadi.

Anche questo, come l'architettura Harvard, è un mero dettaglio implementativo. Infatti il primo ARM di Acorn, apparso per la prima volta dentro l'Archimedes, aveva una pipeline a soli 3 stadi.

ovvio che l'approccio esposto da questi punti si sia evoluto..ma l'evoluzione successiva è comuqnue partita da qui..e da qui non si è mossa.

Direi proprio di no, invece. I punti base possiamo considerarli soltanto la lunghezza fissa degli opcode, e la presenza delle sole load/store per accedere alla memoria, come avevo già scritto tra l'altro. Il resto è soltanto tecnologia impiegata o un dettaglio implementativo...

Le macroistruzioni che sono rimaste ad essere spezzettate in microoperations non hanno alcun significato a livello progettuale se non quello di semplificare la comunicazione tra progettista ed hw...

Scherziamo? Per un progettista è molto più comodo lavorare con delle "macroistruzioni" (e microcodice) che avere un altro processore all'interno a cui passare una o più istruzioni da eseguire.

Se è stato pensato e realizzato questo approccio è per migliorare le prestazioni globali della CPU. Tant'è che anche IBM con Power 4/PPC970 e Power5 ha seguito la stessa strada: eppure sono dei RISC...

a livello progettuale tutto è partito da quio e da qui si è evoluto e da qui il "vero" CISC è morto.

Morto? A me pare più che vivo... Ha semplicemente cambiato col tempo la sua implementazione, ma è una cosa normalissima...

PS:cache L1,L2,bus nooping,write back etc etc...sono cose macroscopiche a livello progettuale..non sono certo quelle che determinano la differenza tra architetture.

Infatti li ho portati, assieme agli altri, come esempi di TECNOLOGIE sperimentate prima coi RISC e approdate poi ai CISC...

Se si pensa infatti che il Pentium2 è stato il primo processore superscalare commerciale..

Infatti non lo è stato: è stato il Pentium il primo...

eppure conteneva tutti questi elementi..

Elementi che sono stati aggiunti nel tempo: Pentium ha aggiunto soltanto la divisione della cache dati e istruzioni (che comunque Intel non aveva realizzato col 486, mentre Motorola sì col "contemporaneo" 68040) e la superpipeline, e null'altro di tecnologicamente significativo.

senza parlare dell'evoluzione vliw o vettoriale.

Nessuna evoluzione VLIW. Inoltre di vettoriale dentro gli attuali CISC ci sono soltanto le unità SIMD, ma queste sono presente anche nei RISC...

[scorpionkkk]

1)proprio perchè la normale prassi da circa 15 anni è quella di scomporre un ISA completo in microistruzioni non ha senso parlare di opcode di lunghezza variabile come forma distintiva.
2)come ho già detto la progettazione e la minimizzazione del set d'istruzioni comporta la formazione dei cosiddetti "control path" e "data path" che definiscono i segnali di controllo e le risorse per il trattamento dei dati.Da queste entità iniziali di progetto dipende il numero di ALU,di registri di contatori etc etc..insomma di qualsiasi cosa intervenga all'interno del processore.e la cosa diventa ancora più importante in un general purpose.Ecco che quindi il set d'istruzioni condiziona pesantemente il progetto dell'hardwrae e la sua minimizzazione (inutile mettere risorse sottoutilizzate o inutilizzate come troppi moltiplicatori ad esempio che prendono spazio su chip..meglio abbondare ad esempio in addizion atori e registri).
3)gli indirizzamenti complessi di processori "CISC" erano uno dei modi che si aveva per sopperire all'assenza di un approccio RISC e di pipeline strutturate e cercare contemporaneamente di aumentare le prestazioni:erano uno stratagemma non certo un vanto.
Lo stesso tipo di stratagemma è,appunto,stato utilizzato nei DSP che,per problemi storici e di costi non possono sempre permettersi le stesse unità funzionali dei general purpose ma necessitano cmq di indirizzare grandi quantità di vettori in maniera efficace.
4)l'architettura Harvard non è una tecnologia. E' un principio generale di progetto che vede l'unità centrale comunicare contemporaneamente sia con la memoria del programma che con la memoria dei dati. L'architettura precedente (detta diu Von neumann) non aveva questa distinzione e quindi comportava un progetto meno efficace.
5)Tipicamente la MOV,la ST,la ADD,la MUL,la SUB hanno latenze (per calcoli non iterativi) di un ciclo di clock (la MUL solo con unità dedicate però).
la LD tipicamente due/tre cicli,la BR tipicamente dai 3 ai 4 (o anche due a volte)..etc etc.
6)un ISA modellato sulle applicazioni è scelto in modo da avere delle risorse su chip minime pur mantenendo l'efficacia di calcolo.
Ad esempio:non ha senso se si devono fare molte somme/sottrazioni su interi inserire sia sommatori che sottrattori (o segnali di controllo diversi per i sommatori)..mi è più utile eliminare l'istruzione di SUB per simularla con l'istruzione di ADD e l'utilizzo dei registri.
Un altro esempio: A meno che io non voglia una macchina vettoriale è inutile inserie moltiplicatori dedicati su chip e la relativa istruzione..tanto meglio utilizzare uno shifter con cui posso calcolare anche gli spazi d'indirizzamento.
alla fine del progetto quindi l?ISA è minimo e anche le risorse su chip sono minimizzate.
7)Come ho già detto..dalle basi del RISC si è poi partiti per i diversi approcci.Il motivo è abbastanza semplice..tutti gli approcci più evoluti comportano l'utilizzo di tutte le features dei RISC,soprattutto della sua pipeline strutturata..e non avrebbero senso senza.
8)Ribadisco inoltre che le macrositruzioni sono comode per fare ottimizzazione..cosi come è comodo lavorare sui programmi e sul codice(chessò il C del programma) per farle.E' dimostrato infatti che più si va a livello utente e più le ottmizzazioni sono efficaci.questo non toglie però che quando vado a progettare il processore i miei giochi li faccio sulle microoperations e non sul codice macroscopico..e se ho già scelto l'ISA del codice i giochi sono fatti.
9)anche le load/store mR sono istruzioni semplici..
10)"Hw esposto al compilatore" significa ottimizzare l'ISA per le applicazioni da compilare attraverso processi che minimizzino le nooperations (nop) e non sprechino quindi risorse (chessò durante un salto ad esempio).
Di solito quindi si definisce un set d'istruzione e si effettuano varie prove compilando programmi in modo da ottimizzare il set stesso a seconda del programma cone con il loop unrolling o altre mille3mila tecniche.
11)come fa la pipeline ad essere solo un dettaglio implementativo..è il cuore del calcolo e della progettazione..se fai una pipeline diversa hai fatto un progetto diverso.
12)Il processore Pentium è stato il primo ad implementare le microoperations..il primo processore Superscalare,come ho detto,è stato il Pentium2 dove per superscalare si intende la codifica e l'esecuzione di più istruzioni per ciclo..cosa che il Pentium faceva ma a metà visto che la soluzione era implementata con una seconda pipeline indipendente (quindi non era superscalare in maniera completa) che lavorava solo quando ce n'era bisogno (cioè quando una istruzione poteva essere mandata in parallelo) cioè molto raramente
13)quando ho parlato di evoluzioni successive mi riferivo all'approccio supercslare prima,al VLIW poi,al VLIW superscalare,e all'implementazione di approcci special purpose come macchine vettoriali,approcci SIMI e MIMD in macchine general purpose.Che poi sono la realtà degli anni passati a livello architetturale.

[cdimauro]

Originariamente inviato da scorpionkkk

1)proprio perchè la normale prassi da circa 15 anni è quella di scomporre un ISA completo in microistruzioni non ha senso parlare di opcode di lunghezza variabile come forma distintiva.

Non è affatto la normale prassi, visto e considerato che ciò si verifica soltanto con alcuni processori (x86 dal K5 in poi e i POWER & derivati di IBM) e soltanto perché l'obiettivo da raggiungere era un miglioramento generale delle prestazioni.

Inoltre quando elencavi le caratteristiche di una macchina RISC o con approccio RISC hai scritto questo :

"3)formato istruzioni fisso (a livello ultimo)"

Che è chiaramente in contraddizione con quanto hai appena asserito e sul fatto che non abbia senso.

Ha senso, invece, perché non ho mai visto un RISC con opcode a lunghezza variabile e questa caratteristica invece la ritroviamo in tutti i CISC.

2)come ho già detto la progettazione e la minimizzazione del set d'istruzioni comporta la formazione dei cosiddetti "control path" e "data path" che definiscono i segnali di controllo e le risorse per il trattamento dei dati.Da queste entità iniziali di progetto dipende il numero di ALU,di registri di contatori etc etc..insomma di qualsiasi cosa intervenga all'interno del processore.e la cosa diventa ancora più importante in un general purpose.Ecco che quindi il set d'istruzioni condiziona pesantemente il progetto dell'hardwrae e la sua minimizzazione (inutile mettere risorse sottoutilizzate o inutilizzate come troppi moltiplicatori ad esempio che prendono spazio su chip..meglio abbondare ad esempio in addizion atori e registri).

Questo è vero soltanto quando si crea un'architettura completamente nuova.

Infatti il set d'istruzioni degli x86 dal 386 in poi è rimasto sostanzialmente lo stesso (escludendo le estensioni SIMD), ma i cambiamenti all'interno delle varie implementazioni sono stati tantissimi e molto profondi. Non è certo stato riprogettato da capo l'ISA x86 quando si è passati dal 386 al 486, e così via...

3)gli indirizzamenti complessi di processori "CISC" erano uno dei modi che si aveva per sopperire all'assenza di un approccio RISC e di pipeline strutturate e cercare contemporaneamente di aumentare le prestazioni:erano uno stratagemma non certo un vanto.

I CISC e le loro modalità d'indirizzamento esistevano prima ancora che IBM tirasse fuori il primo RISC.

Inoltre la presenza di modalità d'indirizzamento "complesse" non era certo una scelta "di ripiego". Al contrario, sono state aggiunte proprio perché molto comode e permettevano di scrivere codice molto compatto. Caratteristica questa, che è tipica proprio dei CISC.

Esempio:

move.l (a0)+,d0

è una modalità presente nei Motorola 68000 utilissima, usatissima, e sfruttata abbondantemente anche dai compilatori (es: Pippo = *Puntatore++.

Altro esempio:

move eax,[ebx + ecx * 4]

per gli x86 è anche questa una modalità molto usata anche dai compilatori (es: Pippo = VettoreDiInt32[Indice]

Le modalità di indirizzamento sono quindi un vanto delle architetture CISC, proprio perché permettono di scrivere velocemente codice, risparmiando anche spazio.
Al contrario, per realizzare le stesse cose coi RISC sono in genere necessarie più istruzioni e quindi più spazio occupato (e questo incide anche sulle cache).

Infine la struttura della pipeline non c'entra niente: è un dettaglio implementativo che non dipende strettamente dal tipo di architettura.

Lo stesso tipo di stratagemma è,appunto,stato utilizzato nei DSP che,per problemi storici e di costi non possono sempre permettersi le stesse unità funzionali dei general purpose ma necessitano cmq di indirizzare grandi quantità di vettori in maniera efficace.

Più che altro hanno bisogno di manipolare grandi quantità di dati, e per far questo non hanno certo bisogno di modalità d'indirizzamento complesse.
Al contrario, poiché sono progettati per elaborare grossi stream di dati, l'accesso alla memoria è spesso sequenziale (o comunque "localizzata").
Infatti i DSP hanno un design molto semplice.

4)l'architettura Harvard non è una tecnologia. E' un principio generale di progetto che vede l'unità centrale comunicare contemporaneamente sia con la memoria del programma che con la memoria dei dati. L'architettura precedente (detta diu Von neumann) non aveva questa distinzione e quindi comportava un progetto meno efficace.

Infatti l'ho anche chiamata architettura. In ogni caso è assolutamente indipendente dal tipo di architettura, ed è questo ciò che conta in questo contesto.

5)Tipicamente la MOV,la ST,la ADD,la MUL,la SUB hanno latenze (per calcoli non iterativi) di un ciclo di clock (la MUL solo con unità dedicate però).
la LD tipicamente due/tre cicli,la BR tipicamente dai 3 ai 4 (o anche due a volte)..etc etc.

Questi dati dove li hai presi? Link?

RISC diversi hanno valori diversi, e tante volte vale anche per quelli che appartengono alla stessa famiglia.

6)un ISA modellato sulle applicazioni è scelto in modo da avere delle risorse su chip minime pur mantenendo l'efficacia di calcolo.
Ad esempio:non ha senso se si devono fare molte somme/sottrazioni su interi inserire sia sommatori che sottrattori (o segnali di controllo diversi per i sommatori)..mi è più utile eliminare l'istruzione di SUB per simularla con l'istruzione di ADD e l'utilizzo dei registri.
Un altro esempio: A meno che io non voglia una macchina vettoriale è inutile inserie moltiplicatori dedicati su chip e la relativa istruzione..tanto meglio utilizzare uno shifter con cui posso calcolare anche gli spazi d'indirizzamento.
alla fine del progetto quindi l?ISA è minimo e anche le risorse su chip sono minimizzate.

Questo, come ho già detto, capita soltanto quando si progettano delle architetture nuove. Anzi, quando capitava, visto che da parecchi anni a questa parte i RISC non hanno certo un set d'istruzioni "ridotto", ma molto ampio e da questo punto di vista in competizione con quello di tanti CISC.

7)Come ho già detto..dalle basi del RISC si è poi partiti per i diversi approcci.Il motivo è abbastanza semplice..tutti gli approcci più evoluti comportano l'utilizzo di tutte le features dei RISC,soprattutto della sua pipeline strutturata..e non avrebbero senso senza.

Quelle che hai elencato non sono tutte caratteristiche intrinseche dei RISC: per lo più si tratta di tecnologie che possono essere impiegate nell'implementazione delle architetture più disparate. Infatti le ritroviamo anche in tanti CISC.

Inoltre, come ho già detto, la struttura della pipeline non è strettamente legata al tipo di architettura. Infatti quella dei processori x86 ha subito notevoli e profonde modifiche col passare del tempo. Ma sempre CISC sono rimasti.

8)Ribadisco inoltre che le macrositruzioni sono comode per fare ottimizzazione..cosi come è comodo lavorare sui programmi e sul codice(chessò il C del programma) per farle.E' dimostrato infatti che più si va a livello utente e più le ottmizzazioni sono efficaci.

Non mi è chiaro: potresti spiegarti meglio, cortesemente?

questo non toglie però che quando vado a progettare il processore i miei giochi li faccio sulle microoperations e non sul codice macroscopico..e se ho già scelto l'ISA del codice i giochi sono fatti.

Appunto, l'ISA di un progetto non la puoi mica stravolgere: cambi soltanto la sua implementazione. E' quel che avvenuto sia coi RISC sia coi CISC. Basta prendere come riferimento le famiglia PowerPC e x86 rispettivamente, ad esempio.

9)anche le load/store mR sono istruzioni semplici..

Più semplici di una move, add, ecc. sicuramente no.

10)"Hw esposto al compilatore" significa ottimizzare l'ISA per le applicazioni da compilare attraverso processi che minimizzino le nooperations (nop) e non sprechino quindi risorse (chessò durante un salto ad esempio).
Di solito quindi si definisce un set d'istruzione e si effettuano varie prove compilando programmi in modo da ottimizzare il set stesso a seconda del programma cone con il loop unrolling o altre mille3mila tecniche.

Ma questo, appunto, si verifica soltanto quando si progetta una nuova architettura. E neanche tanto, visto che esistono tantissime tipologie di codice, anche all'interno della stessa applicazione; infatti difficilmente i processori hanno degli obiettivi talmente specializzati da rimuovere, ad esempio, l'istruzione SUB. Ha molto più senso quando si progetta un DSP per scopi specifici.

Quello dello spreco delle risorse è un problema più che altro dei processori VLIW (ed EPIC / Itanium).

11)come fa la pipeline ad essere solo un dettaglio implementativo..è il cuore del calcolo e della progettazione..se fai una pipeline diversa hai fatto un progetto diverso.

Hai fatto un'implementazione diversa dello stessa architettura, per essere precisi. Vedi ad esempio le differenze fra G3 e G4, che condividono la stessa ISA, ma che internamente sono implementati in maniera molto diversa.

12)Il processore Pentium è stato il primo ad implementare le microoperations..

No, è stato il K5 di AMD, come ho già detto.

il primo processore Superscalare,come ho detto,è stato il Pentium2 dove per superscalare si intende la codifica e l'esecuzione di più istruzioni per ciclo..

Questa è la definizione classica è quindi il Pentium ci rientra perfettamente.

cosa che il Pentium faceva ma a metà visto che la soluzione era implementata con una seconda pipeline indipendente (quindi non era superscalare in maniera completa) che lavorava solo quando ce n'era bisogno (cioè quando una istruzione poteva essere mandata in parallelo) cioè molto raramente

Che è praticamente il modo di lavorare delle architetture con superpipeline: le istruzioni seguenti alla prima vengono eseguite soltanto quando ci sono le condizioni.

Infatti Pentium aveva delle restrizioni sul tipo e l'ordine delle due istruzioni che poteva eseguire, né più né meno di qualunque processore con superpipeline.
Ad esempio PPC970 può eseguire 2 istruzioni intere, ma mica può farlo sempre: dipende dal tipo di istruzione e da eventuali conflitti.

13)quando ho parlato di evoluzioni successive mi riferivo all'approccio supercslare prima,al VLIW poi,al VLIW superscalare,e all'implementazione di approcci special purpose come macchine vettoriali,approcci SIMI e MIMD in macchine general purpose.Che poi sono la realtà degli anni passati a livello architetturale.

Gli x86 hanno avuto l'approccio superscalare prima, e poi l'uso di unità RISC-like (che era sempre superscalare). Nient'altro.
Se per approccio VLIW intendi quest'ultimo caso, allora ok, anche se non è corretto come termine, visto e considerato che tutt'oggi esistono ancora tante istruzione che vengono eseguite tramite microcodice...

[scorpionkkk]

1) Non c'è nessuna contraddizione...quando si progetta il set d'istruzioni non è definito finchè non è ottimizzato e le procedure di ottimizzazioni sono antecedenti al progetto del data path.

2)è ovvio che stiamo parlando di progettazione "full custom" visto che si parla dell'intera architettura.

3)E' risaputo che modalità d'indirizzamento complesse possono essere un vanatggio in alcune tipologie di calcolo ma non è questo il punto.
Le modalità d'indirizzamento usate nei CISC e nei DSP sono una soluzione a problemi diversi.
nei DSP servono ad un'analisi vettoriale completa non possibile con le macchine general purpose...nei CISC sopperivano alla mancanza di registri strutturati all'interno degli stadi delle (piccole) pipeline usate e sopperivano all'assenza degli stadi di interfaccia con la memoria più alti inseriti nella pipeline solo dall'approccio RISC.

4)i DSP non hanno bisogno di strutture d'indirizzamento ma utilizzano un algortimo sequenziale?
Da dove viene questa idea?
Storicamente è l'esatto contrario ed è proprio questo che distacca i DSP da eventuali architetture RISC.
Le strutture d'indirizzamento più usate sono:

• incremento circolare
• bit reversed (per il calcolo della FFT)
• reversed
• crossed (tra registri)

nessun DSP avrebbe le prestazioni che può ottenere se avesse solo indirizzamenti sequenziali dei vettori.

5)L'architettura indipendente dal tipo di architettura?
Ho capito ciò che vuoi dire...ma in realtà quella non si chiama architettura..ma semplicemente implementazione RTL che poi è il livello al quale si progettano i sistemi su processore a livello superiore a quello logico.

6)Nessun link...libri di microelettronica ed esperienza di progettazione...occhio che si parla di microoperations non di macroistruzioni.
Un esempio: la ADD(R2,R1) nel primo pentium(anzi nel pentium mmx) veniva spezzata in
load_aluop (R1)
load_aluop (R2)
add
store (R2) alures
quindi mi riferisco a queste ultime altrimenti che architettura risc sarebbe?

7)La distinzione tra tecnologie e architetture non ha senso.
Le architetture sono caratterizzate da tecnologie.
Le architetture self timed ad esempio sono caratterizzate dall'introduione di tecnologie self timed...adesso non posso andare da philips e dirle che i chip che mette nelle macchinette fotografiche non sono self timed ma sono CISC con una tecnologia self timed.
E cmq hennesy e Patterson parlarono chiaro al tempo sottolineando le caratteristiche della loro architettura nel RISC (il primo processore RISC si chiamava RISC).

8)Come ho detto..quando si progetta un processore si cerca di ottimizzarne l'hardware e quindi l'ISA a seconda delle applicazioni che dovranno girare su chip.E' dimostrato che la curva di ottimizzazione aumenta man mano che aumenta il livello in cui si fanno le ottimizzazioni.
Ad esempio: se io ottimizzo i miei transistor inserendone altri con caratteristiche e layout migliori l'ottimizzazione conseguente sarà limitata.
Se invece ottimizzo direttamente il codice del programma posso anche avere incrementi del 200%/300% nello Speed up di esecuzione.
Sembra una cosa ovvia..ma non lo è.

9)Ovvio che l'ISA non può essere cambiato DOPO la progettazione e l'ottimizzazione.Il piccolo particolare è che l?ISA di un CISC è completamente diverso dall'ISA di un RISC..e,visto che dall'ISA dipendono i data path e quindi la struttura delle risorse che devo mettere sul processore cosi come i segnali di controllo..i miei due processori saranno completamente diversi.
Non solo avranno data path diversissimi (il che potrebbe far gridare solo ad una differenza d'implementazione) ma anche control path diversi (più semplice quello del RISC) e quindi una architettura finale molto diversa.

10)Non è una gara di semplicità tra istruzioni.Dipende dal livello a cui operano.
SUB (R2,R1) è una istruzione complessa..load (R2) è una istruzione semplice...alusub è una istruzione semplice.E' il livello che garantisce la semplicità.

11)3 libri su 8 mi dicono pentium (gli altri non ne parlano)..non so che dire.

12)stiamo parlando di architetture..e quindi bisogna ddentrarsi nell'architettura in toto senza dare nulla per scontato proprio per carpirne le differenze.
Altrimenti è facile mettersi lì e bypassare qualsiasi problema usando il core relativo alla FPU,quello relativo all'unità di BP e cosi via...

13)ho capito che ci rientra..ma stiamo parlando di oggetti che funzionano e il Pentium da questo punto di vista funzionava poco e male...tra l'altro l'utilizzo di due pipeline è anche una soluzione di ripiego.

14)Come ho detto questa è una visione macroscopica.In realtà l'approccio superscalare mira ad avere entità interdipendenti tra loro per aumentare il parallelismo..mentre l'approccio del Pentium era quello di avere unità indipendenti tra di loro.
Pipeline dipendenti tra di loro non solo diminuiscono le noP dopo i salti,aumentano il parallelismo,diminuiscono i vincoli strutturali e quelli di RaW,WaW e WaR ma realizzano meglio la logica moderna con cui viene strutturata un'architettura superscalare:le Reservation stations.
Inoltre nel Pentium,per tanti motivi,non sfruttava appieno l'algortimo di Tomasulo e quindi aveva un basso livello di parallelismo.

15)Gli x86 non possono avere avuto un approccio superscalare antecedente ad unità RISC like semplicemente per il fatto che per avere un approccio superscalare è necessaria una pipeline strutturata e quindi un approccio RISC.
Senza questo approccio non solo è impossibile utilizzare le implementazioni tipiche come issue window+renamin o reservation stations..ma si hanno problemi anche con i vincoli strutturali e tutto il resto...
Certo..si potrebbero mettere pipeline non strutturate in parallelo..ma sarebbe come far correre una Renault5 GT nella F1...

[Fx]

io volevo solo dire:

quoto xeal su entrambi i post

[scorpionkkk]

Originariamente inviato da Fx

io volevo solo dire:

quoto xeal su entrambi i post

ehehehe..si..è meglio finirla cò sti post chilometrici che annoiano chi legge e uccidono chi scrive

[mjordan]

Originariamente inviato da ripper71

dai, dai, che siamo impazienti di vedere i primi apple / intel........

Io sinceramente non sono gran che entusiasta

[mjordan]

Originariamente inviato da LucaTortuga

Apple non fa concorrenza nè a Dell nè tantomeno ad HP.. Nessun potenziale loro acquirente deciderebbe mai di comprare un Mac solo perchè monta un processore più nuovo. E non vale nemmeno il discorso OEM: se anche Intel concedesse ad Apple di usare i suoi processori migliori 3 mesi prima, cosa cambierebbe? Qualcuno immagina orde di smanettoni svaligiare gli Apple Store per acquistare un Powerbook, sventrarlo ed estrarne il prezioso Merom? Tutto si riduce ad una valutazione di fattibilità pratica, ed è più logico pensare che Intel, produzione permettendo, farà in modo di accontentare il buon vecchio Steve. Nessuno sa fare promozione come lui, già lo sento strillare al miracolo del processore piùùùùùù velocissimo dell'universo, con un marchio Intel ben in evidenza alle sue spalle...

Già è vero... Jobs quando parla pare pure simpatico....

[cdimauro]

A me questo tipo di post non annoiano: se c'è qualcun altro interessato, possiamo continuare su un altro thread...

[xeal]

Se lo aprite, posta il link, sicuramente sono interessato a leggere la continuazione della discussione

[cdimauro]

La discussione continua qui per chi fosse interessato...

[repne scasb]

Originariamente inviato da TheZeb

ma sono cpu x86 o risc ??

Trattasi di CRISC (Complex Reducible Instruction Set Computer).

[cdimauro]

Sono CPU x86, e quindi CISC.

[repne scasb]

Originariamente inviato da cdimauro

Sono CPU x86, e quindi CISC.

Intel definisce CRISC le CPU di classe P5 o superiore nel proprio documento IDC-22078 (Intel Confidential Document) del 22 Marzo 1993.

Potresti pero' aver ragione tu e torto Intel. Per fargli notare l'errore puoi scrivere a:

Intel Corporation
2200 Mission College Blvd.
Santa Clara, CA 95052
USA

[cdimauro]

Se è per questo, Intel definisce la "sua" (come ha affermato un suo manager ) estensione a 64 bit EM64T e spaccia come caratteristica quella di permettere accedere a più di 4GB di memoria per applicazione, "dimenticandosi" tutto il resto...

[xeal]

Comunque, il termine CRISC non è proprio da buttar via: suggerisce l'idea di un ibrido tra le due filosofie nel tentativo di unirne i pregi, che è il modo in cui mi piace pensare ai moderni CISC.

L'ISA, nel suo complesso, mi piace pensarla come CISC (non voglio uscire dal campo delle mie opinioni personali, nell'esporre il mio pensiero, perchè non ho la competenza necessaria per presentarle come una visione obiettiva e definitiva: mi limito a concordare con la "visione CISC" ), poichè le caratteristiche dell'instructin set sono quelle di un CISC e determinano il modo in cui il processore viene visto e trattato dall'esterno: il modo in cui verrà programmato, la cache dovrà essere gestita, ecc. - la conoscenza dell'implementazione interna, a mio avviso, può determinare un diverso riordino delle istruzioni o la scelta di workaround per evitare di incappare nell'esecuzione del microcodice, ma non, in generale, a uno stravolgimento totale nelle scelte inerenti la programmazione e l'ottimizzazione del codice: in generale, penso più a una influenza sulle scelte effettuate, scelte comunque possibili e valide a prescindere (le istruzioni e i possibili algoritmi sempre quelli sono), ma che possono assumere un diverso rilievo in un diverso contesto: dettagli su cui giocare per lavorare di fino, insomma, piuttosto che una "condicio sine qua non".

Di conseguenza, volendo assumere come punto di partenza nella progettazione l'idea suggerita in precedenza di un'ISA basata sulle applicazioni e un hardware esposto al compilatore, ritengo che l'instruction set x86, con le sue caratteristiche di "complessità", opcode a lunghezza variabile, ecc., non possa che essere la base imprescindibile nella progettazione dell'architettura interna, pur prevedendo, questa, un'implementazione RISC-like: ben più di una interfaccia "macroscopica", magari con funzioni di retrocompatibilità, come si potrebbe pensare dando troppo risalto alle caratteristiche RISC dell'implementazione interna. Tuttavia, proprio l'implementazione interna fa da "ponte" verso un instruction set ridotto e un'architettura "simil-RISC" che ha la sua importanza, pur non avendo ragion d'essere al di fuori del suo contesto: l'implementazione e l'esecuzione ottimizzata e veloce delle istruzioni x86 (mi piace molto il termine RISC-86, in riferimento ad una unità d'esecuzione RISC di per sé, ma creata e ottimizzata sulla base delle esigenze specifiche dell'ISA x86 da implementare: chi lo ha coniato?).

In questo senso, non mi dispiace il termine "CRISC", come tipologia implementativa o comunque variante in seno alla famiglia dei CISC che abbraccia in parte la filosofia RISC per trarre il meglio di entrambe. Un appunto: se R sta per Reducible può suggerire l'idea di una qualche modifica all'instruction set per farlo si rimanere di tipo "complex", ma al contempo renderlo, per l'appunto, "riducibile", sacrificando qualche istruzione o modificando in qualche modo l'opcode, o in qualunque altro modo, per facilitarne la "riduzione": che io sappia, nulla di tutto ciò è avvenuto, il tutto si riduce all'implementazione dell'architettura, o sbaglio? Personalmente troverei forse più attinente parlare di "Complex-to-Reduced Instruction Set Computer" - sperando di non fare pasticci con l'Inglese (ok, sto cercando il pelo nell'uovo ).

Quanto a EM64T, beh, se c'è di mezzo il marketing ogni verità diventa opinabile... [acid-avoidable-mode on] poi, magari, l'indirizzamento è l'aspetto che hanno implementato meglio di AMD64 e fanno bene a metterlo in risalto, anche nel nome [acid-avoidable-mode off]

X repne scasb

Qualche tempo fa dicevi che negli A64 in modalità 64 bit è possibile che si manifesti un miglior riordino delle istruzioni e che l'uso di istruzioni "miste", in dipendenza delle dimensioni effettive dei dati contenuiti nei registri, o dei registri effettivamente utilizzati, potrebbe non portare ad un decadimento nelle prestazioni e anzi migliorarle, in alcuni casi: hai avuto altri riscontri in merito?

[xeal]

mamma mia quanto ho scritto, e io che speravo di non essere prolisso una volta tanto

forse avrei quel post starebbe meglio nell'altro thread, ma visto che l'argomento prosegue anche qui... magari con i prossimi, se ce ne saranno, ci spostiamo definitivamente la, che dite?

[repne scasb]

Originariamente inviato da cdimauro

Se è per questo, Intel definisce la "sua" (come ha affermato un suo manager ) estensione a 64 bit EM64T e spaccia come caratteristica quella di permettere accedere a più di 4GB di memoria per applicazione, "dimenticandosi" tutto il resto...

Questo e' vero. Ci sarebbe d'aggiungere pero' che quando Intel presenta la documentazione per gli sviluppatori, non tenta di nascondersi dietro un dito. Ti cito per completezza due documenti esemplificativi:

ID: 30083401 - 64-Bit Extension Technology Software Developer’s Guide Volume 1

ID:30083501 - 64-Bit Extension Technology Software Developer’s Guide Volume 2

utili per valutare anche le eventuali differenze rispetto al "modello" AMD64.

Originariamente inviato da xeal

Qualche tempo fa dicevi che negli A64 in modalità 64 bit è possibile che si manifesti un miglior riordino delle istruzioni e che l'uso di istruzioni "miste", in dipendenza delle dimensioni effettive dei dati contenuiti nei registri, o dei registri effettivamente utilizzati, potrebbe non portare ad un decadimento nelle prestazioni e anzi migliorarle, in alcuni casi: hai avuto altri riscontri in merito?

No, in quanto il mio compilatore C-- e' in una fase di stallo per mancanza di tempo, e per tale motivo non sono stata in grado di testare il comportamente di codice mixed (8-16-32-64 bit) generato dal mio compilatore.

---------------------------------------

Un ultima annotazione sul termine Reducible: se ne parla solo nel documento confidenziale da me sopracitato, senza mai ritornare sull'argomento da parte di Intel. Non ho la piu' pallida idea di cosa volesse intendere Intel con il termine reducible nel 1993 a proposito del Pentium(P5).