|
|
|
|
Strumenti |
09-01-2021, 08:39 | #61 | |||||||||||||||
Senior Member
Iscritto dal: Jan 2002
Città: Germania
Messaggi: 26110
|
Quote:
Quote:
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. Quote:
Quote:
Quote:
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. Quote:
Quote:
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". Quote:
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). Quote:
Il vantaggio di 8086 fu, infatti, proprio questo: convertire molto velocemente l'esistente libreria di 8085, ma offrendo un'architettura migliore. Quote:
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... Quote:
Peraltro questa è proprio l'n-esima dimostrazione che, checché se ne dica, le architetture CONTINO, eccome! Quote:
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. Quote:
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. Quote:
Che ovviamente è un modello vincente rispetto a tutti gli altri progetti open source. Quote:
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.
__________________
Per iniziare a programmare c'è solo Python con questo o quest'altro (più avanzato) libro @LinkedIn Non parlo in alcun modo a nome dell'azienda per la quale lavoro Ho poco tempo per frequentare il forum; eventualmente, contattatemi in PVT o nel mio sito. Fanboys Ultima modifica di cdimauro : 09-01-2021 alle 08:42. |
|||||||||||||||
10-01-2021, 02:05 | #62 | ||||||||
Senior Member
Iscritto dal: Jan 2007
Messaggi: 5440
|
Quote:
Decisamente c'erano troppe differenze a livello di tecnologia e risorse per considerarlo un confronto ad armi pari. Quote:
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". Quote:
Quote:
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). Quote:
Ripeto. Nulla vieta in futuro di "ripartire da capo" con un Risc VI ecc. Quote:
Quote:
Quote:
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. |
||||||||
10-01-2021, 08:40 | #63 | ||
Senior Member
Iscritto dal: Oct 2002
Messaggi: 5273
|
Quote:
Quote:
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
__________________
____€UROPA: comunità di -PAGLIACCI €SP€RI€NTI SOLO del "B€N VIV€R€" come fosse COMANDAM€NTO nel loro PROGR€SSISMO di SCIMMI€ S€MPR€ PIU' TOTALI sopprimi** anche tu la miseria massmediale delle serie di telefilms USA (polizziesky, social-medical/comedy, etc...) estranei a cultura. **compresi i doppiatori in copie mentali approvate con le scimmie-fans ripetitrici degli esempi infusi->manda in fogne di calcutta tutta questa roba<- Ultima modifica di raxas : 10-01-2021 alle 08:52. |
||
10-01-2021, 09:56 | #64 | ||||||||||||||||
Senior Member
Iscritto dal: Jan 2002
Città: Germania
Messaggi: 26110
|
Quote:
Comunque ne abbiamo già ampiamente parlato nell'altro thread, dove ci sono tutte le informazioni e i paper. Quote:
Però parlavo d'altro. Mi spiego meglio dopo. Quote:
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. Quote:
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. Quote:
Le prestazioni, al contrario, sarebbero pure aumentate nettamente riprogettando il tutto. Quote:
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. Quote:
Semmai è 8086 che ha fatto fuori iAPX 432. Quote:
Quote:
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. Quote:
Quote:
Per cui l'unica sarà ricorrere a estensioni personalizzate. "Il dado è tratto..." Quote:
Servono soluzioni nuove che ci consentano di divenire completamente autonomi da questi padri-padroni. Quote:
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. Quote:
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... Quote:
Quote:
__________________
Per iniziare a programmare c'è solo Python con questo o quest'altro (più avanzato) libro @LinkedIn Non parlo in alcun modo a nome dell'azienda per la quale lavoro Ho poco tempo per frequentare il forum; eventualmente, contattatemi in PVT o nel mio sito. Fanboys |
||||||||||||||||
10-01-2021, 11:26 | #65 |
Senior Member
Iscritto dal: Oct 2002
Messaggi: 5273
|
è molto semplice : fare un qualcosa che si costruisca la migliore architettura operativa possibile, cioè che la cambi al volo
__________________
____€UROPA: comunità di -PAGLIACCI €SP€RI€NTI SOLO del "B€N VIV€R€" come fosse COMANDAM€NTO nel loro PROGR€SSISMO di SCIMMI€ S€MPR€ PIU' TOTALI sopprimi** anche tu la miseria massmediale delle serie di telefilms USA (polizziesky, social-medical/comedy, etc...) estranei a cultura. **compresi i doppiatori in copie mentali approvate con le scimmie-fans ripetitrici degli esempi infusi->manda in fogne di calcutta tutta questa roba<- |
11-01-2021, 05:50 | #66 |
Senior Member
Iscritto dal: Jan 2002
Città: Germania
Messaggi: 26110
|
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.
__________________
Per iniziare a programmare c'è solo Python con questo o quest'altro (più avanzato) libro @LinkedIn Non parlo in alcun modo a nome dell'azienda per la quale lavoro Ho poco tempo per frequentare il forum; eventualmente, contattatemi in PVT o nel mio sito. Fanboys |
11-01-2021, 08:40 | #67 | |
Senior Member
Iscritto dal: Jan 2015
Città: Euskal Herria
Messaggi: 3665
|
Quote:
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. |
|
12-01-2021, 06:21 | #68 | |||||||
Senior Member
Iscritto dal: Jan 2002
Città: Germania
Messaggi: 26110
|
No, nasce per essere un dispositivo (ri)programmabile (da cui la P dell'acronimo), a seconda di quello che serve implementare (in hardware).
Quote:
Quote:
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. Quote:
Quote:
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. Quote:
Quote:
Quote:
__________________
Per iniziare a programmare c'è solo Python con questo o quest'altro (più avanzato) libro @LinkedIn Non parlo in alcun modo a nome dell'azienda per la quale lavoro Ho poco tempo per frequentare il forum; eventualmente, contattatemi in PVT o nel mio sito. Fanboys |
|||||||
12-01-2021, 07:50 | #69 | |||
Senior Member
Iscritto dal: Jan 2015
Città: Euskal Herria
Messaggi: 3665
|
Quote:
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. Quote:
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). Quote:
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! Ultima modifica di Pino90 : 12-01-2021 alle 07:52. |
|||
12-01-2021, 15:40 | #70 | ||||||||||||
Senior Member
Iscritto dal: Jan 2007
Messaggi: 5440
|
Quote:
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) Quote:
Quote:
Quindi ci sono limiti ben precisi su quel che si può ottenere implementando due decoder molto differenti. Quote:
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. Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
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. Quote:
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) 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. |
||||||||||||
16-01-2021, 09:01 | #71 | |||||||||||||||
Senior Member
Iscritto dal: Jan 2002
Città: Germania
Messaggi: 26110
|
Rieccomi. Finalmente ho abbastanza tempo da dedicare a questo lungo (ma fantastico) thread.
Quote:
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). Quote:
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. Quote:
Quote:
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. Quote:
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. Quote:
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. Quote:
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. Quote:
Quote:
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. Quote:
Quote:
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. Quote:
Quote:
Quote:
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. Quote:
__________________
Per iniziare a programmare c'è solo Python con questo o quest'altro (più avanzato) libro @LinkedIn Non parlo in alcun modo a nome dell'azienda per la quale lavoro Ho poco tempo per frequentare il forum; eventualmente, contattatemi in PVT o nel mio sito. Fanboys |
|||||||||||||||
18-01-2021, 17:06 | #72 | ||||||||||
Senior Member
Iscritto dal: Jan 2007
Messaggi: 5440
|
Quote:
Quote:
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). Quote:
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 ? Quote:
Quote:
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 Quote:
Quote:
Quote:
Quote:
Quote:
C'è inoltre RV32E che non è ancora congelata e che potrebbe essere "ritoccata" in vari modi, prevedendo anche cosa fare con RV32EC. |
||||||||||
19-01-2021, 19:57 | #73 |
Senior Member
Iscritto dal: Oct 2002
Messaggi: 5273
|
"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 )
__________________
____€UROPA: comunità di -PAGLIACCI €SP€RI€NTI SOLO del "B€N VIV€R€" come fosse COMANDAM€NTO nel loro PROGR€SSISMO di SCIMMI€ S€MPR€ PIU' TOTALI sopprimi** anche tu la miseria massmediale delle serie di telefilms USA (polizziesky, social-medical/comedy, etc...) estranei a cultura. **compresi i doppiatori in copie mentali approvate con le scimmie-fans ripetitrici degli esempi infusi->manda in fogne di calcutta tutta questa roba<- Ultima modifica di raxas : 25-01-2021 alle 19:22. |
23-01-2021, 08:26 | #74 | |||||||||
Senior Member
Iscritto dal: Jan 2002
Città: Germania
Messaggi: 26110
|
Nahhh Ormai sta crollando, e oggi gli diamo una bella scorzatura.
Quote:
"IA-32 Support: 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. Quote:
Quote:
Quote:
Quote:
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. Quote:
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. Quote:
Quote:
Quote:
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.
__________________
Per iniziare a programmare c'è solo Python con questo o quest'altro (più avanzato) libro @LinkedIn Non parlo in alcun modo a nome dell'azienda per la quale lavoro Ho poco tempo per frequentare il forum; eventualmente, contattatemi in PVT o nel mio sito. Fanboys |
|||||||||
Strumenti | |
|
|
Tutti gli orari sono GMT +1. Ora sono le: 06:58.