Windows XP Beta per AMD 64

pirolisi... non c'è bisogno di arrivare fino ai betatester microsoft per aneddoti divertenti e soprattutto, neuroni bruciati.

I fp a 64 bit (doppia precisione) esistevano già ai tempi degli 8086, tramite il coprocessore 8087...

e

L'importante ora è ottimizzare i drivers...

E' sceso e'sceso.
http://web.essedi.it/
5 giorni e' gia' e' sceso ,

scusate gli errori ma l'emozione fa' brutti scherzi
VERY

la nuova era...
Cmq non è un po vecchiotta come notizia??

X tutti gli sciettici.
La 32 bit è una tecnologia ormai arrivata ai limiti fisici.Indirizzare + memoria apre un orizzonte nuovo.
Ma quando è uscito il pentium e abbiamo abbandonato i 16 bit eravate così.
Adesso nonn avremmo subito benefici ma aspettate un pò.
Poi pensate che tutta l'evoluzine dell informatica è stata programmata a grandi lineee fino al 2030.

Il problema non è solo la memoria indirizzabile ma anche gli indirizzi virtuali disponibili. Ad esempio su processori a 32 bit, già per gestire 2GB di RAM i sistemi operativi devono fare contorsioni mentali. Oltre i 4GB diventano vere e proprie alchimie, con impatto negativo sulla velocità del sistema.

quanta perplessita' su questi 64bit! Non sarebbe meglio aspettare e dare un'occhiata cosa si potrà fare sul piano pratico? Potrebbe anche essere l'architettura migliore del mondo, ma senza un adeguato supporto software (leggi: compilatori ottimizzati e altri strumenti di sviluppo che dovrebbe fornire AMD, se vuole che i suoi prodotti vengano utilizzati) non servirà ad un beneamato nulla.

Sicuramente Intel supporterà adeguatamente le sue SSE3 come è solita fare, speriamo che AMD si dia una mossa.

In ogni caso otto registri general-purpose in più fanno una bella differenza: se vi ricordate (... ne è passato del tempo ora che mi ci fate pensare... ) dello sviluppo di Linux e del GCC, saprete che un tempo il formato degli eseguibili era il cosiddetto a.out, mentre ora è ELF.

Al momento del passaggio, si notò subito che sui processori x86 il passaggio all'ELF in sè aveva comportato un rallentamento generale dei programmi che si attestava mediamente fra il 5 e l'8%: questo perchè il frame pointer 'occupava' generalmente un registro che altrimenti si sarebbe potuto impiegare diversamente.

Tant'e' che ancora adesso quando compilate qualcosa sotto Linux che non sia necessario debuggare, l'opzione -fomit-frame-pointer è caldamente consigliata in quanto aumenta la velocità senza nessun incoveniente.

Otto registri in piu' serviranno eccome, vedrete... compilatori come GCC che girano già su un sacco di architetture diverse non dovrebbero avere problemi ad essere modificati per sfruttarli

AGGIUNTA: mi accorgo ora che esiste già il GCC per x86-64, anche se non so come sia messo a livello di performance.

infatti non basta solo il sistema operativo bisogna che tutti i programmi siano convertiti per i 64 bit