View Full Version : ISA intel core i7
domenico88
24-08-2016, 16:47
Ciao a tutti
Sto preparando l esame di calcolatori elettronici per ingegneria..
Studiando il capitolo del livello Isa , il tanenbaum(testo di riferimento) tratta in linea generale l architettura x86 di cui fa parte la cpu intel i7( ora forse sarebbe x64 ma cosi riporta il libro :D )
Allora il testo dice che la cpu mantiene il completo supporto alle cpu intel della famiglia 8080 , 8086-88, gli ultimi cambimenti sulle istruzioni dei nuovi processori sarebbero le istruzioni multimediali mmx, sse e sse2 e nelle versioni più recenti sse4 ecc
Ancora, il core i7 è dotato di tre modalità operative, modalità reale(si comporta come un 8088) modalità protetta e modalità virtuale ..
I mie dubbi pero riguardavano i registri dedicati della cpu, dalla figura del testo sarebbero soltanto 16 registri di cui, i registri EAX EBX ECX EDX di uso generale a 32 bit altri CS SS .. a 16 bit che provengono dalle compatibilità del 8088 e gli ultimi EIP EFLAGS , ripettivamente program counter e program status word
Ora mi domando, possibile che una cpu cosi moderna e alquanto veloce possegga solo questi pochi registri, in pratica verrebbe usato solo il primo gruppo da 4 registri per i dati e le istruzioni aritmetiche
Mi sembra di aver capito che il core i7 faccia molti riferimenti allo stack per l elaborazione dei dati con molte operazioni di push e pop, dato che appunto ci sono pochi registri disponibili, al contrario di un architettura RISC ad esempio che limita gli accessi in memoria solo alle istruzioni LOAD e STORE ,
Cioè in questo modo le prestazioni con i continui accessi in memoria dovrebbero essere molto limitate o sbaglio
Ciao grazie in anticipo :)
Sì i registri per uso general purpose (operazioni con interi / puntatori più che altro) sono solo 8 un po' dei 4 che dici, ma sempre molto, molto pochi rispetto ad appunto RISC:
https://en.wikibooks.org/wiki/X86_Assembly/X86_Architecture#General-Purpose_Registers_.28GPR.29_-_16-bit_naming_conventions
Ci sono poi altri 8 registri per i calcoli in virgola mobile e basta!
AMD quando ha creato AMD64 ha raddoppiato il numero di registri che quindi diventano 16 + 16 leggermente meglio...
Come fa a funzionare in maniera decente?
Beh direi ci sono due motivi:
Forza bruta una CPU inefficiente a 3 Ghz riesce a fare una figura decente
Le moderne CPU x86 usano varie tecnologie per mitigare questo in alcuni casi riescono ad eseguire più operaioni contemporanemente riordinando le istruzioni, hanno un decoder che cambia le istruzioni in RISC like e posseggono una tecnologia chiamata "register renaming"
I registri general purpose che riporti sono quelli dell'architettura a 32 bit, le rispettive versioni a 64 bit si chiamano RAX, RBX, RCX, e RDX. Di fatto i registri sono gli stessi, o, in altre parole, EAX sono i 32 bit bassi di RAX, EBX sono i 32 bit bassi di RBX, e cosi' via. L'architettura Intel a 64 bit poi dispone di altri registri general purpose per un totale di 16 come accenna fano, in piu' da quanto ne so questi 16 registri possono essere rinominati cosicche' sia possibile controllare a quale registro faccia riferimento una certa operazione senza modificare l'operazione stessa.
Diciamolo pure apertamente è probabilmente la peggiore architettura di CPU sul mercato (pochi registri, instruction set che contiene migliaia di istruzioni, "pacioccato" alla c*zzo di cane negli anni per aggiungere nuove funzionalità...) purtroppo quello che l'ha fatta sopravvivere era la retro compatibilità che ha fatto sì che archittetture migliori sia di altri (come RISC appunto) che di Intel stessa (come Itanium) non riuscirono mai ad affermarsi perché non erano appunto retro compatibili con x86!
Solo oggi con i cellulari / tablet ARM inizia ad avere qualche chanche...
Diciamolo pure apertamente è probabilmente la peggiore architettura di CPU sul mercato (pochi registri, instruction set che contiene migliaia di istruzioni, "pacioccato" alla c*zzo di cane negli anni per aggiungere nuove funzionalità...) purtroppo quello che l'ha fatta sopravvivere era la retro compatibilità che ha fatto sì che archittetture migliori sia di altri (come RISC appunto) che di Intel stessa (come Itanium) non riuscirono mai ad affermarsi perché non erano appunto retro compatibili con x86!
Solo oggi con i cellulari / tablet ARM inizia ad avere qualche chanche... Per me l'unica cosa agghiacciante di x64 e' (e non sono sicuro e quindi spero di sbagliarmi) la retrocompatibilita' con gli x86 a 16 bit, o modalita' "reale". Il solo fatto che si chiami "modalita' reale" e' patetico. :asd:
Anche perche', se non erro, questa retrocompatibilita' comporta che il processore parta effettivamente in modalita' reale e debba poi essere switchato in modalita' protetta dal software, quindi il primissimo passo di qualsiasi boot loader deve essere scritto in codice assembly 8086 come quello che girava negli anni 80. :fagiano:
Per il resto x64 non mi sembra cosi' terribile, di certo 1000 volte meglio delle idiozie prive di senso umanamente intellegibile che si inventarono per gli 8086, come la segmentazione della memoria in cui i segmenti erano parzialmente sovrapposti. Molto utile, per nulla error-prone. :fagiano:
Va da se' che avrei comunque preferito veder fiorire Itanium.
domenico88
25-08-2016, 00:19
Non ci credo che un architettura cosi sia il "meglio" sul mercato , cioè un architettura RISC come un mips32 o 64 è davvero molto più elegante ed efficiente rispetto all x86, che in pratica sarebbe un architettura CISC con degli accorgimenti che fanno diventare l istrucion set di tipo risc, già le istruzioni di lunghezza variabile complicano di molto l architettura, figuriamoci poi tutte le altre soluzioni per le retrocompatibilità con 8086, il riordino delle istruzioni , gli hazard sulle istruzioni e sui dati ecc ecc :eek:
Le pipeline quanto saranno complesse ?
L unità di controllo , non ne parliamo..:rolleyes:
Ma scusate un mips64 preso cosi, con la tecnologia attuale, con miliardi di transistor che potrebbero essere impiegati e con molte alu e fpu in parallelo , non sarebbe molto più veloce di un i7??
Comunque grazie per le risposte , io davvero non ci credevo al register file del i7 sul libro, pensavo che mancasse qualche pagina :D
Per me l'unica cosa agghiacciante di x64 e' (e non sono sicuro e quindi spero di sbagliarmi) la retrocompatibilita' con gli x86 a 16 bit, o modalita' "reale". Il solo fatto che si chiami "modalita' reale" e' patetico. :asd:
Purtroppo devo darti l'orrenda notizia AMD si è limitata ad aggiungere all'accrocchio un'ulteriore modalità "long mode" a 64 bit... insomma un altro "paciottamento" :cry:
Anche perche', se non erro, questa retrocompatibilita' comporta che il processore parta effettivamente in modalita' reale e debba poi essere switchato in modalita' protetta dal software, quindi il primissimo passo di qualsiasi boot loader deve essere scritto in codice assembly 8086 come quello che girava negli anni 80. :fagiano:
Sì tutti i sistemi operativi che girano su x86 (sì persino Cosmos ;) ) le prime righe di codice sono sempre le stesse è come se facessero il lavaggio del cervello alla CPU:
Tu sei un 8086 a 16 MHz!
In modalità reale con ben 16 bit e 64 KB di RAm
... e io sono un floppino da 3" e 1/4! Salta all'indirizzo 0x000...
Sì assolutamente patetico... pensando che siamo nel 2016 inoltrato!
Forse usando un BIOS (U)EFI si può partire direttamente in modalità "protetta" / "long mode", ma non sono nemmeno certo!
Per il resto x64 non mi sembra cosi' terribile, di certo 1000 volte meglio delle idiozie prive di senso umanamente intellegibile che si inventarono per gli 8086, come la segmentazione della memoria in cui i segmenti erano parzialmente sovrapposti. Molto utile, per nulla error-prone. :fagiano:
x64 è terribile perché tutte le idiozie prive di senso di cui parli sono ancora lì belle paciarotte ad occupare spazio nel die e nell'ISA!
Va da se' che avrei comunque preferito veder fiorire Itanium.
Purtroppo AMD voleva vivere a tutti i costi e ci ha in*ulato :D
Non ci credo che un architettura cosi sia il "meglio" sul mercato , cioè un architettura RISC come un mips32 o 64 è davvero molto più elegante ed efficiente rispetto all x86, che in pratica sarebbe un architettura CISC con degli accorgimenti che fanno diventare l istrucion set di tipo risc, già le istruzioni di lunghezza variabile complicano di molto l architettura, figuriamoci poi tutte le altre soluzioni per le retrocompatibilità con 8086, il riordino delle istruzioni , gli hazard sulle istruzioni e sui dati ecc ecc :eek:
No, non è il meglio sul mercato è il peggio! Sopravvive perché è retro-compatibile (non è nemmeno vero che sia Windows il problema, la Microsoft su richiesta fece Windows NT per Digital Alpha e per RISC, Windows 10 gira anche su ARM) è che la gente ha magari software proprietario che gira solo su x86 a 16 Bit in modalità "reale" e non gliene frega nulla se la CPU sta più tempo a decodificare le istruzioni che ad eseguirle!
Le pipeline quanto saranno complesse ?
L unità di controllo , non ne parliamo..:rolleyes:
Pensa che ci sono pure 2 FPU, la 8087 che è credo qualcosa di roba da una calcolatrice mentre era distratta (forse calcolava il pi greco?) e SSE che avebbe dovuto essere un'unità vettoriale, ma poi si sono impietositi e hanno messo istruzioni anche scalari per rendere obsoleta la vecchia FPU... peccato che almeno in modalità x86 alcune istruzioni non funzionino (per esempio ho scoperto a mie spese che non posso converite un Int64 in un double con SSE, ma con la FPU legacy invece sì! Ma a 64 bit potrei usare anche SSE! Assurdo...).
Ma scusate un mips64 preso cosi, con la tecnologia attuale, con miliardi di transistor che potrebbero essere impiegati e con molte alu e fpu in parallelo , non sarebbe molto più veloce di un i7??
Probabilmente lo sarebbe, ma AMD ha dimostrato che è impossibile scalzare x86, la tecnologia Itanium finisce nel cestino tra un anno e noi ci teniamo stretta la nostra modalità "reale" a 16 Bit!
Dai sarà per la prossima volta quando passeremo ai 128 Bit... tra 30 anni :cry:
Comunque grazie per le risposte , io davvero non ci credevo al register file del i7 sul libro, pensavo che mancasse qualche pagina :D
Dai comunque sono 8 anche se EBP non puoi davvero usarlo e ESP è lo stack, quindi forse sono 6...
x64 è terribile perché tutte le idiozie prive di senso di cui parli sono ancora lì belle paciarotte ad occupare spazio nel die e nell'ISA! Peggio per loro (i produttori di CPU), sono costretti ad aggiungere transistor inutili. Comunque sono idiozie che costituiscono un infinitesimo di tutta la roba che contiene un odierno processore x64, la segmentazione implementata nella IA32 e 64 ha molto piu' senso. I problemi di x86 e x64 veri e propri, oltre alle istruzioni di lunghezza variabile (feature completamente senza senso oggi che la memoria abbonda), sono il ben di Dio di feature e "circuitry" inutilizzati. Per esempio, se ricordo correttamente, gli odierni sistemi operativi piu' diffusi di fatto non usano la segmentazione ma solo la paginazione, e dei 4 "ring" di protezione ne usano solo due (0 e 3).
Direi che in definitiva l'architettura Intel soffre di due problemi: la mostruosa inerzia tecnologica e l'impossibilita' di rimuovere tecnologie per i quali non si sono mai sviluppati use cases rilevanti.
Dai sarà per la prossima volta quando passeremo ai 128 Bit... tra 30 anni :cry: Non credo che cio' avverra': 2^128 e' di piu' del numero di particelle nell'universo visibile, non potra' mai esistere alcun mezzo di storage cosi' capiente semplicemente perche' non esistono abbastanza molecole per memorizzare cosi' tanti byte.
2^64 invece se non erro sono 16 exabyte, altrettanto improbabile per prodotti consumer, pero' almeno ci permette di indicizzare piu' di 4 gigabyte, e questo e' molto comune.
Quanto ai dati grezzi, gia' non si sentiva il bisogno di memorizzare numeri da 64 bit, motivo per cui nei i compilatori C e C++ a 64 bit la dimensione di int e long e' rimasta a 32 bit, figuriamoci 128.
Secondo me con l'ampiezza del bus siamo arrivati, non serve altro. Il prossimo passo sono le macchine non deterministiche (i computer quantistici).
tomminno
29-08-2016, 16:28
Se non ricordo male già dalle CPU Intel Pentium Pro (1995), fisicamente i registri dati erano una decina invece dei soli 4 previsti dall'ISA X86 i quali venivano rimappati dinamicamente tramite Register Ranaming.
La micro-architettura P6 è sempre alla base dei Core di oggi.
Comunque dai non sono 4, ma ben 8!
http://www.cs.virginia.edu/~evans/cs216/guides/x86.html
OK ESP e EBP di fatto non si possono usare se non per tenere puntatori allo stack, ma è leggermente meglio... certo se pensiamo che ci sono architetture che hanno 32 o 64 registri c'è da piangere :cry:
Forse in parte OT, ma questo è un proof of concept di come potrebbe essere la CPU del futuro:
http://forwardcom.info/#introduction
thimoned
01-09-2016, 12:20
Ho core I7 di 6 ° generazione, funziona alla grande.
tomminno
01-09-2016, 13:02
Comunque dai non sono 4, ma ben 8!
http://www.cs.virginia.edu/~evans/cs216/guides/x86.html
OK ESP e EBP di fatto non si possono usare se non per tenere puntatori allo stack, ma è leggermente meglio... certo se pensiamo che ci sono architetture che hanno 32 o 64 registri c'è da piangere :cry:
Forse in parte OT, ma questo è un proof of concept di come potrebbe essere la CPU del futuro:
http://forwardcom.info/#introduction
Si io parlavo di registri per i dati, quelli per X86 ed evoluzioni varie sono 4 non si scappa ;)
Sinceramente non so quanti ne abbiano fisicamente i nuovi Core, sarebbe un dato interessante per capire gli sviluppi della microarchitettura negli ultimi 20 anni.
ingframin
01-09-2016, 13:06
Forse in parte OT, ma questo è un proof of concept di come potrebbe essere la CPU del futuro:
http://forwardcom.info/#introduction
La cosa che mi fa sorridere è che in tutte queste discussioni sulle CPU del futuro non si vede mai una riga di Verilog o di VHDL o niente che riguarda límplementazione vera e propria...
C'è un motivo per cui l'8086 a suo tempo fu implementato in quel modo, non è che alla Intel erano un gruppo di fessi.
Scrivere l'ISA del futuro su un sito web è molto semplice, ma poi trasformarla in un microprocessore non lo è affatto!
Forse il tipo, prima di pensare al formato dei file binari, dovrebbe capire quali sono le limitazioni pratiche di quello che propone.
Tipo l'indicizzazione degli array a rovescio con 4 elementi in parallelo e la gestione del caso di lunghezza non multipla di 4 che è a metà della pagina.
Contare gli elementi 1 a 1 comporta l'uso di un contatore a n-bit come indice del decoder di linea.
Andare a saltelli come vuol fare lui comporta un bus molto più largo e una circuiteria di controllo molto più complessa.
La cosa che mi fa sorridere è che in tutte queste discussioni sulle CPU del futuro non si vede mai una riga di Verilog o di VHDL o niente che riguarda límplementazione vera e propria...
Beh l'intenzione di fare una versione su FPGA c'è poi vedremo se mai ci sarà e come andrà l'idea di avere una ISA standard e open source di sicuro non è male vedremo come andrà a finire.
C'è un motivo per cui l'8086 a suo tempo fu implementato in quel modo, non è che alla Intel erano un gruppo di fessi.
In realtà Intel stessa sapeva che l'architettura x86 non era venuta e secondo la loro roadmap non avrebbe MAI dovuto esistere un 486, ma questo:
https://en.wikipedia.org/wiki/Intel_iAPX_432
il loro problema è che aveva reso 8086 retro-compatibile con 8080 e quindi anche il processore a 32 bit avrebbe dovuto essere retro-compatibile con quello a 16 bit o la gente... beh non lo comprava!
... e infatti iApx 432 non se lo è ca*ato nessuno e Intel è stata costretta a rilasciare 486 di tutta fretta patchando un processore a 16 Bit per diventare a 32 bit!
Quando hai un road map e diventa un colossale fallimento non è c'è da ridere devi tirar fuori qualcosa in fretta o IBM va da qualcun altro :eek:
Non vorrei mai essere stato nei panni di quei poveracci che avevano credo la CPU del futuro e saranno stati licenziati tutti... in tronco!
La storia si è ripetuta quasi 30 anni dopo con Itanium che doveva spaccare il mondo (e io l'ISA me la sono studiata era 100 volte meglio di x86!), ma la compatibilità con x86 era una chiavica (roba tipo Pentium 1 quando in giro c'erano già i Pentium 3!) e quindi nessuno se lo è filato e stavolta è andata peggio Intel ha puntato i piedi e AMD ha accrocchiato x64 al posto ed Intel è stata costretta a chiedere i "sorgenti" al nemico... chissà come ci hanno patito.
Scrivere l'ISA del futuro su un sito web è molto semplice, ma poi trasformarla in un microprocessore non lo è affatto!
Forse il tipo, prima di pensare al formato dei file binari, dovrebbe capire quali sono le limitazioni pratiche di quello che propone.
Quella parte devo dire non l'ho capita nemmeno io va bene definire l'ISA, ma l'ABI forse è un po' troppo quello è compito del Sistamo Operativo definirla...
Cosmos userà probabilmente il formato PEXE (quello di Windows per far la semplice) io "ELF" non lo tocco nemmeno con un palo lungo venti metri :D
Tipo l'indicizzazione degli array a rovescio con 4 elementi in parallelo e la gestione del caso di lunghezza non multipla di 4 che è a metà della pagina.
Contare gli elementi 1 a 1 comporta l'uso di un contatore a n-bit come indice del decoder di linea.
Andare a saltelli come vuol fare lui comporta un bus molto più largo e una circuiteria di controllo molto più complessa.
A me la persona per quanto riguarda i calcoli vettoriali sembra abbastanza preparata:
http://www.agner.org/optimize/#vectorclass
comunque se vuoi chiedere direttamente a lui come ha intenzione di risolvere questo problema non ti resta che chiederglielo:
http://www.agner.org/optimize/blog/read.php?i=634
domenico88
03-09-2016, 15:38
Ho core I7 di 6 ° generazione, funziona alla grande.
You win :D
Diciamolo pure apertamente è probabilmente la peggiore architettura di CPU sul mercato (pochi registri, instruction set che contiene migliaia di istruzioni, "pacioccato" alla c*zzo di cane negli anni per aggiungere nuove funzionalità...) purtroppo quello che l'ha fatta sopravvivere era la retro compatibilità che ha fatto sì che archittetture migliori sia di altri (come RISC appunto) che di Intel stessa (come Itanium) non riuscirono mai ad affermarsi perché non erano appunto retro compatibili con x86!
Solo oggi con i cellulari / tablet ARM inizia ad avere qualche chanche...
Sicuramente è la meno "elegante".
Ma è quella che ha le implementazioni più performanti nel calcolo general purpose. E nell'ultimo periodo possiamo anche affermare che i processori x86 se la battono in efficienza (se parliamo di performance per watt) con i processori basati su ARM.
Il problema di Itanium leggendo la storia è stato principalmente la difficoltà nel fare compilatori ottimizzanti per questa architettura.
Purtroppo non basta l'eleganza di una architettura per rendere le implementazioni performanti e/o ben supportate, bisogna considerare anche la disponibilità e l'efficacia dei tool di sviluppo.
tomminno
06-09-2016, 09:28
Itanium non è mai stata pensata come architettura mainstream. Una CPU costa(va) anche 9000$. Caso mai poteva essere un concorrente per Power. Ma con X86 ormai perennemente presente nella TOP500 a che serve un'architettura teoricamente migliore? Quasi nessun utilizzo necessita di qualcosa che vada oltre le capacità attuali dell'architettura X86.
L'unico settore è il basso consumo, ma ce la vorrei vedere una versione a basso consumo di Itanium...
Itanium non è mai stata pensata come architettura mainstream. Una CPU costa(va) anche 9000$. Caso mai poteva essere un concorrente per Power. Ma con X86 ormai perennemente presente nella TOP500 a che serve un'architettura teoricamente migliore? Quasi nessun utilizzo necessita di qualcosa che vada oltre le capacità attuali dell'architettura X86.
L'unico settore è il basso consumo, ma ce la vorrei vedere una versione a basso consumo di Itanium... Quindi stai dicendo che mentre il mondo aveva bisogno di un'architettura a 64 bit e AMD ne sviluppava una, Intel... faceva altro. :stordita:
Ho difficolta' a crederlo, secondo me gli obiettivi iniziali di Itanium erano diversi.
pabloski
06-09-2016, 10:53
Ma è quella che ha le implementazioni più performanti nel calcolo general purpose. E nell'ultimo periodo possiamo anche affermare che i processori x86 se la battono in efficienza (se parliamo di performance per watt) con i processori basati su ARM.
C'e' da vedere. Intel ha rimaneggiato a turno: il nanometro "bidone", il TDP ( poi ha tirato fuori il SDP ). E considera che i confronti attuali vengono fatti tra CPU x86 che usa FinFET e CPU ARM che non lo usano! Vedremo prossimamente con i nuovi SoC server di Cavium, Applied Micro, Qualcomm, Phytium e compagnia, come si metteranno le cose.
Se tanto mi da' tanto, il fatto che Intel si sia ritirata dal mercato mobile, la dice lunga...
pabloski
06-09-2016, 10:57
Quindi stai dicendo che mentre il mondo aveva bisogno di un'architettura a 64 bit e AMD ne sviluppava una, Intel... faceva altro. :stordita:
Ho difficolta' a crederlo, secondo me gli obiettivi iniziali di Itanium erano diversi.
Non deve meravigliare. Intel all'epoca commise una quantita' colossale di errori, tanto che si arriva ad una vera e propria crisi all'epoca dei Pentium 4. L'adozione di AMD64 e un ritorno a P6 ( cestinando Netburst ) gli salvarono il collo. Era l'epoca in cui AMD faceva furore e i Pentium erano usati dai pizzaioli come forni.
tomminno
06-09-2016, 16:42
Quindi stai dicendo che mentre il mondo aveva bisogno di un'architettura a 64 bit e AMD ne sviluppava una, Intel... faceva altro. :stordita:
Ho difficolta' a crederlo, secondo me gli obiettivi iniziali di Itanium erano diversi.
Non mi pare che abbiano mai cercato di sostituire X86 con Itanium, non c'è stata una sola offerta commerciale che potesse suggerire questo. Hanno solo provato ad aggredire il mercato dei Power, senza riuscirci tra l'altro.
E sappiamo bene che Intel avrebbe potuto (negli anni 2000) vendere in perdita Itanium senza troppi problemi.
Tra l'altro Itanium credo sia morto nel 2012, non mi pare abbiano fatto uscire più niente di nuovo da allora.
Quindi in sostanza per la migrazione alle architetture a 64 bit Intel non ha mosso un dito per anni salvo poi svegliarsi a seguito del successo di AMD? :stordita:
pabloski
07-09-2016, 08:44
Quindi in sostanza per la migrazione alle architetture a 64 bit Intel non ha mosso un dito per anni salvo poi svegliarsi a seguito del successo di AMD? :stordita:
Molto cruda, ma e' cosi'.
tomminno
07-09-2016, 08:54
Quindi in sostanza per la migrazione alle architetture a 64 bit Intel non ha mosso un dito per anni salvo poi svegliarsi a seguito del successo di AMD? :stordita:
Hai mai trovato un solo accenno di Intel da qualche parte di voler sostituire X86 con Itanium?
Se avessero voluto farlo non avrebbero venduto la sola CPU a 9000$. I piani per Itanium erano quelli di aggredire il mercato di Power, Spark, Alpha.
E l'acquisto di Alpha e successiva repentina dismissione serviva proprio a favorire il progetto Itanium.
Negli anni 90 le architetture a 64 bit servivano in ambito grossi mainframe o workstation e X86 non era certamente ben vista.
Hai mai trovato un solo accenno di Intel da qualche parte di voler sostituire X86 con Itanium?
Se avessero voluto farlo non avrebbero venduto la sola CPU a 9000$. I piani per Itanium erano quelli di aggredire il mercato di Power, Spark, Alpha.
E l'acquisto di Alpha e successiva repentina dismissione serviva proprio a favorire il progetto Itanium.
Negli anni 90 le architetture a 64 bit servivano in ambito grossi mainframe o workstation e X86 non era certamente ben vista.
Cito da Wikepedia che quindi magari non è una fonte super certa, ma anch'io ricordo questo:
During development, Intel, HP, and industry analysts predicted that IA-64 would dominate in servers, workstations, and high-end desktops, and eventually supplant RISC and Complex Instruction Set Computing (CISC) architectures for all general-purpose applications.[7][8] Compaq and Silicon Graphics decided to abandon further development of the Alpha and MIPS architectures respectively in favor of migrating to IA-64.[9]
C'era molto fermento per Itanium in quegli anni sembrava che dovesse spaccare il mondo! Di fatto il risultato fu che la versione consumer di Windows XP a 64 Bit uscì con enorme ritardo perché Microsoft aspettò per anni la versione "desktop" di Itanium che non arrivò mai...
Se avessero fatto un miglior emulatore di x86 IMHO oggi avremmo tutti degli Itanium, ma invece... abbiamo AMD64 :cry:
tomminno
12-09-2016, 16:16
Cito da Wikepedia che quindi magari non è una fonte super certa, ma anch'io ricordo questo:
During development, Intel, HP, and industry analysts predicted that IA-64 would dominate in servers, workstations, and high-end desktops, and eventually supplant RISC and Complex Instruction Set Computing (CISC) architectures for all general-purpose applications.[7][8] Compaq and Silicon Graphics decided to abandon further development of the Alpha and MIPS architectures respectively in favor of migrating to IA-64.[9]
C'era molto fermento per Itanium in quegli anni sembrava che dovesse spaccare il mondo! Di fatto il risultato fu che la versione consumer di Windows XP a 64 Bit uscì con enorme ritardo perché Microsoft aspettò per anni la versione "desktop" di Itanium che non arrivò mai...
Se avessero fatto un miglior emulatore di x86 IMHO oggi avremmo tutti degli Itanium, ma invece... abbiamo AMD64 :cry:
Se avessimo avuto degli Itanium, adesso avremmo tutti ARM :ciapet:
Non credo sarebbe stata un'architettura adatta a portatili o dispositivi a basso consumo.
Già PowerPC, derivata da Power, ha perso contro X86 proprio per problemi di efficienza energetica.
E se c'è un'architettura che potrà scalzare X86 è proprio ARM che è più efficiente, non necessariamente più potente.
Mi pare inoltre che un'architettura come quella di Itanium sia più adatta a linguaggi che oggi nessuno vuole più usare e che fanno uso pesante del compilatore (qualcuno ha detto C/C++? :Perfido: ). Oggi sono usatissimi i linguaggi managed e di scripting che fanno tutto (o molto) a runtime, la vedo difficile una generazione di codice ottimizzata su quell'architettura.
Il fatto che i suddetti linguaggi "facciano tutto (o molto) a runtime", che intendo come l'assenza di type system, non e' affatto una cosa positiva o desiderabile, per qualunque linguaggio. Prendi JavaScript ad esempio, diventa molto piu' sicuro se usato con flow (https://flowtype.org/), dove per "sicuro" intendo dire il contrario di "error-prone". Il motore JavaScript poi in realta' continuera' a fare type checking a runtime indipendentemente dall'uso di flow, ma non e' al corrente che se lo sviluppatore ha usato flow certi errori non possono in alcun modo verificarsi. Se JavaScript avesse un type system statico, sarebbe un linguaggio piu' efficiente.
Se invece parliamo della gestione automatica della memoria e della garbage collection e' tutto un altro discorso.
cdimauro
02-10-2016, 11:24
Ancora, il core i7 è dotato di tre modalità operative, modalità reale(si comporta come un 8088) modalità protetta e modalità virtuale ..
Quest'ultima serve per far girare codice 8086 in una sandbox, e dunque in maniera controllata (e possibilmente "sicura").
I mie dubbi pero riguardavano i registri dedicati della cpu, dalla figura del testo sarebbero soltanto 16 registri di cui, i registri EAX EBX ECX EDX di uso generale a 32 bit altri CS SS .. a 16 bit che provengono dalle compatibilità del 8088 e gli ultimi EIP EFLAGS , ripettivamente program counter e program status word
Per IA-32 AKA x86, sì, ma ci sono anche diversi "machine register" per gestire diversi aspetti della CPU, nonché ottenere diverse informazioni.
Ora mi domando, possibile che una cpu cosi moderna e alquanto veloce possegga solo questi pochi registri, in pratica verrebbe usato solo il primo gruppo da 4 registri per i dati e le istruzioni aritmetiche
I registri sono 8, non 4, sebbene uno sia riservato per lo stack pointer.
In ogni caso con tecniche di register rename questo limite viene molto mitigato nelle moderne microarchitetture.
Mi sembra di aver capito che il core i7 faccia molti riferimenti allo stack per l elaborazione dei dati con molte operazioni di push e pop, dato che appunto ci sono pochi registri disponibili, al contrario di un architettura RISC ad esempio che limita gli accessi in memoria solo alle istruzioni LOAD e STORE ,
Stai parlando di due cose diverse.
La prima è riferita all'ABI, e su x86 si usa GENERALMENTE (ma ognuno può definire la sua ABI) lo stack per passare parametri a una routine. Ma puoi benissimo definire un'ABI che preveda il passaggio di dati su alcuni registri, finché non si esauriscono, e gli altri sullo stack.
La seconda cosa di cui parli riguarda, invece, il fatto che x86, da buon CISC, consente di eseguire operazioni che accedono direttamente alla memoria, mentre per i RISC ciò avviene esclusivamente facendo uso di operazioni di LOAD/STORE.
Cioè in questo modo le prestazioni con i continui accessi in memoria dovrebbero essere molto limitate o sbaglio
Gli accessi in memoria di cui parli sono limitati allo stack, e dunque ben gestiti dalla cache dati L1 del processore. Ovviamente con tutti i limiti del caso (una moderna microarchitettura è in grado di eseguire "soltanto" 2 load e 1 una store da/a cache L1 dati).
Per cui è un limite, sicuramente, ma non rappresenta un collo di bottiglia per una moderna architettura, grazie anche all'esecuzione out-of-order che consente di schedulare e gestire meglio questi limiti.
Ciao grazie in anticipo :)
Arrivo molto tardi, per cui non so se ti sarà utile quel che ho scritto adesso.
cdimauro
02-10-2016, 12:35
Diciamolo pure apertamente è probabilmente la peggiore architettura di CPU sul mercato (pochi registri, instruction set che contiene migliaia di istruzioni, "pacioccato" alla c*zzo di cane negli anni per aggiungere nuove funzionalità...) purtroppo quello che l'ha fatta sopravvivere era la retro compatibilità che ha fatto sì che archittetture migliori sia di altri (come RISC appunto) che di Intel stessa (come Itanium) non riuscirono mai ad affermarsi perché non erano appunto retro compatibili con x86!
Cosa intendi per "migliori"? E perché un CISC non potrebbe essere una buona architettura?
Per me l'unica cosa agghiacciante di x64 e' (e non sono sicuro e quindi spero di sbagliarmi) la retrocompatibilita' con gli x86 a 16 bit, o modalita' "reale". Il solo fatto che si chiami "modalita' reale" e' patetico. :asd:
Anche perche', se non erro, questa retrocompatibilita' comporta che il processore parta effettivamente in modalita' reale e debba poi essere switchato in modalita' protetta dal software, quindi il primissimo passo di qualsiasi boot loader deve essere scritto in codice assembly 8086 come quello che girava negli anni 80. :fagiano:
Sì, esatto, ma il legacy dovuto a 8086 è praticamente ininfluente, a parte per i programmatori di boot loader, per l'appunto. :asd:
Per il resto x64 non mi sembra cosi' terribile, di certo 1000 volte meglio delle idiozie prive di senso umanamente intellegibile che si inventarono per gli 8086, come la segmentazione della memoria in cui i segmenti erano parzialmente sovrapposti. Molto utile, per nulla error-prone. :fagiano:
Devi sempre considerare l'epoca in cui è nato 8086, e le finalità. Anche a me non piacciono i segmenti parzialmente sovrapponibili, ma alla fine per gestire la memoria in sistemi di quel tipo, cos'avresti dovuto fare? Con 16 byte di granularità per segmento potevi facilmente gestire l'allocazione di memoria.
A parte questo, 8086 si portava già dietro (ed era necessaria, per esigenze di mercato) la parziale compatibilità con l'8085 (solo assembly, comunque) che aveva avuto un discreto successo commerciale, per facilitare enormemente il porting delle applicazioni esistenti (all'epoca c'era un traduttore da 8085 a 8086, che AL PIU' richiedeva qualche piccola modifica all'output).
Per cui, sì, non è certamente l'architettura più bella mondo, ma cerchiamo anche di contestualizzare. Oggi è facile parlare di architetture più "belle", ma col senno di poi mi pare ovvio che si possa fare molto meglio.
Va da se' che avrei comunque preferito veder fiorire Itanium.
Io no, invece: non ho mai creduto alla possibilità che un compilatore possa fare meglio di un'unità d'esecuzione out-of-order. Di fatti chi ha lavorato con Itanium (di cui non conosco i dettagli dell'ISA, ma ho un po' di conoscenze generali / di più alto livello) ha affermato che nei bundle a 128-bit contenenti le 3 istruzioni impacchettate, c'erano pure parecchie NOP. Il che equivale a un enorme spreco, perché l'obiettivo era, ovviamente, di infilare ed eseguire quante più istruzioni possibili.
Il tutto senza considerare, poi, che il codice generato era decisamente, scarsamente denso, e dunque occupando parecchio spazio -> maggior pressione sulle cache -> maggior pressione sulla memoria. Da cui, penso, l'adozione di generosissime cache per questa famiglia di processori.
Non ci credo che un architettura cosi sia il "meglio" sul mercato , cioè un architettura RISC come un mips32 o 64 è davvero molto più elegante ed efficiente rispetto all x86, che in pratica sarebbe un architettura CISC
E questo è anche il suo vantaggio, che le consente di avere codice più denso con gli annessi benefici (vedi sopra), nonché la possibilità di eseguire più "lavoro utile" con le istruzioni eseguite (il che aiuta sia densità di codice sia le prestazioni).
con degli accorgimenti che fanno diventare l istrucion set di tipo risc,
Qui non ti seguo. Cosa intendi?
già le istruzioni di lunghezza variabile complicano di molto l architettura,
Ma ciò ha pure dei vantaggi non indifferenti (vedi ancora sopra), e non è un caso che tante architetture RISC siano state costrette ad adottare ISA con istruzioni a lunghezza variabile (quindi, di fatto, divenendo dei CISC).
figuriamoci poi tutte le altre soluzioni per le retrocompatibilità con 8086,
Che ha un peso trascurabile.
il riordino delle istruzioni ,
Questo lo fanno praticamente tutti i processori moderni dotati di esecuzione fuori ordine.
gli hazard sulle istruzioni e sui dati ecc ecc :eek:
Tutte cose che avevano senso quando sono nati i RISC, perché avevi pochi transistor a disposizione, ma grazie alla "legge" di Moore già dopo un po' di anni questo non è più stato un problema.
Le pipeline quanto saranno complesse ?
Non molto, specialmente di questi tempi.
L unità di controllo , non ne parliamo..:rolleyes:
Qui c'è sicuramente un vantaggio per i RISC, che hanno ALU più semplici (non devono gestire diverse dimensioni per gli interi, incluse politiche di masking per i dati contenuti nei registri), ma d'altra parte x86 ti consente anche di manipolare direttamente interi a 8 e 16 bit, e anche questo è un discreto vantaggio.
Ma scusate un mips64 preso cosi, con la tecnologia attuale, con miliardi di transistor che potrebbero essere impiegati e con molte alu e fpu in parallelo , non sarebbe molto più veloce di un i7??
Non penso proprio, perché oggi la stragrande maggioranza di questi transistor se la mangiano la cache, unità di branching, tag, ecc. ecc.
Detto in altri termini, il vantaggio dei RISC richiedere pochi transistor per svolgere certe operazioni è diventato assolutamente trascurabile già quando era possibile impacchettare qualche milionata di transistor in un chip.
Tant'è che è a partire dall'80486 (e col 68040 della Motorola), che i CISC cominciarono a essere competitivi coi RISC più blasonati, rubandogli persino mercato in ambito server e workstation.
cdimauro
02-10-2016, 12:46
Purtroppo devo darti l'orrenda notizia AMD si è limitata ad aggiungere all'accrocchio un'ulteriore modalità "long mode" a 64 bit... insomma un altro "paciottamento" :cry:
In realtà x64, oltre ad aver avuto l'innegabile pregio di raddoppiare i registri general purpose e SIMD, ha portato anche a un po' di pulizia (eliminando diverse istruzioni "legacy"), e introducendo la comoda (nonché usatissima) modalità d'indirizzamento relativa all'RIP.
Sì assolutamente patetico... pensando che siamo nel 2016 inoltrato!
Forse usando un BIOS (U)EFI si può partire direttamente in modalità "protetta" / "long mode", ma non sono nemmeno certo!
Sì, ma questo vale per un s.o. "UEFI" da avviare: il firmware UEFI dovrebbe comunque partire in modalità reale (8086).
x64 è terribile perché tutte le idiozie prive di senso di cui parli sono ancora lì belle paciarotte ad occupare spazio nel die e nell'ISA!
Non tanto. In particolare nel die, con miliardi di transistor, il "legacy" è sostanzialmente trascurabile.
Purtroppo AMD voleva vivere a tutti i costi e ci ha in*ulato :D
E' vero che avrebbe potuto fare di molto meglio, pur mantenendo la compatibilità x86, ma avrebbe anche richiesto molto più tempo e risorse, rispetto a piazzare una piccola patch (che ha richiesto soltanto il 5% in più di transistor).
No, non è il meglio sul mercato è il peggio! Sopravvive perché è retro-compatibile (non è nemmeno vero che sia Windows il problema, la Microsoft su richiesta fece Windows NT per Digital Alpha e per RISC, Windows 10 gira anche su ARM) è che la gente ha magari software proprietario che gira solo su x86 a 16 Bit in modalità "reale" e non gliene frega nulla se la CPU sta più tempo a decodificare le istruzioni che ad eseguirle!
Ehm... no! :D
Una CPU Intel moderna esegue l'80% delle istruzioni che sono già decodificate, grazie a una speciale cache per le cosiddette uop. Questo contribuisce enormemente all'abbattimento dei consumi, nonché alle prestazioni (è come se avesse una pipeline molto corta. Anche molto più corta di un RISC).
Pensa che ci sono pure 2 FPU, la 8087 che è credo qualcosa di roba da una calcolatrice mentre era distratta (forse calcolava il pi greco?) e SSE che avebbe dovuto essere un'unità vettoriale, ma poi si sono impietositi e hanno messo istruzioni anche scalari per rendere obsoleta la vecchia FPU...
In realtà la vecchia FPU x87 non è ancora del tutto obsoleta, e anzi in alcuni ambiti viene ancora impiegata perché garantisce una precisione che nessun'altra FPU commerciale (a meno di particolare progetti dedicati) offre: FP a 80 bit (16 di esponente e 64 di mantissa).
Probabilmente lo sarebbe, ma AMD ha dimostrato che è impossibile scalzare x86, la tecnologia Itanium finisce nel cestino tra un anno e noi ci teniamo stretta la nostra modalità "reale" a 16 Bit!
Dai sarà per la prossima volta quando passeremo ai 128 Bit... tra 30 anni :cry:
Non passeremo mai a processori a 128 bit: siamo già arrivati al capolinea... come Itanium.
Dai comunque sono 8 anche se EBP non puoi davvero usarlo e ESP è lo stack, quindi forse sono 6...
EBP puoi usarlo se fai a meno di creare uno stack frame.
cdimauro
02-10-2016, 12:55
Peggio per loro (i produttori di CPU), sono costretti ad aggiungere transistor inutili.
Su chip da miliardi di transistor? :D
Comunque sono idiozie che costituiscono un infinitesimo di tutta la roba che contiene un odierno processore x64, la segmentazione implementata nella IA32 e 64 ha molto piu' senso.
La segmentazione è parzialmente funzionante su x64.
I problemi di x86 e x64 veri e propri, oltre alle istruzioni di lunghezza variabile (feature completamente senza senso oggi che la memoria abbonda),
Direi proprio di no, per quanto detto prima: è estremamente comoda perché aumenta la densità di codice, e questo influisce positivamente su TUTTA la gerarchia della memoria. Non esiste lo spazio, quando parliamo di memoria, ma anche di banda.
sono il ben di Dio di feature e "circuitry" inutilizzati. Per esempio, se ricordo correttamente, gli odierni sistemi operativi piu' diffusi di fatto non usano la segmentazione ma solo la paginazione,
No, la segmentazione c'è ancora, sebbene non funzionante al 100% come IA-32.
Ti sei mai chiesto come venga implementato il meccanismo di Thread-Local-Storage (TLS) su x86 & x64? O come si possa accedere direttamente a (certa) memoria del kernel? ;)
e dei 4 "ring" di protezione ne usano solo due (0 e 3).
Questo è vero. In compenso sono stati introdotti i ring -1 e -2. :asd:
Direi che in definitiva l'architettura Intel soffre di due problemi: la mostruosa inerzia tecnologica e l'impossibilita' di rimuovere tecnologie per i quali non si sono mai sviluppati use cases rilevanti.
Hum. Ancora una volta no. Certi use case che in passato sono stati additati come il cancro, in realtà sono tornati di moda nelle recenti microarchitetture.
Un paio di esempi: spostamento e riempimento della memoria oggi sono più veloci se realizzate usando le ultravecchissime (nate con 8086 per l'appunto) istruzioni di "stringa".
Si io parlavo di registri per i dati, quelli per X86 ed evoluzioni varie sono 4 non si scappa ;)
Per i soli dati sarebbero 7 o 6, a seconda se si possa o meno usare EBP.
Sinceramente non so quanti ne abbiano fisicamente i nuovi Core, sarebbe un dato interessante per capire gli sviluppi della microarchitettura negli ultimi 20 anni.
Siamo nell'ordine di poco meno di 200. :D
cdimauro
02-10-2016, 13:08
In realtà Intel stessa sapeva che l'architettura x86 non era venuta e secondo la loro roadmap non avrebbe MAI dovuto esistere un 486, ma questo:
https://en.wikipedia.org/wiki/Intel_iAPX_432
il loro problema è che aveva reso 8086 retro-compatibile con 8080 e quindi anche il processore a 32 bit avrebbe dovuto essere retro-compatibile con quello a 16 bit o la gente... beh non lo comprava!
... e infatti iApx 432 non se lo è ca*ato nessuno e Intel è stata costretta a rilasciare 486 di tutta fretta patchando un processore a 16 Bit per diventare a 32 bit!
Quando hai un road map e diventa un colossale fallimento non è c'è da ridere devi tirar fuori qualcosa in fretta o IBM va da qualcun altro :eek:
Non vorrei mai essere stato nei panni di quei poveracci che avevano credo la CPU del futuro e saranno stati licenziati tutti... in tronco!
Il problema di iAPX-432 è stato l'overengineering: era davvero un'architettura TROPPO complessa. (http://www.appuntidigitali.it/4151/iapx-432-il-primo-processore-a-32-bit-di-intel-a-oggetti/)
La storia si è ripetuta quasi 30 anni dopo con Itanium che doveva spaccare il mondo (e io l'ISA me la sono studiata era 100 volte meglio di x86!), ma la compatibilità con x86 era una chiavica (roba tipo Pentium 1 quando in giro c'erano già i Pentium 3!)
La compatibilità IA-32 era realizzata con un emulatore interno, che girava decisamente male.
e quindi nessuno se lo è filato e stavolta è andata peggio Intel ha puntato i piedi e AMD ha accrocchiato x64 al posto ed Intel è stata costretta a chiedere i "sorgenti" al nemico... chissà come ci hanno patito.
Direi molto. :D
Itanium non è mai stata pensata come architettura mainstream. Una CPU costa(va) anche 9000$. Caso mai poteva essere un concorrente per Power. Ma con X86 ormai perennemente presente nella TOP500 a che serve un'architettura teoricamente migliore? Quasi nessun utilizzo necessita di qualcosa che vada oltre le capacità attuali dell'architettura X86.
L'unico settore è il basso consumo, ma ce la vorrei vedere una versione a basso consumo di Itanium...
In realtà Itanium sarebbe dovuto approdare poi, gradualmente, anche su desktop, perché Intel non aveva nessuna intenzione di sviluppare un'estensione a 64 bit di IA-32.
Intel aveva già la sua architettura a 64 bit, ed era Itanium, per l'appunto.
C'e' da vedere. Intel ha rimaneggiato a turno: il nanometro "bidone", il TDP ( poi ha tirato fuori il SDP ).
Guarda che i consumi reali sono stati accertati da siti come Anandtech, usando le loro apparecchiature.
E considera che i confronti attuali vengono fatti tra CPU x86 che usa FinFET e CPU ARM che non lo usano! Vedremo prossimamente con i nuovi SoC server di Cavium, Applied Micro, Qualcomm, Phytium e compagnia, come si metteranno le cose.
Già da tempo i FinFET sono arrivati anche per gli ARM.
Se tanto mi da' tanto, il fatto che Intel si sia ritirata dal mercato mobile, la dice lunga...
I prodotti Intel era senz'altro competitivi, come già detto, ma se non hai mercato perché sei arrivato troppo tardi, puoi fare anche se ti chiami Intel.
D'altra parte mi pare che, invece, in ambito tablet / 2:1 le cose vadano decisamente meglio. Qui non hai nulla da dire, immagino...
E l'acquisto di Alpha e successiva repentina dismissione serviva proprio a favorire il progetto Itanium.
Se non ricordo male Alpha, assieme a XScale, non furono acquistati da Intel, ma ottenuti a seguito della chiusura di un contenzioso legale.
Negli anni 90 le architetture a 64 bit servivano in ambito grossi mainframe o workstation e X86 non era certamente ben vista.
All'epoca no, ma i limiti dell'architettura IA-32 relativamente all'indirizzamento della memoria erano piuttosto evidenti, tant'è che fu introdotta anche la famigerata PAE per poter indirizzare fino a 64GB di memoria fisica.
Per era naturale pensare a un successore a 64 bit. Ma per Intel questo era Itanium, per l'appunto.
In realtà x64, oltre ad aver avuto l'innegabile pregio di raddoppiare i registri general purpose e SIMD, ha portato anche a un po' di pulizia (eliminando diverse istruzioni "legacy"), e introducendo la comoda (nonché usatissima) modalità d'indirizzamento relativa all'RIP.
Beh però già che c'erano potevano quadruplicarli no? Col senno di poi anche con il passaggio 386 --> 486 potevano già raddoppiare i registri...
In modalità 32 bit di fatto si è obbligati a passare gli argomenti usando lo stack qualche calling convention più "evoluta" usa almeno un registro per il valore di ritorno... su Linux credo si usi sempre e solo lo stack.
Anche su Cosmos a essere obbiettivi, ma lì è perché - per ora - stiamo seguendo alla lettera le specifiche ECMA e .NET come JVM è una "stack based Virtual Machine" quindi...
Sì, ma questo vale per un s.o. "UEFI" da avviare: il firmware UEFI dovrebbe comunque partire in modalità reale (8086).
Beh ma UEFI non era stato creato apposta per evitare la modalità reale che su Itanium appunto non esisteva? O la versione x86 ha comunque bisogno di questo perché un x86 non può tecnicamente partire in modalità a 32 Bit?
Non tanto. In particolare nel die, con miliardi di transistor, il "legacy" è sostanzialmente trascurabile.
Se vuoi la mia è più una cosa "filosofica" io sono a favore della retrocompatibilità permette di mantenere gli investimenti fatti sul software ecc... ma quando si inizia ad avere 40 anni di retrocompatibilità alle spalle si inizia ad esagerare dai!
E` il momento di mettersi al tavolino e ridisegnare tutto dall'inizio cosa che Intel ha pure fatto con Itanium quindi non è affatto da biasimare sia chiaro... peccato che il mercato voleva solo un x86 che potesse indirizzare > 4 GB di RAM :cry:
Ehm... no! :D
Una CPU Intel moderna esegue l'80% delle istruzioni che sono già decodificate, grazie a una speciale cache per le cosiddette uop. Questo contribuisce enormemente all'abbattimento dei consumi, nonché alle prestazioni (è come se avesse una pipeline molto corta. Anche molto più corta di un RISC).
OK però il fatto che la CPU debba decodificare le sue stesse istruzioni perché di fatto lei stessa non le "capisce" resta e beh fa un po' storcere il naso :D
Non passeremo mai a processori a 128 bit: siamo già arrivati al capolinea... come Itanium.
Questo mi rattrista un po' alla fine escono nuove CPU, ma che cosa realmente sta cambiando in questi anni? Aggiungono solo nuove istruzioni vettoriali che probabilmente il 90% dei compilatori manco supporta (GCC di default compila per 486 quindi :Prrr: ).
Anche l'aumento di velocità pura si è fermato sembra impossibile avere CPU a più di 3 GHz e beh 4 CPU (di 2 magari virtuali con hiperthreading) a 1.6 GHz non saranno mai lo stesso che avere una CPU a 6.4 GHz...
Boh cosa dobbiamo sperare per avere qualcosa di davvero nuovo? CPU non binarie? CPU quantistiche? CPU positroniche? Pare che l'importante in tutti i casi sarà avere un emulatore funzionante di x86 :D
(Che bello un robot "Asimoniano" con emulatore di x86 incorporato mai gli dovesse servire far girare il DOS :Prrr: )
EBP puoi usarlo se fai a meno di creare uno stack frame.
Vero così hai ben 7 registri :D
Beh ma UEFI non era stato creato apposta per evitare la modalità reale che su Itanium appunto non esisteva? O la versione x86 ha comunque bisogno di questo perché un x86 non può tecnicamente partire in modalità a 32 Bit? UEFI si occupa di partire in modalita' reale e switchare in modalita' protetta, cosi' lo sviluppatore di sistemi operativi si risparmia questa idiozia. :D (e anche tante altre)
cdimauro
10-10-2016, 20:00
Beh però già che c'erano potevano quadruplicarli no?
Quando ha introdotto x86-64 AMD dichiarò che avevano fatto delle simulazioni con l'ISA estesa a 32 registri, ma i benefici ottenuti non erano sufficienti per la complessità che ciò comportava. Considera che x86-64 ebbe, all'epoca, un costo di appena il 5% di transistor: una miseria, rispetto ai benefici che ha apportato.
Concordo con te che avrebbe potuto farlo ugualmente, e IMO non sarebbe stato nemmeno complicato, perché un cambiamento del genere avrebbe richiesto la presenza di un prefisso costante di un byte per ogni istruzione. Quindi molto più semplice rispetto all'attuale implementazione, che ha richiesto la ridefinizione di un blocco di 16 vecchie istruzioni IA-32/x86.
Questo perché, per poter gestire 32 registri in tutti i casi, sarebbero stati necessari altri 4 bit rispetto ai 4 di estensione presenti col nuovo prefisso REX ($40-4F).
Per contro, questo avrebbe allungato SEMPRE di un byte tutte le istruzioni, facendo diminuire nettamente la densità del codice, che già adesso per x86-64 è abbastanza più elevata rispetto a x86 (circa 4.3 byte contro 3.6, se non ricordo male). Con tutte le conseguenze che ciò comporta nella gerarchia di memoria.
Dunque, IMO sarebbe stato più semplice avere un byte in più fisso, perché non sarebbe stato un prefisso ma parte integrante degli opcode, rispetto alla soluzione attuale del REX. Ma a prezzo di una densità più scarsa.
La soluzione migliore sarebbe stata quella che ha seguito ARM con la sua ISA a 64 bit: riscrivere completamente l'ISA con annessa opcode table nuova di zecca. E annesso nuovo decoder.
Ma ARM quanti ANNI ha impiegato per progettare ARMv8/ARM64? Parecchi. Ed è un lusso che AMD non s'è potuta permettere, con Itanium alle calcagna e lei completamente fuori dal mercato (Intel NON le concesse la licenza per Itanium).
Col senno di poi anche con il passaggio 386 --> 486 potevano già raddoppiare i registri...
No, non aveva senso. Un cambiamento del genere avrebbero potuto/dovuto introdurlo già col 386, che apportò enormi modifiche, ma altre modifiche sostanziali già un paio d'anni dopo, decisamente no.
In modalità 32 bit di fatto si è obbligati a passare gli argomenti usando lo stack qualche calling convention più "evoluta" usa almeno un registro per il valore di ritorno... su Linux credo si usi sempre e solo lo stack.
Non ricordo come si comporta, ma mi pare che alcuni registri sono disponibili, incluso EAX per un valore di ritorno a 32 bit. Tutto il resto va sullo stack, ovviamente.
Anche su Cosmos a essere obbiettivi, ma lì è perché - per ora - stiamo seguendo alla lettera le specifiche ECMA e .NET come JVM è una "stack based Virtual Machine" quindi...
Peccato. Io amo le ABI che fanno quanto più uso di registri a disposizione. S.o. Amiga docet.
Beh ma UEFI non era stato creato apposta per evitare la modalità reale che su Itanium appunto non esisteva? O la versione x86 ha comunque bisogno di questo perché un x86 non può tecnicamente partire in modalità a 32 Bit?
Qualunque processore x86/x64 parte sempre in Real Mode, anche se ha un firmware UEFI. E' l'UEFI che si occupa poi di semplificare la vita ai s.o. da caricare, facendoli partire già in modalità protetta, e con un bel po' di roba inizializzata, come ha riportato 71106.
Se vuoi la mia è più una cosa "filosofica" io sono a favore della retrocompatibilità permette di mantenere gli investimenti fatti sul software ecc... ma quando si inizia ad avere 40 anni di retrocompatibilità alle spalle si inizia ad esagerare dai!
E` il momento di mettersi al tavolino e ridisegnare tutto dall'inizio cosa che Intel ha pure fatto con Itanium quindi non è affatto da biasimare sia chiaro... peccato che il mercato voleva solo un x86 che potesse indirizzare > 4 GB di RAM :cry:
Son d'accordo con te. ARM, come dicevo, l'ha fatto. Io pure. :D
OK però il fatto che la CPU debba decodificare le sue stesse istruzioni perché di fatto lei stessa non le "capisce" resta e beh fa un po' storcere il naso :D
Ci sono tanti RISC che convertono le loro istruzioni in micro-op più semplici. ;)
Questo mi rattrista un po' alla fine escono nuove CPU, ma che cosa realmente sta cambiando in questi anni? Aggiungono solo nuove istruzioni vettoriali che probabilmente il 90% dei compilatori manco supporta (GCC di default compila per 486 quindi :Prrr: ).
E tu passa a ICC. :cool:
Anche l'aumento di velocità pura si è fermato sembra impossibile avere CPU a più di 3 GHz e beh 4 CPU (di 2 magari virtuali con hiperthreading) a 1.6 GHz non saranno mai lo stesso che avere una CPU a 6.4 GHz...
Qui la "colpa" è delle leggi della fisica, e non ci possiamo fare niente.
Boh cosa dobbiamo sperare per avere qualcosa di davvero nuovo? CPU non binarie? CPU quantistiche? CPU positroniche?
La mia CPU. :D
Pare che l'importante in tutti i casi sarà avere un emulatore funzionante di x86 :D
Quello serve per forza. ;)
(Che bello un robot "Asimoniano" con emulatore di x86 incorporato mai gli dovesse servire far girare il DOS :Prrr: )
O richiamare le API VESA. :asd:
Vero così hai ben 7 registri :D
:cool:
Quando ha introdotto x86-64 AMD dichiarò che avevano fatto delle simulazioni con l'ISA estesa a 32 registri, ma i benefici ottenuti non erano sufficienti per la complessità che ciò comportava. Considera che x86-64 ebbe, all'epoca, un costo di appena il 5% di transistor: una miseria, rispetto ai benefici che ha apportato.
Concordo con te che avrebbe potuto farlo ugualmente, e IMO non sarebbe stato nemmeno complicato, perché un cambiamento del genere avrebbe richiesto la presenza di un prefisso costante di un byte per ogni istruzione. Quindi molto più semplice rispetto all'attuale implementazione, che ha richiesto la ridefinizione di un blocco di 16 vecchie istruzioni IA-32/x86.
Giusto! Dimenticavo che hanno reso obsolete delle istruzioni per fare spazio ai nuovi registri: che pastrocchio :cry:
Questo perché, per poter gestire 32 registri in tutti i casi, sarebbero stati necessari altri 4 bit rispetto ai 4 di estensione presenti col nuovo prefisso REX ($40-4F).
Per contro, questo avrebbe allungato SEMPRE di un byte tutte le istruzioni, facendo diminuire nettamente la densità del codice, che già adesso per x86-64 è abbastanza più elevata rispetto a x86 (circa 4.3 byte contro 3.6, se non ricordo male). Con tutte le conseguenze che ciò comporta nella gerarchia di memoria.
Dunque, IMO sarebbe stato più semplice avere un byte in più fisso, perché non sarebbe stato un prefisso ma parte integrante degli opcode, rispetto alla soluzione attuale del REX. Ma a prezzo di una densità più scarsa.
La soluzione migliore sarebbe stata quella che ha seguito ARM con la sua ISA a 64 bit: riscrivere completamente l'ISA con annessa opcode table nuova di zecca. E annesso nuovo decoder.
Ma ARM quanti ANNI ha impiegato per progettare ARMv8/ARM64? Parecchi. Ed è un lusso che AMD non s'è potuta permettere, con Itanium alle calcagna e lei completamente fuori dal mercato (Intel NON le concesse la licenza per Itanium).
Io credo che sarebbe stato un piccolo prezzo da pagare una maggiore densità di codice per non dover combattere con la "register pressure".
No, non aveva senso. Un cambiamento del genere avrebbero potuto/dovuto introdurlo già col 386, che apportò enormi modifiche, ma altre modifiche sostanziali già un paio d'anni dopo, decisamente no.
Non ricordo quale dei 2 introdusse i 32 bit era il 386? Comunque avrebbe avuto senso raddoppiare i registri già allora...
Non ricordo come si comporta, ma mi pare che alcuni registri sono disponibili, incluso EAX per un valore di ritorno a 32 bit. Tutto il resto va sullo stack, ovviamente.
In modalità x86 GCC usa la cosiddetta "cdecl" in cui tutto è sullo stack, Microsoft credo con C++ (e forse anche con C#) ne usa anche altre in cui alcuni registri sono usati anche per passare / ritornare argomenti...
https://en.wikipedia.org/wiki/X86_calling_conventions#List_of_x86_calling_conventions
Peccato. Io amo le ABI che fanno quanto più uso di registri a disposizione. S.o. Amiga docet.
Beh avendone pochi (6/7) non è che si possa fare molto coi registri! Se li usi per passare argomenti poi non li puoi usare dentro la funzione a meno che non li copi sullo stack e allora a che serve? Motorola 68000 mi dice wiki aveva 15 registri quindi praticamente il doppio...
Comunque mi hanno detto che hanno idee rivoluzionarie sulla "calling convention" e che da alcuni test preliminari fatti anni fa si otteneva un discreto performance boost vediamo quando inizieremo ad usarle... per ora non hanno voluto dire di più!
Qualunque processore x86/x64 parte sempre in Real Mode, anche se ha un firmware UEFI. E' l'UEFI che si occupa poi di semplificare la vita ai s.o. da caricare, facendoli partire già in modalità protetta, e con un bel po' di roba inizializzata, come ha riportato 71106.
Itanium almeno partiva in modalità 64 bit vero? O mi levate anche sto sogno :cry: ?
Gli ARM ovviamente partono a 32 / 64 bit quale che sia la modalità nativa del processore...
Son d'accordo con te. ARM, come dicevo, l'ha fatto. Io pure. :D
Ecco e qui ti volevo! Raccontaci un po' della tua CPU :D
Ci sono tanti RISC che convertono le loro istruzioni in micro-op più semplici. ;)
Che mondo complicato quello della programmazione vero? Boh forse è per questo che ci piace tanto :D
Inimmaginabile quanti passaggi un povero hello world in C faccia prima che la CPU possa davvero eseguirlo :D
E tu passa a ICC. :cool:
Guarda fosse per me userei CSC (C Sharp Compiler) altro che... beh il codice dovrei prima scriverlo in C# ovviamente se no s'inc*zza :D
Purtroppo il C in azienda è un dogma, alcuni "giovani" ribelli hanno iniziato ad usare un nuovo linguaggio chiamato... C++, ma i "vecchi" storcono il naso pensando a ste "sciocchezze" chiamate oggetti :cry:
La mia CPU. :D
La tua CPU ce l'ha un emulatore x86 funzionante :Prrr: ?
Quello serve per forza. ;)
O richiamare le API VESA. :asd:
:cool:
Isaac Asimov si starà rivoltando nella tomba!
cdimauro
11-10-2016, 18:50
Giusto! Dimenticavo che hanno reso obsolete delle istruzioni per fare spazio ai nuovi registri: che pastrocchio :cry:
No, quelle obsolete le hanno rimosse, ma lasciando lo spazio sostanzialmente vuoto (soltanto alcuni opcode sono stati usati per alcune nuove cose. Ad esempio per i prefissi di AVX e AVX-512).
Per introdurre il prefisso REX hanno dovuto togliere di mezzo gli opcode per le PUSH e POP di registri, che sono istruzioni molto usate (specialmente per x86), perché serviva un blocco contiguo di 16 opcode liberi ($40-4F, per l'appunto).
Comunque queste erano le codifiche "veloci/compatte": PUSH e POP di registri sono rimaste, ma codificate con la versione più generale (ma che occupa un byte in più) che referenzia un operando generico (che può essere memoria o, per l'appunto, registro).
Io credo che sarebbe stato un piccolo prezzo da pagare una maggiore densità di codice per non dover combattere con la "register pressure".
Minor densità. :)
La densità, invece, è molto importante, ed è il motivo per cui tanti RISC hanno dovuto "calare le corna", e fornire ISA "compatte", facendo uso di opcode a lunghezza variabile, e dunque facendole divenire di fatto CISC.
Esempi eloquenti: ARM Thumb/-2, MIPS16, AVR, CRISP-32, e qualcun altro che non mi sovviene adesso.
Non ricordo quale dei 2 introdusse i 32 bit era il 386?
Sì, il 386. Prima, col 286, introdussero la modalità protetta (e 16MB di memoria fisica indirizzabili).
Comunque avrebbe avuto senso raddoppiare i registri già allora...
In effetti non sarebbe stato male, ma il problema è che all'epoca un'estensione come questa sarebbe costata parecchio in termini di transistor.
In modalità x86 GCC usa la cosiddetta "cdecl" in cui tutto è sullo stack, Microsoft credo con C++ (e forse anche con C#) ne usa anche altre in cui alcuni registri sono usati anche per passare / ritornare argomenti...
https://en.wikipedia.org/wiki/X86_calling_conventions#List_of_x86_calling_conventions
Visto. Solo con fastcall vengono usati alcuni registri. Meglio che niente.
Beh avendone pochi (6/7) non è che si possa fare molto coi registri! Se li usi per passare argomenti poi non li puoi usare dentro la funzione a meno che non li copi sullo stack e allora a che serve?
Beh, anche se li copi sullo stack, se li devi usare poi li devi comunque infilare in qualche registro.
Motorola 68000 mi dice wiki aveva 15 registri quindi praticamente il doppio...
Yup. Ma divisi in 8 per i dati, e 7 puntatori (l'ottavo è usato come stack pointer).
Comunque mi hanno detto che hanno idee rivoluzionarie sulla "calling convention" e che da alcuni test preliminari fatti anni fa si otteneva un discreto performance boost vediamo quando inizieremo ad usarle... per ora non hanno voluto dire di più!
Waiting... :sbav:
Itanium almeno partiva in modalità 64 bit vero? O mi levate anche sto sogno :cry: ?
Aveva solo quella. :D
Gli ARM ovviamente partono a 32 / 64 bit quale che sia la modalità nativa del processore...
Credo che quella a 32 bit sia sempre supportata, per cui magari si avviano con questa, e poi passano esplicitamente a quella 64 bit.
Ecco e qui ti volevo! Raccontaci un po' della tua CPU :D
In firma nella sezione progetti trovi una descrizione.
Guarda fosse per me userei CSC (C Sharp Compiler) altro che... beh il codice dovrei prima scriverlo in C# ovviamente se no s'inc*zza :D
Purtroppo il C in azienda è un dogma, alcuni "giovani" ribelli hanno iniziato ad usare un nuovo linguaggio chiamato... C++, ma i "vecchi" storcono il naso pensando a ste "sciocchezze" chiamate oggetti :cry:
Tipico atteggiamento reazionario di chi ha paura dei cambiamenti, per pura ignoranza.
La tua CPU ce l'ha un emulatore x86 funzionante :Prrr: ?
No: si va di emulazione. Ma tanto ogni singola istruzione x86 o x64 viene perfettamente mappata in una istruzione della mia ISA. :cool:
Isaac Asimov si starà rivoltando nella tomba!
:D
Scrivete troppo :D.
@fano: siamo arrivati ad avere registri AVX da 512 bit... vedi un po' :D.
La vettorizzazione è molto ben supportata da GCC, ed è attivata di default se passi -O3 oppure a livello -O2 con -ftree-vectorize (vado a memoria potrebbe essere leggermente diversa la dicitura).
Prova a compilare un piccolo codice che faccia il reverse di un buffer "naive" con e senza vettorizzazione su una CPU sufficientemente moderna (ad es. Haswell) e vedi che codice ti tira fuori, ne rimarrai sorpreso :sofico: .
Ci sono alcuni casi poi in cui il programmatore deve dare una mano a GCC (ad esempio con l'allineamento dei dati).
Come compila di default dipende da chi fornisce il compilatore e quali flag di default ha scelto.
Per altro se usi una versione di gcc a 64 bit al 99% il target è x64, quindi non 486.
Ma comunque anche se compilasse di default per 486, questo lascia il tempo che trova perché la maggior parte di programmi e librerie serie che richiedono un certo livello di performance passano i loro flag custom a GCC.
Non solo, in alcuni casi si fa un benchmark a runtime e scelgono l'implementazione più veloce su quella macchina (questo viene fatto anche dal kernel Linux al boot per scegliere ad esempio quale algoritmo di checksum software RAID usare), perché non è sempre detto che la vettorizzazione ti dia maggiori performance.
Se passi -O3 -march=native vengono attivate la maggior parte delle ottimizzazioni e vengono sfruttate tutte le caratteristiche della CPU come ad esempio SSEx e AVX (se supportate ovviamente).
Se passi -O3 -march=native vengono attivate la maggior parte delle ottimizzazioni e vengono sfruttate tutte le caratteristiche della CPU come ad esempio SSEx e AVX (se supportate ovviamente).
Però è anche vero che la -O3 non è che sia consigliatissima. Anzi, che io sappia (ma forse sono rimasto indietro), per andare sul sicuro si consiglia sempre la -O2, a meno che non si abbiano proprio determinate necessità.
Per il resto concordo, quello che fa GCC di default è ininfluente, visto che poi chiunque usa flag custom.
Due cose riguardo GCC (Clang non l'ho ancora potuto usare seriamente nell'ambito lavorativo):
-O2 / -O3: quando provammo anni fa ad abilitare l'ottimizzazione ottenemmo due belle cosine: in caso di SEGFAULT il core non aveva senso ("value optimized out"... SEGFAULT comodo!), tolse un if (x != NULL) perché non serviva secondo lui e il codice iniziò ad andare allegramente in core :cry: Da quel giorno compiliamo tutto in debug :p
Lo sapete vero che -march=native si riferisce alla macchina su cui stai compilando ? Chi ti garantisce per esempio che abbia AVX512 anche la macchina su cui il codice verrà poi eseguito? Penso se provi ad usare AVX512 su una CPU che non ha l'istruzione l'applicazione va bellamente in core. Quindi? Quindi o ti limiti a un safe subset (su X64 puoi sperare che SSE1 e SSE2 sono sempre supportate) o sei fritto... e AVX512? Forse lo sfrutteremo tra 10 anni quando sarà safe abiltarla di default :D
Avevo fatto un po' di test con l'auto vettorizzazione dovevi fare dei for con valori numerici e null'altro bastava una printf() dentro al for e l'auto vettorizzazione si disabilitava (che è ovvio la printf() non è di certo un'operazione vettoriale!) temo che gli ambiti in cui le istruzioni vettoriali hanno senso sia davvero limitato (codec video? Ma non è meglio far fare quel lavoro alla GPU invece che a SSE? Videogames? Di nuovo meglio far fare i conti float alla GPU...).
Due cose riguardo GCC (Clang non l'ho ancora potuto usare seriamente nell'ambito lavorativo):
-O2 / -O3: quando provammo anni fa ad abilitare l'ottimizzazione ottenemmo due belle cosine: in caso di SEGFAULT il core non aveva senso ("value optimized out"... SEGFAULT comodo!), tolse un if (x != NULL) perché non serviva secondo lui e il codice iniziò ad andare allegramente in core :cry: Da quel giorno compiliamo tutto in debug :p
Lo sapete vero che -march=native si riferisce alla macchina su cui stai compilando ? Chi ti garantisce per esempio che abbia AVX512 anche la macchina su cui il codice verrà poi eseguito? Penso se provi ad usare AVX512 su una CPU che non ha l'istruzione l'applicazione va bellamente in core. Quindi? Quindi o ti limiti a un safe subset (su X64 puoi sperare che SSE1 e SSE2 sono sempre supportate) o sei fritto... e AVX512? Forse lo sfrutteremo tra 10 anni quando sarà safe abiltarla di default :D
E poi vi divertite con GDB. :D
Quindi pure con -O2 si rischiano casini?
Beh dai, per il second punto, però, non si può dare la colpa a GCC, anzi, è un problema generale. AVX512 rimarranno segregate per un bel po', secondo me... :)
cdimauro
18-10-2016, 20:38
Lascia almeno che arrivino prima. :D
E poi vi divertite con GDB. :D
Guarda usare GDB è proprio uno spasso :eek:
Almeno lasciando i simboli di debug qualcosa ci capisci, ma spesso si va più a "intuito" o a botte di printf() per capire dove il CORE è capitato :cry:
Eh ma il C è "efficiente" quindi ce lo teniamo... avevo letto una cosa divertente (credo riguardasse proprio Python vs C @cdimauro) "il tempo del programmatore è più importante di quello della CPU" :D
Quindi pure con -O2 si rischiano casini?
Dalla mia esperienza personale sì: del resto da un linguaggio che "unsafe" by design perché mai non dovrebbe essere così? I problemi sono 2:
Le modifiche che GCC fa per "ottimizzare" il tuo codice possono farlo andare in core (inacettabile che codice corretto vada in core perché il compilatore si permette di togliere controlli)
Il core generato ha dei "buchi" dove GCC ha ottimizzato il codice
Non è più il tuo codice quindi anche volendo cosa ci faresti per risolvere il bug? Togli l'ottimizzazione ecco cosa :D
Beh dai, per il second punto, però, non si può dare la colpa a GCC, anzi, è un problema generale. AVX512 rimarranno segregate per un bel po', secondo me... :)
No certo il discorso era generale anche Clang fa la stessa cosa ed ogni compilatore che fa la compilazione AOT deve decidere prima per quale generazione di CPU generare il codice e di solito è ovvio usare il minimo comun denominatore (per x86 era tipico usare 486 :cry:).
L'unico motivo per risolvere questo è far la compilazione JIT o forse ed è una cosa che in futuro mi piacerebbe esplorare in Cosmos usare il "CPU dispatch"...
Guarda usare GDB è proprio uno spasso :eek:
Almeno lasciando i simboli di debug qualcosa ci capisci, ma spesso si va più a "intuito" o a botte di printf() per capire dove il CORE è capitato :cry:
Eh ma il C è "efficiente" quindi ce lo teniamo... avevo letto una cosa divertente (credo riguardasse proprio Python vs C @cdimauro) "il tempo del programmatore è più importante di quello della CPU" :D
Ah guarda, non ti dico quanto mi stia divertendo a fare il debugging di quel progetto con le Pthread... :D
Dalla mia esperienza personale sì: del resto da un linguaggio che "unsafe" by design perché mai non dovrebbe essere così? I problemi sono 2:
Le modifiche che GCC fa per "ottimizzare" il tuo codice possono farlo andare in core (inacettabile che codice corretto vada in core perché il compilatore si permette di togliere controlli)
Il core generato ha dei "buchi" dove GCC ha ottimizzato il codice
Non è più il tuo codice quindi anche volendo cosa ci faresti per risolvere il bug? Togli l'ottimizzazione ecco cosa :D
No certo il discorso era generale anche Clang fa la stessa cosa ed ogni compilatore che fa la compilazione AOT deve decidere prima per quale generazione di CPU generare il codice e di solito è ovvio usare il minimo comun denominatore (per x86 era tipico usare 486 :cry:).
L'unico motivo per risolvere questo è far la compilazione JIT o forse ed è una cosa che in futuro mi piacerebbe esplorare in Cosmos usare il "CPU dispatch"...
Concordo. Cosa che è un po' OT, sto pensando di usare ICC per quel progetto che ho accennato prima, tanto noi universitari lo possiamo scaricare aggratisse :D
Ah guarda, non ti dico quanto mi stia divertendo a fare il debugging di quel progetto con le Pthread... :D
Te lo avevo detto che i pthread erano pure e semplice satanismo sono "intrisi" di undefined behaviour fino al midollo :D
Concordo. Cosa che è un po' OT, sto pensando di usare ICC per quel progetto che ho accennato prima, tanto noi universitari lo possiamo scaricare aggratisse :D
Credo qualunque cosa sia meglio del GCC noi purtroppo non possiamo cambiare compilatore perché come il kernel Linux abbiamo fatto la cappellata di dipenderà da feature che solo GCC possiede (diaboliche estensioni!):
1. __builtin_va_arg_pack / __builtin_va_arg_len (siamo costretti ad usare il C, ma alla fine nei paradigmi moderni molte cose del mondo ad oggetti sono necessario per esempio una funzione con argomenti opzionali)
2. _Decimal32 i faccio calcoli con valute: non mi serve che sia veloce, ma che sia corretto :D
Clang non supporta nulla di tutto questo (l'1 si può fare lo stesso ed in modo più elegante hanno messo un po' di C++ dentro al C! Il 2 mi attacco...) ICC non lo so sinceramente...
No il codice era semplicemente:
if (var != NULL) {
do_something_with_var();
}
Il SEGFAULT era dentro do_something_with_var() e var secondo GDB era NULL! Il compilatore aveva deciso che l'if era inutile e l'aveva raschiato via :muro:
'var' poteva senza problemi valere NULL non aveva scuse di "assumere" che fosse sempre valorizzato (era a sua volta un parametro di input di quella funzione).
Sarà stato un bug di quella specifica versione di GCC tanto ne esce una al mese e chi mai le testa?
cdimauro
19-10-2016, 18:20
Ma è un bug troppo strano, e soprattutto in un pattern molto comune, per essere sfuggito. Non ci posso credere. :|
Due cose riguardo GCC (Clang non l'ho ancora potuto usare seriamente nell'ambito lavorativo):
[LIST=1]
-O2 / -O3: quando provammo anni fa ad abilitare l'ottimizzazione ottenemmo due belle cosine: in caso di SEGFAULT il core non aveva senso ("value optimized out"... SEGFAULT comodo!), tolse un if (x != NULL) perché non serviva secondo lui e il codice iniziò ad andare allegramente in core :cry: Da quel giorno compiliamo tutto in debug :p
E' chiaro che un certo tipo di ottimizzazioni rendono più ostico il debug, ma questo è normale (es. l'inlining delle funzioni).
Una delle caratteristiche di -O3 se non ricordo male è abilitare un inlining più aggressivo e una profondità maggiore per il loop unroll, oltre ad attivare (questo lo so per certo) la vettorizzazione.
Due caratteristiche che non sempre sono convenienti, banalmente perché aumentano la size del codice e quindi l'impatto sulla cache istruzioni.
E' possibile visualizzare quali flag vengono usati ad un certo livello di ottimizzazione usando il comando:
gcc -Q --help=optimizers
E passandogli il relativo flag, ad esempio:
gcc -Q --help=optimizers -O2
Ti mostra quali ottimizzazioni sono abilitate a livello O2.
Relativamente alla "rimozione" del controllo NULL, come hai verificato questa cosa? Hai visto il codice assembly che è stato generato?
Se è come dici è presumibile che il compilatore abbia determinato che x non potesse mai essere NULL e quindi ha rimosso un check inutile.
Bisognerebbe vedere il codice originale per poter dire quali assunzioni ha fatto GCC.
Detto ciò in fase di debug presumibilmente conviene compilare con -Og (è un O2 ma con meno inlining).
Lo sapete vero che -march=native si riferisce alla macchina su cui stai compilando ? Chi ti garantisce per esempio che abbia AVX512 anche la macchina su cui il codice verrà poi eseguito? Penso se provi ad usare AVX512 su una CPU che non ha l'istruzione l'applicazione va bellamente in core. Quindi? Quindi o ti limiti a un safe subset (su X64 puoi sperare che SSE1 e SSE2 sono sempre supportate) o sei fritto... e AVX512? Forse lo sfrutteremo tra 10 anni quando sarà safe abiltarla di default :D
Certamente!!! Se vuoi distribuire un eseguibile che giri su tutte le piattaforme le strade sono due:
- ti adegui restringendo il compilatore a generare codice meno ottimizzato ma che giri su un ampio numero di macchine
- rendi il tutto dinamico, scegliendo a runtime l'implementazione ottimizzata per la CPU che trovi (vedi kernel Linux e molte librerie matematiche).
Avevo fatto un po' di test con l'auto vettorizzazione dovevi fare dei for con valori numerici e null'altro bastava una printf() dentro al for e l'auto vettorizzazione si disabilitava (che è ovvio la printf() non è di certo un'operazione vettoriale!) temo che gli ambiti in cui le istruzioni vettoriali hanno senso sia davvero limitato (codec video? Ma non è meglio far fare quel lavoro alla GPU invece che a SSE? Videogames? Di nuovo meglio far fare i conti float alla GPU...).
L'ambito in cui la vettorizzazione da il meglio di se è proprio quando devi eseguire una singola istruzione su più dati contemporaneamente (SIMD), ed in generale dunque gli ambiti di calcolo numerico sono quelli in cui i vantaggi sono più evidenti.
In realtà negli ultimi anni anche nel processamento delle stringhe, con le istruzioni di shuffle si riescono a fare cose interessanti.
Se fai una chiamata a funzione ad ogni passo di un ciclo for non c'è niente da vettorizzare, l'esecuzione dev'essere per forza di cose serializzata.
Riguardo le GPU sicuramente sono progettate appositamente per il calcolo vettoriale, ma il problema grande che ancora sussiste è la comunicazione tra CPU e GPU, e il fatto che le GPU mediamente hanno una quantità di memoria molto inferiore rispetto a quanto accessibile alla CPU.
Quindi come sempre la risposta a tutto è: dipende.
cdimauro
19-10-2016, 21:30
appunto, quel codice è orrendo.
do_something_with_var() è una funzione che non riceve var come parametro di ingresso eppure assume che var sia valido, ed il check di validità è effettuato all'esterno della funzione.
nello scope del chiamante molto probabilmente il compilatore ha assunto che var non poteva cambiare. se volevate semplicemente evitare che il compilatore ottimizzasse quel pezzo di codice potevate semplicemente dichiarare var volatile.
bisogna stare attenti ad usare O3 (personalmente ho sempre usato O2 e solo controllando l'assembly prodotto), questo perchè le regole per poter scrivere codice solido anche dopo l'ottimizzazione sono tante e non sono conosciute.
per poter dire che era un bug di gcc si doveva indagare un po' di più, personalmente 1 volta su 50 forse in problemi di questo tipo il bug è nello strumento piuttosto che nell'utilizzatore (ci vorrebbe un disclaimer "use with care")
Rimane un fatto strano, perché se quella variabile viene scritta da qualche parte, il compilatore dovrebbe tenerne conto e non togliere di mezzo quel controllo.
Detto ciò in fase di debug presumibilmente conviene compilare con -Og (è un O2 ma con meno inlining).
No no: -O0 e basta per il debug! :D
L'ambito in cui la vettorizzazione da il meglio di se è proprio quando devi eseguire una singola istruzione su più dati contemporaneamente (SIMD), ed in generale dunque gli ambiti di calcolo numerico sono quelli in cui i vantaggi sono più evidenti.
In realtà negli ultimi anni anche nel processamento delle stringhe, con le istruzioni di shuffle si riescono a fare cose interessanti.
Da un po' di anni sono state introdotte anche apposite istruzioni per alcune operazioni comuni con le stringhe, come il confronto.
appunto, quel codice è orrendo.
do_something_with_var() è una funzione che non riceve var come parametro di ingresso eppure assume che var sia valido, ed il check di validità è effettuato all'esterno della funzione.
nello scope del chiamante molto probabilmente il compilatore ha assunto che var non poteva cambiare. se volevate semplicemente evitare che il compilatore ottimizzasse quel pezzo di codice potevate semplicemente dichiarare var volatile.
Non mi ricordo adesso se era una funzione o se dentro l'if era inserito il codice in linea, ma dai non è difendibile che GCC ottimizzando leva i controlli che un povero programmatore C è costretto a mettere per evitare che tutto vada in core!
bisogna stare attenti ad usare O3 (personalmente ho sempre usato O2 e solo controllando l'assembly prodotto), questo perchè le regole per poter scrivere codice solido anche dopo l'ottimizzazione sono tante e non sono conosciute.
Boh erano i flag di default di come compilavamo in azienda uso il passato perché le ottimizzazione le ho abolite e compiliamo sempre con -g3 invece...
Almeno se va in core (e il C primo o poi ci andrà) c'è una flebile speranza di recuperare qualcosa dal core se no era tutto un "value optimezed out" :muro:
per poter dire che era un bug di gcc si doveva indagare un po' di più, personalmente 1 volta su 50 forse in problemi di questo tipo il bug è nello strumento piuttosto che nell'utilizzatore (ci vorrebbe un disclaimer "use with care")
Per me che l'ottimizzatore faccia corare codice corretto è un bug poi...
Un sistema di ottimizzazione che io povero programmatore devo pure "aiutare" se no crea codice non valido non è che sia proprio il massimo dai!
Poi non so che tipo di programmi fate voi, ma i miei devono stare su H24 / 365 giorni all'anno appena c'è un crash tutti i telefoni iniziano a suonare :D
E' per questo che io inizio ad essere sempre più convinto che il C non sia più una soluzione efficace cosa me ne frega se è veloce se poi si schianta (va in SEGFAULT)?
Ritornando in topic mi è piaciuto come hanno fatto le istruzioni SSE per confrontare i double (CMPSD e CMPSS) che ritorna il valore come un array di bit 1 o 0 nella destinazione se la condizione è true o false... molto semplice da convertire nel tipo bool di .NET: un bel AND e via! Senza dover fare branch o altri casini...
Peccato che manchi l'istruzione equivalente per fare il confronto tra interi la vecchia CMP setta i flag register e lì un branch non te lo toglie nessuno (forse puoi usare l'istruzione TEST per evitarlo?). Avevo provato a cercare nelle istruzione MMX, ma mi sembra che le uniche comparazione erano tra "packed integer" e non scalari... poi MMX usa gli stessi "registri" della FPU quindi mi pare un incubo da usare (infatti mi sa non la usa più nessuno!).
Non mi piace nemmeno che SSE non abbia modo di operare su Int64 (mentre la vecchia FPU sì come è possibile?), né con valori unsigned... questo mi ruppe le uova nel paniere quando cercai di abolire ogni traccia della FPU da Cosmos :cry:
cdimauro
30-10-2016, 20:47
Ritornando in topic mi è piaciuto come hanno fatto le istruzioni SSE per confrontare i double (CMPSD e CMPSS) che ritorna il valore come un array di bit 1 o 0 nella destinazione se la condizione è true o false... molto semplice da convertire nel tipo bool di .NET: un bel AND e via! Senza dover fare branch o altri casini...
Peccato che manchi l'istruzione equivalente per fare il confronto tra interi la vecchia CMP setta i flag register e lì un branch non te lo toglie nessuno (forse puoi usare l'istruzione TEST per evitarlo?). Avevo provato a cercare nelle istruzione MMX, ma mi sembra che le uniche comparazione erano tra "packed integer" e non scalari... poi MMX usa gli stessi "registri" della FPU quindi mi pare un incubo da usare (infatti mi sa non la usa più nessuno!).
Non mi piace nemmeno che SSE non abbia modo di operare su Int64 (mentre la vecchia FPU sì come è possibile?), né con valori unsigned... questo mi ruppe le uova nel paniere quando cercai di abolire ogni traccia della FPU da Cosmos :cry:
Hai dato un'occhiata alle varie PCMP*?
Un sistema di ottimizzazione che io povero programmatore devo pure "aiutare" se no crea codice non valido non è che sia proprio il massimo dai!
Poi non so che tipo di programmi fate voi, ma i miei devono stare su H24 / 365 giorni all'anno appena c'è un crash tutti i telefoni iniziano a suonare :D
E' per questo che io inizio ad essere sempre più convinto che il C non sia più una soluzione efficace cosa me ne frega se è veloce se poi si schianta (va in SEGFAULT)?
Sì però non è che va all'improvviso va tutto in SEGFAULT così, senza un motivo. Quando succede è perché c'è un errore nella gestione delle memoria eh. :D
Hai dato un'occhiata alle varie PCMP*?
Si le ho viste, ma appunto funzionano con "packed integers" e non con "scalar integers" cioè non possono essere usati per fare il semplice:
int a = 42;
int b = 69;
bool res = (a == b); // res = false;
Giusto?
cdimauro
01-11-2016, 20:41
E tu usa solo la parte bassa / primo elemento. :D
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.