WWDC 2020: con macOS Big Sur arriva la transizione verso ARM con i SoC Apple Silicon

[recoil]

Originariamente inviato da Phoenix Fire

compra e non ci pensare, si parla di due anni prima di sostituire tutta la lineup
Non si sa quando usciranno MacBook Air o Pro con la nuova architettura

nel 2021 sicuramente saranno sul mercato almeno gli Air ma presumo anche i Pro 13 almeno i base senza GPU discreta
io oggi comprerei Intel, ma solo a prezzo vantaggioso se no non ne vale la pena, al momento di venderli usati avranno un valore molto ridotto a differenza del passato

una considerazione sui Mac touchscreen: sui Mac ARM gireranno nativamente le app per iPad e iPhone, ovviamente pensate per il touchscreen
in alcuni casi si può usare il mouse, ma le gesture con più dita come fai a farle? potrebbero usare il trackpad, ma sembra un compromesso, mentre un Mac touchscreen ti darebbe la stessa esperienza d'uso del iPad
lo sviluppatore può evitarlo, ma è chiaro che se la tua app gira bene hai tutto l'interesse a fornirla su un'altra piattaforma, senza fare niente nemmeno il giro di Catalyst
pensate ai giochini o a certe utility, l'app store di iOS è pieno di quella roba e la gente la scarica
magari ti serve il Mac perché lo preferisci a un iPad, ma quando usi quelle app lo vuoi fare con il touchscreen

[cdimauro]

Originariamente inviato da RaZoR93

Secondo quale principio esattamente Apple non sarebbe capace di offrire performance paragonabili alle CPU x86 di Intel?

Anandtech la pensa diversamente dopo aver condotto molteplici test sull'A13:

https://www.anandtech.com/show/14892...d-max-review/4

SPECint è un benchmark 100% CPU.
Il fatto che Apple usi ISA ARM non significa che un core "super" wide come Lightning non sia in grado di performare come una cpu Intel. Sarebbe ora di finirla con questa aria mitologica di x86 sinceramente.

Intanto:
- non c'è ancora arrivata sugli interi, ed è indietro sulle prestazioni FP;
- è dietro una micro-architettura x86 vecchia di 5 anni (Skylake);
- Apple usa un design estremamente aggressivo (basti confrontare i diagrammi delle micro-architetture) con una spaventosa quantità di risorse a disposizione (anche qui basti confrontare gli elementi micro-architetturali: numero di istruzioni decodificate per ciclo di clock, numero di istruzioni eseguite per ciclo di clock, numero di porte d'esecuzione, dimensioni delle cache L1, L2, branch predictor, reservation station, etc.), tant'è che i suoi core ad alte prestazioni sono enormi.

Negli anni a venire Apple potrà limare un po' le prestazioni, e affidarsi per lo più ai progressi del processo produttivo di TSMC, mentre Intel ha in programma l'arrivo di nuove micro-architetture che, per il solo IPC, da Skylake arriveranno a un incremento dell'80%. Questo perché ha ancora parecchio da giocarsi (vedi ultimo punto del precedente elenco).

Originariamente inviato da Cfranco

Boh
Solo io ho notato a che frequenze girano quelle cpu Intel ?
No perché a 1.1-1.2 Ghz consumeranno poco ma ho come l' impressione che non vadano poi così veloci
Perché se parliamo di cpu a basso consumo gli ARM possono sicuramente dire la loro
Il problema è sostituire le cpu desktop o professionali

Esattamente.

Originariamente inviato da LMCH

Su Fugaku le cpu fanno di tutto e di più, uno dei punti di forza che ha è un enorme banda di I/O (che crescerà ancora di più nelle versioni di successive di A64FX) ed una versatilità maggiore (eccelle sia nei carichi "da gpu" che in quelli "da cpu").
Il rapporto prestazioni/watt è 3 volte superiore agli Xeon attualmente sul mercato, che è un bel vantaggio anche per quel che riguarda i costi operativi (Fugaku si ciuccia più di 22MWatt, una soluzione con potenza di calcolo equivalente basata du Xeon richiederebbe più di 60MWatt).
Inoltre gli ARM di punta possono permettersi di implementare solo AArch64+SVE senza avere requisiti di retrocompatibilità ... e guadagnando pure "compatibilità in avanti" a livello di software applicativo.
L'implementazione di SVE su A64FX usa registri a 512bit, ma lo stesso software fatto girare su un hardware futuro con SVE a 2048bit sfrutterebbe al massimo anche tale architettura.
Quindi ad esempio si potrebbero pure realizzare sistemi big.LITTLE dove i core "big" hanno SVE a 2048bit mentre i "little" delle SVE a 128bit e lo stesso codice girerebbe su entrambi senza modifiche).
Insomma, considerando che ARM stessa ha collaborato con Fujitsu nella progettazione ed ottimizzazione architetturale degli A64FX, non mi stupirei se i frutti di tale collaborazione apparissero anche su cpu di fascie più basse.

Voglio proprio vedere le SVE a 2048, coi problemi di clock skew che ne derivano.
Intel ha già problemi con le AVX-512, che devono girare a clock decisamente più bassi persino delle AVX a 256 bit.

Per il resto è vero: Intel si porta dietro il legacy di più 40 anni, mentre chi usa ARM può ritagliarsi l'ISA come vuole.

Per il resto e come qualcuno ha già detto, i benchmark effettuati lasciano il tempo che trovano.
Quando Apple passò dai PowerPC agli x86, sbandierò prestazioni fino a 4 volte superiori rispetto ai G5 (quando il giorno prima sbandierava prestazioni fino al doppio più veloce rispetto ai PC).
Qui non c'è nulla del genere: il silenzio. Soltanto un generico "migliori prestazioni per watt". Che vuol dire tanto per dispositivi mobili, ma non per desktop e server (vabbé che Apple ne è uscita da un bel pezzo ormai)...

[megamitch]

Io ho paura per l'obsolescenza software.

Esempio: ho un mac con High Sierra, sistema che mi risulta ancora supportato fino a che non esce Big Sur.

Stamattina volevo provare Parallels Desktop da App Store. Non me lo fa installare perché vuole almeno Mac OSX 10.14.6.

Se vado sul sito Parallels posso comprarlo e usaro anche su High Sierra.

Morale, se fanno tutto su ARM e spostano su AppStore tante applicazioni, e già oggi imac App Store non permette di scaricare versioni precedenti di una applicazione, che impatto avremo noi acquirenti ? Saremo costretti ad aggiornare più spesso i computer per obsolescenza programmata?

[bonzoxxx]

Originariamente inviato da megamitch

Io ho paura per l'obsolescenza software.

Esempio: ho un mac con High Sierra, sistema che mi risulta ancora supportato fino a che non esce Big Sur.

Stamattina volevo provare Parallels Desktop da App Store. Non me lo fa installare perché vuole almeno Mac OSX 10.14.6.

Se vado sul sito Parallels posso comprarlo e usaro anche su High Sierra.

Morale, se fanno tutto su ARM e spostano su AppStore tante applicazioni, e già oggi imac App Store non permette di scaricare versioni precedenti di una applicazione, che impatto avremo noi acquirenti ? Saremo costretti ad aggiornare più spesso i computer per obsolescenza programmata?

Ad apple non dispiacerebbe, già ora come ora con il fatto che i mac sono sostanzialmente non riparabili con tutto saldato pare proprio abbiano preso quella direzione.

[megamitch]

Originariamente inviato da Dotto Raus

Bah io non so come andrà a finire ma io entro fine estate devo acquistare il portatile. Andrò di x86 tanto per sviluppo web penso andrà bene almeno un 5/6 anni tutti. Poi si vedrà. Anche perché sono proprio a piedi adesso.

Sei obbligato a comprare Apple per via di qualche tool specifico?

[bonzoxxx]

Se office e adobe sbarcano su linux secondo me ci sarà un'impennata di adozione del pinguino

[bonzoxxx]

Idem, al momento uso prevalentemente windows per i giochi, i programmi e perché il portatile non gestisce al meglio l'autonomia.

Potrei affidarmi a wine ma non ho voglia poi se voglio usare linux ho sempre il Lenovo da combattimento con kali

Ora come ora tutti abbiamo l'ssd ma win10 su disco meccanico è un disastro eh, lentissimo

[cdimauro]

Originariamente inviato da Dotto Raus

Obbligato non sono obbligato. Voglio levarni di torno Windows per tante ragioni maturate negli ultimi anni sopratutto per problemi con l'ultimo thinkpad che ho avuto tutti derivati da Windows. Ho provato con Linux ma non è fattibile ancora per le mie esigenze. Voglio un OS unix-like con tutti quei software commerciali (Adobe, office ecc) che all'occorrenza posso utilizzare senza problemi che Linux purtroppo non mi fornisce.

Hai provato Windows 10 con WSL2?

[cdimauro]

Capito. E sui gusti non si discute.

[megamitch]

Originariamente inviato da Dotto Raus

Obbligato non sono obbligato. Voglio levarni di torno Windows per tante ragioni maturate negli ultimi anni sopratutto per problemi con l'ultimo thinkpad che ho avuto tutti derivati da Windows. Ho provato con Linux ma non è fattibile ancora per le mie esigenze. Voglio un OS unix-like con tutti quei software commerciali (Adobe, office ecc) che all'occorrenza posso utilizzare senza problemi che Linux purtroppo non mi fornisce.

Strano, in azienda sono anni che abbiano thinkpad serie T e mai un problema

[Vul]

Comunque ti ribadisco che i macbook pro 2018 in poi sono dei forni su cui è difficile mettere le mani sopra.

https://lmgtfy.com/?q=macbook+pro+hot

Aspettati:

- brew cask install macs-fan-control
il controller delle ventole del macbook da svariati problemi e a volte le ventole non partono nemmeno, vanno controllate via terminale.
Altrimenti http://tbswitcher.rugarciap.com/

- rumore di ventole perenne se programmi, specialmente d'estate, fisso con docker

- multi monitor = calore, tanto calore, specie se li attacchi a sx

- prestazioni basse e quantità di memoria bassa. Il mbp ha di base la stessa memoria di un raspberry pi da 70 euro. Fai tu. Per 8 gb in piu paghi circa 200 euro in piu. Inutile dire che salire di frequenze e modelli di cpu è un problema per il calore.

Cioè non riesco a capire questa tua incomprensibile fissa per "ommioddio non mi piace la grafica windows", quando qualsiasi macbook pro skylake in su è una immensa fonte di problemi.

Altre cose a caso:

- caricare dal lato sinistro del macbook, via adattatore, può portare al bruciare la componentistica, usa sempre la parte dx (idem per monitor) (ah, se hai il macbook non stra carrozzato non hai due usb-c a dx, quindi devi per forza farlo a sx)

- stai comprando roba che è già programmata per essere obsoleta tra qualche anno

O ti prendi un notebook e ci metti linux/windows o aspetti arm (ma lì puoi dire addio al dual boot, potrebbe essere importante, anche se io non l'ho mai usato).

Comprare un mbp skylake in poi è un disastro di acquisto sotto tutti i punti di vista.

Io non so quanto tu abbia usato un mbp in vita tua, ma il case in alluminio diventa davvero bollente anche con i modelli vecchi, con quelli degli ultimi anni è inutilizzabile.

Questa tua fissa per il mbp mi sa tanto, onestamente, di una persona che un macbook non l'ha mai usato a sufficienza.

Io lo faccio per lavoro e ringrazio dio di avere un fisso a casa e un altro portatile win.

Sia chiaro, non ho nulla in contrario ad Apple, non vedo l'ora esca il nuovo ipad pro per comprarlo ad esempio e ho avuto 4 mbp in vita mia, ma poichè hai detto che fai il dev ti stai fissando con roba che non serve e che andrà a influire molto piu negativamente sul tuo lavoro del quanto lo faccia l'aspetto dell'UI che tanto ti interessa.

In compenso, però, macos è d'obbligo se devi compilare per iOS e molto utile per testare roba su safari (che è l'internet explorer dei browser).

Dammi retta, non ha senso prendere un mbp ora, (tra l'altro se fai il dev non te lo dovrebbe dare il tuo datore di lavoro...?) quando tra qualche mese escono le versioni arm che risolveranno il 90% dei problemi attuali dei mbp.

[LMCH]

Originariamente inviato da cdimauro

Voglio proprio vedere le SVE a 2048, coi problemi di clock skew che ne derivano.
Intel ha già problemi con le AVX-512, che devono girare a clock decisamente più bassi persino delle AVX a 256 bit.

I tipi di ARM hanno ben chiaro il problema, infatti il set di istruzioni è stato pensato per porre il minor numero di vincoli possibile per quel che riguarda l'implementazione.
Invece di visualizzare l'implementazione in termini di "registri a 2048bit", visualizzala come "gruppo di 16 registri a 128bit" e relative ALU a 128bit che in base all'implementazione vanno da 1 a 16, con tutte le possibili varianti (es: solo 8 ALU ma a frequenza di clock doppia).

Originariamente inviato da cdimauro

Per il resto è vero: Intel si porta dietro il legacy di più 40 anni, mentre chi usa ARM può ritagliarsi l'ISA come vuole.

Si,
ARM Ltd. ha creato nel tempo una famiglia di set di istruzioni che viene incontro un po' a tutte le esigenze, con il passaggio ai 64bit hanno creato un nuovo set di istruzioni "da zero" con tutti i vantaggi che ne derivano, ma secondo me Risc-V è ancora più interessante in termini di versatilità e potenziale di crescita.

[cdimauro]

Originariamente inviato da LMCH

I tipi di ARM hanno ben chiaro il problema, infatti il set di istruzioni è stato pensato per porre il minor numero di vincoli possibile per quel che riguarda l'implementazione.
Invece di visualizzare l'implementazione in termini di "registri a 2048bit", visualizzala come "gruppo di 16 registri a 128bit" e relative ALU a 128bit che in base all'implementazione vanno da 1 a 16, con tutte le possibili varianti (es: solo 8 ALU ma a frequenza di clock doppia).

Questo discorso lo si può applicare a qualunque architettura, però, ed è stato già fatto in passato.

Ad esempio la prima implementazione delle SSE (con vettori a 128 bit) arrivò col Pentium III, che però "spezzava" tali istruzioni in coppie di uop ognuna in grado di gestire 64 bit dei 128 bit.

Il problema con queste implementazioni è che ti serve un backend in grado di eseguire il doppio delle uop per ciclo di clock, se vuoi mantenere lo stesso data rate, il che non è affatto possibile (i costi esplodono all'aumentare del numero di porte d'esecuzione).

Si,
ARM Ltd. ha creato nel tempo una famiglia di set di istruzioni che viene incontro un po' a tutte le esigenze, con il passaggio ai 64bit hanno creato un nuovo set di istruzioni "da zero" con tutti i vantaggi che ne derivano, ma secondo me Risc-V è ancora più interessante in termini di versatilità e potenziale di crescita.

Sulla potenzialità di crescita concordo, perché la stanno abbracciando praticamente tutti i produttori di processori, e principalmente perché non ci sono royalty da pagare.

Non concordo affatto sulla versatilità, perché è un'ISA progettata da accademici, e se ne vedono tutti i limiti.

Hanno cercato a tutti i costi la "purezza" nella struttura degli opcode, che li hanno costretti a notevoli compromessi. Salvo poi calare le braghe quando hanno sbattuto le corna sul design dell'estensione SIMD (che doveva essere pronta almeno un paio d'anni fa, se non ricordo male, e ci stanno ancora lavorando), che li ha sostanzialmente obbligati a sfornare parecchi formati per gli opcode.

Per non parlare dei proclami sulle estensioni immodificabili (una volta finalizzati), salvo poi essersi accorti della colossale sciocchezza di aver obbligato a implementare anche le divisioni in hardware anche se ti servono soltanto le moltiplicazioni, visto che l'estensione standardizzata li prevedeva obbligatoriamente entrambi. Per risolvere il problema hanno nuovamente calato le braghe e tirato fuori le "sottoestensioni", dove puoi avere soltanto le moltiplicazioni. Ma è soltanto un esempio, perché di questi errori ne hanno commessi diversi, e creato apposite sottoestensioni per metterci una pezza.
Il bello è che hanno ancora la faccia di bronzo di affermare che non c'è frammentazione nell'ISA...

Dulcis in fundo, hanno voluto mantenere il set d'istruzione di base ridotto all'osso per salvaguardare la purezza (RISC -> set d'istruzioni ridotto), ma si sono scontrati sia con la scarsa densità di codice (risolto, in parte, con l'estensione "compressa", C) sia con problemi prestazionali (dovuti al fatto di dover eseguire più istruzioni rispetto ad altre architettura, per eseguire gli stessi compiti).
Per cercare di metterci una pezza hanno suggerito (nonché pubblicato entusiastici paper per evangelizzare la trovata "geniale") di implementare nel frontend il macro-op fusion (roba che Intel fa da una vita. E meno male che tanti esperti di questo forum dicono che non innovi) per convertire una coppia di istruzioni a 16-bit compresse in una sola istruzione a 32 bit, in modo da risolvere almeno il problema delle prestazioni (ma dovendo far ricorso sia al set d'istruzioni compresso, sia snaturando la semplicità del frontend di cui andavano fieri, implementando un meccanismo di pattern-matching delle istruzioni che costringe pure ad allungare la pipeline).

E sempre su quest'onda la ciliegina sulla torta è rappresentata da una sola modalità d'indirizzamento per referenziare la memoria. Il che costringe i compilatori a generare codice apposito quando serve referenziare array di elementi (operazione tutt'altro che rara, come sappiamo), quando altre architetture risolvono il problema con l'apposita modalità d'indirizzamento [registro base + registro indice scalato + offset].

Mi fermo qui, che è meglio.

Aggiungo soltanto che ARM con ARMv8/ARM64 ha fatto un ottimo lavoro, e pur avendo commesso l'errore di non implementare un set d'istruzioni compresso / a 16-bit (come Thumb, insomma), ha dato una bella lezione di come si progetta un'ISA che tenga conto di come funziona il mondo reale e delle esigenze degli sviluppatori.

[LMCH]

Originariamente inviato da cdimauro

Sulla potenzialità di crescita concordo, perché la stanno abbracciando praticamente tutti i produttori di processori, e principalmente perché non ci sono royalty da pagare.

Fossero solo le royalties il problema allora OpenRisc, Amber (core ARMv2, set d'istruzioni non coperto da brevetti), J2/J4/J6 (reimplementazioni di Hitachi SH-2, SH-4 ed SH4 a 64bit di cui sono scaduti i brevetti) sarebbero già ovunque (specialmente AMBER e J2 visto che hanno un ecosistema software completo).

Originariamente inviato da cdimauro

Non concordo affatto sulla versatilità, perché è un'ISA progettata da accademici, e se ne vedono tutti i limiti.

A parte che allo sviluppo delle attuali specifiche di Risc-V concorrono anche aziende, gli accademici coinvolti avevano già una certa esperienza pratica nella progettazione di processori ed hanno attinto da quanto sviluppato sia a livello accademico che commerciale.

Inoltre non si parla di un ISA, ma di una famiglia di ISA per cui si può sviluppare un ecosistema software ed hardware comune.
Attualmente i "set di istruzioni base" sono RV32I, RV32E, RV64I con inoltre "predisposizioni" per un eventuale RV128I.
Ed oltre a questo l'idea di base è di lasciare il più libera possibile l'implementazione architetturale mantenendo comunque buona compatibilità a livello software.

I limiti mi sembrano più che altro dei compromessi tra requisiti contrastanti, ma quelli ci sono in tutte le architetture (dagli x86 agli ARM).

Originariamente inviato da cdimauro

Hanno cercato a tutti i costi la "purezza" nella struttura degli opcode, che li hanno costretti a notevoli compromessi. Salvo poi calare le braghe quando hanno sbattuto le corna sul design dell'estensione SIMD (che doveva essere pronta almeno un paio d'anni fa, se non ricordo male, e ci stanno ancora lavorando), che li ha sostanzialmente obbligati a sfornare parecchi formati per gli opcode.

Attualmente Risc-V come famiglia di architetture è ancora in evoluzione ed alcune delle estensioni sono ancora in fase di definizione, specialmente quelle su cui ci sono punti di vista molto diversi.
Nel caso delle SIMD sono state "bloccate" perche non c'era un bisogno pressante di averle subito e perchè si volevano valutare bene le questioni sia teoriche che pratiche e commerciali a riguardo.
Se non sbaglio ora l'idea di massima è avere delle estensioni "P" (Packed SIMD) che usano i GPR e delle estensioni "V" che introducono un set di registri vettoriali con istruzioni simili alle SVE di Arm Ltd. come concetto.

Originariamente inviato da cdimauro

Per non parlare dei proclami sulle estensioni immodificabili (una volta finalizzati), salvo poi essersi accorti della colossale sciocchezza di aver obbligato a implementare anche le divisioni in hardware anche se ti servono soltanto le moltiplicazioni, visto che l'estensione standardizzata li prevedeva obbligatoriamente entrambi. Per risolvere il problema hanno nuovamente calato le braghe e tirato fuori le "sottoestensioni", dove puoi avere soltanto le moltiplicazioni. Ma è soltanto un esempio, perché di questi errori ne hanno commessi diversi, e creato apposite sottoestensioni per metterci una pezza.
Il bello è che hanno ancora la faccia di bronzo di affermare che non c'è frammentazione nell'ISA...

Uhm! Sei sicuro della faccenda della divisione ? Per quanto ne so se si dichiara che una cpu Risc-V supporta l'estensione M, deve avere sia moltiplicazioni che divisioni, solo che l'implementazione viene lasciata libera (quindi ad esempio si può decidere di implementare la divisione in modo "economico", mica è obbligatorio che le divisioni siano eseguite in un singolo ciclo).

Poi, devo aggiungere che in 35 anni e passa di sviluppo software con ogni tipo di microprocessore e qualche DSP tanto per non farmi mancare niente, se hai bisogno della moltiplicazione in hardware, il 99% delle volte torna utile anche la divisione in hardware (magari lentissima, ma sempre meglio di doverla fare in software) oppure la complessità aggiuntiva del divisore è trascurabile rispetto al core nel suo complesso.

Originariamente inviato da cdimauro

Dulcis in fundo, hanno voluto mantenere il set d'istruzione di base ridotto all'osso per salvaguardare la purezza (RISC -> set d'istruzioni ridotto), ma si sono scontrati sia con la scarsa densità di codice (risolto, in parte, con l'estensione "compressa", C) sia con problemi prestazionali (dovuti al fatto di dover eseguire più istruzioni rispetto ad altre architettura, per eseguire gli stessi compiti).

Non è che sia il problema che pensi, c'è ancora spazio nei set di istruzioni per aggiungere ulteriori estensioni utili.
Inoltre le estensioni C erano previste praticamente dall'inizio del progetto, non è che sono state aggiunte dopo come ad esempio è avvenuto con ARM, MIPS ed altre architetture.

Originariamente inviato da cdimauro

Per cercare di metterci una pezza hanno suggerito (nonché pubblicato entusiastici paper per evangelizzare la trovata "geniale") di implementare nel frontend il macro-op fusion (roba che Intel fa da una vita. E meno male che tanti esperti di questo forum dicono che non innovi) per convertire una coppia di istruzioni a 16-bit compresse in una sola istruzione a 32 bit, in modo da risolvere almeno il problema delle prestazioni (ma dovendo far ricorso sia al set d'istruzioni compresso, sia snaturando la semplicità del frontend di cui andavano fieri, implementando un meccanismo di pattern-matching delle istruzioni che costringe pure ad allungare la pipeline).

Veramente la macro-op fusion era prevista fin dall'inizio, in particolare per ottimizzare l'esecuzione di jump brevi "in avanti" producendo una sequenza di micro-op condizionali e senza dover eseguire una jump prediction, come pure per ottimizzare le moltiplicazioni da XLEN bit con risultato a 2*XLEN bit, le divisioni+resto e le divisioni con check del caso di divisione per zero "senza usare eccezioni/trap".
E' solo una questione di implementazione.
Se serve giusto un processore senza tante pretese è possibile farne un implementazione economica in-order, senza jump-prediction, senza macro-op-fusion e pure senza istruzioni compatte.
Se invece vuoi qualcosa di più potente sono già previste un sacco di possibilità ed i compilatori possono generare codice che sfrutta bene l'hardware in entrambi i casi senza dover ricompilare (nel caso in cui ci sia il supporto dell' estensione C, in caso contrario basta ricompilare cambiando un flag, come si fa con gli ARM)

Originariamente inviato da cdimauro

E sempre su quest'onda la ciliegina sulla torta è rappresentata da una sola modalità d'indirizzamento per referenziare la memoria. Il che costringe i compilatori a generare codice apposito quando serve referenziare array di elementi (operazione tutt'altro che rara, come sappiamo), quando altre architetture risolvono il problema con l'apposita modalità d'indirizzamento [registro base + registro indice scalato + offset].

Nel caso dei Risc-V il problema non è così grave come lo sarebbe su un architettura con meno registri e con set di istruzioni meno regolari.
In primo luogo, con le estensioni C diventa possibile generare sequenze di istruzioni "facili da fondere" che implementano [registro base + registro indice scalato + offset], in secondo luogo se si deve "scorrere" un array spesso si usa preincremento/postincremento (o a livello di codice sorgente o come ottimizzazione fatta dal compilatore quando identifica indicizzazioni "sequenziali") ed anche quel tipo di sequenza si presta bene ad essere fusa.

Originariamente inviato da cdimauro

Aggiungo soltanto che ARM con ARMv8/ARM64 ha fatto un ottimo lavoro, e pur avendo commesso l'errore di non implementare un set d'istruzioni compresso / a 16-bit (come Thumb, insomma), ha dato una bella lezione di come si progetta un'ISA che tenga conto di come funziona il mondo reale e delle esigenze degli sviluppatori.

Risc-V non è che sia tanto da meno, permette di implementare le istruzioni "compresse" per risparmiare memoria e banda di I/O nel fetch di istruzioni ed al tempo stesso di macro-fonderle (tra loro o con istruzioni più "lunghe") se serve un architettura ad alte prestazioni tenendo conto delle esigenze di sviluppatori di software e progettisti di hardware.
Aggiungi il margine di crescita che ha a livello di "istruzioni ancora da assegnare" e ne vien fuori una famiglia di set di istruzioni mica male.

Per ora sono in commercio imlementazioni di Risc-V "per applicazioni embedded a basso costo", ma man mano che si finalizzano le varie estensioni mi sa che ne vedremo delle belle.
Poi non è da trascurare il fatto che Risc-V non ha bisogno di essere "il più potente di tutti" per avere successo e fare le scarpe ad ARM ed x86, gli basta avere prestazioni sufficienti ed avere un buon ecosistema software, senza contare che il fatto di essere libero da brevetti e già ora molto flessibile come possibili implementazioni lo rende estremamene interessante in settori in cui servono fornitori indipendenti per mettersi al riparo da brutte sorprese oppure chip "speciali" che devono avere implementazioni molto particolari ed al tempo stesso un buon ecosistema software già disponibile.

Non è un caso se ad esempio OrzakIC stia sviluppando una "cpu venusiana" per conto della NASA basandola proprio su Risc-V.
cpu venusiana = cpu realizzata su substrato di SiC (carburo di silicio) capace di funzionare a 500°C di temperatura senza sistemi di raffreddamento (la temperatura al suolo su Venere sta sui 460°C).

[cdimauro]

Originariamente inviato da LMCH

Fossero solo le royalties il problema allora OpenRisc, Amber (core ARMv2, set d'istruzioni non coperto da brevetti), J2/J4/J6 (reimplementazioni di Hitachi SH-2, SH-4 ed SH4 a 64bit di cui sono scaduti i brevetti) sarebbero già ovunque (specialmente AMBER e J2 visto che hanno un ecosistema software completo).

No, non sono soltanto le royalty chiaramente, anche se è il fattore più importante.

Le ISA che hai citato sono troppe legate all'embedded, mentre RISC-V s'è prefisso di essere utilizzata dall'embedded low-cost/resource all'HPC.

A parte che allo sviluppo delle attuali specifiche di Risc-V concorrono anche aziende, gli accademici coinvolti avevano già una certa esperienza pratica nella progettazione di processori ed hanno attinto da quanto sviluppato sia a livello accademico che commerciale.

No, è partito tutto come progetto accademico (per rimpiazzare l'ISA studiata nei corsi universitari con una più moderna), e il core dell'ISA più altre estensioni base/comuni sono state sviluppate lì.

Soltanto successivamente (e da un po' di anni) si sono unite delle aziende, una volta che il progetto ha cominciato a prendere con delle implementazioni (le prime realizzate sempre nelle università) e il supporto software.

Poi che gli accademici avessero esperienza non ha impedito loro di commettere degli errori, per l'appunto.

Inoltre non si parla di un ISA, ma di una famiglia di ISA per cui si può sviluppare un ecosistema software ed hardware comune.
Attualmente i "set di istruzioni base" sono RV32I, RV32E, RV64I con inoltre "predisposizioni" per un eventuale RV128I.
Ed oltre a questo l'idea di base è di lasciare il più libera possibile l'implementazione architetturale mantenendo comunque buona compatibilità a livello software.

RV32E è soltanto una castrazione di RV32I, che peraltro vorrebbero pure cambiare visto che si sono accorti di alcune scelte sbagliate (tanto per cambiare) proprio nell'estensione C del set compresso, che per questa versione embedded sono non sono inutili (occupano opcode inutilizzabili in quest'ambito) ma che potrebbero essere usate per aggiungere altre preziose (nonché ben più utili) istruzioni.

I limiti mi sembrano più che altro dei compromessi tra requisiti contrastanti, ma quelli ci sono in tutte le architetture (dagli x86 agli ARM).

Sì, ci sono in tutte le architetture, ma quelle che citi si portano dietro decenni di legacy.

Qui parliamo di un'ISA completamente nuova. Di pacca. E, con tutti gli use-case ed errori del passato da tenere bene a mente, avrebbero dovuto tirarla fuori senza gli errori madornali che ho citato.

Attualmente Risc-V come famiglia di architetture è ancora in evoluzione ed alcune delle estensioni sono ancora in fase di definizione, specialmente quelle su cui ci sono punti di vista molto diversi.

Dovrebbero darsi una mossa, specialmente considerando quanti hanno abbracciato quest'ISA, e quante "teste pregiate" ci siano dietro ormai (provenienti da tante università e aziende).

Il progetto è nato nel 2011, e di tempo ne hanno avuto abbastanza.

Nel caso delle SIMD sono state "bloccate" perche non c'era un bisogno pressante di averle subito e perchè si volevano valutare bene le questioni sia teoriche che pratiche e commerciali a riguardo.
Se non sbaglio ora l'idea di massima è avere delle estensioni "P" (Packed SIMD) che usano i GPR e delle estensioni "V" che introducono un set di registri vettoriali con istruzioni simili alle SVE di Arm Ltd. come concetto.

No, è successo di peggio, invece. Sono partiti con un'estensione SIMD spaziale che sarebbe stata flessibilissima e fichissima, facendo un'immensa propaganda e con profusioni d'incenso (basti vedere i talk e le presentazioni di un po' di anni fa).

Salvo poi dover togliere di mezzo il cavallo di battaglia, la punta di diamante di questa estensione (il polimorfismo dei tipi di dati), perché chi realizza microarchitetture ha fatto notare che l'implementazione sarebbe stato parecchio complicata (e probabilmente le prestazioni ne avrebbero risentite).
E non è che ci volesse un'arca di scienze per capirlo, eh!

Inoltre avrebbero voluto mantenere la struttura base degli opcode, in modo a rendere semplice la decodifica. Invece anche qui hanno dovuto fare retromarcia perché per le istruzioni SIMD tale struttura è troppo limitata e castrante, specialmente perché hanno voluto anche aggiungere delle caratteristiche sono molto utili in quest'ambito (primo fra tutti le "maschere". Già introdotte da Intel con Larrabee prima, Xeon Phi poi, e con AVX-512).
Questo li ha costretti a tirare fuori parecchi opcode per compattare al meglio lo spazio a disposizione per infilarci i campi addizionali che servivano allo scopo.
Altrimenti avrebbero dovuto utilizzare opcode a 48 bit, mandando in frantumi la semplicità dell'ISA "base".

Nel frattempo, visto che le estensioni SIMD vettoriali a lunghezza variabile dei vettori (come SVE di ARM, appunto) sono overkill in ambito embedded, hanno dovuto aggiungere le estensioni SIMD "packed" classiche (come quelle che conosciamo), che tanto le aziende avevano già deciso per conto loro di implementare, visto che erano e rimangono utili (specialmente in ambito embedded. Dove peraltro usano i registri GP per risparmiare sull'implementazione dell'ISA).

Uhm! Sei sicuro della faccenda della divisione ? Per quanto ne so se si dichiara che una cpu Risc-V supporta l'estensione M, deve avere sia moltiplicazioni che divisioni, solo che l'implementazione viene lasciata libera (quindi ad esempio si può decidere di implementare la divisione in modo "economico", mica è obbligatorio che le divisioni siano eseguite in un singolo ciclo).

Sono assolutamente sicuro (anche perché seguo RISC-V da parecchio tempo ormai).

Infatti se vai prendere una vecchia versione del PDF con le specifiche dell'ISA trovi soltanto l'estensione M, per l'appunto (e che ti obbliga a implementare tutti i tipi di moltiplicazione e divisione definiti), mentre le più recenti riportano delle sotto-estensioni in cui sono definite soltanto le moltiplicazioni.

Poi, devo aggiungere che in 35 anni e passa di sviluppo software con ogni tipo di microprocessore e qualche DSP tanto per non farmi mancare niente, se hai bisogno della moltiplicazione in hardware, il 99% delle volte torna utile anche la divisione in hardware (magari lentissima, ma sempre meglio di doverla fare in software) oppure la complessità aggiuntiva del divisore è trascurabile rispetto al core nel suo complesso.

No, invece non è trascurabile, e sono state le aziende che lavorano in ambito embedded a fare pressioni per introdurre le sotto-estensioni, e liberarsi della divisione in hardware.

Spesso a loro serve soltanto la moltiplicazione, che tante volte consente di evitare la divisione moltiplicando opportunamente il registro con un determinato valore e scalando (shiftando) poi il risultato. Roba ordinaria, comunque: lo fanno già alcuni compilatori.

Non è che sia il problema che pensi, c'è ancora spazio nei set di istruzioni per aggiungere ulteriori estensioni utili.

Eh... no! L'ISA base più altre estensioni sono ormai finalizzate e non si possono toccare (hanno fatto questa promessa proprio per avere un'ISA stabile, e adesso la devono mantenere).

Per cui di aggiunte non se ne parla. Ma per risolvere le rogne saranno costretti ad aggiungere delle apposite estensioni, appunto. Che poi è la stessa cosa, anche se così salvano formalmente l faccia.

Ma tanto così facendo aumenteranno la frammentazione.

Inoltre le estensioni C erano previste praticamente dall'inizio del progetto, non è che sono state aggiunte dopo come ad esempio è avvenuto con ARM, MIPS ed altre architetture.

Non è così. Nel progetto iniziale avevano previsto una futura estensione compressa, perché sapevano già che sarebbe servita, visto che l'ISA "base" avrebbe sicuramente sofferto di problemi di scarsa densità di codice (non che ci volesse molto a capirlo, guardando le istruzioni).

Ma non l'avevano definita. Questo è avvenuto dopo e in parallelo, con uno dei progettisti di RISC-V che ha proposto l'estensione C. Come puoi vedere dalla sua tesi.

Veramente la macro-op fusion era prevista fin dall'inizio, in particolare per ottimizzare l'esecuzione di jump brevi "in avanti" producendo una sequenza di micro-op condizionali e senza dover eseguire una jump prediction, come pure per ottimizzare le moltiplicazioni da XLEN bit con risultato a 2*XLEN bit, le divisioni+resto e le divisioni con check del caso di divisione per zero "senza usare eccezioni/trap".

Ancora una volta no. Mi spiace, ma è evidente che tu non segui attivamente lo sviluppo e il mondo di RISC-V in generale (lo seguo da anni e mi spazzo puntualmente tutta la documentazione prodotta, inclusi i video su YT dei talk su RISC-V nelle varie conferenze).

Adesso non lo trovo, ma il paper di Patterson & co., presentato qualche anno fa, nasce come proposta per risolvere quei problemi. Dunque una soluzione postuma.

E' solo una questione di implementazione.
Se serve giusto un processore senza tante pretese è possibile farne un implementazione economica in-order, senza jump-prediction, senza macro-op-fusion e pure senza istruzioni compatte.
Se invece vuoi qualcosa di più potente sono già previste un sacco di possibilità ed i compilatori possono generare codice che sfrutta bene l'hardware in entrambi i casi senza dover ricompilare (nel caso in cui ci sia il supporto dell' estensione C, in caso contrario basta ricompilare cambiando un flag, come si fa con gli ARM)

Che sia una questione di pura implementazione è pacifico. Ma, come dicevo, sono costretti ad aggiungere qualche stadio di pipeline per implementarlo. Soprattutto sono costretti a stravolgere il modello di semplicità di RISC-V, visto che tale implementazione ti costringe, ad esempio, a dover scrivere su 2 registri per "macro-op"/istruzione eseguita.

In ogni caso il macro-op fusion funziona soltanto con l'estensione C, che quindi diviene obbligatoria.

Nel caso dei Risc-V il problema non è così grave come lo sarebbe su un architettura con meno registri e con set di istruzioni meno regolari.
In primo luogo, con le estensioni C diventa possibile generare sequenze di istruzioni "facili da fondere" che implementano [registro base + registro indice scalato + offset], in secondo luogo se si deve "scorrere" un array spesso si usa preincremento/postincremento (o a livello di codice sorgente o come ottimizzazione fatta dal compilatore quando identifica indicizzazioni "sequenziali") ed anche quel tipo di sequenza si presta bene ad essere fusa.

Sì, ma rimane una pecca dell'ISA che hanno dovuto ammettere anche i progettisti dell'ISA davanti ad alcuni benchmark SPEC in cui il netto calo prestazionale (rispetto alle altre architetture) è dovuto proprio alla mancanza di modalità d'indirizzamento più complesse.

Cosa che, invece, ARM ha saputo ben prevedere e risolvere con ARMv8, che mette a disposizione diverse modalità d'indirizzamento complicate, molti utili in tanti casi comuni come quelli citati.

Reduced and Simple isn't always better.

Risc-V non è che sia tanto da meno, permette di implementare le istruzioni "compresse" per risparmiare memoria e banda di I/O nel fetch di istruzioni ed al tempo stesso di macro-fonderle (tra loro o con istruzioni più "lunghe") se serve un architettura ad alte prestazioni tenendo conto delle esigenze di sviluppatori di software e progettisti di hardware.

Sono tutte complicazioni che con un'ISA progettata meglio non ci sarebbero state.

Aggiungi il margine di crescita che ha a livello di "istruzioni ancora da assegnare" e ne vien fuori una famiglia di set di istruzioni mica male.

Ehm... no! Per quanto detto sopra, l'ISA base e diverse estensioni sono già state ratificate e sono intoccabili.

Aggiungere singole istruzioni per risolvere i problemi comuni di cui sopra richiederebbe la realizzazione di tante micro-estensioni, che farebbe aumentare ancora di più la frammentazione.

Certa roba sarebbe dovuta arrivare già nell'ISA base, anziché ridursi all'osso.

Che poi il paradosso è che tante estensioni SIMD sono farcite di istruzioni (alla faccia del set ridotto). Ad esempio quella per l'FPU ha persino istruzioni di minimo e massimo!

Ma si sono persi per strada tanta roba utile.

Per ora sono in commercio imlementazioni di Risc-V "per applicazioni embedded a basso costo", ma man mano che si finalizzano le varie estensioni mi sa che ne vedremo delle belle.

Non è così. Vedi sopra.

E non è un caso che una delle estensioni & implementazioni RISC-V più comuni e utilizzate è quella PULP dell'università di Zurigo, che di base aggiunge diverse estensioni custom che consentono di implementare loop in hardware, come pure istruzioni di load/store con pre/post-incremento del registro base. Quindi di fatto hanno colmato alcune di quelle lacune.
Ma PULP rimane un'estensione custom...

Poi non è da trascurare il fatto che Risc-V non ha bisogno di essere "il più potente di tutti" per avere successo e fare le scarpe ad ARM ed x86, gli basta avere prestazioni sufficienti ed avere un buon ecosistema software, senza contare che il fatto di essere libero da brevetti e già ora molto flessibile come possibili implementazioni lo rende estremamene interessante in settori in cui servono fornitori indipendenti per mettersi al riparo da brutte sorprese oppure chip "speciali" che devono avere implementazioni molto particolari ed al tempo stesso un buon ecosistema software già disponibile.

E su questo mi pare che ho avuto nulla da dire. Anzi, l'ho detto pure io che è un vantaggio.

Non è un caso se ad esempio OrzakIC stia sviluppando una "cpu venusiana" per conto della NASA basandola proprio su Risc-V.
cpu venusiana = cpu realizzata su substrato di SiC (carburo di silicio) capace di funzionare a 500°C di temperatura senza sistemi di raffreddamento (la temperatura al suolo su Venere sta sui 460°C).

Interessante.