RISC e CISC

[cdimauro]

Questa discussione segue da un'altra iniziata nella sezione delle news, esattamente qui: http://www.hwupgrade.it/forum/showth...1024834&page=3

Originariamente inviato da 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.

La contraddizione sta nel fatto che sostieni sia che gli opcode a lunghezza variabile non sono rilevanti nella classificazione dell'architettura CISC sia che gli opcode a lunghezza fissa sono un elemento rilevante nella classificazione di un processore come RISC.

Per me (e non credo di essere il solo; oltre al fatto che la storia lo conferma) l'utilizzo di opcode a lunghezza variabile o fissa è un chiaro elemento distintivo della tipologia di architettura CISC o RISC.

Per il resto, quando si è progettato 8086 e successori, non era certo prevedibile che vent'anni dopo si sarebbe utilizzato un approccio RISC-like (per ALCUNI processori x86) per velocizzar l'esecuzione del codice.

3)E' risaputo che modalità d'indirizzamento complesse possono essere un vanatggio in alcune tipologie di calcolo ma non è questo il punto.

E' risaputo, ma allora perché non compaiono anche nei RISC?

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

Cioé?

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.

La struttura della pipeline IMHO non c'entra niente con ciò: non vedo come potrebbe condizionare l'utilizzo di una modalità d'indirizzamento più o meno complicata.
Infatti anche i più vecchi processori CISC avevano una sorta di pipeline (più che altro per ottimizzare le fasi di fetch-decode-execute). Per il resto, un processore poteva avere modalità molto semplici (vedi 6800, ad esempio) o molto complicate (vedi, ad esempio, Motorola 68020+: a dir poco mostruose).

Anche la mancanza di registri è abbastanza opinabile: può andar ben per giustificare processori come il 6502 (3 a 8 bit), ma non per processori come lo Z80 (8 + 8 a 8 bit e 2 di indice a 16 bit) o meglio ancora il 68000 che era dotato di ben 16 registri (e ti assicuro che non mai sentito la necessità di averne di più ).

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.

Ma infatti avevo correttamente scritto questo:

"Al contrario, poiché sono progettati per elaborare grossi stream di dati, l'accesso alla memoria è spesso sequenziale (o comunque "localizzata")."

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.

Benissimo. L'importante è che ci siamo capiti...

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?

Anche considerando le microoperazioni, le latenze (e il throughput, che è un altro valore molto importante) dipendono sempre dall'implementazione, non dal fatto che un processore è un RISC. Non è affatto detto che una Load richieda 2 o 3 cicli di clock, un Branch 2, 3 o 4, ecc. Ad esempio nei processori Power di IBM le istruzioni di branch non vengono inserite nel flusso delle istruzioni da eseguire, ma vengono "intercettate" prima (è come se non fossero delle istruzioni vere e proprio dal punto di vista delle unità di esecuzione), e hanno una latenza di 8 o 12 (adesso non ricordo bene) cicli di clock.

Per quanto riguarda l'esempio che hai fatto, se per microoperazioni intendi quelle eseguite dal microcodice del Pentium (anche MMX), OK, perché questo processore non aveva ancora un'unità d'esecuzione RISC-like.

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

Le architetture sono caratterizzate da tecnologie utilizzate. Non sono le tecnologie a determinare la tipologia di architettura: è questo il concetto a cui voglio arrivare.

Ad esempio fino a Pentium di Intel e al 68060 di Motorola, questi processori CISC hanno utilizzato diverse tecnologie che sono prima MATURATE in ambito RISC. Ma ciò non vuol dire che il loro semplice utilizzo le abbia fatte diventare RISC.

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.

Benissimo. E questo non basta per dimostrare che un x86 moderno, anche se utilizza un approccio RISC-like per l'esecuzione delle istruzioni, rimane comunque un CISC, visto che l'ISA è rimasto lo stesso ed è questo che determina in ultima istanza la struttura interna del processore?

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

Dico che dovrebbero aggiornarsi, perché la storia è quella.

Poi che per certi esperti esista soltanto Intel e trascurino AMD (o altre società che operano nel settore dei processori) può solo dispiacere perché producono delle false informazioni.

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

Scusami, ma non riesco ad afferrare il concetto che vuoi esprimere. Potresti essere più chiaro? Magari utilizzando il quote, in modo da "aggangiare" la parte del discorso a cui ti riferivi...

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

Io ricordo che funzionava piuttosto bene. Funzionava male all'inizio perché il codice non era pensato per sfruttare al meglio la presenza delle due pipeline. Infatti poco tempo la sua introduzione arrivarono i primi compilatori che facevano un buon lavoro da questo punto di vista.
Intel stessa fu parecchio prodiga nel fornire documentazione su come ottimizzare il codice per Pentium. Tant'è che i programmatori più esperti che lavoravano in assembly x86 cambiarono radicalmente la scrittura del loro codice, rendendolo anche UN POCHINO incomprensibile...

tra l'altro l'utilizzo di due pipeline è anche una soluzione di ripiego.

Perché? Tanti RISC realizzati in quel tempo avevano due pipeline di esecuzione. Non si poteva mica aumentare il numero di pipeline a dismisura: la tecnologia era pur sempre quella, e il numero di transistor da infilare in un die era di qualche milione (una quisquilia in confronto ad oggi ).

Tra l'altro, a 15 anni di distanza, notiamo che gli x86 moderni sono in grado di eseguire al più 3 istruzioni per ciclo di clock: se non si è sentito il bisogno di aumentarne il numero, qualche motivo ci dovrà pur essere...

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.

Questo dipende anche dal tipo di architettura: come approccio è molto importante per le architetture VLIW (le NOP sono particolarmente deleterie: Intel con Itanium e Transmeta con Efficeon ne sanno qualcosa ), ma meno per i RISC "classici" o i CISC, che possono contare sull'esecuzione di codice fuori ordine.

Comunque nei Pentium le unità non potevano essere indipendenti. Al contrario, l'esecuzione contemporanea di due istruzioni aveva una forte dipendenza derivante sia dal tipo di istruzioni (la seconda pipeline era più semplice della prima) sia da eventuali risultati necessari (il classico problema del produttore / consumatore).

Inoltre nel Pentium,per tanti motivi,non sfruttava appieno l'algortimo di Tomasulo e quindi aveva un basso livello di parallelismo.

Non conosco quest'algoritmo: potresti accennarlo a grandi linee?

Comunque scrivendo codice "pensato" per Pentium, si ottenevano comunque ottimi risultati.

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.

Potresti chiarire cosa intendi per "pipeline strutturata"?

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

Questo dipende comunque da come si pensa di implementare un'architettura. Ad esempio G4 e G5 hanno un approccio molto diverso fra di loro, eppure sono dei RISC e per giunta della stessa famiglia... Il P4 ne ha un altro ancora.