View Full Version : [ASM] La vostra architettura preferita
Salve a tutti !
Apro questo thread per chiedervi: qual'è la vostra architettura di processore preferita? Perchè vi piace / quali sono le caratteristiche preferite / quali sono le caratteristiche che odiate ? Come dovrebbe essere il vostro processore ideale?
Non dovete dire per forza nomi famosi o processori moderni; và bene anche se dite che vi piace l'architettura del' IBM 360 o del PDP-1 ;)
Creo anche un sondaggio, spero di comprendere la maggior parte delle architetture.
Sarebbe carino aggiungere un post motivando la scelta, piuttosto che votare e basta ;)
68000.
E' ordinata, regolare, quasi del tutto simmetrica (pochi registri specifici obbligatori su alcune istruzioni) tanti registri utente, poco orientata allo stack (non mi piacciono le architetture orientate allo stack).
Peccato non sia molto presente.
Ma Betamax vs VHS insegnano che non per forza la tecnologia migliore e' quella che vince.
cdimauro
21-03-2010, 06:18
Concordo con "gugo" per le stesse ragioni: 68000 senza ombra di dubbio (anche se è rimasta a 32 bit come architettura).
Tra l'altro di recente ho completato la serie di articoli sui microprocessori di questa famiglia, e sono tornato a mangiarmi le mani per gioielli come il 68040 o il 68060 (ne avrei tanto voluto qualcuno per programmarci). :cry:
Alpha !!! :cry:
Secondo me è stata l'architettura che ha rivoluzionato di più il mondo delle CPU. Tutte le CPU moderne si sono ispirate ad Alpha, a volte anche una decina di anni dopo :D
Tra l'altro di recente ho completato la serie di articoli sui microprocessori di questa famiglia, e sono tornato a mangiarmi le mani per gioielli come il 68040 o il 68060 (ne avrei tanto voluto qualcuno per programmarci). :cry:
Parli degli articoli su "Appunti Digitali" vero? Li ho letti tutti, veramente ben fatti!
cdimauro
21-03-2010, 12:34
Alpha !!! :cry:
Secondo me è stata l'architettura che ha rivoluzionato di più il mondo delle CPU. Tutte le CPU moderne si sono ispirate ad Alpha, a volte anche una decina di anni dopo :D
Secondo me c'è stato troppo hype sull'Alpha. Sicuramente è stata una fucina di idee, ma di carattere prettamente implementativo (per l'architettura interna).
Come architettura faceva concorrenza ai MIPS per quanto riguarda la R di RISC, e onestamente non mi piace.
Parlo da programmatore assembly, ovviamente. Considera che i 680x0 erano così comodi da programmare, che buona parte delle mie applicazioni le ho scritte interamente in assembly.
Parli degli articoli su "Appunti Digitali" vero? Li ho letti tutti, veramente ben fatti!
Grazie.
Sfortunatamente non ho mai programmato in assembly su Alpha, ma proprio come dici tu, l'architettura interna è stata l'ispirazione per tutti i processori, anche quelli di oggi. Gli ingegneri che hanno lavorato su Alpha hanno creato Athlon in AMD, inoltre una volta dismesso il progetto, tutti gli assets ed i brevetti sono stati acquisiti da Intel nel 2004.
Si dice che il simultaneous multi-threading dei Core I7 sia ispirato direttamente da quello del mai uscito EV8.
Io invece ho scaricato un emulatore MIPS (EduMIPS64) e stò cercando di ottimizzare una routine per sommare 2 vettori in modo da ottenere il minor numero di cicli e di stalli sulla pipeline :D
Devo dire che non è poi così complesso programmare un RISC.
Io invece ho scaricato un emulatore MIPS (EduMIPS64) e stò cercando di ottimizzare una routine per sommare 2 vettori in modo da ottenere il minor numero di cicli e di stalli sulla pipeline :D
Devo dire che non è poi così complesso programmare un RISC.
Per il MIPS c'è anche MARS come simulatore. Conosci?
Sfortunatamente non ho mai programmato in assembly su Alpha, ma proprio come dici tu, l'architettura interna è stata l'ispirazione per tutti i processori, anche quelli di oggi. Gli ingegneri che hanno lavorato su Alpha hanno creato Athlon in AMD, inoltre una volta dismesso il progetto, tutti gli assets ed i brevetti sono stati acquisiti da Intel nel 2004.
Si dice che il simultaneous multi-threading dei Core I7 sia ispirato direttamente da quello del mai uscito EV8.
Da wikipedia "Architettura MIPS" leggo
"L'architettura dei processori MIPS ha influenzato le architetture di molti altri processori RISC tra i quali si segnala la famiglia DEC Alpha."
:Prrr:
Mi è capitato di leggerlo perchè in uni, per il corso di architettura degli elaboratori, ci occupiamo proprio del MIPS.
Mi è capitato di leggerlo perchè in uni, per il corso di architettura degli elaboratori, ci occupiamo proprio del MIPS.
Vorrei anche vedere, l'architettura MIPS è storicamente una di quelle più importanti. Però su Alpha è rimasto quell'alone di mito che devo dire mi ha sempre affascinato.
cdimauro
22-03-2010, 07:17
Io invece ho scaricato un emulatore MIPS (EduMIPS64) e stò cercando di ottimizzare una routine per sommare 2 vettori in modo da ottenere il minor numero di cicli e di stalli sulla pipeline :D
Devo dire che non è poi così complesso programmare un RISC.
Dipende dall'architettura. In ogni caso richiedono mediamente molto più lavoro rispetto ai CISC per implementare le stesse routine.
Architetture come quelle dei MIPS e degli Alpha sono l'immagine di questa situazione: poche istruzioni per lo più "semplici" e listati decisamente lunghetti.
Ah, come da firma ci sarebbe anche il CRAY, che ho studiato e ho anche visto acceso.
Certo, non proprio un personal computer.
Ma le operazioni matriciali erano uno spettacolo.
Per il MIPS c'è anche MARS come simulatore. Conosci?
Si lo ho provato, è buono, ma in questo caso ho usato edumips perchè era più semplice e volevo vedere la pipeline ;)
Ah, come da firma ci sarebbe anche il CRAY, che ho studiato e ho anche visto acceso.
Certo, non proprio un personal computer.
Ma le operazioni matriciali erano uno spettacolo.
Cray, grandi macchine, ma solo internamente, fuori sono dei portatili a confronto! (parlo del Cray 2)
Pensa che la tua firma mi ha fatto incuriosire e ho fatto tutta una ricerca sui Cray :D
Dipende dall'architettura. In ogni caso richiedono mediamente molto più lavoro rispetto ai CISC per implementare le stesse routine.
Architetture come quelle dei MIPS e degli Alpha sono l'immagine di questa situazione: poche istruzioni per lo più "semplici" e listati decisamente lunghetti.
Mi hai fatto venire in mente un'idea: perchè non presentiamo per ogni architettura un esempio dello stesso programma, e vediamo le differenze tra le varie architetture? Sarebbe anche didattico, e sarebbe interessante vedere codici per macchine vecchie e storiche. Secondo te va bene farlo in questo thread o è meglio aprirne un altro?
Vorrei anche vedere, l'architettura MIPS è storicamente una di quelle più importanti. Però su Alpha è rimasto quell'alone di mito che devo dire mi ha sempre affascinato.
Da noi facevano il MIPS fino a 2 anni fa... adesso fanno l'architettura Intel.
Per allenarmi prima dello scritto ho voluto fare la moltiplicazione tra matrici (tradizionale riga-colonna), una sudata... :D.
Sinceramente avrei preferito quest'ultima, anche perché adesso ci ritroviamo l'esame di Linux Avanzato alla specialistica (10 crediti) e appunto serve sapere quella.
Di contro ho visto solo quell'architettura quindi non posso votare per una preferita, mi astengo fino a quando nn vedrò quella Intel quantomeno :D.
cdimauro
22-03-2010, 18:30
Mi hai fatto venire in mente un'idea: perchè non presentiamo per ogni architettura un esempio dello stesso programma, e vediamo le differenze tra le varie architetture? Sarebbe anche didattico, e sarebbe interessante vedere codici per macchine vecchie e storiche. Secondo te va bene farlo in questo thread o è meglio aprirne un altro?
Meglio un altro.
Ovviamente io mi prenoto per 68000+ e 68020+. :D
Per l'algoritmo, non saprei. Non dovrebbe essere né troppo banale (tipo il classico Fibonacci, che ha pure stancato) né troppo complicato (altrimenti chi dovrà implementarlo con un RISC troppo "Reduced" si suiciderà al solo pensiero :asd:).
Meglio un altro.
Ovviamente io mi prenoto per 68000+ e 68020+. :D
Per l'algoritmo, non saprei. Non dovrebbe essere né troppo banale (tipo il classico Fibonacci, che ha pure stancato) né troppo complicato (altrimenti chi dovrà implementarlo con un RISC troppo "Reduced" si suiciderà al solo pensiero :asd:).
Magari un ordinamento? Tipo un semplice bubble-sort. Ti viene in mente qualche titolo per il thread?
cdimauro
22-03-2010, 19:22
Magari un bell'heap sort (http://en.wikipedia.org/wiki/Heap_sort). :fagiano:
The Great Microprocessors Contest. :cool:
banryu79
22-03-2010, 23:44
The Great Microprocessors Contest. :cool:
Iscritto :O (come spettatore, molto interessante l'idea del confronto).
Azzo, ma quanto siete nerd, ragazzi! :D (detto con una punta di invidia...)
Magari un bell'heap sort (http://en.wikipedia.org/wiki/Heap_sort). :fagiano:
The Great Microprocessors Contest. :cool:
Io andrei di quick o di merge sort, heap mi sembra abbastanza complesso da implementare in assembly.
cdimauro
23-03-2010, 08:02
Io andrei di quick o di merge sort, heap mi sembra abbastanza complesso da implementare in assembly.
Per me va bene, basta che non ci riduciamo a Select o Bubble Sort, che sono troppo semplici.
Così avremo modo di sfruttare un po' di più l'ISA dei processori. :fagiano:
astorcas
23-03-2010, 10:32
ragazzi scusate ma quanti anni avete? Io ho votato l'unica su cui ho mai messo mani (a basso livello intendo). Caspita vi invido :cry:
Per me va bene, basta che non ci riduciamo a Select o Bubble Sort, che sono troppo semplici.
Così avremo modo di sfruttare un po' di più l'ISA dei processori. :fagiano:
Io propongo per il momento :D perché conosco solo il MIPS (che per altro ricordo poco, dovrei rivedermelo), però potrebbe essere interessante per studiare almeno quello Intel :Prrr:
cdimauro
23-03-2010, 13:02
ragazzi scusate ma quanti anni avete? Io ho votato l'unica su cui ho mai messo mani (a basso livello intendo). Caspita vi invido :cry:
39 anni, e 28 di esperienza nel campo dell'informatica.
Io propongo per il momento :D perché conosco solo il MIPS (che per altro ricordo poco, dovrei rivedermelo), però potrebbe essere interessante per studiare almeno quello Intel :Prrr:
Beh, mi aspetto che ci sia gente che conosca l'architettura x86 e/o x86-64 e provveda, quindi, a fornire gli equivalenti.
Al limite potrei farlo io, ma ho poco tempo e preferirei dedicarmi esclusivamente a quella 680x0. ;)
Iscritto :O (come spettatore, molto interessante l'idea del confronto).
Azzo, ma quanto siete nerd, ragazzi! :D (detto con una punta di invidia...)
The Revenge of the Nerds!
http://marksayers.files.wordpress.com/2009/01/revengeofthenerds.jpg
Io andrei di quick o di merge sort, heap mi sembra abbastanza complesso da implementare in assembly.
Si, anche secondo me è meglio un quick.A parte gli ordinamenti possiamo anche fare algoritmi di puro calcolo, l'importante e che non richiedino memoria dinamica e/o intervento dall'utente: deve essere possibile leggere la soluzione o direttamente da un registro o da una locazione di memoria; si deve immaginare solo il processore + memoria, nemmeno un sistema operativo.
ragazzi scusate ma quanti anni avete? Io ho votato l'unica su cui ho mai messo mani (a basso livello intendo). Caspita vi invido :cry:
18, e qualcuno nel campo dell'informatica :D
cdimauro
23-03-2010, 19:22
Si, anche secondo me è meglio un quick.A parte gli ordinamenti possiamo anche fare algoritmi di puro calcolo, l'importante e che non richiedino memoria dinamica e/o intervento dall'utente: deve essere possibile leggere la soluzione o direttamente da un registro o da una locazione di memoria; si deve immaginare solo il processore + memoria, nemmeno un sistema operativo.
D'accordo, e infatti fornirei soltanto il sorgente che implementa l'algoritmo concordato, e di questo prendiamo uno pseudocodice che utilizzeremo tutti.
D'accordo, e infatti fornirei soltanto il sorgente che implementa l'algoritmo concordato, e di questo prendiamo uno pseudocodice che utilizzeremo tutti.
Perfetto, allora concordato per "The great microprocessor contest?"
( oppure un semplice "programma il tuo processore preferito" ;) )
cdimauro
23-03-2010, 20:12
Boh, per me un titolo vale l'altro. L'importante è che sia esplicativo.
Boh, per me un titolo vale l'altro. L'importante è che sia esplicativo.
Accidenti io non sono bravo con i titoli :D
Mi serve qualche conferma, qualcuno ha qualche idea?
cdimauro
24-03-2010, 07:23
Considerato il numero di architetture, e le eventuali discussioni che scaturiranno, forse è meglio aprire un thread per ogni algoritmo.
Quindi il titolo per il mergesort a mio avviso dovrebbe essere questo:
[Assembly] Mergesort
Oppure:
[Assembly] Microprocessors contest: Mergesort
che forse è più esplicativo.
Approvo. Dovrebbe venire fuori una cosa molto interessante.
Considerato il numero di architetture, e le eventuali discussioni che scaturiranno, forse è meglio aprire un thread per ogni algoritmo.
Quindi il titolo per il mergesort a mio avviso dovrebbe essere questo:
[Assembly] Mergesort
Oppure:
[Assembly] Microprocessors contest: Mergesort
che forse è più esplicativo.
Approvo. Dovrebbe venire fuori una cosa molto interessante.
Perfetto, vada per [Assembly] Micorprocessors contest: Merge Sort
(Inizio con il merge sort, poi decideremo se aggiungere thread)
Eccola!
http://www.hwupgrade.it/forum/showthread.php?t=2165970
Ho messo qualche "regola" che mi è venuta in mente. Se vedete errori o ve ne viene in mente qualche altra ditemelo.
Uhm il thread non sta avendo un gran successo... ;)
lupoxxx87
30-03-2010, 19:27
concordo nel dire che l'architettura mips è quella che ha portato l'evoluzione nel mondo delle architetture per come le conosciamo oggi...
però il mio voto sta con K.Zuse e lo Z3, per le contenute dimensioni che aveva (l'ha costruito in camera sua, in confronto agli stanzoni dell'univac e univar e balle americaninglesi varie xD, ed è stato lui ad introdurre l'aritmetica binaria nei registri)....quindi.....io sto dalla sua parte ;)
concordo nel dire che l'architettura mips è quella che ha portato l'evoluzione nel mondo delle architetture per come le conosciamo oggi...
però il mio voto sta con K.Zuse e lo Z3, per le contenute dimensioni che aveva (l'ha costruito in camera sua, in confronto agli stanzoni dell'univac e univar e balle americaninglesi varie xD, ed è stato lui ad introdurre l'aritmetica binaria nei registri)....quindi.....io sto dalla sua parte ;)
Già, veramente bella macchina, però devo correggerti: è lo Z1 (1937) che ha costruito nella sua camera, ed era completamente meccanico. Lo Z3 è del 1941 ed è completamente a relè. Cmq hai ragione sulla compattezza della macchina, che tra l'altro ho visto dal vivo al Deutsche Museum di Monaco :cool:.
Ora mi son messo per gli esami/interesse personale a fare un emulatore per il GameBoy, quindi in pratica per lo Z80.
Però non mi riesce a piacere l'assembly, troppo basso livello e troppo lontano dai problemi da risolvere :stordita:
lupoxxx87
30-03-2010, 19:58
se non ami l'assembly vuol dire che non ti piace ottimizzare gli algoritmi...quindi, come li chiamiamo noi in dipartimento, sei un programmatore parassita xD
sei bravo solo se sfrutti il lavoro di qualcun'altro xD
...è per questo che stimo da morire ritchie e thompson xD
Ora mi son messo per gli esami/interesse personale a fare un emulatore per il GameBoy, quindi in pratica per lo Z80.
Però non mi riesce a piacere l'assembly, troppo basso livello e troppo lontano dai problemi da risolvere :stordita:
Intendi l'assembly Z80 o l'assembly in generale?
Cmq mi sembra anche comprensibile che l'assembly sia di basso livello :D una volta avevano provato a fare un processore orientato agli oggetti, ma non ha avuto molto successo ;)
cdimauro
30-03-2010, 20:20
se non ami l'assembly vuol dire che non ti piace ottimizzare gli algoritmi...quindi, come li chiamiamo noi in dipartimento, sei un programmatore parassita xD
sei bravo solo se sfrutti il lavoro di qualcun'altro xD
...è per questo che stimo da morire ritchie e thompson xD
Ma anche no. E' una questione di gusti.
L'ottimizzazione la si può fare con qualunque linguaggio.
Intendi l'assembly Z80 o l'assembly in generale?
Cmq mi sembra anche comprensibile che l'assembly sia di basso livello :D una volta avevano provato a fare un processore orientato agli oggetti, ma non ha avuto molto successo ;)
Un po' di spam: iAPX 432: il primo processore a 32 bit di Intel… a oggetti! (http://www.appuntidigitali.it/4151/iapx-432-il-primo-processore-a-32-bit-di-intel-a-oggetti/) :fagiano: :D
iAPX 432: il primo processore a 32 bit di Intel… a oggetti! (http://www.appuntidigitali.it/4151/iapx-432-il-primo-processore-a-32-bit-di-intel-a-oggetti/) :fagiano: :D
Infatti mi riferivo proprio a quello :D
se non ami l'assembly vuol dire che non ti piace ottimizzare gli algoritmi...quindi, come li chiamiamo noi in dipartimento, sei un programmatore parassita xD
sei bravo solo se sfrutti il lavoro di qualcun'altro xD
...è per questo che stimo da morire ritchie e thompson xD
Grazie ma non mi serviva un'altra conferma che l'università italiana è allo sfascio.
Comunque non mi piace il "modus operandi" diciamo dell'assembly, che è troppo vicino alla macchina per permettere di operare più ad ampio respiro... in pratica la cosa difficile dell'emulatore è andare ad acchiappare e riprodurre tutte quelle "non-features" tipo reset automatici di alcuni registri, uso dell'overflow nei programmi, fino al bounce degli interrupts che qualche programmatore potrebbe aver usato per ottimizzare un pò troppo...
non che si possa fare a meno dell'assembly certo :D
poi anzi quello dello Z80 mi piace, per quella parte che ho visto.
PS con "a oggetti" che si intende in un processore?
Grazie ma non mi serviva un'altra conferma che l'università italiana è allo sfascio.
Comunque non mi piace il "modus operandi" diciamo dell'assembly, che è troppo vicino alla macchina per permettere di operare più ad ampio respiro...
Certo, cmq l'assembly secondo me non è neppure un linguaggio vero e proprio, è solo una traduzione utile al povero programmatore umano.
in pratica la cosa difficile dell'emulatore è andare ad acchiappare e riprodurre tutte quelle "non-features" tipo reset automatici di alcuni registri, uso dell'overflow nei programmi, fino al bounce degli interrupts che qualche programmatore potrebbe aver usato per ottimizzare un pò troppo...
Vabbé la istruzioni non documentate, ma qua andiamo veramente troppo oltre :D
poi anzi quello dello Z80 mi piace, per quella parte che ho visto.
Adesso che mi viene in mente, il processore che monta il game boy non è proprio uno Z80 stretto: manca di molte funzioni tipo i registri IX e IY, e ne aggiunge altre per gestire rapidamente i registri hardware.
PS con "a oggetti" che si intende in un processore?
Ti conviene leggere l'articolo di cesare che lo spiega veramente bene ;)
No per fortuna il GB è come dici te, è un Z80 parecchio castrato... quindi non ha alcuna istruzione non documentata...
In pratica da quello che ho capito ha solo gli opcode standard e quelli CB, e aggiunge qualche LD r (FF00+n) ad uso e consumo dei registi HW che sono mappati in memoria da FF00 a FF4F mi pare.
Certo che il processore ad oggetti è "da malati" comunque, non mi stupisce per niente che abbia floppato :D
E il bello è che in teoria, "congelando" gli algoritmi OOP nell'hardware sarebbe dovuto andare più veloce...
cmq ottimo articolo come sempre!
^TiGeRShArK^
30-03-2010, 22:43
Salve a tutti !
Apro questo thread per chiedervi: qual'è la vostra architettura di processore preferita? Perchè vi piace / quali sono le caratteristiche preferite / quali sono le caratteristiche che odiate ? Come dovrebbe essere il vostro processore ideale?
Non dovete dire per forza nomi famosi o processori moderni; và bene anche se dite che vi piace l'architettura del' IBM 360 o del PDP-1 ;)
Creo anche un sondaggio, spero di comprendere la maggior parte delle architetture.
68000, non c'è nemmeno da chiederlo.
Anche se come RISC la sparc mi piaceva decisamente.
^TiGeRShArK^
30-03-2010, 22:45
68000.
E' ordinata, regolare, quasi del tutto simmetrica (pochi registri specifici obbligatori su alcune istruzioni) tanti registri utente, poco orientata allo stack (non mi piacciono le architetture orientate allo stack).
Peccato non sia molto presente.
Ma Betamax vs VHS insegnano che non per forza la tecnologia migliore e' quella che vince.
Concordo con "gugo" per le stesse ragioni: 68000 senza ombra di dubbio (anche se è rimasta a 32 bit come architettura).
Tra l'altro di recente ho completato la serie di articoli sui microprocessori di questa famiglia, e sono tornato a mangiarmi le mani per gioielli come il 68040 o il 68060 (ne avrei tanto voluto qualcuno per programmarci). :cry:
fico, quindi siamo stati noi 3 gli unici a votare per il 68k mi sa. :asd:
^TiGeRShArK^
30-03-2010, 22:49
:mbe:
ora mi dite chi ha votato per l'IA64 dell'ITANIUM, please... :mbe:
Non credo esista architettura peggiore per programmare in assembly... o almeno io non la conosco... :mbe:
Un po' di spam: iAPX 432: il primo processore a 32 bit di Intel… a oggetti! (http://www.appuntidigitali.it/4151/iapx-432-il-primo-processore-a-32-bit-di-intel-a-oggetti/) :fagiano: :D
Bello, lo trattavano in un capitolo del mio primo manuale dell'8086...
:mbe:
ora mi dite chi ha votato per l'IA64 dell'ITANIUM, please... :mbe:
Non credo esista architettura peggiore per programmare in assembly... o almeno io non la conosco... :mbe:
L'unico assembly creato appositamente per non essere usato :D
L'istruciton level parallelism è la cosa più brutta della storia delle architetture. Certo con i compilatori si dovrebbero ottenere veramente ottimi risultati: dico dovrebbero perché ci stanno ancora lavorando :asd:
cdimauro
31-03-2010, 07:21
:mbe:
ora mi dite chi ha votato per l'IA64 dell'ITANIUM, please... :mbe:
Non credo esista architettura peggiore per programmare in assembly... o almeno io non la conosco... :mbe:
Perché non hai visto i PIC di MicroChip... e qualcuno li ha votati. :asd:
L'unico assembly creato appositamente per non essere usato :D
L'istruciton level parallelism è la cosa più brutta della storia delle architetture.
Più che altro è cercare di ottenerlo a livello di compilatore che è un approccio fallimentare. :D
Certo con i compilatori si dovrebbero ottenere veramente ottimi risultati: dico dovrebbero perché ci stanno ancora lavorando :asd:
Istruzione+istruzione+NOP
Istruzione+NOP+NOP
ecc. ecc.
:fiufiu:
wizardgsz
07-04-2010, 15:44
Ecco il mio voto, se interessa a qualcuno :banned:
Motorola 68k per motivi nostalgici
per il gran divertimento ARM 7 TDMI :read:
rеpne scasb
08-04-2010, 21:08
■
A molti piacciono i 68k, e hanno ragione ;)
Cesare, un giorno parlerai dei Motorola 88000? Ho letto che usavano gli stessi registri sia per i numeri interi che quelli floating; da un po' pensavo a questa soluzione, ma non pensavo che qualcuno l'avesse già implementata!
cdimauro
09-04-2010, 07:26
Sì, ho in già programma di trattare gli 88000, ma solo se riesco a trovare lo user/reference manual.
Comunque passerà parecchio tempo: devo ancora parlare del 68070 (non Motorola. :fagiano: ), e ho in programma una serie di articoli su come si sviluppavano giochi su Amiga. ;)
Sì, ho in già programma di trattare gli 88000, ma solo se riesco a trovare lo user/reference manual.
Comunque passerà parecchio tempo: devo ancora parlare del 68070 (non Motorola. :fagiano: ), e ho in programma una serie di articoli su come si sviluppavano giochi su Amiga. ;)
Gli articoli sull' Amiga mi allettano molto :D
Nessun' altro che ci vuole raccontare la sua esperienza?
Avanti ragazzi, raccontatemi le vostre esperienze ;)
Io vorrei rispondere ma... Per onestà, mi astengo. Molte architetture non le conosco e quelle che conosco, spesso, è solo superficialmente. Programmato solo su Z80 e ARM, oltre che, ovviamente, x86.
Su x86 ci programmai abbastanza. A volte direttamente in codice macchina (!!). Ero un ragazzino...
Tutto quello che sapevo erano qualche documento trovato alla rinfusa, più il debug del DOS. Ci scrivevo le routine in ASM per i miei programmi in QuickBasic quando la velocità non era abbastanza :fagiano: Non avevo nemmeno un compilatore ed Internet non c'era ancora, in casa.
Risponderei x86 perché è l'architettura che conosco meglio, mica per altro.
Alpha !!! :cry:
Secondo me è stata l'architettura che ha rivoluzionato di più il mondo delle CPU. Tutte le CPU moderne si sono ispirate ad Alpha, a volte anche una decina di anni dopo :DVero. Forse in elenco ci doveva essere l'Alpha piuttosto che, ad esempio, il poco significativo IA-64 di Intel.
Comunque, complimenti Z80Fan: ci vuole qualcuno di davvero "hardcore" ogni tanto :)
Vero. Forse in elenco ci doveva essere l'Alpha piuttosto che, ad esempio, il poco significativo IA-64 di Intel.
Per elenco intendi il sondaggio? Se si, l'Alpha è incluso nella lista ;)
Comunque, complimenti Z80Fan: ci vuole qualcuno di davvero "hardcore" ogni tanto :)
Ti ringrazio :) Hai già visto il mio thread dove programmo un sistema operativo? :D
Per elenco intendi il sondaggio? Se si, l'Alpha è incluso nella lista ;):fagiano:
Devo essere cieco...
Ti ringrazio :) Hai già visto il mio thread dove programmo un sistema operativo? :DE come si fa a non vederlo? Lascia tutti così: :eek:
Mi dispiace di non poterlo seguire come si deve, un lavoro a tempo pieno non mi consente di fare molto :boh:
Chiedo un vostro parere su questa idea:
Facciamo che devo costruire un processore quasi-RISC. Per aumentare le prestazioni decido di usare una pipeline. Nonostante progetto bene il set di istruzioni, vedo che in molti casi si potrebbero verificare stalli sulla pipeline, e questo mi costa molto lavoro nella circuiteria di controllo. Secondo voi è meglio creare la circuiteria complessa, e che mi impone una frequenza inferiore, o creare una pipeline che non esegue una istruzione ogni ciclo di clock, ma che non mi crea stalli e mi permette di innalzare la frequenza?
Un po' troppo generica la domanda. Mi immagino che tu abbia già un branch predictor. A cosa sono dovuti gli stalli della pipeline ? Al fallimento del branch predictor ? Ai cambi di contesto ? La pipeline è corta o è profonda (stile P4) ?
Se aumenti la circuiteria di controllo (mi immagino il branch predictor) od ottieni un critical path maggiore di quello dello stage più lento allora devi per forza diminuire gli stage.
Un po' troppo generica la domanda. Mi immagino che tu abbia già un branch predictor. A cosa sono dovuti gli stalli della pipeline ? Al fallimento del branch predictor ? Ai cambi di contesto ? La pipeline è corta o è profonda (stile P4) ?
Se aumenti la circuiteria di controllo (mi immagino il branch predictor) od ottieni un critical path maggiore di quello dello stage più lento allora devi per forza diminuire gli stage.
Ok, rettifico:
La pipeline è corta, con non più di 5-6 stadi. Al branch predictor non ci avevo pensato, presumiamo che non ci sia (anche perchè penso sia anch'esso un elemento complesso, e torniamo al discorso di prima), gli stalli avvengono per dipendenze dei dati.
Cmq forse è meglio che chiarisco il dubbio:
mettiamo che l'unico problema sia la dipendenza dei dati. I dati vengono presi direttamente dai registri e calcolati nel blocco execute, poi c'è un blocco di accesso alla memoria, e poi c'è il blocco di scrittura registri. Avendo la stessa pipeline, è meglio aggiungerli il controllo degli stalli ma facendola andare ad una frequenza inferiore (con caso ideale = una istr. ogni clock), o intervallare tutte le istruzioni con 2 nop in modo che sono assolutamente sicuro che quando una istruzione arriva in execute, l'istruzione precedente ha già eseguito il salvataggio dei registri (o lo sta facendo in quel momento, precisando che l'execute prende i dati aggiornati), ma avendo una frequenza più alta visto che si semplifica il circuito (qui il caso ideale è una istr ogni 2 cicli di clock).
E' in-order o out-of-order ?
E' in-order o out-of-order ?
in-order
in-orderCi credo, se lo vuoi tenere semplice.
Si può ancora considerare semplice se ci aggiungi un quintale di cache? :O :asd:
in-order
Data la pipeline corta, il risultato che crea dipendenza può essere reso disponibile all'istruzione successiva subito prima dell'esecuzione del calcolo nella ALU.
La ALU può aggiornare il register file (temporaneo, non quello disponibile al programmatore) con il risultato dell'esecuzione dell'istruzione precedente.
Ad esempio:
|F|D|X|M|W|
|F|D|X|M|W|
Se c'è dipendenza, in ogni caso la fase di esecuzione lavorerà comunque con il risultato aggiornato ottenuto dalla fase di esecuzione dell'istruzione precedente. In pratica l'uscita viene subito scritta in un register file temporaneo da cui viene preso il valore per l'esecuzione successiva.
Altrimenti c'è la cosiddetta tecnica delle bubble, cioè si ritarda l'esecuzione di tutte le istruzioni successive nella pipeline di tot cicli necessari a risolvere la dipendenza.
Si può ancora considerare semplice se ci aggiungi un quintale di cache? :O :asd:
Solo se è cache direct mapped, che è semplice da implementare ;)
Data la pipeline corta, il risultato che crea dipendenza può essere reso disponibile all'istruzione successiva subito prima dell'esecuzione del calcolo nella ALU.
La ALU può aggiornare il register file (temporaneo, non quello disponibile al programmatore) con il risultato dell'esecuzione dell'istruzione precedente.
Ad esempio:
|F|D|X|M|W|
|F|D|X|M|W|
Se c'è dipendenza, in ogni caso la fase di esecuzione lavorerà comunque con il risultato aggiornato ottenuto dalla fase di esecuzione dell'istruzione precedente. In pratica l'uscita viene subito scritta in un register file temporaneo da cui viene preso il valore per l'esecuzione successiva.
è una buona idea, ma non funziona se il risultato precedente deve essere prelevato dalla memoria. In questo caso, l'execute deve fermarsi per 1 ciclo (EDIT: passo) (presumendo che anche la fase di memoria scrive nei registri shadow, ma in questo caso non servirebbe neanche la fase di scrittura registri)
Altrimenti c'è la cosiddetta tecnica delle bubble, cioè si ritarda l'esecuzione di tutte le istruzioni successive nella pipeline di tot cicli necessari a risolvere la dipendenza.
Ecco, io pensavo di applicare una bubble di un ciclo (EDIT: passo) indiscriminatamente a qualsiasi istruzione, per evitare qualsiasi tipo di controllo. Può funzionare?
è una buona idea, ma non funziona se il risultato precedente deve essere prelevato dalla memoria. In questo caso, l'execute deve fermarsi per 1 ciclo (presumendo che anche la fase di memoria scrive nei registri shadow, ma in questo caso non servirebbe neanche la fase di scrittura registri)
Per le dipendenze in memoria non ci sono soluzioni valide, se non la cache. Bisognerebbe anche vedere quanti cicli occupa la lettura dalla cache. Ed in ogni caso se c'è un cache miss siamo punto e a capo. Un lettura dalla memoria occupa molti più di un ciclo...
Per le dipendenze in memoria non ci sono soluzioni valide, se non la cache. Bisognerebbe anche vedere quanti cicli occupa la lettura dalla cache. Ed in ogni caso se c'è un cache miss siamo punto e a capo. Un lettura dalla memoria occupa molti più di un ciclo...
Anche questo è vero...
Cmq sopra intendevo dire "l'execute deve fermarsi per 1 passo di pipeline ", visto che cmq abbiamo detto che non è out-of-order. La dipendenza non la intendevo come lentezza nell'aspettare la memoria, più che altro intendevo che la scrittura del dato cmq deve farla al passo successivo.
Sulla bubble indiscriminata cosa ne pensi?
Non ho capito cosa intendi... Lasciamo da parte le dipendenze in memoria e il bubble. La scrittura vera la può fare quando vuole, l'importante è che il dato aggiornato si trovi nel register file invisibile intermedio non appena finisce lo stage X.
Non ho capito cosa intendi...
Tranquillo, mi sono accorto di aver creato un po' di confusione ;)
Lasciamo da parte le dipendenze in memoria e il bubble. La scrittura vera la può fare quando vuole, l'importante è che il dato aggiornato si trovi nel register file invisibile intermedio non appena finisce lo stage X.
Ok, fin qui non ci piove. Io avevo cominciato a discutere nel caso avessimo una situazione del genere:
...
1] carica R1 da memoria
2] operazione con R1
...
Avevo preso come riferimento lo schemino che avevi fatto tu (|F|D|X|M|W|), dove X doveva aspettare la fine di M (o la fine di W se M non aggiorna i registri shadow alla fine dell'operazione, come abbiamo ipotizzato per X) prima di operare. Se non volessimo avere nessun sistema di controllo di stalli, imponevamo che qualsiasi istruzione fosse intervallata dall'altra di un passo di pipeline, così avevamo:
|F1|..|..|..|..|
|..|D1|..|..|..|
|F2|..|X1|..|..|
|..|D2|..|M1|..| // M1 prende dalla memoria (eventualmente bloccando tutto il processore finché non ha finito) e scrive subito il ris. nei registri shadow
|F3|..|X2|..|W1| // X2 prende i dati giusti dai registri shadow mentre W1 aggiorna i registri "ufficiali"
e non si creavano stalli per dipendenze di dati.
In questo caso ci vuole una cache L1 per i dati. Difficile farne a meno.
In questo caso ci vuole una cache L1 per i dati. Difficile farne a meno.
Ok. Grazie mille per le risposte :)
Se io ho un ciclo come questo:
for(...)
{
if(condizione)
{
codice1
}
else
{
codice2
}
}
premettendo che la condizione rimane costante per tutto il ciclo (è sempre o vera o falsa), il branch predictor dovrebbe "capire" che il salto dato dalla condizione dell'if è sempre preso (o non preso), quindi non ci dovrebbero essere stalli ad ogni ciclo per via del mancato salto dopo la condizione, vero?
Devo scrivere un codice del genere che deve avere alte prestazioni, ed ero indeciso se fare così, o scrivermi dei for separati scelti in base alla condizione.
cdimauro
27-05-2010, 21:00
Se la condizione è statica, meglio due for separati, ma se sei sicuro che la CPU implementa un branch predictor, allora puoi star tranquillo.
Solo che i due for separati in ogni caso ti garantiscono l'esecuzione di meno istruzioni (non c'è il check e il branch).
Anche se è meno elegante, for separati tutta la vita. In ogni caso sono più performanti, o almeno non mi risulta alcuna architettura in cui possa verificarsi il contrario (né mi viene in mente come potrebbe accadere).
Questi ragionamenti li devo fare di continuo sviluppando in JavaScript, dove l'ottimizzazione è ridotta a zero o quasi. :help:
killercode
28-05-2010, 11:39
Sicuramente il pic, o gli avr.
Se la condizione è statica, meglio due for separati, ma se sei sicuro che la CPU implementa un branch predictor, allora puoi star tranquillo.
Solo che i due for separati in ogni caso ti garantiscono l'esecuzione di meno istruzioni (non c'è il check e il branch).
Anche se è meno elegante, for separati tutta la vita. In ogni caso sono più performanti, o almeno non mi risulta alcuna architettura in cui possa verificarsi il contrario (né mi viene in mente come potrebbe accadere).
Bene, meglio i for allora...
E se ci progettassimo e costruissimo noi un'architettura? :D
Definire il set di istruzioni, il formato del linguaggio macchina, scrivere dei programmi di prova...
Potremo usare l'ottimo simulatore Hades (http://tams-www.informatik.uni-hamburg.de/applets/hades/webdemos/index.html) per costruirlo e testarlo. Ho già fatto delle prove, e il simulatore si presta ad emulare progetti così grandi.
Se qualcuno è interessato apro un nuovo thread così da discutere dell'architettura.
Vedo che le idee folli non ti mancano :asd:
Io non saprei nemmeno da dove cominciare... :stordita:
Io ne ho progettata una a suo tempo, per la tesi di laurea.
Lo scopo non era quello, ma quello di studiare la fattibilita' e dare una proposta di un'architettura fault-tolerant. In pratica un processore in grado di funzionare anche se alcuni pezzi interni non funzionano piu' bene, a causa di vari motivi.
Applicazioni spazio, dove oltre che alle celle di RAM, anche pezzi di microprocessori stessi possono essere eccitati da raggi cosmici e non funzionare piu' temporaneamente (o permanentemente).
Scopo era quello di fare in modo che il processore continuasse a funazionare, magari piu' lentamente e degradato, ma che non si fermasse e non dovesse essere al limite sostituito.
Missione compiuta.
Abbiamo (in 2) quindi progettato l'architettura, costruito il micro e il macrocompilatore e l'iniettore virtuale di martellate sul chip (spacco qui, spacco la') e il simulatore/debugger di macrocodice.
6 mesi di tempo full time in 2.
E l'architettura era davvero banale. Una RISC a 32 bit con le istruzioni di base...
Vedo che le idee folli non ti mancano :asd:
Io non saprei nemmeno da dove cominciare... :stordita:
Nessuna follia, sembra solo complesso perchè pensiamo ai nostri moderni processori Intel, pieni di circuiteria inutile; ma un processore cmq efficente e relativamente potente si può fare con molta meno circuiteria ;)
Pensa che una volta ho pure costruito un processore a 2 bit! (http://z80fan.altervista.org/cpu2bit/index.html) :eek: (solo 2 bit per mancanza nel simulatore di "bus", non usavo ancora Hades)
Io ne ho progettata una a suo tempo, per la tesi di laurea.
Lo scopo non era quello, ma quello di studiare la fattibilita' e dare una proposta di un'architettura fault-tolerant. In pratica un processore in grado di funzionare anche se alcuni pezzi interni non funzionano piu' bene, a causa di vari motivi.
Applicazioni spazio, dove oltre che alle celle di RAM, anche pezzi di microprocessori stessi possono essere eccitati da raggi cosmici e non funzionare piu' temporaneamente (o permanentemente).
Scopo era quello di fare in modo che il processore continuasse a funzionare, magari piu' lentamente e degradato, ma che non si fermasse e non dovesse essere al limite sostituito.
Missione compiuta.
Abbiamo (in 2) quindi progettato l'architettura, costruito il micro e il macrocompilatore e l'iniettore virtuale di martellate sul chip (spacco qui, spacco la') e il simulatore/debugger di macrocodice.
6 mesi di tempo full time in 2.
E l'architettura era davvero banale. Una RISC a 32 bit con le istruzioni di base...
Wow !!! :eek:
Un processore per "veri duri" ;)
Lo avete solo emulato con un programma, o lo avete anche implementato e simulato a livello di circuiti elettronici (come intendevo fare io)?
Hai qualche documentazione? Mi piacerebbe leggerla :)
Nessuna follia, sembra solo complesso perchè pensiamo ai nostri moderni processori Intel, pieni di circuiteria inutile; ma un processore cmq efficente e relativamente potente si può fare con molta meno circuiteria ;)
Pensa che una volta ho pure costruito un processore a 2 bit! (http://z80fan.altervista.org/cpu2bit/index.html) :eek: (solo 2 bit per mancanza nel simulatore di "bus", non usavo ancora Hades)
Wow !!! :eek:
Un processore per "veri duri" ;)
Lo avete solo emulato con un programma, o lo avete anche implementato e simulato a livello di circuiti elettronici (come intendevo fare io)?
Hai qualche documentazione? Mi piacerebbe leggerla :)
L'abbiamo scritto anche in VHDL e sintetizzato con Synopsis per vedere la copertura dei test, ma non abbiamo simulato nulla perche' era un mostro troppo grande per poter essere emulato in tempi umani.
Documentazione da leggere... la tesi :)
Che ho anche in formato elettronico, ma non qui in UK. Se mi ricordo la prima volta che torno in Italia me la spedisco.
Ho utilizzato solo 8086 e 68k e devo dire che non c'è paragone tra i due... 68k tutta la vita. L'eleganza fatta architettura. Mi piacerebbe vedere qualche cosa dei PPC.
Ho creato la discussione per l'architettura:
http://www.hwupgrade.it/forum/showthread.php?p=32351125
Spero veniate numerosi ;)
un piccolo up me lo perdonerete ;)
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.