Niente x86-64 per Intel

[cdimauro]

Originariamente inviato da magomerlinopaolo
[b]a rigor di Assembly dei registri a 64bit non saranno proprio inutili! se poi si aggiunge che l' hammer avrà come avete detto altri registri, il supporto alle SSE 2, equalche altra diavoleria per velocizzare il tutto, non sarà proprio male!
il problema è che a me piacerebbe che intel IMPONESSE LO STANDARD ITANIUM! xchè così diremmo addio al vetusto x86, è incredibile che le nostre macchine possono far girare del codice x processori 086!
il problema è che INTEL il salto lo vuole far fare soltanto ai server, mentre ci lascia nella cacchetta a noi poveri utenti...stando così le cose, W AMD! che gradualmente ci porterà ai 64bit pieni...
una SCOMMESSA! se INTEL continuerà ad appoggiare l' itanium, si farà prima ad eliminare il reparto 32bit dei futuri hammer per passare completamente al 64bit o si fa prima ad aspettare che l' itanium si diffonda sui sistemi dell' utente medio?
in entrambi i casi penso ci vorranno non meno di 3 anni!

Infatti anch'io credo che l'Hammer non sarà affatto male: anzi!

Quanto al fatto che vorresti che Intel imponesse l'Itanium, beh, è quello che sta cercando di fare, ma spero proprio che non ci riesca.

Primo perché l'architettura EPIC non mi convince affatto (non è quella gran rivoluzione sbandierata ai quattro venti né tanto meno quel campione di performance, anzi!).

Secondo perché l'Intel se l'è riservata per sé, tagliando fuori ogni concorrente, perché i diritti li cederà a nessuno. E tu dovresti sapere bene che senza concorrenti il mercato sarebbe completamente alla sua mercé, come ha già fatto prima dell'arrivo dell'Athlon...

E veramente questo che vuoi?

P.S. Non è necessario "eliminare" il reparto 32 bit dell'Hammer: possono coesistere entrambi là dentro, al contrario dell'Itanium, che fa a botte con l'emulazione x86...

[cdimauro]

Originariamente inviato da ilsensine
[b]
Non è affatto il migliore (anche perchè pare che le prestazioni della fpu siano ancora un pò deludenti), ma mi risulta (forse mi sbaglio) che sia dotato di un numero considerevole di registri general purpose a 128 bit.


Purtroppo non ho avuto occasione di leggere tutte le specifiche tecniche; ho solo dato un'occhiata alla struttura dei registri e ho riscontrato (a parte qualche registro nuovo) che l'ossatura del x86 è mantenuta. Mi riferisco alle "funzioni specifiche" svolte da alcuni registri e non da altri.


Questo non sarebbe un mio problema, visto che fortunatamente uso soltanto linux e qui questi "intoppi" sono inesistenti Per il mercato desktop "generale", sicuramente la soluzione amd può essere allettante, ma a lungo termine non la vedo vincente.

Le prestazioni FPU non sono malaccio, ma niente di eccezionale, come invece Intel aveva lasciato intedere.

I registri GP non sono a 128 bit, ma sono 128 interi + 128 FPU, a cui si aggiungono altri 64 "registri" (ad 1 bit) per il calcolo della predizione dei salti. Il che non è male, anzi! Avere tanti registri è sicuramente una buona cosa, parola di programmatore, ma nella stragrande maggioranza del codice, e all'interno dei cicli in particolare (che sono gli parti veramente critiche di un programma) ne vengono utilizzati pochi... Il discorso comunque è molto complicato, perché l'Hammer (come tanti CISC) sopperisce alla minor quantità di registri con delle modalità d'indirizzamento più complesse, mentre i RISC ne hanno pochissime basiliari e per fare un certo lavoro complesso debbono sprecare dei registri per i calcoli temporanei e utilizzare più istruzioni per fare la stessa cosa.

Ripeto, il discorso è molto complesso e non si può trattare in questo contesto, ma in generale l'equazione più registri = architettura migliore non è sempre vera, anzi. Dipende tutto dall'architettura e da come vengono utilizzati.

Per quanto riguarda il secondo "punto", beh, alcuni registri devono per forza continuare ad avere delle funzioni "speciali": non si può fare a meno dello Stack Pointer... Non vedo una cosa negativa in questo, anzi! O ci sono altre cose che ti turbano?

La soluzione Amd la vedo vincente a lungo termine perché saprà crearsi quella base di utenza che la farà diventare un nuovo, solido standard. Al contrario, il taglio prevalentamente high-end dell'Itanium lo relegherà ad un nicchia che difficilmente potrà imporsi nel mercato consumer...

Vedremo in futuro, comunque...

[cdimauro]

Originariamente inviato da ilsensine
[b]
E' questo il problema: la fpu non viene salvata con lo stato del processore. Questo perchè in passato la fpu era un processore a parte e operava in parallelo ma indipendentemente dal processore principale. Ora la fpu è integrata nel processore, ma sempre per la dannata "compatibilità" viene usata come ai tempi del 286. nb (altra delizia di Intel): gli mmx sono "mappati" sui registri della fpu, non sono dei registri a parte.

Infatti mi ero confuso con il bus degli indirizzi; l'ia64 ha "appena" 128 registri general purpose a 64 bit.

Beh, anche l'FPU dei 680x0 soffriva degli stessi "problemi". Ma, francamente, la cosa non mi fa assolutamente inorridere: è un problema che non tocca il normale programmatore, e che obbliga quello di sistema fa semplicemente ad aggiungere due istruzioni in fase di cambio di contesto. Ripeto: non lo vedo come un problema tanto grave...

Il fatto che i registri MMX siano mappati su quelli FPU è stata una soluzione che non ha comportato cambiamenti ai s.o. e che ne ha reso l'implementazione su silicio molto meno difficoltosa. Considera anche i tempi in cui è stata introdotta questa generazione di istruzioni... A volte non è facile conciliare la perfezione con la realtà dei fatti. Sicuramente ai tempi delle SSE le cose erano diverse ed hanno permesso di scegliere la soluzione migliore, perché economicamente "trattabile" e non tanto complessa...

E' ovvio che riprogettare da zero un processore è molto meglio che estenderne uno esistente, ma di questi tempi è difficile investire tantissimi soldi in nuovo progetto con la spada di Damocle del mercato che ti pende sulla testa. E se poi le cose vanno male, come la mettiamo?

Il mondo, purtroppo, è fatto di compromessi, spesso difficili da digirere per gli idealisti...

[ALEX_440BX]

Non sono una novità CPU a 64 Bit, molte workstations proprietarie (come IBM nell'RS6000 Risc ) usavano processori a 64 bit (già nel 1991). Probabilmente l'IA64 farà la stessa fine di questi, con programmi studiati meticolosamente per queste CPU.

[cdimauro]

Originariamente inviato da ALEX_440BX
[b]Non sono una novità CPU a 64 Bit, molte workstations proprietarie (come IBM nell'RS6000 Risc ) usavano processori a 64 bit (già nel 1991). Probabilmente l'IA64 farà la stessa fine di questi, con programmi studiati meticolosamente per queste CPU.

Infatti, ci sono da una vita, ma è ancora presto per decidere le sorti dell'IA64: lasciamo che l'Intel presenti le nuove versioni, che dovrebbero essere più performanti.

Il mio dubbio sul futuro è che le sue performance sono TROPPO legate alla capacità dei compilatori di generare del codice molto ottimizzato. E questo non è sempre facile, anzi! Se la Intel ha sbagliato con questa architettura, è che ha creduto troppo in questo fattore. Gli ha semplificato sicuramente la vita in fase di progettazione, perché il progetto diventa molto più semplice (gestire delle unità con out-of-order-execution, speculative execution, register renaming, ecc. ecc., si sa, è molto complicato, anche da realizzare e da debuggare), ma l'ha anche castrato perché finora l'Itanium ha ottenuto dei numeri veramente ridicoli paragonati a quelli che si aspettava.

Comunque, loro dicono che ci stanno lavorando e arriveranno presto dei buoni compilatori. Mah. Io dico: quando arriveranno faremo i conti... Ma se sarà troppo tardi, lo sarà anche per l'Itanium nell'entrare nel mercato che conta, quello dei server, perché i concorrenti nel frattempo non stanno certo con le mani in mano (in particolare la Sun, da sempre in guerra con Intel...)

[cdimauro]

Scusate, ho commesso un errore... :P