Un chip RISC-V promette di demolire Apple M1. Ecco chi c'è dietro e di cosa si tratta

[cdimauro]

Originariamente inviato da LMCH

Perchè anche se le ALU dei Pentium 4 giravano al doppio del clock, ricevevano una singola microistruzione per ciclo di clock che agiva su un singolo registro.
Se ricordo bene, il vantaggio che davano era in termini di area e di riduzione del clock skew nell'ALU.

OK. Purtroppo non ricordo più questi dettagli.

E' un costo che si fa sentire a livello di complessità di implementazione

Sì, ma bisogna vedere anche quanto.

Posto che il costo per decodificare un'istruzione di load/store con quelle modalità di istruzioni sia fisso, non andresti certo a duplicarlo per ogni istruzione facente accesso alla memoria.

e del maggior numero di interdipendenze per microistruzione

Ma il vantaggio è proprio che non ci sono interdipendenze fra microistruzioni.

(a meno che non la si scomponga in due microistruzioni, vanificando l'effettivo vantaggio in termini di prestazioni finali).

L'esecuzione out-of-order non è magica, aiuta tantissimo ma più di tanto non può fare.

Però è proprio in questi casi che fa tantissimo.

Basta pensare che ad esempio è possibile implementare delle stack machine con esecuzione out-of-order in teoria fantastiche come compattezza del codice, ma che poi stressano parecchio le unità di load/store.

Vero, ma proprio perché fanno continuo riferimento alla memoria. Non è certo il caso di cui stiamo parlando adesso.

Infatti nel nostro caso le unità di load/store vengono stressate soltanto quando non si hanno abbastanza registri a disposizione, e il compilatore è costretto a salvare e ripristinare i registri su/dallo stack.

Ma è più frequente schedularle "più distanti", guadagnando cicli di clock utili.

Guardati quei frammenti di codice, e poi ne riparliamo.

Difatti in un sacco di applicazioni si usano ancora architetture in-order in cui ha più senso un Risc che un x86 proprio perchè si possono ottenere buone prestazioni con un implementazione relativamente semplice.

Dipende da cosa si intende per "equivalenti", stesso processo produttivo e stesso numero di gate ? E quanto potevano rispettivamente salire di clock ?

Ne abbiamo parlato nell'altro thread in cui c'erano a confronto l'Atom in-order e i Cortex in-order e out-of-order.

Numeri alla mano, non c'è proprio storia a livello prestazionale: le soluzioni CISC in-order obliterano quelle RISC in-order, e sono persino competitive con quelle OoO "low/mid-end".

Quello che cambia è il costo di tale retrocompatibilità.
ARM A32 non aveva vincoli di retrocompatibilità quando è nato e come formato delle istruzioni era semplice e regolare, mentre l' 80386 doveva essere retrocompatibile con l' 80286 che a sua volta doveva essere retrocompatibile con l'8086

Ma non cambia di una virgola la questione.

Il punto è x86-64 e AArch64 sono modalità di esecuzione a 64 bit AGGIUNTIVE a quelle a 32-bit delle rispettive famiglie, che funzionano diversamente e richiedono anche decoder diversi.

Questo è esplicitato proprio con x86-64, che chiama Long Mode la modalità nativa a 64 bit, e "Compatibility / legacy" mode tutto il resto (che da tanti anni a questa parte vuol dire soltanto modalità protetta a 32-bit).

Qualunque sia il legacy che si portano dietro (e anche ARM a 32-bit ne ha tanto), il concetto è che per entrambe le famiglie c'è un nuovo set d'istruzioni (incompatibile col precedente) e un nuovo ambiente di esecuzione (molti più registri, e anche modalità d'indirizzamento diverse). Poi possono far girare ANCHE il legacy, qualunque esso sia.

Per cui ribadisco il concetto: la modalità a 64-bit di AMD sarebbe potuta benissimo essere molto diversa da x86-64 (ben più semplice da decodificare, più efficiente, e con buona parte del legacy rimosso in QUESTA modalità d'esecuzione). Senza intaccare tutto il resto (come fa anche AArch64, appunto).

che a sua volta fu pensato per facilitare il porting di applicazioni scritte in assembly per l'8080 se ricordo bene.

8085; comunque ricordi bene. Intel aveva un tool per tradurre i sorgenti 8085 in equivalenti 8086, che funzionava nella quasi totalità dei casi.

Il vantaggio di 8086 fu, infatti, proprio questo: convertire molto velocemente l'esistente libreria di 8085, ma offrendo un'architettura migliore.

Ricorda che Intel aveva già provato a sganciarsi da x86 proprio per i limiti di tale architettura per poi ritornare sui suoi passi ed aggiungere un ennesima pezza ad x86.
Aveva provato a farlo con gli iAPX 432 per poi abbandonarlo e concentrarsi sull'80386.
Poi ci ha riprovato con i "suoi" RISC i80960 (principalmente per roba embedded) ed i80860 (che tentò di piazzare come RISC per workstation e server).
Ed infine c'e' stato l'Itanium che questa volta "per retrocompatibilità" nella prima versione aveva in hardware l'equivalente in prestazioni ad un i80486.
Ma prima che Intel ritornasse sui suoi passi e mettesse la sua pezza, quella volta fu AMD a farlo e non è che abbia fatto un lavoro peggiore di Intel a riguardo.

Direi di sì, invece, perché i precedenti tentativi di Intel non erano delle male pezze su x86, ma architetture completamente nuove che nulla avevano a che fare con x86 e successori.

L'unico di tali tentativi che offrì retrocompatibilità x86 fu proprio Itanium, ma consisteva in una soluzione in parte hardware che cercava di aiutare nell'esecuzione di codice x86. Nulla a che vedere col Compatibility mode di x86-64.

Quindi, ancora una volta sì: AMD ha fatto un lavoro nettamente peggiore di Intel, visto che ha preferito creare una veloce e brutta pezza su x86, anziché cercare di togliere di mezzo una volta per tutte il legacy di x86. Anzi: ci ha costruito sopra il nuovo legacy x86-64...

Dagli tempo, al momento Risc V è ancora in evoluzione e non è che ci siano implementazioni OoO effettivamente disponibili sul mercato.

Ce ne sono diverse, invece, ma tanto il problema rimane lo stesso: anche se in evoluzione, molti elementi chiave di RISC-V rimarranno gli stessi, e quindi rimarranno le problematiche di cui abbiamo discusso.

Peraltro questa è proprio l'n-esima dimostrazione che, checché se ne dica, le architetture CONTINO, eccome!

Risc V è nato come "architettura didattica e spartana" ma sono anni che sta diventando una specie di famiglia di set di istruzioni estendibili in cui l'estendibilità è nel DNA stesso del set di istruzioni.
RV32I o RV64I sono la "versione spartana" per quando ti serve una cpu senza tante pretese, poi a colpi di estensioni diventa qualcosa che si adatta a casi d'uso di ogni tipo.
Non è "perfetta", basta che sia sufficientemente versatile e con meno vincoli di quelli che si avrebbero utilizzando ARM o x86.

Vedi sopra: per quanto versatile, rimarrà quel che è con le diverse scelte che sono state fatte.

L'unico modo per aggirarle è facendo uso di estensioni custom (non proprietarie: ce ne sono di pubbliche, come PULP per l'appunto), ma qui andiamo fuori dallo standard e della sue estensioni ufficiali. Altra frammentazione, insomma.

Mi sembra che da qualche annetto si parli più della semplicità del decoder Risc V rispetto ad x86, del fatto che la lunghezza delle istruzioni la sai già con i primi bit invece di caricare prefisso dopo prefisso, ecc. ecc.
Stai ancora guardando alle origini di Risc V mentre ora di fatto è diventato altro.

Vero: ricordo tante cose vecchie, perché è da tempo che seguo quest'ISA.

Ma in realtà ormai da tempo non si parla più di semplicità del decoder, ma del fatto che l'architettura sia libera da vincoli e licenze da pagare. E' su questo punto che battono continuamente i creatori di RISC-V, e chi ha abbracciato questo progetto.

Spiegalo ad OpenRISC, al J-core o ad altre architetture open source, non hanno avuto lo stesso successo di Risc V.

Non è solo questione di avere un core open source, tutto l'ecosistema che si sta costruendo attorno nasce da esigenze reali a livello accademico e di R&D che stanno piano piano aprendosi la strada in altri ambiti.

Poi se avrà successo così oppure se ci sarà un Risc VI o se la cosa finirà in un ecosistema frammentato è ancora tutto da vedere, ma a livello di microcontroller e core "di servizio" mi sembra che stia facendosi strada cominciando dalla fascia bassa.

La differenza è che OpenRISC e J-core sono troppo specializzati, mentre con RISC-V si è posto fin dall'inizio l'obiettivo di essere un'architettura scalabile e utilizzabile dai microcontrolli ai supercomputer.

Che ovviamente è un modello vincente rispetto a tutti gli altri progetti open source.

E' almeno dalla versione 4.6.4 (del 2013) che GCC usa NOP "lunghe".
Nell'esempio su godbolt.org che ho linkato sopra, ho forzato "-falign-labels=32" in modo da rendere evidente l'inserimento di NOP "lunghi"; ma in generale a partire dal livello generico -O1 vengono attivate tutte le -falign-XXXX su valori di default che fanno scattare la generazione dei NOP (lunghi e corti a seconda delle esigenze) solo se non si genera troppo sfrido.

Purtroppo non è così, e lo puoi vedere tu stesso col tool di cui hai passato il link: è soltanto da GCC 10.1 che vengono finalmente generate le NOP correttamente DOPO le istruzioni di call. Prima di tale versione le NOP spesso non venivano inserite dopo le call.

Inoltre in diversi casi continuano a venire generate più NOP di quelle necessarie per coprire il padding.

Infine, sarebbe bastato abilitare di default -falign-labels=16 per imitare ciò che fanno gli altri compilatori, senza costringere i programmatori a dover usare questo parametro addizionale.

[LMCH]

Originariamente inviato da cdimauro

Ne abbiamo parlato nell'altro thread in cui c'erano a confronto l'Atom in-order e i Cortex in-order e out-of-order.

Appunto, ed avevi citato una paper in cui veniva confrontato un Atom con un TDP molto più alto con dei SoC ARM completi che eppure avevano un TDP più basso.
Decisamente c'erano troppe differenze a livello di tecnologia e risorse per considerarlo un confronto ad armi pari.

Originariamente inviato da cdimauro

Il punto è x86-64 e AArch64 sono modalità di esecuzione a 64 bit AGGIUNTIVE a quelle a 32-bit delle rispettive famiglie, che funzionano diversamente e richiedono anche decoder diversi.

Questo è esplicitato proprio con x86-64, che chiama Long Mode la modalità nativa a 64 bit, e "Compatibility / legacy" mode tutto il resto (che da tanti anni a questa parte vuol dire soltanto modalità protetta a 32-bit).

Qualunque sia il legacy che si portano dietro (e anche ARM a 32-bit ne ha tanto), il concetto è che per entrambe le famiglie c'è un nuovo set d'istruzioni (incompatibile col precedente) e un nuovo ambiente di esecuzione (molti più registri, e anche modalità d'indirizzamento diverse). Poi possono far girare ANCHE il legacy, qualunque esso sia.

Per cui ribadisco il concetto: la modalità a 64-bit di AMD sarebbe potuta benissimo essere molto diversa da x86-64 (ben più semplice da decodificare, più efficiente, e con buona parte del legacy rimosso in QUESTA modalità d'esecuzione). Senza intaccare tutto il resto (come fa anche AArch64, appunto).

Prima implementazionedi 8086 (16bit) 1978: circa 29000 gate.
Prima implementazionedi 80186 (16bit) 1982: circa 55000 gate.
Prima implementazione di 80286 (16bit) 1982: circa 134000 gate.
Prima implementazione di ARM2 (32bit) aprile 1985: circa 30000 gate.
Prima implementazione di 80386 (32bit) ottobre 1985: circa 275000 gate.

ARM2 letteralmente DISINTEGRAVA a livello di prestazioni gli 80286 e gli 8086 ancor di più.
Un ARM2 ad 8MHz aveva pure prestazioni maggiori di un 80386 a 16Mhz, non so se rendo l'idea.

Uno dei punti di forza di ARM2 era il decoder istruzioni estremamente semplice.

Quando poi fu introdotta la modalità Thumb il "decoder Thumb" faceva giusto una rimappatura 1:1 delle istruzioni ampie 16bit su un sottoinsieme di quelle ampie 32bit
(tutto il resto del chip bastava fosse ottimizzato per eseguire il set d'istruzioni A32, come se Thumb quasi non esistesse).

Con gli x86 questo avrebbe richiesto due decoder istruzioni distinti se si voleva sganciarsi dal formato delle istruzioni x86 della generazione precedente, fu scelto di mantenere un formato simile proprio per non perdere troppe prestazioni eseguendo codice "vecchio".

Originariamente inviato da cdimauro

8085; comunque ricordi bene. Intel aveva un tool per tradurre i sorgenti 8085 in equivalenti 8086, che funzionava nella quasi totalità dei casi.

Il vantaggio di 8086 fu, infatti, proprio questo: convertire molto velocemente l'esistente libreria di 8085, ma offrendo un'architettura migliore.

Solo che aveva poco senso farlo, poichè per sfruttare le cose in più che rendeva disponibili l'8086 di fatto bisognava riscrivere da zero il codice assembly.

Originariamente inviato da cdimauro

Direi di sì, invece, perché i precedenti tentativi di Intel non erano delle male pezze su x86, ma architetture completamente nuove che nulla avevano a che fare con x86 e successori.

L'unico di tali tentativi che offrì retrocompatibilità x86 fu proprio Itanium, ma consisteva in una soluzione in parte hardware che cercava di aiutare nell'esecuzione di codice x86. Nulla a che vedere col Compatibility mode di x86-64.

Le cose stanno peggio di come ricordi: di fatto 8086 nacque anche per mettere una pezza ai ritardi accumulati da Intel nello sviluppare iAPX 432.

Intel iniziò nel 1975 lo sviluppo della cpu a 32bit 8800 (poi rinominata iAPX 432), mentre lo sviluppo di 8086 (come ulteriore evoluzione della famiglia di cpu iniziata con l'8080, il cui ultimo esponente era l'8085) iniziò nel 1976.
In quel periodo Motorola stava lavorando allo sviluppo di MC68000 e Zilog allo sviluppo dello Z8000 (la cpu usata poi sugli Olivetti M20) ed Intel aveva bisogno di qualcosa da piazzare sul mercato perchè lo sviluppo di iAPX 432 era troppo lento.
In teoria POI doveva arrivare iAPX 432 e sarebbe stato quello la cpu del futuro.

Se ci pensi è grottesco, il piano originale di Intel è stato sempre sin dal principio quello di sganciarsi da x86 ...

iAPX 432 fu lanciato ufficialmente nel 1981 ma di fatto fu un flop, dopo 3 release alla fine fu abbandonato nel 1985, con l'uscita dell' 80386.

80386 fu il primo x86 a 32bit, ma pur avendo la possibilità di implementare un set d'istruzioni "nuovo" fu scelto di realizzarlo come estensione degli x86 a 16bit, perchè per molti anni fu usato come "8086 molto veloce" più che come "processore a 32bit" e quindi le prestazioni in modalità retrocompatibile erano quelle che interessavano di più.

In pratica 80386 fu una pezza al fallimento completo di iAPX 432 ed alle limitazioni degli x86 a 16bit ed Intel si limitò ad allargare i registri interi ed aggiungere nuove modalità di indirizzamento invece di fare un vero restyling del set di istruzioni.

Non mi sembra abbia fatto un lavoro migliore di quello fatto in seguito da AMD con i 64bit, specialmente se si considera che anche con x86-64 all'inizio la cosa più importante erano le prestazioni in modalità retrocompatibile (a 32bit).

Originariamente inviato da cdimauro

Ce ne sono diverse, invece, ma tanto il problema rimane lo stesso: anche se in evoluzione, molti elementi chiave di RISC-V rimarranno gli stessi, e quindi rimarranno le problematiche di cui abbiamo discusso.

Ma almeno per ora le problematiche attuali non è che siano così devastanti, si fanno sempre dei compromessi e per ora non viene chiesto l'impossibile.
Ripeto. Nulla vieta in futuro di "ripartire da capo" con un Risc VI ecc.

Originariamente inviato da cdimauro

L'unico modo per aggirarle è facendo uso di estensioni custom (non proprietarie: ce ne sono di pubbliche, come PULP per l'appunto), ma qui andiamo fuori dallo standard e della sue estensioni ufficiali. Altra frammentazione, insomma.

E' una frammentazione "controllata", inoltre le estensioni custom servono anche per collaudare sul campo estensioni che poi possono essere rimappate in istruzioni standard aggiunte successivamente.

Originariamente inviato da cdimauro

Ma in realtà ormai da tempo non si parla più di semplicità del decoder, ma del fatto che l'architettura sia libera da vincoli e licenze da pagare. E' su questo punto che battono continuamente i creatori di RISC-V, e chi ha abbracciato questo progetto.

Per forza che battono su tali aspetti, con gli USA che vietano l'export di certe IP e la Cina che "fa campagna acquisti" (vedere MIPS e la filiale cinese di ARM), diventa vitale non avere vincoli export e licenze di IP.

Originariamente inviato da cdimauro

La differenza è che OpenRISC e J-core sono troppo specializzati, mentre con RISC-V si è posto fin dall'inizio l'obiettivo di essere un'architettura scalabile e utilizzabile dai microcontrolli ai supercomputer.

Troppo specializzati ?!?!?

OpenRISC grossomodo è un simili-MIPS e MIPS come architettura mi sembra abbastanza versatile (usata a suo tempo dagli embedded ai server).

J-core nasce some "versione libera da vincoli" di SH-2 ed ora che i brevetti su SH-4 sono scaduti in teoria potrebbe esssere spinta oltre, aveva già un ecosistema di supporto ben rodato e non è che mi sembrasse così "specializzata" come dici.

Allo stato attuale Risc V non è un architettura, ma una famiglia di set d'istruzioni "accessibile a tutti" e supportata da un ecosistema software che facilita l'implementazione di nuove architetture, è quello il punto di forza che ha.

[raxas]

Originariamente inviato da raxas

ma si potrebbe avere un riassuntino degli ultimi 9 o 10 post?
tipo due righe, strette strette

Originariamente inviato da amd-novello

mission impossible

Originariamente inviato da cdimauro

Anche una soltanto: è una disquisizione su RISC vs CISC, con particolare focus su RISC-V/ARM da un lato e x86/x86-64 dall'altro.
...

mi erano sfuggiti i replay (alla mia "richiesta" )
visti solo ieri sera, rispondo di domenica con un pò di calma

":" mi chiedo se sia possibile fare una cpu che faccia le istruzioni in maniera che non si debba definire questo e quello e l'altro e cioè che facciano tutto elle cpu tipo come quando si paga un professionista e non si sa cosa faccia, mettendo lui in campo le sue conoscenze... ma sempre in maniera standard e fissa

non so se sono stato chiaro

cioè si "istruiscono" in maniera tale "sbrigatela tu cpu" senza che il progettista sappia nulla

tipo come il "temuto" avvento dei robòt, come che prendano loro potere e si sia in mano loro, con gli specialisti che vanno alla "loro presenza" e cerchino di capire cosa arr"o"battino

[cdimauro]

Originariamente inviato da LMCH

Appunto, ed avevi citato una paper in cui veniva confrontato un Atom con un TDP molto più alto con dei SoC ARM completi che eppure avevano un TDP più basso.
Decisamente c'erano troppe differenze a livello di tecnologia e risorse per considerarlo un confronto ad armi pari.

I confronti erano esclusivamente sul lato prestazionale della CPU, e anche dal punto di vista dei consumi l'Atom era messo bene a livello complessivo (ossia considerando il tempo per portare a termine i benchmark e il consumo impiegato in quell'arco di tempo).

Comunque ne abbiamo già ampiamente parlato nell'altro thread, dove ci sono tutte le informazioni e i paper.

Prima implementazionedi 8086 (16bit) 1978: circa 29000 gate.
Prima implementazionedi 80186 (16bit) 1982: circa 55000 gate.
Prima implementazione di 80286 (16bit) 1982: circa 134000 gate.
Prima implementazione di ARM2 (32bit) aprile 1985: circa 30000 gate.
Prima implementazione di 80386 (32bit) ottobre 1985: circa 275000 gate.

ARM2 letteralmente DISINTEGRAVA a livello di prestazioni gli 80286 e gli 8086 ancor di più.
Un ARM2 ad 8MHz aveva pure prestazioni maggiori di un 80386 a 16Mhz, non so se rendo l'idea.

Uno dei punti di forza di ARM2 era il decoder istruzioni estremamente semplice.

Ma su tutto questo hai riportato non ho assolutamente nulla da dire.

Però parlavo d'altro. Mi spiego meglio dopo.

Quando poi fu introdotta la modalità Thumb il "decoder Thumb" faceva giusto una rimappatura 1:1 delle istruzioni ampie 16bit su un sottoinsieme di quelle ampie 32bit
(tutto il resto del chip bastava fosse ottimizzato per eseguire il set d'istruzioni A32, come se Thumb quasi non esistesse).

Quasi proprio no, perché Thumb richiedeva un decoder ad hoc (completamente diverso da quello di ARM2) per le sue istruzioni, nonché un'apposita modalità d'esecuzione.

Il fatto che poi le istruzioni Thumb venissero convertite in istruzioni ARM2 è una mera questione micro-architetturale.

Infatti ci sono processori ARM Cortex che hanno esclusivamente l'ISA Thumb-2, avendo abbandonato del tutto l'originale set ARM2+.
ARM avrebbe potuto benissimo lasciare sia l'ISA ARM2+ sia quella Thumb-2 se il costo di tenerle entrambe fosse stato quasi inesistente. Cosa che evidentemente non è affatto.

Idem per ThumbEE e Jazilla: altre due ISA & modalità d'esecuzione che integrano soltanto pochi core ARM, e che ormai sono state del tutto abbandonate da ARM (ma ovviamente sempre disponibili per chi ne avesse ancora bisogno).

C'è una ragione per tutto ciò, ed è proprio nei costi di implementazione, che non sono così ridotti.

Con gli x86 questo avrebbe richiesto due decoder istruzioni distinti se si voleva sganciarsi dal formato delle istruzioni x86 della generazione precedente,

Infatti ci sono effettivamente due decoder di istruzioni per x86 e x86-64, visto che il set d'istruzioni è diverso: in modalità x86 le istruzioni vengono decodificate in un certo modo, mentre in quella x86-64 in maniera diversa.

Molto dei due decoder è condiviso ovviamente, perché la maggior parte della struttura base degli opcode è comune, ma ci sono diverse differenze che sono anche molto rilevanti, e di cui il rispettivo decoder si deve far carico di considerare.

fu scelto di mantenere un formato simile proprio per non perdere troppe prestazioni eseguendo codice "vecchio".

Non è una questione prestazionale, ma di mera convenienza implementativa: la modalità a 64-bit richiedeva soltanto il 5% in più di transistor rispetto allo stesso core Athlon utilizzato per "espanderlo" a 64-bit.

Le prestazioni, al contrario, sarebbero pure aumentate nettamente riprogettando il tutto.

Solo che aveva poco senso farlo, poichè per sfruttare le cose in più che rendeva disponibili l'8086 di fatto bisognava riscrivere da zero il codice assembly.

Non è così. Già con la sola conversione meccanica dal codice 8085 si guadagnavano 64KB di spazio per il codice, altrettanti per i dati, e altrettanti per lo stack. A costo zero, insomma, semplicemente usando il binario generato per 8086.

Con cambiamenti veramente minimi si guadagnavano altri 64KB per dati extra.

Inoltre c'era un guadagno prestazionale per il fatto di avere un bus dati a 16 bit, e ALU a 16 bit.

Ovviamente per sfruttare meglio l'8086 serviva codice ad hoc, ed è quello che poi è stato fatto. Non è un caso che ancora oggi ci ritroviamo a usare eredi di quest'architettura.

Le cose stanno peggio di come ricordi: di fatto 8086 nacque anche per mettere una pezza ai ritardi accumulati da Intel nello sviluppare iAPX 432.

Intel iniziò nel 1975 lo sviluppo della cpu a 32bit 8800 (poi rinominata iAPX 432), mentre lo sviluppo di 8086 (come ulteriore evoluzione della famiglia di cpu iniziata con l'8080, il cui ultimo esponente era l'8085) iniziò nel 1976.
In quel periodo Motorola stava lavorando allo sviluppo di MC68000 e Zilog allo sviluppo dello Z8000 (la cpu usata poi sugli Olivetti M20) ed Intel aveva bisogno di qualcosa da piazzare sul mercato perchè lo sviluppo di iAPX 432 era troppo lento.
In teoria POI doveva arrivare iAPX 432 e sarebbe stato quello la cpu del futuro.

Se ci pensi è grottesco, il piano originale di Intel è stato sempre sin dal principio quello di sganciarsi da x86 ...

iAPX 432 fu lanciato ufficialmente nel 1981 ma di fatto fu un flop, dopo 3 release alla fine fu abbandonato nel 1985, con l'uscita dell' 80386.

80386 fu il primo x86 a 32bit, ma pur avendo la possibilità di implementare un set d'istruzioni "nuovo" fu scelto di realizzarlo come estensione degli x86 a 16bit, perchè per molti anni fu usato come "8086 molto veloce" più che come "processore a 32bit" e quindi le prestazioni in modalità retrocompatibile erano quelle che interessavano di più.

Quasi nulla da dire anche su questo, a parte farti notare che qui è l'esatto opposto di quello che avevi scritto: iAPX 432 NON nasce per far fuori x86, visto che quando il progetto è partito non se ne parlava ancora di 8086 (e derivati).

Semmai è 8086 che ha fatto fuori iAPX 432.

In pratica 80386 fu una pezza al fallimento completo di iAPX 432 ed alle limitazioni degli x86 a 16bit ed Intel si limitò ad allargare i registri interi ed aggiungere nuove modalità di indirizzamento invece di fare un vero restyling del set di istruzioni.

Cosa che mi ricorda esattamente quello che ha fatto AMD con x86-64 nei confronti di x86.

Non mi sembra abbia fatto un lavoro migliore di quello fatto in seguito da AMD con i 64bit, specialmente se si considera che anche con x86-64 all'inizio la cosa più importante erano le prestazioni in modalità retrocompatibile (a 32bit).

Intanto vedi sopra: x86-64 sta a x86 come 80386 sta a 8086/80286, e iAPX 432 non c'entra nulla con la discussione.

E aggiungo che con gli altri tentativi di rimpiazzare x86 (80860, 80960, Itanium) Intel ha, esattamente al contrario di AMD con x86-64, progettato architetture totalmente nuove. Dei "clean design", insomma. Che non hanno nulla a che vedere con la mala pezza di AMD su x86.

Ma almeno per ora le problematiche attuali non è che siano così devastanti, si fanno sempre dei compromessi e per ora non viene chiesto l'impossibile.
Ripeto. Nulla vieta in futuro di "ripartire da capo" con un Risc VI ecc.

Considerato l'ecosistema che s'è creato e si sta continuando a creare su RISC-V, dubito che vedremo un nuovo "clean design" da Berkeley...

E' una frammentazione "controllata", inoltre le estensioni custom servono anche per collaudare sul campo estensioni che poi possono essere rimappate in istruzioni standard aggiunte successivamente.

Non funziona così. Come ho già detto prima, le istruzioni standard sono quelle e sono destinate a rimanere "set in the stone". Stanno sistemando alcune cose con le famigerate sottoestensioni, ma non toccheranno le fondamenta dell'ISA, che sono ben piantate per terra. Lo puoi vedere tu stesso nel documento / paper che ho già fornito. Ci sono cose (e sono tante) su cui non scenderanno mai a compromessi, perché sono dei fanatici.

Per cui l'unica sarà ricorrere a estensioni personalizzate.

"Il dado è tratto..."

Per forza che battono su tali aspetti, con gli USA che vietano l'export di certe IP e la Cina che "fa campagna acquisti" (vedere MIPS e la filiale cinese di ARM), diventa vitale non avere vincoli export e licenze di IP.

Fanno benissimo. Se c'è una cosa buona che ha fatto Trump è dimostrare di quanto siamo dominati dall'imperialismo americano nonché legati mani e piedi agli USA, che allargano prepotentemente il loro raggio d'azione all'intero globo.

Servono soluzioni nuove che ci consentano di divenire completamente autonomi da questi padri-padroni.

Troppo specializzati ?!?!?

OpenRISC grossomodo è un simili-MIPS e MIPS come architettura mi sembra abbastanza versatile (usata a suo tempo dagli embedded ai server).

OpenRISC è arrivata quando di RISC-V avevano già definito l'architettura base e alcune importanti estensioni. Infatti la versione 1.0 di OpenRISC risale al 2012, come puoi leggere nel loro sito, mentre il precedente draft risale al 2006 ed era rimasto a prendere la polvere.

A parte questo, OpenRISC mette a disposizione diverse istruzioni MAC sin dall'inizio, mostrando che l'ambito di utilizzo per cui nasce è l'embedded, ma sono soprattutto le scelte fatte per le istruzioni FP e vettoriali (SIMD) che lo dimostrano indubitabilmente: utilizzano tutte e soltanto i 32 registri general purpose!
In particolare l'estensione vettoriale sembra essere realizzata apposta per implementare classiche istruzioni da DSP.
La cosa peggiore in assoluto, che purtroppo è derivata dalla scelta di usare i registri GP, è che le istruzioni FP a doppia precisione sono a disposizione soltanto nell'ISA a 64 bit e non in quella a 32 bit. Idem per diverse istruzioni vettoriali che richiedono i 64 bit.

Infine, gli opcode sono fissi a 32 bit, e dalla loro struttura immagino già che la densità di codice non sarà delle migliori. Non c'è e non può nemmeno essere prevista un'ISA o delle estensioni compatte (tipo a 16-bit) a causa delle scelte fatte con la struttura degli opcode, e questa è una grande penalizzazione.

Quindi, direi proprio di no. Sebbene sia effettivamente un'ISA RISC (togliendo da parte un attimo la presenza di numerose istruzioni), a mio avviso OpenRISC non è affatto adeguata per coprire tutti gli ambiti di utilizzo & segmenti di mercati.

J-core nasce some "versione libera da vincoli" di SH-2 ed ora che i brevetti su SH-4 sono scaduti in teoria potrebbe esssere spinta oltre, aveva già un ecosistema di supporto ben rodato e non è che mi sembrasse così "specializzata" come dici.

A parte il fatto che, come dici, soltanto di recente sono scaduti i brevetti su SH-2 & SH-4 (e già soltanto questo sarebbe stato sufficiente a non prendere in considerazione quest'architettura), guarda che SH-2..4 è una famiglia di CISC sotto mentite spoglie.
Viene spacciata come RISC soltanto perché, come ormai dovrebbe essere chiaro a tutti, è a causa della propaganda "RISC è meglio / fico / bello, CISC fa schifo / è brutto / cattivo").
Quest'ISA ha tonnellate di diverse (anche complicate) modalità d'indirizzamento verso la memoria, nonché istruzioni aritmetiche per accedere direttamente alla memoria con la famigerata modalità read-execute-write che hai pure criticato quando l'ho citata come punto di forza dei CISC (e di x86/x86-64 in particolare).
Inoltre è chiaramente specializzata in ambito embedded, con tutte le (numerose) istruzioni di manipolazione di bit, nonché istruzioni di MAC e relativi registri addizionali. Le mancano pure le istruzioni ternarie (due registri sorgenti e uno di destinazione. Tipico dei RISC), e deve ripiegare sul riutilizzo del registro destinazione anche come sorgente (tipico dei CISC).
Infine ha soltanto 16 registri general purpose (e tu sostieni che è meglio averne tanti), di cui alcuni persino specializzati.
E' anche importante sottolineare che è soltanto a 32-bit. SH-5, che è a 64 bit, è arrivato dopo, ma è importante notare che ha definito anche un'ISA completamente nuova, con opcode fissi a 32 bit (SH fino alla 4 ha opcode fissi a 16-bit), e quindi due diverse modalità d'esecuzione (devi passare dall'una all'altra ogni volta). Ha ben 64 registri GP e 64 FP con la nuova modalità, che sono un'enorme esagerazione, e che quindi la portano lontana da certi ambiti (proprio l'embedded, paradossalmente).

Direi che ce n'è abbastanza per far scappare a gambe levate i cattedratici puristi di Berkeley, che è la patria dei RISC...

Allo stato attuale Risc V non è un architettura, ma una famiglia di set d'istruzioni "accessibile a tutti" e supportata da un ecosistema software che facilita l'implementazione di nuove architetture, è quello il punto di forza che ha.

Senz'altro.

Originariamente inviato da raxas

mi erano sfuggiti i replay (alla mia "richiesta" )
visti solo ieri sera, rispondo di domenica con un pò di calma

":" mi chiedo se sia possibile fare una cpu che faccia le istruzioni in maniera che non si debba definire questo e quello e l'altro e cioè che facciano tutto elle cpu tipo come quando si paga un professionista e non si sa cosa faccia, mettendo lui in campo le sue conoscenze... ma sempre in maniera standard e fissa

non so se sono stato chiaro

cioè si "istruiscono" in maniera tale "sbrigatela tu cpu" senza che il progettista sappia nulla

tipo come il "temuto" avvento dei robòt, come che prendano loro potere e si sia in mano loro, con gli specialisti che vanno alla "loro presenza" e cerchino di capire cosa arr"o"battino

Scusami, ma non è chiaro cosa vorresti ottenere.

[raxas]

Originariamente inviato da cdimauro

...
Scusami, ma non è chiaro cosa vorresti ottenere.

è molto semplice : fare un qualcosa che si costruisca la migliore architettura operativa possibile, cioè che la cambi al volo

[cdimauro]

Se hai costruito la miglior architettura possibile allora non c'è più bisogno di doverla cambiare al volo dopo.

Cambiare architettura "dinamicamente" (ossia ridefinendola alla bisogna) si può fare, e lo si fa già con gli FPGA. Ma il prezzo da pagare è il notevole calo prestazionale perché i processori "sintetizzati" (è il termine che si usa in genere) non sono assolutamente ottimizzati come invece avviene coi chip "tradizionali" (diciamo così per semplificare. In genere si parla di ASIC).

Spero di essere stato chiaro.

[Pino90]

Originariamente inviato da cdimauro

Se hai costruito la miglior architettura possibile allora non c'è più bisogno di doverla cambiare al volo dopo.

Cambiare architettura "dinamicamente" (ossia ridefinendola alla bisogna) si può fare, e lo si fa già con gli FPGA. Ma il prezzo da pagare è il notevole calo prestazionale perché i processori "sintetizzati" (è il termine che si usa in genere) non sono assolutamente ottimizzati come invece avviene coi chip "tradizionali" (diciamo così per semplificare. In genere si parla di ASIC).

Spero di essere stato chiaro.

Cesare però FPGA è per calcolo parallelo, almeno secondo me non può essere messo sullo stesso piano di una CPU "tradizionale" (per quello che può valere). Cioè il vantaggio di una FPGA è che riesco a creare una architettura ad hoc che tipicamente risolve un problema specifico molto velocemente perchè lo affronta con un approccio parallelo e non sequenziale come un processore tradizionale. Ossia invece di fare un processore generico che può essere programmato faccio una architettura per risolvere un problema specifico. Ed è per questo che nonostante le frequenze siano molto più basse spesso risulta conveniente: pensa ai campi classici come l'applicazione di filtri, campionamento di segnali o reti neurali etc., tutte applicazioni in cui si trae un enorme vantaggio dal design ad hoc del calcolatore che può affrontare le sfide algoritmiche in parallelo. Per altro un FPGA ha bisogno di una CPU tradizionale e di un bus di interfaccia (AXI, PCI) per funzionare.

Un ASIC è qualcosa di ancora diverso - almeno per come usiamo noi il termine a lavoro. FPGA normalmente si usa per prototipare o per applicazioni su piccola scala o di ricerca.

Scusate la precisazione.

[cdimauro]

Originariamente inviato da Pino90

Cesare però FPGA è per calcolo parallelo,

No, nasce per essere un dispositivo (ri)programmabile (da cui la P dell'acronimo), a seconda di quello che serve implementare (in hardware).

almeno secondo me non può essere messo sullo stesso piano di una CPU "tradizionale" (per quello che può valere).

Infatti non lo è. Ci si possono fare delle CPU (e in ambito retrogaming, ad esempio, le soluzioni FPGA dilagano), ma le prestazioni saranno scarse (rispetto a un ASIC equivalente).

Cioè il vantaggio di una FPGA è che riesco a creare una architettura ad hoc che tipicamente risolve un problema specifico molto velocemente perchè lo affronta con un approccio parallelo e non sequenziale come un processore tradizionale. Ossia invece di fare un processore generico che può essere programmato faccio una architettura per risolvere un problema specifico.

Sì, ma non deve necessariamente essere un approccio parallelo: è sufficiente che si risolva il problema specifico a un costo migliore di un sistema discreto esistente (altrimenti si userebbe quello, ovviamente).

Poi è chiaro che se lo specifico problema si presta a essere parallelizzato gli elementi di logica integrati li puoi sfruttare per creare tante copie dei core, ALU, o altro, che ti servono.

Ed è per questo che nonostante le frequenze siano molto più basse spesso risulta conveniente: pensa ai campi classici come l'applicazione di filtri, campionamento di segnali o reti neurali etc., tutte applicazioni in cui si trae un enorme vantaggio dal design ad hoc del calcolatore che può affrontare le sfide algoritmiche in parallelo.

SE i risultati sono migliori di un'esistente soluzione discreta... sì. Bisogna sempre farsi i conti.

Per altro un FPGA ha bisogno di una CPU tradizionale e di un bus di interfaccia (AXI, PCI) per funzionare.

No, con l'FPGA la CPU tradizionale te la puoi costruire sfruttando gli elementi di logica integrati, e puoi fare lo stesso coi bus d'interfacciamento con l'esterno (memorie incluse).

Quindi questi elementi non servono.

Però molti FPGA includono anche delle CPU e/o dei controller di memoria e/o dei controlli PCI, ecc., perché sono componenti che vengono usati molto spesso, e quindi è inutile che i programmatori FGPA si reinventino la ruota ogni volta.

Un ASIC è qualcosa di ancora diverso - almeno per come usiamo noi il termine a lavoro.

Come lo usate?

FPGA normalmente si usa per prototipare o per applicazioni su piccola scala o di ricerca.

Esattamente. Oppure se non si hanno i soldi per realizzare un ASIC (visto che produrli è molto costoso).

Scusate la precisazione.

Non ti devi scusare: è un forum, ed è nato per discutere. Poi questo è pure un forum tecnico.

[Pino90]

Originariamente inviato da cdimauro

No, nasce per essere un dispositivo (ri)programmabile (da cui la P dell'acronimo), a seconda di quello che serve implementare (in hardware).

Infatti non lo è. Ci si possono fare delle CPU (e in ambito retrogaming, ad esempio, le soluzioni FPGA dilagano), ma le prestazioni saranno scarse (rispetto a un ASIC equivalente).

Sì, ma non deve necessariamente essere un approccio parallelo: è sufficiente che si risolva il problema specifico a un costo migliore di un sistema discreto esistente (altrimenti si userebbe quello, ovviamente).

Poi è chiaro che se lo specifico problema si presta a essere parallelizzato gli elementi di logica integrati li puoi sfruttare per creare tante copie dei core, ALU, o altro, che ti servono.

SE i risultati sono migliori di un'esistente soluzione discreta... sì. Bisogna sempre farsi i conti.

Si certo si possono fare delle CPU e in generale ci si può fare un po' quello che si vuole nei limiti delle capacità del singolo chip. Scusa, è che in effetti le ho sempre usate per compiti ad alto parallelismo e quindi do per scontato che si usino sempre per questo genere di compiti ma come giustamente fai notare tu non è vero.

In generale do per scontato che se si usa una FPGA l'analisi dei rischi e dei costi sia già stata fatta. Nel senso, nel momento in cui si arriva ad usarla già si pensa che se ne possa beneficiare, anche perchè l'investimento di termini di ore uomo per la stesura di un codice HDL di qualità decente è piuttosto ingente.

No, con l'FPGA la CPU tradizionale te la puoi costruire sfruttando gli elementi di logica integrati, e puoi fare lo stesso coi bus d'interfacciamento con l'esterno (memorie incluse).

Quindi questi elementi non servono.

Però molti FPGA includono anche delle CPU e/o dei controller di memoria e/o dei controlli PCI, ecc., perché sono componenti che vengono usati molto spesso, e quindi è inutile che i programmatori FGPA si reinventino la ruota ogni volta.

Nella mia piccola esperienza (settore aeronautico e ferroviario) FPGA è sempre accompagnato da una CPU tradizionale. Di nuovo hai ragione tu nel dire che non è necessario anche se io non l'ho mai visto in maniera diversa.
Solo come completezza rimarco che le trame moderne già hanno dei blocchi di memoria all'interno della trama stessa (i cosiddetti bram blocks) e spesso e volentieri hanno anche dei piccoli banchi ram per memorizzare dati intermedi più consistenti senza sprecare registri né cicli per accedere ad una memoria esterna (se ne vanno svariate decine di cicli per leggere un dato da una RAM normalmente).

Come lo usate?

Nel nostro caso parliamo di ASIC quando è finito il ciclo di V&V su FPGA, le ottimizzazioni del design sono state fatte e viene fatta la sintesi in silicio. Non so se il termine sia generalmente corretto. Cioè prima di stampare vogliamo essere 150% sicuri che vada tutto bene anche perché se no volano euro che è un piacere.
Ai clienti normalmente vengono consegnati i sistemi già certificati e prodotti in silicio insieme a tutta la documentazione. Normalmente la produzione viene eseguita dopo la certificazione del design (per componenti safety) per evitare casini con il re-design e i conseguenti costi esorbitanti.

Io chiudo qui ché siamo OT. Sempre un piacere!

[LMCH]

Originariamente inviato da cdimauro

Quasi proprio no, perché Thumb richiedeva un decoder ad hoc (completamente diverso da quello di ARM2) per le sue istruzioni, nonché un'apposita modalità d'esecuzione.

Il fatto che poi le istruzioni Thumb venissero convertite in istruzioni ARM2 è una mera questione micro-architetturale.

Infatti ci sono processori ARM Cortex che hanno esclusivamente l'ISA Thumb-2, avendo abbandonato del tutto l'originale set ARM2+.
ARM avrebbe potuto benissimo lasciare sia l'ISA ARM2+ sia quella Thumb-2 se il costo di tenerle entrambe fosse stato quasi inesistente. Cosa che evidentemente non è affatto.

Idem per ThumbEE e Jazilla: altre due ISA & modalità d'esecuzione che integrano soltanto pochi core ARM, e che ormai sono state del tutto abbandonate da ARM (ma ovviamente sempre disponibili per chi ne avesse ancora bisogno).

C'è una ragione per tutto ciò, ed è proprio nei costi di implementazione, che non sono così ridotti.

I Cortex-M implementano solo Thumb2 perchè ARM li contrappone alle vecchie cpu ad 8bit ed ai vari microcontroller in area sul chip ridotta al minimo (per avere costi di produzione più bassi), bassi consumi e compattezza del codice sono fondamentali.
Quindi hanno limato via tutto quello che potevano.

Basta pensare che i core Cortex-M0 nella loro implementazione più spartana richiedono circa 12000 gate contro i circa 6000 gate di un core 8051 ad 8bit.

Non è un caso che i Cortex-M0 stiano spazzando via le cpu ad 8bit anche in termini di costo/prestazioni

Poi, a parte il target di fascia più bassa, i Cortex-M implementano solo Thumb2 anche nelle versioni "più potenti" (in cui conta meno la minimizzazione del numero di gate utilizzati) perchè con Thumb2 oltre alla compattezza del codice, ad un microcontroller basta avere il bus da flash a core ampio 16bit per avere buone prestazioni
(e se poi uno vuole il set completo di istruzioni a 32bit, ci sono i Cortex-R)

Originariamente inviato da cdimauro

Infatti ci sono effettivamente due decoder di istruzioni per x86 e x86-64, visto che il set d'istruzioni è diverso: in modalità x86 le istruzioni vengono decodificate in un certo modo, mentre in quella x86-64 in maniera diversa.

Molto dei due decoder è condiviso ovviamente, perché la maggior parte della struttura base degli opcode è comune, ma ci sono diverse differenze che sono anche molto rilevanti, e di cui il rispettivo decoder si deve far carico di considerare.

Non si tratta solo di quello che c'e' sul decoder, ma anche di quello che sta a valle di esso. Il formato e la codifica delle microOP, degli scheduler di istruzioni, il dimensionamento di ALU, AGU, ecc. non viene mica deciso arbitrariamente. Se la tipologia o il formato di quello che generano i decoder è troppo diverso, si hanno effetti anche su tutto quello che sta a valle OPPURE si deve accettare che uno dei due set di istruzioni sia penalizzato.

Originariamente inviato da cdimauro

Non è una questione prestazionale, ma di mera convenienza implementativa: la modalità a 64-bit richiedeva soltanto il 5% in più di transistor rispetto allo stesso core Athlon utilizzato per "espanderlo" a 64-bit.

Le prestazioni, al contrario, sarebbero pure aumentate nettamente riprogettando il tutto.

Ti faccio notare che con Itanium hanno letteralmente riprogettato tutto ed il suo punto debole più rilevante per il grosso degli utilizzatori era che in emulazione x86 era troppo lento (aveva circa le prestazioni di un 486 quando sul mercato c'erano Pentium III, Pentium 4 ed Athlon ).
Quindi ci sono limiti ben precisi su quel che si può ottenere implementando due decoder molto differenti.

Originariamente inviato da cdimauro

Non è così. Già con la sola conversione meccanica dal codice 8085 si guadagnavano 64KB di spazio per il codice, altrettanti per i dati, e altrettanti per lo stack. A costo zero, insomma, semplicemente usando il binario generato per 8086.

Con cambiamenti veramente minimi si guadagnavano altri 64KB per dati extra.

Inoltre c'era un guadagno prestazionale per il fatto di avere un bus dati a 16 bit, e ALU a 16 bit.

Ovviamente per sfruttare meglio l'8086 serviva codice ad hoc, ed è quello che poi è stato fatto. Non è un caso che ancora oggi ci ritroviamo a usare eredi di quest'architettura.

Il costo non era zero.
La conversione automatica andava bene solo per roba che si limitava a max 64k di dati e programmi nello stesso spazio di memoria
E che non facesse uso di codice automodificante, per tutto il resto era meglio riscrivere tutto.

Se ad esempio il programma usava puntatori, bisognava verificare che non ci fossero parti di codice che presupponevano che stack, variabili globali/heap e codice fossero nello stesso spazio di indirizzamento lineare
(tipo se allochi una struttura sullo stack e poi passi ad una funzione il puntatore alla struttura).

Infatti il grosso del software per 8080 ed 8085 col tempo o è migrato verso gli Z80 oppure è stato riscritto per la maggior parte a mano (se era codice assembly).
Non è un caso se al giorno d'oggi trovi ancora in produzione un sacco di microcontroller Z80-compatibili oppure le loro versioni evolute retrocompatibili a livello di codice binario.

Originariamente inviato da cdimauro

Quasi nulla da dire anche su questo, a parte farti notare che qui è l'esatto opposto di quello che avevi scritto: iAPX 432 NON nasce per far fuori x86, visto che quando il progetto è partito non se ne parlava ancora di 8086 (e derivati).

Semmai è 8086 che ha fatto fuori iAPX 432.

Per la precisione in precedenza avevo scritto:

Originariamente inviato da LMCH

Ricorda che Intel aveva già provato a sganciarsi da x86 proprio per i limiti di tale architettura per poi ritornare sui suoi passi ed aggiungere un ennesima pezza ad x86.
Aveva provato a farlo con gli iAPX 432 per poi abbandonarlo e concentrarsi sull'80386.

Infatti poi successivamente ho chiarito cosa intendevo, mi sembra.

Originariamente inviato da cdimauro

Cosa che mi ricorda esattamente quello che ha fatto AMD con x86-64 nei confronti di x86.

Intanto vedi sopra: x86-64 sta a x86 come 80386 sta a 8086/80286, e iAPX 432 non c'entra nulla con la discussione.

C'entra eccome, le uniche cpu Intel che sono tuttora in produzione sono esclusivamente quelle con retrocompatibilità con x86 e con buone prestazioni (rispetto al loro target di mercato) in tale modalità.

Originariamente inviato da cdimauro

E aggiungo che con gli altri tentativi di rimpiazzare x86 (80860, 80960, Itanium) Intel ha, esattamente al contrario di AMD con x86-64, progettato architetture totalmente nuove. Dei "clean design", insomma. Che non hanno nulla a che vedere con la mala pezza di AMD su x86.

Ed ogni volta il potenziale sostituto ... è stato sostituito da una nuova generazione di x86 con una mala pezza (di Intel oppure di AMD).

Originariamente inviato da cdimauro

Considerato l'ecosistema che s'è creato e si sta continuando a creare su RISC-V, dubito che vedremo un nuovo "clean design" da Berkeley...

Mai dire mai, specialmente quando ci sono di mezzo gli accademici.

Originariamente inviato da cdimauro

Non funziona così. Come ho già detto prima, le istruzioni standard sono quelle e sono destinate a rimanere "set in the stone". Stanno sistemando alcune cose con le famigerate sottoestensioni, ma non toccheranno le fondamenta dell'ISA, che sono ben piantate per terra. Lo puoi vedere tu stesso nel documento / paper che ho già fornito. Ci sono cose (e sono tante) su cui non scenderanno mai a compromessi, perché sono dei fanatici.

Per cui l'unica sarà ricorrere a estensioni personalizzate.

Ci sono ancora un sacco di estensioni "standard" di Risc-V ancora da congelare e gruppi di istruzioni ancora da assegnare, vediamo che succede.

Originariamente inviato da cdimauro

Fanno benissimo. Se c'è una cosa buona che ha fatto Trump è dimostrare di quanto siamo dominati dall'imperialismo americano nonché legati mani e piedi agli USA, che allargano prepotentemente il loro raggio d'azione all'intero globo.

Servono soluzioni nuove che ci consentano di divenire completamente autonomi da questi padri-padroni.

Inoltre la longevità/reperibilità dei componenti e del software sta diventando sempre più rilevante.
Un pericolo sempre più tangibile è ritrovarsi con prodotti dal lungo ciclo di vita il cui hardware diventa obsoleto troppo presto o non più reperibile.
E li più che la geopolitica pesa il vendor lock-in.
Avere un hardware che male che vada puoi reimplementare su FPGA o farti fare un ASIC da un produttore a tua scelta diventa molto interessante sotto questo punto di vista.

Originariamente inviato da cdimauro

OpenRISC è arrivata quando di RISC-V avevano già definito l'architettura base e alcune importanti estensioni. Infatti la versione 1.0 di OpenRISC risale al 2012, come puoi leggere nel loro sito, mentre il precedente draft risale al 2006 ed era rimasto a prendere la polvere.

Veramente i lavori su OpenRISC erano iniziati nel 2000, il 2012 è quando è stato fissato lo standard 1.0 (ed un computer basato su OpenRisc fu utilizzato in orbita sulla ISS), ma ad esempio già nel 2009 c'era Samsung che usava i core OpenRisc in prodotti commerciali (i suoi SoC per televisori).

I lavori su Risc V sono iniziati nel 2010, è progredito molto più rapidamente sotto tutti gli aspetti ed inizialmente sembrava essere solo una "versione accademica" di OpenRisc.

(riguardo J-core)

Originariamente inviato da cdimauro

Direi che ce n'è abbastanza per far scappare a gambe levate i cattedratici puristi di Berkeley, che è la patria dei RISC...

Il mio punto non era riguardo cpu open source "sviluppate da puristi dei RISC" ma semplicemente che cpu non gravate da brevetti (ed il J-core ed OpenRisc rispondono a tali requisiti) non hanno sfondato come sta facendo Risc V.

[cdimauro]

Rieccomi. Finalmente ho abbastanza tempo da dedicare a questo lungo (ma fantastico) thread.

Originariamente inviato da Pino90

Si certo si possono fare delle CPU e in generale ci si può fare un po' quello che si vuole nei limiti delle capacità del singolo chip. Scusa, è che in effetti le ho sempre usate per compiti ad alto parallelismo e quindi do per scontato che si usino sempre per questo genere di compiti ma come giustamente fai notare tu non è vero.

In generale do per scontato che se si usa una FPGA l'analisi dei rischi e dei costi sia già stata fatta. Nel senso, nel momento in cui si arriva ad usarla già si pensa che se ne possa beneficiare, anche perchè l'investimento di termini di ore uomo per la stesura di un codice HDL di qualità decente è piuttosto ingente.

Nella mia piccola esperienza (settore aeronautico e ferroviario) FPGA è sempre accompagnato da una CPU tradizionale. Di nuovo hai ragione tu nel dire che non è necessario anche se io non l'ho mai visto in maniera diversa.
Solo come completezza rimarco che le trame moderne già hanno dei blocchi di memoria all'interno della trama stessa (i cosiddetti bram blocks) e spesso e volentieri hanno anche dei piccoli banchi ram per memorizzare dati intermedi più consistenti senza sprecare registri né cicli per accedere ad una memoria esterna (se ne vanno svariate decine di cicli per leggere un dato da una RAM normalmente).

Esattamente, ed è anche il motivo per cui gli FPGA si sono diffusi e si stanno diffondendo molto negli ultimi anni. Ormai non sono soltanto dei componenti che offrono un certo numero di elementi di logica e basta, ma integrano tanta roba già bella e pronta, che devi soltanto selezionare e usare per quello che ti serve.

Scrivere HDL richiede tempo, ma grazie a tutta questa roba integrata è diventato di gran lunga più facile. Oggi realizzare una CPU interamente in FPGA non è più un tabù, e progetti se ne vedono parecchi in giro (specialmente in ambito retrogaming, come già detto).

Nel nostro caso parliamo di ASIC quando è finito il ciclo di V&V su FPGA, le ottimizzazioni del design sono state fatte e viene fatta la sintesi in silicio. Non so se il termine sia generalmente corretto. Cioè prima di stampare vogliamo essere 150% sicuri che vada tutto bene anche perché se no volano euro che è un piacere.
Ai clienti normalmente vengono consegnati i sistemi già certificati e prodotti in silicio insieme a tutta la documentazione. Normalmente la produzione viene eseguita dopo la certificazione del design (per componenti safety) per evitare casini con il re-design e i conseguenti costi esorbitanti.

Da quel che scrivi dovete avere un bel giro d'affari con cifre importanti.

Già soltanto per tirare fuori una maschera per un ASIC ci vogliono parecchi soldi (centinaia di migliaia di euro, a memoria. Ma non so se i costi sono calati negli ultimi anni). E devi sperare che vada tutto bene e che non devi rifarne altre.
Poi andare in produzione per lotti di poche decine di migliaia di chip dovrebbe richiedere qualche milione di euro.
Cifre assolutamente fuori portata di hobbisti et similia.

Io chiudo qui ché siamo OT. Sempre un piacere!

Idem.

Originariamente inviato da LMCH

I Cortex-M implementano solo Thumb2 perchè ARM li contrappone alle vecchie cpu ad 8bit ed ai vari microcontroller in area sul chip ridotta al minimo (per avere costi di produzione più bassi), bassi consumi e compattezza del codice sono fondamentali.
Quindi hanno limato via tutto quello che potevano.

Basta pensare che i core Cortex-M0 nella loro implementazione più spartana richiedono circa 12000 gate contro i circa 6000 gate di un core 8051 ad 8bit.

Non è un caso che i Cortex-M0 stiano spazzando via le cpu ad 8bit anche in termini di costo/prestazioni

Poi, a parte il target di fascia più bassa, i Cortex-M implementano solo Thumb2 anche nelle versioni "più potenti" (in cui conta meno la minimizzazione del numero di gate utilizzati) perchè con Thumb2 oltre alla compattezza del codice, ad un microcontroller basta avere il bus da flash a core ampio 16bit per avere buone prestazioni
(e se poi uno vuole il set completo di istruzioni a 32bit, ci sono i Cortex-R)

Assolutamente sì, infatti, ma lo vedi tu stesso che i costi implementativi sono importanti e non indifferenti.

Se consideri che il primo ARM (ARM1) richiedeva 25 mila gate (se non ricordo male) e che nel frattempo l'ISA è aumentata non poco (ARMv7), a conti fatti tenere Thumb-2 e ARM assieme richiedono non poche risorse.

Non si tratta solo di quello che c'e' sul decoder, ma anche di quello che sta a valle di esso. Il formato e la codifica delle microOP, degli scheduler di istruzioni, il dimensionamento di ALU, AGU, ecc. non viene mica deciso arbitrariamente. Se la tipologia o il formato di quello che generano i decoder è troppo diverso, si hanno effetti anche su tutto quello che sta a valle OPPURE si deve accettare che uno dei due set di istruzioni sia penalizzato.

Certamente, ma non stiamo parlando di ISA completamente diverse. Perfino ARM64 ricicla parecchia "infrastruttura" di ARM, estendendola.

Nel caso di x86 e x64 (ormai uso le sigle più comuni nonché abbreviate) i dati li ha fornito AMD all'epoca: l'implementazione di quest'ultima ha richiesto il 5% in più di transistor rispetto allo stesso, identico, core, ma soltanto con x86. Non è molto, se consideri che dentro c'è il raddoppio dei registri sia general purpose sia SIMD (e, come sai, il register file è uno degli elementi microarchitetturali che richiede più transistor & area in un core).

Vuol dire che è stato possibile riciclare quasi tutto, praticamente, con poche modifiche sia al frontend sia al backend.

Ti faccio notare che con Itanium hanno letteralmente riprogettato tutto ed il suo punto debole più rilevante per il grosso degli utilizzatori era che in emulazione x86 era troppo lento (aveva circa le prestazioni di un 486 quando sul mercato c'erano Pentium III, Pentium 4 ed Athlon ).
Quindi ci sono limiti ben precisi su quel che si può ottenere implementando due decoder molto differenti.

Vero, ma Itanium è un caso a parte, perché non aveva effettivamente due decoder separati le due diverse ISA: aveva soltanto qualche accelerazione hardware integrata per x86.

Per il resto vedi sopra, sulla questione.

E' chiaro che se hai due ISA completamente diverse ci saranno costi maggiori sia per i decoder sia per il backend, perché ci sarà un limite alla possibilità di riciclare / usare parti comuni.

Infatti persino Transmeta, che aveva un'ISA nativa completamente diversa, ha dovuto incorporare (in hardware, intendo) alcuni elementi di x86, altrimenti l'emulazione sarebbe stata mooooolto più lenta.

Infine e per ritornare alla discussione originale (mi riferisco a questa specifica parte ): x64 rimane una brutta pezza che AMD ha messo su x86, che ha velocemente applicato e implementato per non dover perdere tempo nel progettare un'ISA ex-novo (seppure basata sui concetti di x86, e riciclando ugualmente quasi tutto il backend).
Questo lo posso affermare con assoluta certezza, perché ho dati concreti in mano che lo dimostrano senza alcun dubbio.

Il costo non era zero.
La conversione automatica andava bene solo per roba che si limitava a max 64k di dati e programmi nello stesso spazio di memoria
E che non facesse uso di codice automodificante, per tutto il resto era meglio riscrivere tutto.

Se ad esempio il programma usava puntatori, bisognava verificare che non ci fossero parti di codice che presupponevano che stack, variabili globali/heap e codice fossero nello stesso spazio di indirizzamento lineare
(tipo se allochi una struttura sullo stack e poi passi ad una funzione il puntatore alla struttura).

Corretto. Diverse cose si potevano sistemare meccanicamente e automaticamente (col traduttore) usando i famigerati prefissi di segmento, ma per le cose che hai elencato servivano modifiche al codice, effettivamente.

Comunque si poteva sempre partire da una traduzione in cui tutti i segmenti fossero uguale, in modo da avere immediatamente codice funzionante. Per poi fare modifiche migliorative col tempo.

Infatti il grosso del software per 8080 ed 8085 col tempo o è migrato verso gli Z80 oppure è stato riscritto per la maggior parte a mano (se era codice assembly).

All'epoca si usava per lo più l'assembly con questi processori.

Non è un caso se al giorno d'oggi trovi ancora in produzione un sacco di microcontroller Z80-compatibili oppure le loro versioni evolute retrocompatibili a livello di codice binario.

Già in produzione magari sì, ma danni non vedo roba Z80 o simile. Come pure 6502/65C02/65816. O, sfortunatamente, 68000+.

E' tutta roba legacy, mentre oggi sono più diffusi microcontrollori a basso costo come Microchip, Atmel, Renaissance, ecc.. Meno male che stanno prendendo piede i Thumb-2, per l'appunto, che sono di gran lunga più versatili e potenti.

C'entra eccome, le uniche cpu Intel che sono tuttora in produzione sono esclusivamente quelle con retrocompatibilità con x86 e con buone prestazioni (rispetto al loro target di mercato) in tale modalità.

Sì, ma iAPX 432 non ha mai impensierito né tanto meno sostituito 8086 e successori.

Mai dire mai, specialmente quando ci sono di mezzo gli accademici.

Hanno avuto una gran botta di culo perché hanno trovato un enorme appoggio dai privati, ma son treni che in genere passano una sola volta.

Sarà difficile pensare a un sostituito una volta che RISC-V diventerà un ecosistema solido e paragonabile a x86 e ARM a livello di diffusione e supporto.

Ci sono ancora un sacco di estensioni "standard" di Risc-V ancora da congelare e gruppi di istruzioni ancora da assegnare, vediamo che succede.

Vero ma, come dico dicevo prima, quelle più importanti sono già state ratificate. Fra le più importanti rimaste ancora da ratificare manca quella vettoriale, che sta avendo un lunghissimo travaglio.

Inoltre la longevità/reperibilità dei componenti e del software sta diventando sempre più rilevante.
Un pericolo sempre più tangibile è ritrovarsi con prodotti dal lungo ciclo di vita il cui hardware diventa obsoleto troppo presto o non più reperibile.
E li più che la geopolitica pesa il vendor lock-in.
Avere un hardware che male che vada puoi reimplementare su FPGA o farti fare un ASIC da un produttore a tua scelta diventa molto interessante sotto questo punto di vista.

A chi lo dici. Pensa al settore automobilistico, dove serve garantire assistenza e ricambi per 17 anni (se non ricordo male). Avendo FPGA o (meglio ancora, visto l'utilizzo) ASIC permetterebbe di evitare di mettere a magazzino tanta roba che poi andrà per lo più buttata. Quando, invece, alla bisogna si potrebbero produrre nuovamente i componenti necessari.

Veramente i lavori su OpenRISC erano iniziati nel 2000, il 2012 è quando è stato fissato lo standard 1.0 (ed un computer basato su OpenRisc fu utilizzato in orbita sulla ISS), ma ad esempio già nel 2009 c'era Samsung che usava i core OpenRisc in prodotti commerciali (i suoi SoC per televisori).

I lavori su Risc V sono iniziati nel 2010, è progredito molto più rapidamente sotto tutti gli aspetti ed inizialmente sembrava essere solo una "versione accademica" di OpenRisc.

Non ero a conoscenza dell'implementazione di Samsung. Comunque parliamo del draft non ancora ratificato (nemmeno la 1.0).

Per il resto rimangono le mie obiezioni tecniche su OpenRISC: purtroppo è troppo specializzato e non adatto a poter essere impiegato in qualunque ambito applicativo, che era l'obiettivo di RISC-V.

(riguardo J-core)

Il mio punto non era riguardo cpu open source "sviluppate da puristi dei RISC" ma semplicemente che cpu non gravate da brevetti (ed il J-core ed OpenRisc rispondono a tali requisiti) non hanno sfondato come sta facendo Risc V.

Per due motivi: perché, come già detto, erano e sono troppo specializzate, e poi all'epoca erano ancora gravate dai brevetti (spirati soltanto qualche anno fa). In entrambi i casi inutilizzabili per i fini di RISC-V.

[LMCH]

Originariamente inviato da cdimauro

Rieccomi. Finalmente ho abbastanza tempo da dedicare a questo lungo (ma fantastico) thread.

Stiamo costruendo una vera e propria muraglia di testo.

Originariamente inviato da cdimauro

Vero, ma Itanium è un caso a parte, perché non aveva effettivamente due decoder separati le due diverse ISA: aveva soltanto qualche accelerazione hardware integrata per x86.

Soltanto "accelerazione hardware integrata" ?

Il Merced aveva nella descrizione del layout del chip un unico blocco denominato "instruction fetch and decode" e due altri blocchi denominati "IA-32 Control" ed "IA-64 Control".
intel_itanium.jpg.
Quindi a valle del decoder c'erano due sottosistemi di esecuzione separate ma il decoder poteva decodificare direttamente entrambi i set di istruzioni (probabilmente l'IA-64 in modo più efficiente, per ovvi motivi, ma pur sempre di decodifica in hardware si trattava)

Il successivo McKinley aveva un "IA-32 Engine" ancora più complesso
(vedere pagina 8 di questo pdf)
ma anche in quel caso il codice x86 era seguito in hardware, non con l'ausilio di software che si appoggiasse ad acceleratori hardware integrati per l'esecuzione!

Solo dopo nelle versioni che seguirono il decoder istruzioni x86 ed il resto della logica di controllo esecuzione furono eliminati (presumibilmente con ancora alcune estensioni che semplificasseo l'emulazione x86, ma di quello non sono sicuro).

Originariamente inviato da cdimauro

Infine e per ritornare alla discussione originale (mi riferisco a questa specifica parte ): x64 rimane una brutta pezza che AMD ha messo su x86, che ha velocemente applicato e implementato per non dover perdere tempo nel progettare un'ISA ex-novo (seppure basata sui concetti di x86, e riciclando ugualmente quasi tutto il backend).
Questo lo posso affermare con assoluta certezza, perché ho dati concreti in mano che lo dimostrano senza alcun dubbio.

Sono d'accordo con te, era una brutta pezza, ma funzionava e non penalizzava troppo le prestazioni in modalità retrocompatibile, ricordo anche che a suo tempo circolava voce che Intel avesse a sua volta preparato un evoluzione a 64bit degli x86 incompatibile con x86-64 di AMD, ma che poi non se ne fece niente perchè Microsoft si rifiutò di supportare un altro set di istruzioni dopo il bagno di sangue di Itanium.
Viene da chiedersi cosa avessero preparato, forse una modalità a 64bit molto più innovativa ? Oppure avevano deciso di estendere a 64bit gli 8 registri interi e poco altro ?

Originariamente inviato da cdimauro

Corretto. Diverse cose si potevano sistemare meccanicamente e automaticamente (col traduttore) usando i famigerati prefissi di segmento, ma per le cose che hai elencato servivano modifiche al codice, effettivamente.

Originariamente inviato da cdimauro

Comunque si poteva sempre partire da una traduzione in cui tutti i segmenti fossero uguale, in modo da avere immediatamente codice funzionante. Per poi fare modifiche migliorative col tempo.

Avere immediatamente codice assembly che forse-funziona-forse-no ?
Se era relativamente complesso, come minimo lo avrebbero dovuto passare al setaccio con code review multiple.
Se era relativamene semplice, sempre per gli stessi motivi conveniva riscriverlo a mano in modo da sfruttare bene i registri e le istruzioni disponibili.
Mi ricordo come erano i due set d'istruzioni e passare da una cpu all'altra
era così: https://www.youtube.com/watch?v=S9WW...mKLsuY&index=9

Originariamente inviato da cdimauro

All'epoca si usava per lo più l'assembly con questi processori.

Me lo ricordo, adesso persino per i PIC di Microchip esistono dei compilatori C, allora era assembly o forth per la roba embedded (a meno di usare roba "grossa").

Originariamente inviato da cdimauro

Già in produzione magari sì, ma danni non vedo roba Z80 o simile. Come pure 6502/65C02/65816. O, sfortunatamente, 68000+.

Si nascondono, ma ci sono, di solito sono usati per sviluppare nuovo hardware da usare come retrofit di roba "vecchia" di cui si sono persi i sorgenti oppure per riciclare software già sviluppato e testato da anni (dove ora al posto di una schedina con 2..3 chip c'e' un SoC supereconomico).

Originariamente inviato da cdimauro

Sì, ma iAPX 432 non ha mai impensierito né tanto meno sostituito 8086 e successori.

Ma nei piani della stessa Intel doveva essere il loro nuovo prodotto di punta al posto degli 8086.

Originariamente inviato da cdimauro

Hanno avuto una gran botta di culo perché hanno trovato un enorme appoggio dai privati, ma son treni che in genere passano una sola volta.

Concordo sulla botta di culo, ma i cambiamenti che inevitabilmente ci saranno in futuro a livello di tecnologie e di mercato, finiranno con il creare nuove finestre di opportunità.

Originariamente inviato da cdimauro

Vero ma, come dico dicevo prima, quelle più importanti sono già state ratificate. Fra le più importanti rimaste ancora da ratificare manca quella vettoriale, che sta avendo un lunghissimo travaglio.

In compenso c'e' ancora spazio e tempo per aggiungere nuove istruzioni in base alle esigenze concrete che sono già emerse e che emergeranno.
C'è inoltre RV32E che non è ancora congelata e che potrebbe essere "ritoccata" in vari modi, prevedendo anche cosa fare con RV32EC.

[raxas]

"Homo homini papȳrus magnum."(cit.)

(traduco vah... "l'uomo è un grande papiro per l'altro uomo" )

aggiungo magari qualcuno non lo sa, che è una riedizione, ed adattamento ,
della frase latina "Homo homini lupus" (trad. Ogni uomo è un lupo per l'altro uomo) espressione in campo socio-antropologico, più conosciuta di Thomas Hobbes, filosofo inglese, e prima ancora di Plauto, scrittore latino
ancora questi tizi non conoscevano i notevoli dibattiti in materia digitale-informatica, meritori comunque
(senza riferimento necessario ad altro genere di papiri )

[cdimauro]

Originariamente inviato da LMCH

Stiamo costruendo una vera e propria muraglia di testo.

Nahhh Ormai sta crollando, e oggi gli diamo una bella scorzatura.

Soltanto "accelerazione hardware integrata" ?

Il Merced aveva nella descrizione del layout del chip un unico blocco denominato "instruction fetch and decode" e due altri blocchi denominati "IA-32 Control" ed "IA-64 Control".
intel_itanium.jpg.
Quindi a valle del decoder c'erano due sottosistemi di esecuzione separate ma il decoder poteva decodificare direttamente entrambi i set di istruzioni (probabilmente l'IA-64 in modo più efficiente, per ovvi motivi, ma pur sempre di decodifica in hardware si trattava)

Il successivo McKinley aveva un "IA-32 Engine" ancora più complesso
(vedere pagina 8 di questo pdf)
ma anche in quel caso il codice x86 era seguito in hardware, non con l'ausilio di software che si appoggiasse ad acceleratori hardware integrati per l'esecuzione!

In entrambi i casi x86 veniva sostanzialmente emulato, sfruttando dell'accelerazione hardware per agevolare il compito. Lo si può vedere dalle slide che hai riportato, a partire da pag. 32, di cui riporto alcune parti:

"IA-32 Support:
Done with hardware emulation

32 Bit Hardware Emulation

Less than 1% of the chip devoted to Hardware Emulation"

In particolare è da notare quest'ultima frase, che dimostra quanto poco spazio sia stato dato all'accelerazione hardware per aiutare l'emulatore x86.

Comunque se leggi quelle slide lo vedi tu stesso che era veramente poca cosa.

Solo dopo nelle versioni che seguirono il decoder istruzioni x86 ed il resto della logica di controllo esecuzione furono eliminati (presumibilmente con ancora alcune estensioni che semplificasseo l'emulazione x86, ma di quello non sono sicuro).

No, sembra che sia stata totalmente rimossa l'accelerazione hardware, e che l'emulazione fosse soltanto software. Ne parlano anche le slide, in cui riportano che l'emulatore software era addirittura più veloce, per cui non c'era proprio alcun motivo per continuare a sprecare silicio (per quanto fosse poco) per questa funzionalità.

Sono d'accordo con te, era una brutta pezza, ma funzionava e non penalizzava troppo le prestazioni in modalità retrocompatibile,

Ma infatti: assolutamente nulla dire sui risultati. E' il come sia stato fatto che non mi va a genio.

ricordo anche che a suo tempo circolava voce che Intel avesse a sua volta preparato un evoluzione a 64bit degli x86 incompatibile con x86-64 di AMD, ma che poi non se ne fece niente perchè Microsoft si rifiutò di supportare un altro set di istruzioni dopo il bagno di sangue di Itanium.
Viene da chiedersi cosa avessero preparato, forse una modalità a 64bit molto più innovativa ? Oppure avevano deciso di estendere a 64bit gli 8 registri interi e poco altro ?

Sì, anche Intel fu costretta a preparare la sua estensione a 64 bit di x86. Purtroppo non c'è nessuna informazione in merito, ma visti i tempi ben più stretti rispetto ad AMD, e al fatto che di x86-64 ormai si conosceva tutto, probabilmente avrà realizzato una pezza estremamente simile.

Avere immediatamente codice assembly che forse-funziona-forse-no ?
Se era relativamente complesso, come minimo lo avrebbero dovuto passare al setaccio con code review multiple.
Se era relativamene semplice, sempre per gli stessi motivi conveniva riscriverlo a mano in modo da sfruttare bene i registri e le istruzioni disponibili.

Non servivano code review, nemmeno multiple. Come già detto, il codice prodotto dalla traduzione era già funzionante (ovviamente tolta roba come codice automodificante, o inserimento inline di codice binario in mezzo all'assembly): non serviva nulla. E girava pure più veloce.

L'8086 ebbe successo proprio per quello, e rimane uno use-case studiato. Come lo è stato anche il 68HC12 di Motorola, che ha seguito una strada molto simile.

Mi ricordo come erano i due set d'istruzioni e passare da una cpu all'altra
era così: https://www.youtube.com/watch?v=S9WW...mKLsuY&index=9

LOL Mi sarei fermato alla sola parte iniziale... Bella anche la canzone: non conoscevo il gruppo. Grazie. :P

Per il resto, beh, sì, le istruzioni erano diverse, ma molte erano in comune. Ma l'8086 risultava pure più semplice da programmare, IMO, e anche questo potrebbe aver invogliato al passaggio.

Concordo sulla botta di culo, ma i cambiamenti che inevitabilmente ci saranno in futuro a livello di tecnologie e di mercato, finiranno con il creare nuove finestre di opportunità.

Per eventuali concorrenti. Spero...

In compenso c'e' ancora spazio e tempo per aggiungere nuove istruzioni in base alle esigenze concrete che sono già emerse e che emergeranno.

Per lo più sarà appannaggio di estensioni custom, come peraltro avviene già da tempo.

C'è inoltre RV32E che non è ancora congelata e che potrebbe essere "ritoccata" in vari modi, prevedendo anche cosa fare con RV32EC.

Sì, non è stata ancora ratificata (dopo anni di discussioni), ma dovrebbe essere a buon punto.

Ma non è vista molto bene, ed è ritenuta sostanzialmente inutile, perché a fronte di una riduzione dell'area del chip provoca anche una riduzione della densità del codice e prestazioni inferiori. Lo ha dimostrato Patterson in un talk di giusto qualche anno fa.