somiglia all'HAmmer solo piu' potente :)

[homero]

http://www.lostcircuits.com/cpu/hp_pa8800/

[ev8]

Qualke precisazione...
There are some similarities between the IBM Power4 and the HP PA-8800 RISC processor. Both are running at 1 GHz clock frequency or greater ...
Il power4 ha ben 13stadi di pipeline contro i 5 dell'8700 e può raggiungere delle frequenze molto superiori a quelle del PA-8700.
180 nm SOI copper interconnect, 7 metal layers in the Power4
Da quanto mi risulta il power4 si produce a 130nm
In addition, the IBM Power4 features an off-chip L3 cache of 32 MB.
I 128Mb di L3 sono condivisibili fra tutte le cpu quindi , teoricamente sono 128Mb.
The fastest processor is useless without an adequate system bus. The HP PA-8800 uses a 200 MHz double-pumped (400 MHz data rate) 128 bit data bus interface with source synchronous clocking and a total bandwidth of 6.4 GB/sec.
The data bus is using ECC while the address bus uses parity protection. According to the current industry standards, the bus supports pipelined transactions and out of order completion. The interface is 100 % compatible with the Intel Itanium processor family (IPF) bus. This by itself allows interchangeability with Intel's next generation CPUs to upgrade to higher performance and single chip SMP if necessary.
Il McKinley ha un bus Quad-pumped a 100MHz, non un DDR a 200MHz.
Cmq non ci vedo nessuna somilianza con il K8

[Athlon]

In effetti con l' Hammer con ci vedo nulla in comune.

[ev8]

Forse una cosa la hanno in comune... le prime versioni del K8 model2 avevano i due core in SMP come questi, ma non sono nulla di definitivo

[homero]

io ci vedo invece molte somiglianze:

1 multi core con multilevel cache controller e external bus.

2 128bit bus su 64bit architecture.


hammer funziona cosi' in pratica è un sistema multiprocessing a 32 bit concentrati in un singolo core, che grazie ad un microcode x86 esteso puo' essere visto come un unico sistema a 64bit...
ovvio che i PA-RISC sono 64bit nativi e non hanno bisogno di questo...ma la struttura per avere un surplus di potenza senza cambiare architettura è la stessa...

[alexmaz]

Originariamente inviato da homero
[b]

hammer funziona cosi' in pratica è un sistema multiprocessing a 32 bit concentrati in un singolo core, che grazie ad un microcode x86 esteso puo' essere visto come un unico sistema a 64bit...

ma sei sicuro di questa cosa? a me lascia qualche dubbio...

[homero]

purtroppo non posso esserne sicuro, non lavoro alla AMD

pero' posso dire con sicurezza che amd è specializzata nel progettare microcode x86 su architettura risc visto che lo fanno fin dal lontato 5x86, gli stessi k7 che abbiamo oggi sono microcode x86 su architettura risc infatti non sarebbe possibile ottenere tali prestazioni gestendo il microcode in maniera nativa ossia su architettura cisc.
pertanto non vedo la ragione per non continuare la progettazione strutturando microcode x86 su architettura risc anche per l'hammer, e mappare per mappare tanto vale riutilizzare e ottimizzare i metodi usati per il k7 che già hanno dato ottimi risultati nel rapporto mhz/capacità di calcolo semplicemente raddoppiando le unità risc di calcolo e riprogettando da zero solo il microcode di gestione.
a tal proposito voglio ricordare che intel/HP con ITANIUM riprogettando l'architettura da zero hanno raggiunto risultati infimi e di gran lunga inferiori alle aspettative proprio per tentare una architettura CRISC ossia a metà con in piu' l'emulazione 32bit nel microcode... tutto questo è costato molti anni di sviluppo ben lontani dagli appena 2 anni di sviluppo che amd sta impiegando per l'hammer, quindi a meno che non siano straordinariamente capaci, all'amd cercano di capitalizzare la loro arma vincente ossia rimappare microcode su architetture risc in questo caso x86 esteso su 2 unità risc k7 con un cache controller multilevel

[alexmaz]

il mio dubbio è appunto sulle due unità a 32 bit, sugli schemi AMD non ne fa menzione...

ALT!!!!!!

i processori intel fanno la stessa cosa dal Pentium Pro. Il codice di livello isa, le istruzioni x86, vengono divise dall'unità di decode in micro-operazioni di tipo risc con un opcode , 2 resgistri sorgente e uno destinazione, queste istruzioni sono quelle che vengono poi effettivamente eseguite in pipeline.

Itanium va invece preso da un lato diverso: fa schifo sul codice x86 perchè non è un processore x86!!!! di base è una macchina con istruzioni risc (un opcode 2 registri sorgente e uno destinazione nella maggior parte dei casi) tutte della stessa lunghezza (40 bit). La novità sta in quello che Intel ha chiamato Epic (Explicitly Parallel Instruction Computing): le istruzioni arrivano in fasci di 3, 120 bit + 8 bit di template. Il template contiene informazioni sulle istruzioni eseguibili in parallelo. Il tutto è gestito dal compilatore.
Tutti si confondo perchè è un processore Intel e quindi deve essere x86 e invece, per fortuna secondo me, non lo è.

[Second Reality]

parole sante Alex

[homero]

concordo con la tua esposizione... ad ogni modo 2 unita core a 32 sono nell'hammer + o - come nei pa risc 8800 in cui abbiamo 2 unità 8700, cosi' nell'hammer k8 abbiamo 2 unità k7.

[ev8]

Queste prime versioni di K8 solidstate hanno un solo core, nonostante l'Xbar sia progettata per accettarne due in parallelo.
x homero : dovresti spiegare
1: cosa intendi per "mappare", perchè io intendo quello che fà l'itanium, e non il k7.
2. cosa vuol dire CRISC.

Per quanto concerne il tuo post precedente:
1 multi core con multilevel cache controller e external bus.

2 128bit bus su 64bit architecture.

Allora ci sono altri 100progetti che sono identici a questo.

[homero]

L'architettura dell'Athlon


L' Athlon include 3 decoders per istruzione x86. Questi decoders traducono le istruzioni x86 in macro operations (MacroOPs) a lunghezza fissa per un più alto rendimento nell'esecuzione dell'elaborazione. Invece di eseguire direttamente le istruzioni x86 che hanno lunghezza da 1 a 15 bytes, l'Athlon esegue le MacroOPs RISC-Like migliorando di molto le prestazioni delle altre unità di elaborazione ed ottimizzazione.

Una volta che le MacroOPs sono decodificate, fino a 3 MacroOPs sono inviate all' ICU, per ogni ciclo di clock. L'ICU è un Buffer Reorder per MacroOPs a 72 entry che gestisce lo smistamento delle istruzioni, esegue la rinominazione del registro per gli operandi, e gestisce tutti gli stati d'eccezione e le operazioni di ritiro. L' ICU invia le MacroOPs agli Schedulers delle numerose unità di esecuzione multiple presenti nel K7.

(http://www.lithium.it/articolo0022p8.htm)

Esecuzione fuori ordine (Out of order): Nel Pentium, come abbiamo visto, era possibile l’esecuzione contemporanea di due istruzioni utilizzando due pipeline separate; l'esecuzione era legata alla sequenza definita dal programma, perciò ogni volta che un'operazione non poteva essere eseguita subito a causa di un stallo, entrambe le pipeline restavano ferme. Nel Pentium Pro invece le operazioni x86 vengono convertite in istruzioni micro-ops (micro-operazioni) con una tecnica che ricorda i processori Risc. Attraverso questo passaggio si eliminano molte delle limitazioni tipiche del set di istruzioni x86, cioè la codifica irregolare delle istruzioni e le operazioni sugli interi che richiedono il passaggio di dati dai registri interni alla memoria. Le micro-ops vengono quindi passate a un motore di esecuzione capace di eseguirle fuori ordine, modificandone la sequenza così da mandare in esecuzione quelle pronte e lasciare in attesa quelle che non sono. Con ciò se una Pipeline nel Pentium Pro va in stallo le altre due possono continuare ad operare senza essere svuotate. La sequenza delle istruzioni viene infine riordinata da una apposita sezione hardware detta Reorder Buffer alla fine della elaborazione.

Superscalarità spinta: sono state portati a tre i canali di elaborazione parallela delle istruzioni contro i due del Pentium. Possiamo dire, con buona approssimazione, che il Pentium Pro implementa al suo interno tre 486 OPERANTI IN PARALLELO.

Se il Pentium o l'Athlon (o quello che è) sono ancorati alla decodifica di un set di istruzioni arcaico e complicato come quello x86, dovrebbero essere considerati processori CISC, quindi poco performanti...eppure, sappiamo bene che l'Athlon ha una struttura a pipeline composta da ben 10 stadi, è superscalare ed ha un sacco di "chicche" in più! Così anche il P4 che di stadi nè ha addirittura 20. Quindi dovrebbero essere RISC, secondo la tabella di cui sopra! Insomma ,CISC o RISC? La risposta è: entrambi!

http://www.lithium.it/articolo0017p6.htm


i dati sopra sono presi da lithium,

in sostanza i pentium fino la P3 conservano ancora l'ALU del vecchio 486 anche se con il precache e il branch prediction, al contrario AMD non puo' fare questo per la semplice ragione che ha solo la licenza sul microcode e non sull'intera architettura x86, pertanto deve letteralmente convertire le istruzione x86 i vari move, jmp, and etc etc in istruzioni native risc, questo io intendo per mappare, ossia a ciascun pull di istruzioni cisc x86 fa corrispondere una mappatura sulle sue unita logiche risc.

ho scritto che l'itanium è un Crisc per la semplice ragione che deriva da un processore RISC il PA-RISC HP come architettura, su cui hanno inserito un microcode x86 ossia un microcode ad istruzioni complesse, in questo caso l'architettura risc non è ottimizzata per x86 visto che già di suo ha un esteso microcode, pertanto c'è la traduzione della traduzione ossia microcode x86 -> microde I64 -> architettura risc, questa è la ragione per cui le prestazioni sono cosi' lente quest'ultimo fatto è una congettura di cui non ho trovato chiara conferma anche se molti indizzi fanno sospettare che sia cosi' primo tra tutti la non compatibilità dell'itanium con il microcode PA-RISC da cui deriva.

ps: chiedo scusa per lo sproluquio tantè....

[homero]

si ci sono numerosi progetti identici a questo nelle unità di calcolo ftp per processori grafici inseriscono in un core fino a 6 unità elaborative come nelle wildcat, o isistemi visualize hp...pero' nei processori penso che ci sia solo HP e AMD a produrre qualcosa del genere..

[alexmaz]

C'è scritto anhe li che i processori Intel dividono le istruzioni x86 in micro-operazioni fin dal Ppro... è la stessa identica cosa...

Itanium la parte x86 manco dovrebbe averla, è stata messa per compatibilità, ma il suo codice nativo quella parte non la guarda nemmeno... il microcodice dei processori risc esegue direttamente l'isa nella maggior parte dei casi, perchè è adatto all'esecuzione in pipeline...

[ev8]

Originariamente inviato da homero
[b]...
in sostanza i pentium fino la P3 conservano ancora l'ALU del vecchio 486 anche se con il precache e il branch prediction, al contrario AMD non puo' fare questo per la semplice ragione che ha solo la licenza sul microcode e non sull'intera architettura x86, pertanto deve letteralmente convertire le istruzione x86 i vari move, jmp, and etc etc in istruzioni native risc, questo io intendo per mappare, ossia a ciascun pull di istruzioni cisc x86 fa corrispondere una mappatura sulle sue unita logiche risc.

1.Dal P6 in poi, l'esecuzione è DEC-OOO, esattamente come avviene sugli attuali AMD.
2.Da come lo scrivi tu non si nota, ma c'è molta differenza fra "mappare" delle istruzioni e fare "decode+rename+shed ecc... su una macchina OOO" come avviene sul K7.
[b]

ho scritto che l'itanium è un Crisc per la semplice ragione che deriva da un processore RISC il PA-RISC HP come architettura

EPIC non deriva da nulla, a mio modo di vedere, è frutto della collaborazione fra ingegneri HP ed Intel ed è un'architettura completamente nuova.[b]

, su cui hanno inserito un microcode

decoder[b]

x86 ossia un microcode ad istruzioni complesse, in questo caso l'architettura risc

Non è opinione diffusa, cmq non considero RISC architetture basate su FMAC.[b]

non è ottimizzata per x86 visto che già di suo ha un esteso microcode, pertanto c'è la traduzione della traduzione ossia microcode x86 -> microde I64 -> architettura risc, questa è la ragione per cui le prestazioni sono cosi' lente quest'ultimo fatto è una congettura di cui non ho trovato chiara conferma anche se molti indizzi fanno sospettare che sia cosi' primo tra tutti la non compatibilità dell'itanium con il microcode PA-RISC da cui deriva.

Questa parte non è molto chiara, cmq le prestazioni x86 sono scarse perchè si cerca(inutilmente) di mappare ISA CISC IOE su altre ISA CISC IOE diverse.
Le congetture si usano in aule di tribunale ... L'itanium è solidstate da 2anni, ne sono stati venduti un paio di migliaia... le sue scarse prestazioni sono conclamate.[b]

ps: chiedo scusa per lo sproluquio tantè....

[b]

si ci sono numerosi progetti identici a questo nelle unità di calcolo ftp per processori grafici inseriscono in un core fino a 6 unità elaborative come nelle wildcat, o isistemi visualize hp...pero' nei processori penso che ci sia solo HP e AMD a produrre qualcosa del genere..

Io parlavo di CPU non di processori in genere.
La tua ultima frase mi fà pensare che tu non abbia letto l'articolo in oggetto del 3d.

[ev8]

Cmq. per chi avesse dei dubbi riguardo al model1 (quello solidstate) può fare riferimento qui :
http://www.amd.com/us-en/Processors/...5_4622,00.html

Ciauzzz!

[mind12]

uffa voglio sapere anche io l'inglese così bene

[homero]

http://www.extremetech.com/article/0...mp;ap=6,00.asp


articolo su hammer che taglia la testa al toro, spiega cisc su risc meglio di quanto io potessi fare...


inoltre devo rettificare in parte quello che ho detto, qualche volta le inessattezze mi scappano (qualche volta solo?)

3 alu k7 invece che 2

30 % in piu' rispetto al k7 unità distribuite e niente multi processing, ho detto una grossa inessattezza e rettificate tutto...

invece è esatta tutta la questione sul microcode...

[ev8]

Originariamente inviato da homero
[b]http://www.extremetech.com/article/0...mp;ap=6,00.asp


articolo su hammer che taglia la testa al toro, spiega cisc su risc meglio di quanto io potessi fare...


inoltre devo rettificare in parte quello che ho detto, qualche volta le inessattezze mi scappano (qualche volta solo?)

3 alu k7 invece che 2

30 % in piu' rispetto al k7 unità distribuite e niente multi processing, ho detto una grossa inessattezza e rettificate tutto...

invece è esatta tutta la questione sul microcode...

Rigardo all'articolo da te indicato:

The first Hammer processor, Clawhammer, may only support two processors using a single HyperTransport link
using two HT link

Clawhammer will likely have dual 64K L1 caches and a 256K L2 cache
512k L2

It's the nonparallel nature of x86 code that's impossible to overcome.
esistono 3DNow ed SSE2

Poor Hammer has to pry what secrets it can from an inherently serial binary stream, searching for tiny fragments of instruction-level parallelism in hardware
come sopra

Hammer, on the other hand, is the result of a decade of stretching, tweaking, and cajoling a Paleolithic architecture into modern form
frasetta altisonante, poverissima di significato, generalmente utilizzata dai giornalisti che non possono conoscere l'architettura interna di tutte le cpu di cui parlano.
La frase seguente lo conferma It's difficult to believe there would be as much life left in Father Time as in the New Year's baby. ....

Besides, whether they appear in future Pentium derivatives or not, Intel's 64-bit extensions could appear in future IA-64 processors instead. New IA-64 features plus competitive x86 performance--now that's a compelling product.
spero per l'intel che queste frasi siano una totale invenzione dell'articolista.

Both processors are totally, completely, and inarguably backward compatible with x86 binaries. Anything else would be a criminal dereliction of duty. If what you want is a faster x86 PC, it's entirely likely that Hammer-based systems will run old (or upcoming) PC applications much faster than an Itanium- or McKinley-based system.
non sò se qualcuno di voi abbia provato, ma un buon emulatore x86 su un G4 è MOLTO più veloce di un Itanium che esegue x86 nativamente.

Porting major applications and operating systems to Hammer will not be trivial--but neither is supporting IA-64
L'articolista non programma in EPIC

[cionci]

Il problema dell'EPIC sono soltanto i compilatori.... La strada per l'ottimizzazione totale secondo me durerà qualche altro anno...