Newsgroup: it.comp.hardware.cpu
Titolo: sempre su noncona/eax...

http://www.siliconinvestor.com/stocktalk/msg.gsp?msgid=20289129
no comment.
-- 
    (iao!!oai)                                    (ICQ: 10860566)
    //.aurizio
[WARNING!: togliete _nessuno_ per rispondere]
    Il segreto per essere considerato un creativo sta nel non fare
    mai riconoscere le proprie fonti [A. Einstein]


premessa: stasera ho mangiato pesante, quanto segue probabilmente
dipende da quello.
ora, qui sul ng abbiamo parlato spesso sul comportamento "strano"
delle alu dei p4, ovvero le due alu lavorano a frequenza doppia
rispetto al resto del processore ma funzionano soltanto un ciclo si e
l'altro no, in modo alternato.
fino ad adesso abbiamo sempre stipulato che questa sia una soluzione
di compromesso, le alu a frequenza doppia erano state introdotte
sperando che il sistema di trace-cache e l'evolutissima sezione di
branch-prediction potessero fornire dati sufficienti per rimanere a
regime - quando questo non si e' rivelato vero sono state mantenute
come soluzione per distribuire meglio il calore sul die.
in effetti, a pensarci bene, non e' che regga gran che come
ragionamento - appena la prima maschera di test del proto-p4 ha
mostrato che le due alu eseguite a pieni cicli sarebbero andate
costantemente in stallo sarebbe semplicemente bastato riportarle a
clock semplice, riducendo drasticamente il calore prodotto ed i costi
produttivi.
strano.
ora, stasera stavo spulciando come al solito le varie fonti di
documentazione storiche sui processori (ognuno ha i suoi hobby - o le
sue croci come dicono altri...) e mi sono imbattuto in un dato che
fino ad adesso mi era sfuggito: il progetto p4 in origine doveva
essere a 64bit (o meglio 32/64bit, stile 8088) ma la decisione del
management Intel di riservare tutti gli sforzi verso l'high-end su
ia-64 fecero ridimensionare il progetto e sviluppare una versione
ridotta a 32bit, ovvero il p4 come lo conosciamo adesso.
ora, cosa interessante: l'attuale incarnazione di p4 con em64t (o come
lo chiamano adesso in intel) eseguono il codice a 64bit "spezzandolo"
sulle due alu, facendole lavorare in parallelo (e quindi a pieni
cicli).
al che mi e' venuto il dubbio: non e' che l'intera manfrina delle alu
"sdoppiate" salta fuori proprio da questa modalita' operativa -
ovvero: che i p4 sono rimasti dei processori 32/64bit come dal
progetto originale ma con la parte a 64bit disattivata e per quello
una alu e' sempre spenta quando l'altra e' attiva (visto che la
seconda parte della parola a 64bit non esiste...), in altre parole in
Intel si sono limitati a completare il progetto originale,
"spolverarci" sopra un po' di kludge tanto per renderlo limitatamente
compatibile x86-64 e tanti saluti (in effetti l'atteggiamento di Intel
e' sempre stato "se vogliamo i 64bit li tiriamo fuori in cinque minuti
e ci resta pure il tempo per la pausa caffe'....).
mah, imho dovrei mangiare piu' leggero...


 mah, imho dovrei mangiare piu' leggero...
io piu' pesante, forse farei piu' viaggi come te, facendo fisica puo'
tornare utile... ;-)
-- 
Ciao
Tomalak
"Victory is life"

possibilita' di eseguire il codice a 64 bit dai tempi del Willamette?
non senza completare lo sviluppo della parte a 64bit, ma le parti
escutive  imho erano gia' presenti per quanto non funzionali.
che nei p4 ci fossero un sacco di transistors non usati lo si sapeva
da un pezzo, non e' che cambi niente, ma dietro questa nuova ottica
l'intero schema del processore diventa molto piu' interessante, si
spiegano molte cose che nei p4 parevano proprio non avere senso (come,
per l'appunto, quelle due alu ultrapompate e poi depotenziate...).


 -- 
Sto P4 sta diventando sempre più un "oggetto misterioso" in effetti...;-)
Tra l'altro non mi risultava nemmeno che le due ALU ormai
andassero a regime ridotto, risparmiando nel contempo un pò di calore. Altro
che Rapid Execution Engine quindi...
Saluti

[CUT]
Significa che con il passaggio a 64 bit dissiperà 200W :)
Boh il mio mac mi regala soddisfazioni che ne il mio Barton a casa ne il 
il mio p4 in ufficio riescono ad immaginare... ed è un G3.

 e ci resta pure il tempo per la pausa caffe'....).
Forse la spiegazione e' un altra, ma prima serve una delle mie
"piccole" premesse. ;-)
[inizio premessa]
Paradossalmente, la capacita di elaborare dati a 64bit e' presente
da parecchi anni sulle cpu x86, e di generazione in generazione
tale capacita' e' stata migliorata non appena se ne presentava
l'occasione.
La capacita di elaborare *dati* a 64bit e' sempre stata presente
in forma limitata gia a partire dagli 8086 con coprocessore 8087
(usando la mantissa dei floating point a precisione estesa).
Poi a partire dai Pentium MMX (estensioni MMX con registri
MMX0..7) era possibile usare un registro MMX come un unico intero
a 64bit.
Infine con le estensioni SSE2 sono stati aggiunti vari "formati interi"
ai registri XMM0..7 (da non confondere con quelli MMX0..7) che
in precedenza con le SSE "semplici" potevano essere usati solo
con formato floating point.
Tra i vari formati ve ne e' uno che permette di manipolare
un registro XMM come una *coppia di interi* a 64bit.
In altre parole le "ottimizzazioni" alle ALU sono state fatte
indipendentemente dal fatto che si volesse arrivare ai 64bit "pieni".
Inoltre nei Prescott le ALU sono tornate "a frequenza normale", quindi
hanno cambiato idea rispetto a quanto pianificavano mentre
progettavano i core Willamette e Northwood.
[fine premessa]
Detto questo, per rendere "full 64bit" i P4 le uniche modifiche
assolutamente necessarie riguardano l'estensione a 64bit dei
registri interi "classici" e l'estensione a 64bit degli indirizzi
(le prestazioni a 64bit non saranno stratosferiche ma con il vantaggio
  in termini di clock che hanno i Nocona sugli Opteron, la cosa
  dovrebbe bastare per ora).
Sui Nocona l'estensione a 64bit pieni ad occhio e croce e' stata
fatta proprio limitandosi all'assolutamente necessario, visto che
l'interfaccia "esterna" e' rimasta quella dei P4 a 32bit
(incluso la capacita di generare indirizzi fisici max. di 36bit
  sfruttando l'hardware gia presente per il supporto delle PAE)
potevano fare di piu ma considerato da cosa sono partiti
e che tempi avevano a disposizione il risultato non e' poi
cosi "scarso".
In fin dei conti, nonostante le modifiche ridotte all'osso
e' verosimile ipotizzare che con le stesse ALU "ottimizzate per i 32bit"
(ma capacissime di elaborare valori a 64bit)
e senza l'attivazione di altra roba "nascosta" nel chip, si ottiene che
allo stesso "costo" di una operazione SSE2 su "coppia di interi a 64bit"
*in media* si esegue una
"istruzione su dato a 64bit accoppiata ad un calcolo di indirizzo a 64bit".
L. Micheletto



Cos'è, il tuo Mac è bravo a letto ? :-)
Ciao Mariop

 Ciao Mariop