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