Kaupasta ei saa bugittomia versioita ikinä.
Ei välttämättä, ei ole julkistettu missä tuo bugi tarkkaanottaen on.
Se ei välttämättä ole FMA3-käskyn suoritusyksiköissä tms. vaan se voi olla myös prosessorin virransäästölogiikassa tms. joka on ihan softakoodia, jolloin sen korjaaminen on ihan "oikea korjaus" eikä "kierto".
Ja prosessorin johonkin tulevaan versioon laitetaan jo "sisään" uusi mikrokoodi, jolloin sitä ei tarvisi BIOSilta ladata.
Sitä tilaa jälkikäteen päivitettävälle mikrokoodille on joka tapauksessa siellä prosessoilla rajallisesti, joten joka tapauksessa halutaan minimoida sen käyttö.
Mikro-ohjelmoinnilla muutetaan koneen käynnistyksen yhteydessä prosessorin koodia. Tämä muutos tulee todennäköisesti BIOS-päivityksessä, mutta voi se tulla myös Windows-päivityksenä.
Prosessorin uudelleenohjelmointi käynnistyksessä on ihan yleisesti käytetty taktiikka pienten virheiden korjaukseen. Intelillä on Errata jokaisen prosessorin speksien lopussa ja AMD:llä taitaa olla samoin jossain virhelista, joita tulee näin isoissa prosessoreissa ihan pakostakin.
Koska virhe jää fyysisesti prosessoriin, sen kiertäminen käyttämällä mikro-ohjelmointia voi aiheuttaa nopeusongelmia. Tuskin saavat tarkistuksia samaan kellojaksoon ikinä. Ja pahimmassa tapauksessa poistavat (osan) FMAsta käytöstä. Tuossa ei nyt tarkasti sanottu, mitä AMD aikoo tehdä - vain miten se sen tekee.
Prosessori voi suorittaa käskyjä kahdella eri tavalla:
1) Käsky dekoodataan suoraan yhdeksi tai muutamaksi prosessorin mikro-operaatioksi, jotka suoritetaan peräkkäin liukuhihnamaisesti prosessorin liukuhihnalla.
2) Käsky suoritetaan mikrokoodilla, mikä tarkoittaa sitä, että prosessori käytännössä vaihtaa toimintamoodia ja alkaa suorittamaan mikrokoodi-ROMissa olevaa ohjelmaa, jossa voi olla esim. monimutkaista kontrollia kuten hyppyjä, ja sitten kun tämä mikrokoodiohjelma valmistuu, palataan takaisin suorittamaan "normaaleja käskyjä" siitä, mihin jäätiin. Käytännössä samaan aikaan ei siis voida kunnolla suorittaa muita käskyjä rinnakkain ja mikrokoodimoodiin siirtyminen hidastaa prosessoria huomattavasti.
Se, mitä voidaan uploadata prosessorille bootin yhteydessä on tyypillisesti
1) uusia paloja mikrokoodia
2) käskykohtaisesti pointteri mikrokoodirutiiniin tai tieto siitä että dekoodataan suoraan eikä suoriteta mikrokoodilla.
Esim. Bulldozerissa oli rikkinäinen kokonaislukujen jakolaskuyksikkö. Tämä huomattiin ennen piirin julkaisua, mutta aikaa sen korjaamiseen ei ollut ilman että piiriä olisi pitänyt myöhästyttää kuukausia, joten se otettiin vaan kokonaan pois päältä ja kokonaislukujen jakolaskut suoritettiin mikrokoodilla(joka saattoi ehkä jopa ehtiä siihen prosessorin mukana tulevaan ROMiin mukaan, en ole varma tästä). Jakolasku on joka tapauksessa hidas operaatio joita ei ole järkevästi optimoidussa koodissa innerloopissa, joten tämän vaikutus ei ollut kovin paha. Piledriveriin mennessä tämä jakolaskuyksikkö oli sitten korjattu, ja siinä se oli päällä.
FMA3-käsky sen sijaan (sille optimoidulla koodilla) on niin yleinen ja suorituskykykriitinen käsky, että sen suorittaminen mikrokoodilla olisi todella paha juttu ja hidastaisi paljon, käytännössä silloin kannattaisi vaan disabloida koko FMA3-tuki ja laittaa CPUID sanomaan, että tätä käskyä ei ole tuettu, jolloin softa valitsisi koodipolun jossa käytettäisiin erillisiä FADD- ja FMUL-käskyjä FMA-käskyn sijaan(erityisesti kun Zenissä rakenne on sellainen, että FMAsta ei hyödytä muutenkaan kovin paljoa, toisin kuin haswellissa ja bulldozer-johdannaisissa, joissa sen käyttö tuplaa teoreettiset flopsit)
Se, että AMD on vaan sanonut tuovansa pienen mikrokoodikorjauksen ja puhunut bugin korjaamisesta eikä kiertämisestä eikä pahoitellut mitään eikä puhunut FMA3n poistamisesta käytöstä vihjaisi siihen, että se oikeasti saadaan korjattua ilman että mitään joka nyt ajetaan suoraan tarvisi alkaa ajamaan mikrokoodilla.
