AMD tar bort Bulldozer-specifika instruktioner från kommande Zen

Ok. Det blir nog bra.
Då väntar vi bara på att Yoshman ska reda ut begreppen här

2016 Q3 + försening.

OMG, DAFUQ. ROFL.

Jag väntar med köp tills dess, och min måttligt överklockade FX-8350 får hänga med ett tag till. Förhoppningsvis ligger dollarn runt 6.30 igen så man kan köpa processorerna till ett humant pris

?????????

Är det bara jag som känner mig dum som inte fattar dessa tekniska förtkortningar?

Intels nästa arkitektur är Skylake som väntas dyka upp till hösten. Den är andra omgången 14 nm. Den följs av Cannonlake som väntas komma 2017 och det bör vara en krympning av Skylake till 10 nm. Efter Cannonlake vet vi inte vad som händer. Intel har inte släppt något om det än. Det verkar som att Intel börjar titta på andra halvledare än kisel för nästa steg. De tittar också på mer avancerade 3D-strukturer än nuvarande FinFET. Men vad som händer efter Cannonlake 2017 vet vi inte. Eller om det ens kommer vara ekonomiskt att gå lägre än 10 nm. Om Zen släpps i tid kommer verkar det som att båda lagen kommer köra på 14 nm.

Om ZEN skulle faila, så skall jag limma fast en CPU från Intel på Ozzed's vägg ovanför hans dator.
/Lifooz

Jag har skrämt upp min i 4.6GHz och nordbryggan ligger på 2.6GHz, så jag klarar mig. Har dessutom lyckats få den hyfsat sval genom att sänka PLL-voltage och massa annat som jag inte minns namnet på så den går sällan över 55c i full load (54 enligt sensorn på själva CPU'n men AMD's temperaturmätare är ju lika pålitliga som stefan löfvens löften så...) så jag känner att jag är rätt nöjd

Sitter just nu på ett 670 dessutom, så risken finns ju att det blir "Nytt alltihoppa" när man då köper ZEN.. Nytt moderkort, minnen, grafikkort, processor, lagring, och förmodligen även chassi.. Sitter idag på ett Antec TWELVE HUNDRED och det känns lagom modernt med endast USB2-portar i fronten.. Men men.. Det får stå sig ett tag till som sagt

Eftersom det ska dröja 2 år undrar man egentligen lite varför AMD inte bara släpper Excavator för AM3+ och "gör alla glada". Jag hade instaköpt en 8-kärnig för ~2k lätt.

Lite onödigt cyniskt kanske..

Tycker det är ett rimligt drag. AMD inser väl att de kan få svårt för brett stöd runt egna, mer specialiserade, instruktioner. Bättre då att lägga tid och kretsyta på att bygga bra funktionalitet runt redan etablerade, i det här fallet sådana som är populära via Intels modeller.

Kan tilläggas att Intel och därmed Zen, kör med FMA3 som där instruktionerna har 3 argument och ett av dessa agerar resultatregister (vilket i detta fall beror på instruktion). FMA4 är typisk "RISC" medan FMA3 är typisk "CISC", Intel vacklade mellan FMA3/FMA4 men valde till slut det förra då FMA4 resulterade i väldigt långa instruktioner. Är en avvägning mellan kompaktare kodning som ger bättre cache hit-rate och icke-förstörande instruktioner som ibland gör det möjligt att undvik extra register-till-register move. Gissar att Intel i slutändan valde FMA3 då man i Haswell (som är första Intel-CPU med FMA) lyckades lura ut ett sätt att göra register-till-register moves helt i front-end (d.v.s. tar inga ALU-resurser alls).

Om vi fortsätter

• SMAP är egentligen inte en instruktion utan en kontrollbit i kontrollregister CR4 som gör gör det omöjligt för kärnan att komma åt minne i applikationer. I alla moderna OS måste alltid OS-kärnan minne vara oåtkomligt för applikationer, men innan SMAP fanns inget skydd i motsatt riktigt. Detta kan vara viktigt i vissa lägen så att en bugg i kärnan inte råkar göra så data läcker mellan applikationer.

• RDSEED är redan rätt bra förklarad, läser ut ett slumptal från speciell HW som kan generera "äkta" slumptal och lägger resultatet i ett register.

• SHA HW implementation av kryptografisk stark s.k. hash-funktion

• CLFLUSHOPT gissar att detta är en felskrivning och det som menas är instruktionen CLFLUSH som säger åt CPUn att skriva ut en viss s.k. cache-line (i x86 delar cachen-systemet upp RAM i 64-bytes stora områden som kallas cache-lines, detta tvingar ut cachad data från en sådan "linje" till RAM).

• ADCX/ADOX är en variant på en ADD/ADC (add/add-with-carry) som funnits sedan x86 begynnelse, skillnaden är att de senare inte fungerar helt optimalt för att göra heltal med "obegränsad" storlek. ADD/ACD fungerar bra att för att hantera 64-bitars tal på en 32-bitars CPU eller 128-bitars tal på 64-bitars CPU, men det går inte (extremt effektivt) att generalisera det till större tal.

• CLZERO enda rimliga är att detta är ett effektivt sätt att sätta alla 64-bytes i en cache-line till noll. Inte helt ovanligt att man ser kod likt struct my_struct s; memset(&s, 0, sizeof s); d.v.s. man vill initiera allt minne för s till noll, denna instruktion kan göra detta mer effektivt på strukturer som tar upp hela cache-lines.

• XSAVEC/XSAVES används t.e.x när en CPU-tråd ska byta till en annan OS-tråd. Gissar att man lagt till komprimering på detta då det börjar bli ganska mycket data att spara/återställa med AVX och än mer med AVX512 då dessa register är väldigt stora (256 resp 512 bitar, 32 resp 64 bytes).