Estensioni a 64bit nelle cpu 32bit di Intel

perche' tu non hai capito che non si tratta di itanium che esegue codice 32 bit per emulazione ed è lentissim... per itanium il SO gia' c'è allora o intel utilizza l'architettura x86-64 di amd o si attacca a......non è tanto difficile da capire che se intel dovesse adottare l'archiettura x86-64 di amd sarebbe come dire che nvidia integrasse tecnoliga di ati per le proprie schede video...ognuno vuole essere il leader...forse non riesco a spiegare cosa voglio dire..:P

I processori x86-64 già servono (anche se serviranno tra alcuni anni per i più e saranno un passo obbligato anche per Intel, anche se ora sono quasi solo un fattore di marketing.
Non si può pensare di riscrivere tutto il software a 32bit esistente solo per poter sfuttare appieno i 64 con processori dedicati.
Se il prescott avesse già integrato yamhill (non mi sembra così improbabile) spero proprio che sia compatibile con Amd-64, altrimenti sarebbe una gran confusione avere software specifici per ognuno (con grossi pericoli per il secondo).
Ma poi che aspetta M$ a rilasciare sto winxp a 64 bit se la beta è pronta da un sacco? Non ci hanno messo molto a creare un sistema per far girare meglio i 32bit su itanium quando è uscito l'opteron (ma li lavorava x Intel...).

per Nikname

Senza un sistema operativo che sfrutta codice a 64 bit l'itanium non serve a niente(lo stesso Athlon 64 risulta parzialmente inutilizzato); esiste gia linux a 64 bit ma in un sistema desktop (per la maggiorparte degli utenti me compreso) non mi sembra molto semplice da usare.
Secondo me è sempre zio Bill a decidere tutto e intel questo lo sa bene quindi fa benissimo ad aspettare microsoft per immetere un sistema a 64 bit che sia itanium o un "Prescott modificato".
Personalmente preferirei l'Itanium gl'ibridi non mi ispirano per niente.

Aspettiamo il 17, fare previsioni adesso, senza sapere niente di preciso è un po' difficile.

Certo che l'adozione della soluzione x86-64 di AMD da parte di Intel sarebbe un bel danno di immagine, anche se per l'utente medio, a molti noto come "utonto", probabilmente si tratterebbe di una sottigliezza, magari nemmeno lo saprebbe, e per lui la questione si porrebbe sempre nei termini "AMD 64 vs INTEL 64". Quanto al sistema operativo, se anche la Microsoft accettasse di realizzare un terzo SO a 64 bit (ok, togliamo il se...) occorrerebbe del tempo per realizzarlo, ritengo improbabile che la Intel abbia fornito specifiche per questa tecnologia con largo anticipo rispetto alla realizzazione e soprattutto che la MS abbia accettato di lavorare in background, investendo tempo e risorse, in un progetto ipotetico che vuol essere una risposta ai risultati di AMD: non dimentichiamo che alla Intel hanno investito tantissimo su Itanium e che una soluzione diversa nativa significherebbe, se non buttare tutto alle ortiche, versare della benzina sul progetto Itanium e accendere un fiammifero sperando di non doverlo lasciar cadere... Credo personalmente che Yamhill sia una sorta di risorsa estrema per correre ai ripari e per quanto forte possa essere il legame MS-Intel, dubito che lo zio Bill abbia investito su qualcosa di ipotetico. La scelta di scrivere un OS per AMD64, anche se con tutti i comodi, testimonia invece che i k8, opteron in primis, sono una bella realtà già oggi, ricordiamoci che 3 dei 4 principali produttori di server commercializzano soluzioni basate su questo processore, e se Intel adottasse una tecnologia compatibile non farebbe altro che sottolineare la bontà di questo progetto. D'altra parte, potrebbe anche realizzare una soluzione abbastanza simile da rendere alla MS estremamente semplice il compito di riscrivere il SO, ma abbastanza diversa da farne una soluzione proprietaria, anche se questo potrebbe dare adito a conseguenze legali, certo alla Intel, come alla MS, gli avvocati, e i soldi per pagarli, non mancano...

Dubito che Intel introduca (a breve) una versione desktop di Itanium, almeno per ore si suppone "Che Intel possa introdurre nei propri processori a 32bit una tecnologia che permetta di sfruttare anche applicazioni a 64bit in modo nativo" (parole di Corsini); una soluzione ibrida x86 - epic mi sembra molto improbabile, le due architetture, e quindi i relativi set di istruzioni, sono estremamente differenti e una loro integrazione mi pare troppo complicata.

Quanto alla possibilità di usare una sorta di preprocessor senza alterare l'architettura interna, ho parecchi dubbi al riguardo: innanzi tutto, serve comunque un instruction register a 64 bit, come anche un program counter, anche se poi le dimensioni effettive delle istruzioni, come dei dati, varieranno; inoltre, per indirizzare i dati a 64 bit, e memorizzare i dati a 64 bit, servono, per l'appunto, 64 bit, cioè due registri a 32 bit, ne segue, nell'ipotesi di un core invariato:

a) produrranno cpu con lo stesso numero di registri e le applicazioni a 64 bit di fatto disporranno della metà dei registri;

b) raddoppieranno il numero dei registri, la metà dei quali risulterà inutilizzata dalle applicazioni a 32 bit (a meno di ricompilazioni). Tanto vale, imho, raddoppiare la "lunghezza" dei registri e al più aggiungerne qualcuno di uso speciale, come nelle cpu hammer. Questo discorso si estende anche al bus degli indirizzi, che dovrà contenere indirizzi a 64 bit, e al bus dati, quindi probabilmente ai memory controller e ai chipset (se non sbaglio). Ma il problema principale è un altro: attualmente i dati a 64 bit vengono letti ed elaborati in due fasi, 32 bit per volta, quindi non variando l'architettura interna nell'elaborazione delle applicazioni a 64 bit i processori Intel rischierebbero di risultare terribilmente + lenti. Ad es: per sommare 2 numeri a 64 bit con un ALU a 32 bit occorre prima sommare i 4 byte meno significativi, poi sommare gli altri 4, considerando l'eventuale overflow della prima somma come riporto; oppure sommare i due blocchi di 32 bit contemporaneamente in due segmenti diversi dell'ALU, tenendo però sempre conto dell'eventuale riporto della prima somma, quindi introducendo un ritardo nella seconda o effettuandone una terza. In alternativa si potrebbero convertire in floating point a doppia precisione ed eseguire il calcolo con l'fpu, ma non so quanto converrebbe in termini di tempo e inoltre si introdurrebbe un overhead per l'unità in virgola mobile. Pertanto ritengo che Yamhill sia una vera e propria architettura nativa a 64 bit.

Se le ho sparate col botto, prendetelo come uno scherzo di carnevale anticipato, rideteci su
Ciao a tutti

Sugli FP hai ragione, ma sugli interi mi sembra alquanto debole...

Hai mai dato un'occhiata alle istruzioni dedicate per questi scopi che sono già presenti a partire dal 3DNow! sui sistemi x86?

Facciamo 25, per essere più precise.

Da quando in qua l'età è il parametro che denota la bontà di un'architettura? Non dovrebbero essere le prestazioni (reali)?
E poi mi sembra che tu sconosca l'architettura x86-64: fatti un giretto su www.x86-64.org e documentati...

400 milioni di transistori in un desktop non li vedo affatto. Se poi vogliamo ammazzare le prestazioni, ma ridurre il costo, si potrebbe ridurre molto la cache L3. Ma addio alle prestazioni, appunto...

4MB di cache sono comunque tanti per una soluzione desktop: già il P4EE ne integra 2, e presenta prestazioni superiori all'Itanium...

Perché, attualmente cosa gira nei nostri sistemi? O sei in grado di darmi una definizione formale e rigorosa di preemptive "reale" e "non reale"...

Idem. Perché di preemptive "reale" non ne ho mai sentito parlare...

Per il resto, aggiungo che non credo che vedremo soluzioni Intel proprietarie a 64 bit per gli x86: sarebbe un vero suicidio. In primis per Itanium, che a questo punto troverebbe in casa un concorrente micidiale, che rischierebbe di spazzarlo via del tutto.

E infatti in teoria non si dovrà ;già ora per la versione linux a 64 bit su cui i si trova software open source dove possiedi il sorgente puoi ricompilare il codice a 64bit.
Alla MicroSoft (o non so chi lo svilupperà basta creare un buon compilatore a 64 bit e in teoria ricompilando il loro codice sorgente hai una versione dello stesso software ottimizzato per architetture a 64 bit. (di sicuro non è facile come l'ho spiegato ma teoricamente neanche la fine del mondo come la volete far credere voi).

Secondo me non servono a niente adesso (un esempio: è come immetere la PS2 in commercio quando ci sono solo giochi per ps1 chi la compra ha sicuramente soldi da buttare) e in futuro quando inizierà ad uscire codice a 64 un architettura come l'itanium sarà sicuramente piu performande del x86-64.
In conclusione non importa quanto l'hardware sia potente perchè nella maggiorparte dei casi è sempre il software che ne decreta il sucesso . Quindi per ora chi sta con MicroSoft vincè sempre (un esempio palese: Ati ha superarto Nvidia solo perchè è piu performande con le Dx9 nessuno può dire pero che l'hardware Nvida sia inferiore a quello Ati).
l'AMD non puo sperare che la MS faccia un SO per lei ;anzi nel mondo desktop si può dire che è l'Hardware che si deve adeguare al software MS quindi se è vero che intel è piu amica di MS l'x86-64 (secondo la mia modesta opinione) non avrà molta fortuna .

Facciamo un po di chiarezza... Istruzioni a 64 bit vuol dire avere istruzioni che lavorano su dati a 64 bit e questo avviente anche oggi con le istruzioni SIMD come MMX,SSE,SSE2. Processore a 64 bit significa avere dei registri generici a 64 bit estendendo i classici registri dell architettura x86. Avendo registri a 64 bit è possibile inserire ad esempio un float di tipo double in un solo registro, mentre con registri a 32 bit e necessario spezzarlo per poi inserirlo in due registri con ovvio dispendio di cicli di clock. Avere registri a 64 bit rende possibile indirizzare fino a 2 alla 64 byte di memoria invece che 2 all 32 (4 gigabyte). Inoltre AMD con la sua implementazione x86-64 non solo ha esteso i registri ma li ha anche raddoppiati, questo ha permesso di avere più registri generici e di poter utilizzare meno lo stack( più lento). Questa caratteristica se ben sfruttata permette un aumento notevole delle prestazioni e lascia più liberta al programmatore( lo sa bene chi ha programmato anche poco in assembler quanto è comodo avere più registri a disposizione). Inoltre il cuore della tecnologia AMD non è tanto l'estensione e il raddopio dei registri( già visto con il passaggio 16/32 del 386) ma è il funzionamendo ibrido 32-64 che permette di utilizzare appllicazioni a 32 bit su di un sistema operativo a 64 bit. Questa teconologia sarà stata brevettata e non credo che intel possa copiarla spudoratamente senza pagare AMD.

Inoltre sento dire il passaggio a 64 bit non porterebbe ad un aumento delle prestazioni...Questa è una inesattezza, l'aumento dei registri porta automaticamente ad un aumento delle prestazioni se si ottimizza un minimo il codice. Inoltre come ho già scritto con tipi di dati a 64 bit (es float double) si possono avere interessanti aumenti di prestazioni. E' ovvio che se si considera un programma a 32 bit sotto sistema operativo a 64 l'unico beneficio sarà il maggiore indirizzamento della memoria, non si può però per questo dire che i 64 bit siano inutili.

Mi sento di dire che credo che sia positivo che ci sia concorrenza e che AMD si stia affermando con il suo standard a 64 bit. Credo però che sarebbe stato meglio per il mondo dei pc se si fosse arrivati ad una cambio dell ISA x86 a favore di un archittettura nuova... Intel ha gestito molto male il progetto Itanium è credo che questa news stia a significare il vicino abbandono di questo processore. Come ho già detto credo che neanche la potente intel possa sostenere per molto tempo questa situazione( due linee di sviluppo,ricerca ect...) e che debba scegliere una delle due architetture. Penso propio che ripiegherà su x86-64 e tornerà a recitare il ruolo che ha recitato per tanti anni abbandonando il mercato dei super-server,main-frame e dedicandosi solo ai desktop.

Una Domanda

Perdonate la mia ignoranza ma cosa impedisce a intel di modificare l'itanium per far girare anche codice a 32bit cioè creare un processore che nativamente funziona a 64 bit e modificarlo affinchè possa elaborare codice a 32 senza per forza emulare un sistema a 32bit?
Esattamente il contrario di cio che ha fatto AMD con l' x86-64; che se ho capito bene ha preso un processore a 32 bit è l'ha modificato affinche funzionasse anche a 64.
Non essendo un ingeniere elettronico ma neppure un perito sicuramente ho detto una baggianata ma basandomi solo sulla logica a me sembra possibile voi che ne pensate?