Guarda che il ciclo fetch-decode-execute vale anche per le architetture RISC, la CU controlla ogni istruzione e setta il datapath di conseguenza, senza questa fase come fai ad settare la alu per eseguire un'operazione logico/matematica anziché un'altra e tutti gli altri segnali di controllo...

Il problema della branch prediction purtroppo difficilmente si risolverà nella sua totalità, serve uno stravolgimento delle architetture ad oggi esistenti...

Detto ciò anch'io sono per le architetture RISC, più facili da progettare ed implementare ed a parità di costo escono bestie di processori, amd64 deve essere superata non possiamo rimanere ancorati a questa architettura per sempre, tralaltro l'assurdità è che alcune architetture CISC(nei processori intel avviene) traducono le varie istruzioni CISC in microistruzioni RISC-like...

sbagli nel fatto che questa cosa: "Le istruzioni RISC non hanno la fase di DECODE" non è vera. Il decode lo devi comunque fare. Come faresti a prendere gli operandi altrimenti? Per magia?
Oltretutto anche questa constatazione " sono lunghe tutte uguali, quindi non serve sapere quale istruzioni vengono eseguite dopo se sono tutte lunghe uguali." è falsa. Le architetture moderne sono superscalari e lanciano più istruzioni nello stesso ciclo di clock. Senza contare che un'istruzione attraversa diversi stadi della pipeline prima di essere completata, quindi ti ritrovi con N istruzioni in esecuzione tutte assieme in step diversi. Sapere quale istruzione viene dopo è fondamentale per no sprecare cicli inutilmente su tutte le architetture e indipendentemente dall'IS.

esempio:

immagina di avere questo codice (a caso):

a = 14
b = 4
c = b - a

for (;a-b>0;)
a = a-1
b = b + 1

a = c-b
b = b*6

write (a+b)

che si traduce in:

a = add(0,1)
b = add(0,4)
c = sub(a,b)
blez(label della riga sotto al for)
a = add(a,1)
b = add(b,1)
c = sub(a,b)
bgz(label della riga a=add(a,1))

a = sub(c,b)
...

immagina ora di essere a bgz(label della riga a=add(a,1)) e di dover decidere la prossima istruzione da eseguire. COsa fai? esegui a = sub(c,b) oppure segui il for ed esegui a = add(a,1) ??
A decidere quale istruzione eseguire ci pensa l'unità di branch prediction. Ad esempio, col branch prediction di tipo "branch always taken" tu fai sempre il jump alla label e consideri sempre giusta l'esecuzione del ciclo per un certo numero di volte. Ovviamente all'ultima esecuzione sbaglierai ma tutte le alte saranno giuste. Metti che hai un ciclo di 100 volte, ne sbaglierai solo 1.
Se invece tu arrivato a bgz(label della riga a=add(a,1)) dovessi decidere per "branch always not taken" cercheresti tutte le volte di caricare l'istruzione a = sub(c,b). Su un ciclo di 100 volte sbaglieresti 99 e per 99 volte dovresti pulire la pipeline (perchè quando ti accorgi di aver sbagliato l'istruzione sbagliata è già inserita nella pipeline. Se ci sono dipendenze si aspetta).
La lunghezza non c'entra una fava e come ti ho detto, anche Intel gira in RISC da una ventina d'anni almeno.

Le istruzioni RISC non hanno la fase di DECODE perchè sono lunghe tutte uguali, quindi non serve sapere quale istruzioni vengono eseguite dopo se sono tutte lunghe uguali.
Quindi questo ci porta a una maggiore efficienza rispetto a un CISC.

Se sbaglio, dove sbaglio?

e allora!
RISC e CISC non c'entrano assolutamente nulla con l'unità di branch prediction, ossia ciò che determina quale istruzione eseguire dopo un salto (salto = ritorno alla prima istruzione di un ciclo, scelta del ramo if-else, chiamata a funzione ecc.). Se non riesci a prevedere in tempo a quale istruzione saltare rischi di avere in pipeline istruzioni che non devi eseguire e sei costretto a farne il flush. Il risultato è una perdita di tempo (e di prestazioni) e la necessità di caricare di nuovo le istruzioni giuste (se le avessi predette giuste all'inizio non avresti perso tempo a fare il flush e tutto il resto).
Per fare ciò si usano degli algoritmi di branch prediction. Sono segreti industriali per cui salvo gli esempi storici più banali non trovi, ma comunque ti danno un'idea-
Il problema con spectre e meltdown è che questi algoritmi non facevano differenza tra istruzioni privilegiate e non privilegiate, generando dei leak sfruttabili.
Siccome questi algoritmi sono su per giù comuni a tutti i produttori di CPU (o fai così o fai così, non c'è altra scelta), TUTTI hanno avuto il problema, compresa ARM e tutti gli altri RISC che vuoi.
Che poi, Intel gira in RISC da un sacco di tempo e salvo che tu non stia eseguendo codice compilato negli anni 80 la parte CISC non la usi mai (ma proprio mai).
Tu eri scettico su 'sta cosa, dimmi tu se non stavi opinando =)

Non opiniamo, piccolo cervo.

no, non è come voglio. E' così, fine. Non è opinabile

Come vuoi.

non c'entra assolutamente niente

Mannaggia!

Non mi accontento.
Ma sono obbligato la scheda video del portatile si é rotto e non si può riparare senza cambiare la scheda madre

Magari

Non comprare ora un processore non ti conviene. Non si può sapere se in futuro siamo "obbligati" a cambiare PC per colpa di questa falla maledetta. Io ho un PC portatile con un i3 330m non sono sicuro del 330m ma dopo la patch era diventato un catorcio lento solo ad avviare windows 7

Ti domando seriamente se conosci la differenza sostanziale tra le due architetture.

Se ti accontenti di un nucleo solo.

No.

Il mio AMD Duron Processor del 2003 non é vulnerabile per fortuna

L'unico senso logico è "la costrizione"... visto che quelle in commercio e per adesso quelle di prossima uscita sono tutte bucate :-(
ahime

Dalla padella nella brace. Come buttare nel cesso un buon lavoro fatto dagli ingegneri di Google. Ma che senso ha pagare a prezzo pieno una CPU che sai che è bucata?!

E forse AMD un lo più protetta. Mi sembra

Mi sa anche con i prossimi...se non ho capito male

Boh, mi servirebbe una CPU, ma a questo punto non so più che fare. Aspetto la prossima generazione?

Deprezziamo tutte le CPU di ultimissa generazione fallate!
I9 pleny-core a 50€ !

E dove l'hai visto, nei fondi del caffè ?

Non c'entra nulla RISC, CISC o ibrido. E' proprio come vengono gestiti i dati. Quindi tutte le cpu fin qui costruite sono potenzialmente insicure.

Io vedo solo che in realtà una architettura Risc risolverebbe per sempre il problema.
Ma lasciamolo decidere ai cervelloni.

i vari spectre non vanno a "leggere" i dati delle esecuzioni speculative ma ne estrapolano i dati analizzando le latenze esecutive - non mi e' chiaro come spostare i dati aiuterebbe

no, hanno semplicemente creato un altro problema piu grosso

Povero fantasmino, lo hanno ingabbiato

E io che speravo di trovare una cpu a poco

gli ingegneri Intel hanno riconosciuto che la prossima architettura dei processori renderà inefficace Retpoline

quindi non solo non sanno ancora come risolvere il problema, ma ne impediscono anche la migliore soluzione attualmente esistente?