Allora... Menziono le cose più importanti mano a mano che leggo...
- E' confermato che internamente BD usa ancora macro-op (operazione intera oppure FP + operazione memoria). Ciò è importante per stabilire quanto riesce a macinare...
- E' confermato che esistono ancora operazioni single, double e vector (anche se i nomi sono cambiati: FastPath Single, FastPath Double e Microcode). Ciò è importante per stabilire la potenza del decoder.
- Parla delle istruzioni supportate: AVX, XOP, FMA(C) ecc... Tutto confermato. Più qualche cosa poco nota come istruzioni per l'estrazione della parte frazionaria di un numero FP e istruzioni vettoriali di rotazione, shift, shuffle.
- Menziona le nuove unità FP a 128 bit e dice che le prestazioni possono essere fino al doppio. Non mi è chiaro questo punto. Anche le unità del K10 sono a 128 bit. Ma poi spiega l'uso del FMAC che non è automatico e dice che l'FMA è più preciso di una ADD+MUL (si sapeva già). Forse è a questo che si riferisce quando parla di prestazioni doppie.
- Ora BD non soffre più in prestazioni se le istruzioni sia di load/store, sia load/execute lavorano su dati non allineati. Possibili benefici con codice con dati non allineati. Questo potrebbe essere un refuso del documento del K10. Mi pare di ricordare che era una delle novità del passaggio da K8 a K10...
- Novità del fetching istruzioni. Non più una finestra di 32 bytes, ma DUE finestre di 32 bytes da cui possono essere prodotte fino a 4 mops/ciclo. Si accenna al fatto che queste due finestre assieme alla FPU a 128 bit consentono di avere un ritmo di fetch/execute/retire di 4 mops/ciclo... Ora come ora è molto nebulosa la cosa. Non menziona mai il fatto che è condivisa tra due thread...
- Accenno al fatto che molte istruzioni sono state promosse da vector a double o a single, che sono migliorate le latenze e che molte istruzioni FPU sono state spostate di pipe... ATTENZIONE! Fino ad ora avevamo supposto che l'architettura a FO4 17 avrebbe comportato l'aumento delle latenze delle istruzioni... Secondo quanto scritto qui E' IL CONTRARIO!
Potrebbe anche questo essere un refuso della modifica del documento del K10.
- Miglioramento in velocità delle istruzioni di shuffle, di trasferimento registri FP-interi (nonostante la FP condivisa!), di trasferimento FP-FP (quello a cui accennava JF-AMD degli zero latency move), delle operazioni su stringhe (i vari REP, SCAS ecc), delle operazioni stack e del paging a 1GB.
- Le operazioni di shuffle (tallone di achille) possono essere fatte al quadruplo della velocità grazie a più unità, al fatto che sono a 128 bit (???) e ora le istruzioni sono Direct Path e non vector path (mi sa che è un refuso del vecchio documento perchè parla delle pipeline FADD, FMUL e FSTORE... anche per le operazioni di move reg-reg)
- poi parla delle TLB e della virtualizzazione.
--- FINE SEZIONE INTRODUTTIVA ---
- Confermate le cose che si sapevano sull'architettura (caches ecc). Predizione e fetch sono disaccoppiati, decoding a 4 vie (limite teorico). Scheduling dinamico. 2 istruzioni ALU + 2 AGU per ciclo (confermato). 2 128 BIT FPU. Supporto AVX, XOP ecc. Superforwarding (probabilmente quella cosa del poter usare subito i risultati di una operazione).
- Descrive il fatto delle 4 microop/ciclo. Dice che può fare il fetch di 32 bytes per ciclo e che puo fare la scansione di due blocchi da 16 bytes per ciclo (su due finestre di 32 bytes). Può decodificare fino a 4 mops/ciclo. E' un limite teorico che dipende dalle istruzioni presenti nelle finestre di 16 bytes e anche dalla modalità in cui si trova la CPU: FAST o SLOW (???)
- Schema a blocchi della CPU: nulla da notare se non che non divide le ALU/AGU ma le chiama genericamente pipeline e anche qui la FPU è indicata con solo le due pipeline a 128 bit...
- Caches: L1 istruzioni UNICA da 64 KB, a 2 vie con linea da 64 bytes e lettura di 32 bytes (come quella del K10). Quando è letta una nuova cache line è automaticamente fatto il prefetch di quella successiva. Il predecoing è fatto subito dopo il load. La L1 dati è da 16 KB. Può fare 2 load a 128 bit per ciclo. Ha 16 banchi e un solo load per banco. Quindi i due load sono simultanei se sono in banchi separati. Latenza di 4 cicli (! data l'alta latenza, prevedo clock stratosferici). Menziona genericamente il prefetching. La cache L1 è write through e non write back come il K10... Hanno imparato da INTEL... Ci sono vantaggi nello snooping. Solo la cache L2 va testata... Quest'ultima appunto è inclusiva e condivisa tra i due core. Menziona il write trough e finalmente conferma che le caches sono due. La latenza è 18-20 cicli e la cache è full speed (quindi con il clock alto...
). Il perchè è presto detto: la dimensione è dipendente dall'implementazione! Ci possono essere modelli con più o meno L2 per core (magari parzialmente disattivata per difetti...). La cache L3 può essere massimo 8MB con 4 blocchi di massimo 2MB (anche qui il binning per difettosità...). La cache L3 è non inclusiva e victim buffer. Ci vanno i dati buttiati dalle L2. Un dato rimane nella L3 se è usato da più cores (un predittore?). Altrimenti va nella L1 del core che la usa. La L3 è dichiarata migliorata come banda. Latenza non specificata.
- Branch prediction: penalità da 15 a 20 cicli in caso di miss. In caso di hit, un solo ciclo se è nella cache L1, 4 cicli se è nella L2. La L1 è 4x128 entry e la L2 5x1024 entry. 512 entry per gli indiretti e 24 per il return stack. Il branch prediction è abbastanza complesso ma credo che sia simile a quello del K10...
- Fetch e decode. Sono letti 32 bytes/ciclo. Le finestre sono di 16 bytes e esistono due code (una per thread). Si possono decodificare fino a 4 istruzioni per ciclo contenute in 2 finestre a 16 bytes.
- TLB: L1 istruzioni 48 4KB, 24 2MB o 1GB. Entry da 4MB occupano due entry da 2MB. L1 dati 32 (64 per i modelli 20H-2FH) per 4KB, 2MB e 1GB. Entry da 4MB occupano due entry da 2MB. L2 istruzioni 512 4KB. L2 dati 1024 condiviso tra 4KB, 2MB e 1GB. Entry da 4MB occupano 2 slot.
- Esecuzione intera: c'è lo scheduler e le unità di esecuzione. Lo scheduler è completamente data-driven. Non ci sono più le lane del K10. Ossia è più inteligente: l'unico limite è la disponibilità dei dati e delle unità. Inoltre tiene traccia del completamento e delle eccezioni delle istruzioni FP: è questa unità che decide il da farsi. L'unità FP fa solo il "lavoro sporco"... Lo scheduler intero può ricevere e schedulare fino a 4 mops/ciclo. Fa il register renaming e sveglia le istruzioni in attesa. Le unità di esecuzione sono 4. ATTENZIONE: 2 ALU e 2 AGLU. Le due ALU sono chiamate Ex0 e Ex1. Possono fare tutte le operazioni aritmetiche, logiche e di shift. La Ex0 fa anche DIV e POPCNT. La EX1 fa anche MUL e BRANCH. Le AGLU possono fare le AGU e operazioni ALU SEMPLICI. NOVITA' rispetto al K10: le mops sono divise nello scheduler in microops. Possono essere eseguite indipendentemente e fuori ordine (non più le lanes...
) quando dati e unità esecutiva sono libere, in particolare in contemporanea in ALU e AGLU separate. Lo scheduler può ricevere 4 MOPS/ciclo (quindi potenzialmente 4 istruzioni intere più 4 memoria). Questo è un dispatch group. Il divisore di EX0 non è pipelined ed è a latenza variabile. Il moltiplicatore in EX1 è pipelined. L'AGLU contiene una ALU semplice per fare istruzioni aritmentico logiche semplici... Guardando le tabelle delle latenze sembra che le AGLU siano sfruttate in poche istruzioni, giusto per non usare le EX unit. LZCNT e POPCNT sono gestite in EX0.
- FPU. E' dichiarato che la FPU ha 4 volte la potenza di picco di quella del K10. 4 pipeline. 2 FMAC a 128 bit. Una può fare anche le IMAC (multiply - accumulate su dati interi) e le conversioni tra int e fp e una ha un crossbar per gli shuffle SIMD. 2 unità SIMD intere per MMX e SIMD intere. Una delle due ha la pipeline FSTORE. C'è poi una unità di load/store che può fare 2 letture a 128 bit + una scrittura a 128 bit. La CPU può ricevere fino a 4 mops/ciclo, ma da un solo thread alla volta. Il thread può cambiare a ogni ciclo. La FPU può eseguire 4 mops/ciclo. Una volta ricevute in cicli separati, poi possono essere eseguite anche inframezzate nello stesso ciclo, al ritmo di 4/ciclo. Nella FPU possono essere accettati fino a 2 loads per ciclo, anche da 2 thread separati. 4 pipeline, 2 FP e 2 INT. 2 128 bit FMAC. Ognuno può fare anche ADD e MUL anche x87. Ogni FMAC ha anche un divisore e calcolo radice quadrata a latenza variabile. Una istruzione a 256 bit può essere eseguita in un ciclo. Se non ci sono due unità libere è spezzata in due senza penalità. Cioè in pratica una istruzione a 256 bit è spezzata in due subistruzioni a 128 bit che possono essere eseguite indipendentemente (e anche in due cicli separati) senza bloccare le altre. Massima flessibilità, dunque.
- Unità di load/store. Una per core, due per modulo. Ogni unità supporta 2 letture a 128 bit e una scrittura a 128 bit per ciclo. La coda di scrittura è di 24 entry. La coda di lettura ha 40 entry. Due pipeline per ogni unità LS per fare 2 operazioni in contemporanea. Menziona il fuori ordine per le operazioni memoria ma non entra nei dettagli. Il write combining supporta 4 stream, con 4 buffer da 64 bytes (condivisi tra i due cores). C'è una cache di 4KB prima della L2 (64 blocchi da 64 bytes) per gestire il write combining da sorgenti varie (compreso il write chaining per la trasmissione su bus HT).
- Controller RAM. Supporta DIMM da 4, 8 e 16 bit, interleaving, ECC, e canali a 64 bit indipendenti. Ha algoritmi di scheduling e predizione ottimizzati in particolare per sequenze alternate di read e write. Il prefetcher tiene i dati nel controller e non li spedisce alle caches. Può adattarsi a pattern ascendenti e discendenti e altri più complicati. Le specifiche del MC possono cambiare da modello a modello.
- HT: supporto a 25.6GB/s (quindi 3.2 GHz) e varie features dell'HT 3. HT assist per sistemi a 4 o più socket: ancora con consumo di 1-2 MB di L3.
- Branch fusion. Non è specificato un limite al numero massimo di branch fusion però molto probabilmente al massimo uno. Perchè i limiti sono che il compare e il branch devono essere adiacenti, che il compare non deve essere la quarta istruzione del dispatch group, che il branch deve avere indirizzamento rip-relativo, che il compare non deve avere dati immediati o indirizzamento SIB.
- LATENZE istruzioni. Purtroppo è difficile confrontare le latenze senza avere a fianco quelle del K10. Ci dobbiamo fidare dei proclami dell'inizio del PDF. Molte istruzioni hanno un N/A, non so se per NDA oppure perchè effettivamente al tempo di stesura del PDF non erano note. Però lo scheduler data-driven, le uops che possono andare indipendentemente, le pipeline intere e FP separate possono addirittura far sperare in un IPC superiore al SB!
Questo è quanto...