AMD levert eerste Bulldozer-server-cpu's

waarom zou het dat niet zijn? de i-cache is 2-way met 1 way voor elke core. decode hebben sommige CPU's niet eens dus het daar vanaf laten hangen is onzin.

dan blijft fetch over. maar die is er enkel om het L1 te vullen. belangrijk, maar nou niet echt de essentie van een core.

Ik zou wat voorzichter zijn met dingen onzin noemen, zeker als je daarna zelf dingen claimt die niet kloppen. Misschien tijd om even je computer architectuur kennis op te frissen

1) Een n-way cache heeft niets te maken met de hoeveelheid clients die aan een cache hangen, maar heeft te maken met de interne structuur van de cache en hoe de adressen van geheugen afgebeeld worden op de cachelines in de cache. Dit wordt ook wel set-associative cache genoemd. Een n-way cache houdt in dat een enkel geheugenadres in een van n cachelines binnen een set geladen kan worden wat meer flexibiliteit biedt dan een direct mapped cache waarin elk adres maar in een specifieke cacheline terecht kan komen. Het andere uiterste is een fully associative cache waarbij elk adres in elke cacheline van de cache geladen kan worden maar dit is zeer duur om te implementeren in hardware.

2) CPU's die geen decode stage hebben komen sinds begin jaren '60 nog maar erg weinig voor sinds het idee van pipelining geintroduceerd werd in de IBM STRETCH. Een van de meest simpele vormen is de RISC stijl pipeline en die bestaat uit de vijf Fetch, Decode, Execute, Memory access en Writeback stages. De decode logic heeft meerdere functies, ten eerste worden de juiste pipeline latches gezet zodat de instructie in het juiste formaat bij de juiste executie unit uitkomt, en in het geval van een CISC core zoals de x86 zal ook daar een instructie vertaald worden van een CISC instructie naar meerdere micro-ops.

3) De fetch stage heeft niet de functie om de L1 te vullen, waarschijnlijk ben je in de war met een prefetcher. De fetch stage haalt de instructie data op uit de L1 I-cache en voert dit aan de rest van de pipeline. Hier zal je de program counters en branch predictors vinden waarmee bepaald wordt welke instructies er opgehaald moeten worden.

Nog even ter verduidelijking een figuurtje uit de AMD paper met de Bulldozer module pipeline(s):
http://staff.science.uva.nl/~mwvantol/bulldozer.png

hier haal je dus 2 dingen door elkaar. elke bulldozer core is 4 issue (2x integer 2x mem operatie).
als je een module als 1 core ziet dan zou die core dus 8-issue moeten zijn... maar wel een waarbij elke thread er maar 4 van kan gebruiken. en dat klinkt weer veel meer als 2 cores als dat het als 1 core klinkt.

Nee, de Bulldozer Module is 4-wide issue, je kan niet zeggen wat de issue van de afzonderlijke 'cores' is aangezien ze hun issue logic delen (de eerder besproken fetch en decode). Het is ook niet gelimiteerd aan 2x integer en 2x mem, dat zijn het aantal aanwezige executie units in de Integer units, maar het kan net zo goed een andere mix zijn van vier instructies die geissued worden. Er kunnen net zo goed 4 integer operaties geissued worden, twee in elke thread.

Nou ja ik hoop dat dit wat verduidelijking schept, misschien was mijn vergelijking met de oude Pentium ook wel een klein beetje kort door de bocht, en ik denk toch niet dat we het snel eens gaan worden over wat nu wel of niet een 'core' genoemd moet worden