ISA intel core i7

[pabloski]

Originariamente inviato da 71106

Quindi stai dicendo che mentre il mondo aveva bisogno di un'architettura a 64 bit e AMD ne sviluppava una, Intel... faceva altro.

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]

Originariamente inviato da 71106

Quindi stai dicendo che mentre il mondo aveva bisogno di un'architettura a 64 bit e AMD ne sviluppava una, Intel... faceva altro.

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.

[71106]

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?

[pabloski]

Originariamente inviato da 71106

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?

Molto cruda, ma e' cosi'.

[tomminno]

Originariamente inviato da 71106

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?

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.

[fano]

Originariamente inviato da tomminno

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

[tomminno]

Originariamente inviato da fano

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

Se avessimo avuto degli Itanium, adesso avremmo tutti ARM
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++? ). 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.

[71106]

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, 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]

Originariamente inviato da domenico88

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]

Originariamente inviato da fano

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?

Originariamente inviato da 71106

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.

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.

Sì, esatto, ma il legacy dovuto a 8086 è praticamente ininfluente, a parte per i programmatori di boot loader, per l'appunto.

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.

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.

Originariamente inviato da domenico88

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

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..

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]

Originariamente inviato da fano

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"

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

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!

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

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]

Originariamente inviato da 71106

Peggio per loro (i produttori di CPU), sono costretti ad aggiungere transistor inutili.

Su chip da miliardi di transistor?

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.

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".

Originariamente inviato da tomminno

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.

[cdimauro]

Originariamente inviato da fano

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
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.

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.

Originariamente inviato da tomminno

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.

Originariamente inviato da pabloski

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...

Originariamente inviato da tomminno

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.

[fano]

Originariamente inviato da cdimauro

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...

Originariamente inviato da cdimauro

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?

Originariamente inviato da cdimauro

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

Originariamente inviato da cdimauro

Ehm... no!

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

Originariamente inviato da cdimauro

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 ).

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

(Che bello un robot "Asimoniano" con emulatore di x86 incorporato mai gli dovesse servire far girare il DOS )

Originariamente inviato da cdimauro

EBP puoi usarlo se fai a meno di creare uno stack frame.

Vero così hai ben 7 registri

[71106]

Originariamente inviato da fano

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. (e anche tante altre)

[cdimauro]

Originariamente inviato da fano

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

Son d'accordo con te. ARM, come dicevo, l'ha fatto. Io pure.

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

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 ).

E tu passa a ICC.

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.

Pare che l'importante in tutti i casi sarà avere un emulatore funzionante di x86

Quello serve per forza.

(Che bello un robot "Asimoniano" con emulatore di x86 incorporato mai gli dovesse servire far girare il DOS )

O richiamare le API VESA.

Vero così hai ben 7 registri

[fano]

Originariamente inviato da cdimauro

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

Originariamente inviato da cdimauro

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".

Originariamente inviato da cdimauro

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...

Originariamente inviato da cdimauro

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_ca...ng_conventions

Originariamente inviato da cdimauro

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ù!

Originariamente inviato da cdimauro

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 ?
Gli ARM ovviamente partono a 32 / 64 bit quale che sia la modalità nativa del processore...

Originariamente inviato da cdimauro

Son d'accordo con te. ARM, come dicevo, l'ha fatto. Io pure.

Ecco e qui ti volevo! Raccontaci un po' della tua CPU

Originariamente inviato da cdimauro

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

Inimmaginabile quanti passaggi un povero hello world in C faccia prima che la CPU possa davvero eseguirlo

Originariamente inviato da cdimauro

E tu passa a ICC.

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
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

Originariamente inviato da cdimauro

La mia CPU.

La tua CPU ce l'ha un emulatore x86 funzionante ?

Originariamente inviato da cdimauro

Quello serve per forza.

O richiamare le API VESA.

Isaac Asimov si starà rivoltando nella tomba!

[cdimauro]

Originariamente inviato da fano

Giusto! Dimenticavo che hanno reso obsolete delle istruzioni per fare spazio ai nuovi registri: che pastrocchio

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_ca...ng_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...

Itanium almeno partiva in modalità 64 bit vero? O mi levate anche sto sogno ?

Aveva solo quella.

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

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
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

Tipico atteggiamento reazionario di chi ha paura dei cambiamenti, per pura ignoranza.

La tua CPU ce l'ha un emulatore x86 funzionante ?

No: si va di emulazione. Ma tanto ogni singola istruzione x86 o x64 viene perfettamente mappata in una istruzione della mia ISA.

Isaac Asimov si starà rivoltando nella tomba!

[WarDuck]

Scrivete troppo .

@fano: siamo arrivati ad avere registri AVX da 512 bit... vedi un po' .

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 .

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).

[GTKM]

Originariamente inviato da WarDuck

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.