"Cores: 2/4" taitaakin tarkoittaa että niitä on 2- ja 4-ytimisinä eikä virheellisesti tulkitsemaani 2C4T:tä, uutista korjattu:
Anandillahan oli tuosta Tremontista juttu jo viime lokakuussa, mutta oli mennyt minulta ohi, nyt huomasin kun aloin googletella.
Se, että siinä on nuo kaksi fetch- ja decode-clusteria hämäsi minut aika hyvin. Ajattelin, että sopisi hyvin SMTn kanssa, toinen toiselle säikeelle ja toinen toiselle säikeelle.
Mutta se toinen onkin sitä varten, että sillä fetchataan ja dekoodaaan koodia eri puolilta haaraa saman kellojakson aikana. Ja jos haarautumisenennustus sanoo että mitään haaraa ei juuri sillä hetkellä ole tulossa, sitten toinen clusteri idlaa.
Perinteisestihän
1) kun käskyjä haetaan normaalisti käskyvälimuistista, fetch-yksikkö hakee vaan joka kellojakso käskyvälimuistista ison yhtämittaisen klöntin (esim 16 tai 32 tavua) ja sitten dekooderi erottelee siitä käskyt erilleen. Ja jos tulee hyppy (muualle kuin parin käskyn päähän saman klöntin sisällä), sitten hypyn kohteesta voidaan hakea käskyjä aikaisintaan seuraavalla kellojaksolla.
2) nopeimmissa prossuissa(zen, sandy brige ja siitä eteenpäin) on myös mikrokoodia tallettava L0-käskyvälimuisti josta voidaan käskyjä hakea myös "tarkemmalla granulariteetilla" ilman tätä rajoitusta.
Tässä Tremontissa sinänsä hienosti haarautumisenennustusta hyödynnetään siihen, että saadaan helpommin dekoodattua enemmän käskyjä kellojaksossa; Monen käskyn dekoodaaminen samasta fetch-klöntistä kellojakson aikana on hankalaa koska seuraavan käskyn aloituspaikka tiedetään vasta kun edellistä on dekoodattu tarpeeksi, joten jos vaikka halutaan dekoodata 4 käskyä kellojaksossa niin jokaisen pituus pitäisi teoriassa selvittää neljäsosakellojakson aikana. (*)
Mutta kun klöntti on lyhyt ja haarautumisenennustus on jo kertonut tarkan paikan mistä seuraava käsky todennäköisesti alkaa, edes sen paikka on selvillä ilman että tarvii odotella edellisten käskyjen pituuden selvittämistä, voidaan dekoodata useampaa käskyä rinnakkain ilman että meillä on ilkeitä riippuvuuksia niiden käskyjen dekoodauksen välillä.
(*) Tosin käytännössä homma yleensä ratkaistaan siten että siellä dekoodataan spekulatiivisesti monesta paikasta yhtä aikaa, aloitetaan dekoodaa esim. rinnakkain sekä kohdista 0, 1,2,3,4,5,6,7, 8, 9, 10, 11, 12,13, ja sitten siinä vaiheessa kun selviää, että ekan käskyn pituus on 3 tavua, heitetään mäkee kohdista 1 ja 2 aloitetun dekoodaukset, ja kun selviää että tokan käskyn pituus on 4 tavua, heitetään mäkeen kohdista 4,5,6 alkaneet dekoodaukset. Ja kun selviää, että kolmannen käskyn pituus on 2 tavua, heitetään mäkeen kohdas 8 alkanut dekoodaus jne.
Käytännössähän ne eri dekoodaukset valmistuu todennäköisesti aika lailla yhtä aikaa, eli ekan käskyn pituustuloksen perusteella vaan valitaan muutamasta eri vaihtoehdosta, että mistä otetaan seuraavan käskyn pituustulos, summataan ne, käytetään tätä taas indeksoimaan sitä että minkä dekoodauken tuloksesta löytyy seuraavan käskyn oddsetti jne, kriittisellle polulle tulee käytännössä yhden käskyn pituuden dekoodaus, sekä jokaista rinnakkaista käskyä kohden adder ja mux.
Mutta se, että dekoodataan monesta paikkaa rinnakkain ja heitetään näistä n. 2/3 mäkeen on melkoista energianhukkaa, sen takia tätä ei haluta näissä virrankulutusoptimoiduissa ytimissä tehdä kovin suuressa mittakaavassa.
