funkcionálně.cz

Přední český blog o funkcionálním programování, kde se o funkcionálním programování nepíše
««« »»»

Dualismus hardwaru a softwaru, strojů a virtuálních strojů

26. 3. 2016 — k47

René De­s­car­tes věřil v myš­lenku du­a­lismu, který se dá di­le­tant­sky vy­svět­lit tak, že tělo a duše jsou dvě různé vzá­jemně ne­slu­či­telné ka­te­go­rie.

V po­dob­ném duchu se nese jiný du­a­lis­mus, který je na rozdíl od De­s­car­te­ro­vých tvr­zení méně me­ta­fy­zický, ale zato je pří­tomný a hma­ta­telný. Oba pak mají jedno spo­lečné: Jde o fa­leš­nou di­cho­to­mii i když všichni v hloubi duši tou­žíme po opaku.

Po­cho­pi­telně mluvím o du­a­lismu hard­ware a soft­ware, strojů a vir­tu­ál­ních strojů, kdy jeden dělá to, co to druhý nemůže, kdy „mys­lící“ pro­gram ovládá „hmotu“ stroje. Tato de­mar­kace na první pohled působí správně a uspo­ko­jivě, jako kdyby to tak sku­tečně bylo. Když ale začnu pro­ble­ma­tiku zkou­mat po­drob­něji a vezmu to okli­kou přes his­to­rii CPU ar­chi­tek­tur, toto roz­dě­lení, před chvílí ještě krys­ta­licky jasné, na­jed­nou začíná mizet v mlhách.

Všechno, co vypadá jako ne­měnné pravdy vy­te­sané do kamene, jsou jen roz­hraní a úrovně abs­trakce.

Už in­strukční sada pro­ce­soru (ISA) není ten po­my­slný pevný bod, na kterém stojí všechny ostatní želvy, ale také jen abs­trakce. Téměř žádný dnešní pro­ce­sor (možná s vý­jim­kou ně­kte­rých jed­no­du­chých RICSů nebo DSP) ne­vy­ko­nává in­strukce tak, jak jsou za sebou vy­sklá­dány v bi­nárce, ale dy­na­micky je v hard­waru pře­kládá na jed­no­dušší (RIS­Co­vější, i když tohle ozna­čení už moc ne­zna­mená) mikro ope­race (μops). Jedna in­strukce se může roz­pad­nout na ně­ko­lik μops nebo naopak může být běžná sek­vence ně­ko­lika in­strukcí pře­lo­žena na jednu mikro ope­raci (tzv macro-op fusion)1 . Si­tu­aci dále kom­pli­kuje mi­k­ro­kód, kdy jsou ně­které in­strukce pro­ce­so­rem pře­lo­ženy na malý pro­gram (na­pří­klad tri­go­no­me­t­rické funkce jsou mi­k­ro­kó­do­vány, práce se de­nor­mál­ními floaty nebo GATHER in­strukce na Haswellech, vy­lep­šená v ná­sle­du­jí­cích ge­ne­ra­cích)14 . In­strukce tedy není nutně nejmenší jed­notka práce2 a často ani není přímo im­ple­men­to­vána v hard­ware.

Tato or­ga­ni­zace není po­u­žita zbůh­darma, ale má dobrý důvod. Není totiž nutné plýtvat kře­mí­kem na každou funk­ci­o­na­litu, která je v pro­gra­mech po­u­ží­vána jen okra­jově. Místo toho je možné použít mik­ro­ar­chi­tek­turu s menším počet vysoce op­ti­ma­li­zo­va­ných funkč­ních jed­no­tek, které jsou sdí­lené mezi in­struk­cemi3 . Dále to zjed­no­du­šuje návrh pi­pe­line, pro­tože není třeba po­čí­tat s ope­ra­cemi, které mají divoce roz­dílné la­tence, a vede to k efek­tiv­něj­ším out-of-order jádrům, které můžou vy­ko­ná­vat různé μop (které trvají ±stejný počet taktů) růz­ných CISC in­strukcí na­jed­nou a využít tak do­stupný ILP. Jako pří­klad můžu uvést sta­řičké VAXy. Ty na­pří­klad přímo pod­po­ro­valy kom­pli­ko­va­nou in­strukci INDEX, která byla po­u­ží­vána jen velice zřídka, a proto nikdo ne­strá­vil čas op­ti­ma­li­zací její hard­wa­rové im­ple­men­tace. To došlo tak daleko, že když někdo napal stej­nou funk­ci­o­na­litu pomocí jed­no­duš­ších ope­rací, soft­wa­rový vý­sle­dek byl rych­lejší než přímá im­ple­men­tace v kře­míku. Víc o tom mluví Onur Mutlu v jedné ze svých skvě­lých před­ná­šek o ar­chi­tek­tuře pro­ce­sorů.

Jestliže in­strukce jsou atomy, pak mikro ope­race jsou jejich kvarky.

Jako další pří­klad na spek­tru abs­trakce může po­slou­žit Transmeta. Ta v dobách své ne­dlouhé slávy pro­du­ko­vala čipy, které do­ká­zaly roz­bě­hat ba­rokní x86 bi­nárky. Sám hard­ware přitom neuměl nic z mon­strózní x86 ISA, ale místo toho běhal na vlastní pro­pri­e­tární VLIW ar­chi­tek­tuře a x86 pro­gram byl za běhu pře­klá­dán pomocí tak­zva­ného Code Mor­phing soft­ware (CMS) do in­terní ISA4 . Ne­pře­klá­dal ale všechno. Zpo­čátku kód jen naivně in­ter­pre­to­val, když pak ob­je­vil opa­ko­vaně pro­vá­děný blok, rychle ho pře­kom­pi­lo­val z x86 do na­tiv­ního VLIW for­mátu, když pak zjis­til, že jde o sku­tečný hot­spot, pro­vedl dů­klad­nou (a po­ma­lou) kom­pi­laci, jejímž vý­sled­kem byl kva­litní a rychlý kód. Pro­ce­sory od Transmety se tak v mnohém po­do­bají JVM, jen s tím roz­dí­lem, že jejich vstu­pem není Java by­te­kód, ale x86 bi­nárka, cíl JITu není x86, ale in­terní níz­ko­úrov­ňový VLIW formát a hard­ware je spe­ci­ficky na­vr­žen pro tento účel.

VLIW in­strukce se v mnohém po­do­bají mikro ope­ra­cím – jde o ope­race na velice nízké úrovni, které věrně opi­sují cho­vání a mik­ro­ar­chi­tek­turu hard­ware5 . Jsou pro­vá­děny ve sta­tic­kém pořadí ur­če­ném kom­pi­lá­to­rem (sta­ti­cally sche­du­led) a ob­na­žují všechny in­terní de­taily pro­ce­soru, jako jsou počty funkč­ních jed­no­tek, délku pi­pe­line a la­tence jed­not­li­vých ope­rací. To vede k pro­blé­mům s pře­no­si­tel­ností, kdy pro­gram zkom­pi­lo­vaný pro jeden model VLIW stroje ne­fun­guje na no­věj­ším modelu, který má víc nebo rych­lejší funkční jed­notky.9 Když je však tento in­terní formát skryt pod jednou úrovní abs­trakce (jako v pří­padě x86 a dal­ších ne-VLIW ISA), může se mik­ro­ar­chi­tek­tura li­bo­volně měnit a vrstva o jednu úroveň výše se po­stará, aby byly všechny pro­středky co nej­lépe vy­u­žity – ne­zá­leží jestli jde o celkem naivní pře­klad v hard­ware, nebo dy­na­mic­kou re­kom­pi­laci v soft­ware. Do­konce je te­o­re­ticky možné takto po­sta­vit stroj, který zvládá ně­ko­lik růz­ných ISA na­jed­nou (třeba x86 a ARM).

V pří­padě Transmety se in­terní formát měnil celkem zna­telně – první ge­ne­race pro­ce­sorů po­jme­no­vaná Crusoe byla široká 128 bitů a každá in­strukce ob­sa­ho­vala 4 ope­race. Další ge­ne­race byla dva­krát širší s dva­krát větším počtem ope­rací v in­strukci. Více in­for­mací je v ofi­ci­ál­ním whi­te­pa­peru nebo ve dvou člán­cích o sna­hách re­verzně vy­in­že­ný­ro­vat mik­ro­ar­chi­tek­turu Transmety.

Velice po­dobně jako čipy už dlouho mrtvé Transmety pra­cují ně­které ARM čipy z rodiny Tegra od Nvidie za­lo­žené na mik­ro­ar­chi­tek­tuře Denver (nebo ruský Elbrus, když už jsem u toho). Na rozdíl od Transmety, která začala pro­gram v in­ter­pre­tru, Denver umí přímo vy­ko­ná­vat ARM kód na celkem zá­kladní úrovni. Hlavní síla čipů však spo­čívá v pro­pri­e­tární in­terní VLIW ISA, která je 7-wide (7 ops v in­strukci). Pro­gram je zpo­čátku vy­ko­ná­ván v ARM módu s tím, že jakmile soft­ware objeví horký kus kódu, začne kom­pi­lo­vat. Roz­po­zná­vání hot­spotů ne­fun­guje na úrovni zá­klad­ních bloků, ale na úrovni prů­chodů (trace), které jsou ty­picky tvo­řeny jednou ite­rací smyčky a můžou pro­chá­zet mnoho zá­klad­ních bloků a do­konce i volání funkcí. Když je na­le­zena frek­ven­to­vaná trace ARM in­strukcí, je soft­wa­rově pře­kom­pi­lo­vána do VLIW ISA jako li­ne­ární sek­vence ope­rací, bez vět­vení a bez od­bo­ček. V mnohém tedy při­po­míná tra­so­vací (tra­cing) JIT kom­pi­lá­tory, jako je třeba ten v PyPy (po­u­ží­vaný i v jiných ja­zy­cích než Python), jen ne­tra­suje ně­ja­kou formu by­te­kódu nebo ope­race in­ter­pre­tru (jako v pří­padě meta-tra­cing JIT), ale přímo ARM in­strukce.

Jako další pří­klad může slou­žit spo­leč­nost Azul, která dříve vy­rá­běla čipy Vega spe­ci­a­li­zo­vané pro běh Java apli­kací. In­terně šlo o velice jed­no­du­ché a ne­pří­liš rychlé in-order RISC pro­ce­sory, které byly na­vr­ženy s ohle­dem na spe­ci­fi­kaci Javy. Ne­po­kou­šely se však přímo vy­ko­ná­vat Ja­vov­ský by­te­kód – lidé se o to dříve po­kou­šeli a zjis­tili, že je to velice špatný nápad. Na rozdíl od Teger a čipů Transmety měly Vegy vlastní ope­rační systém, stan­dardní knihovny a JVM zkom­pi­lo­vané do na­tiv­ního kódu, ale roz­hra­ním pro uži­va­tel­ské apli­kace byl jedině Java by­te­kód. Šlo tedy o po­měrně vy­so­kou úroveň abs­trakce, která ná­vr­há­řům10 dala velkou míru vol­nosti jak spo­lečně na­vr­ho­vat mi­chro­ar­chi­tek­turu a JIT. Hard­ware se mohl mezi ge­ne­ra­cemi měnit (a také se měnil), aniž by to na­ru­šilo kom­pa­ti­bi­litu pro uži­va­tel­ské apli­kace.

Úroveň abs­trakce může být však i jinde, o čemž svědčí chys­taný pro­ce­sor Mill. Jde opět o VLIW sta­ti­caly sche­du­led, open pi­pe­line stroj, který šířkou, kdy v jedné in­strukci může být až 33 ope­rací, pře­ko­nává všechno ostatní. ISA je za­mýš­lena jako cíl pro kom­pi­lá­tor a bude přímo vy­ko­nána pro­ce­so­rem na nej­nižší možné úrovni bez dal­ších vrstev abs­trakce. Od ostat­ních VLIWů se Mill liší v tom, že není na­vr­ho­ván jako jedna ar­chi­tek­tura, ale rodina ar­chi­tek­tur s růz­nými schop­nostmi a hard­wa­ro­vými pro­středky.12

VLIW má pro­blém v tom, že jde o příliš nízkou úroveň abs­trakce – v pod­statě před­sta­vuje ob­na­že­nou mik­ro­ar­chi­tek­turu. Když se hard­ware změní, soft­ware se musí při­způ­so­bit. Mill se tohle snaží vy­ře­šit tím, že pro­gramy ne­bu­dou dis­tri­bu­o­vány jako bi­nárky přímo určené ke spuš­tění, ale budou na něco abs­trakt­nější úrovni s tím, že se před spuš­tě­ním nebo během in­sta­lace sta­ticky spe­ci­a­li­zují pro kon­krétní hard­ware. Na rozdíl od pří­kladů v mi­nu­lých od­stav­cích by nemělo jít o nijak kom­pli­ko­va­nou re­kom­pi­laci, ale celkem přímé ma­po­vání po­ža­davků pro­gramu na pro­středky hard­ware. Mill tak abs­tra­huje nejen mož­nosti daného stroje, ale i bi­nární kó­do­vání in­strukcí, které může být spe­ci­fické pro každý model a přesto si za­cho­vává výhody sta­tic­kého sche­dule, který ne­po­tře­buje kom­pli­ko­vaný de­ko­dér nebo out-of-order hard­ware.6

O Millu zatím nemůžu pro­hla­šo­vat nic kon­krét­ního, pro­tože se ještě nedá koupit reálný křemík. Všechny in­for­mace po­chá­zejí ze série velice de­tail­ních před­ná­šek, které uspo­řá­dal Ivan Godard a uka­zuje v nich všechny vlast­nosti, kte­rými se Mill liší od běž­ných strojů a ar­chi­tek­tur.

Z pře­de­šlých od­stavců lze vy­po­zo­ro­vat jedno spo­lečné téma: všechno je jen abs­trakce na určité úrovni. Od velice nízké jako v pří­padě Millu, přes o něco vyšší (x86 a ARM ISA) až po re­la­tivně vy­so­kou jako je Java by­te­kód. A to ne­mlu­vím o FPGA, které všechno tohle staví na hlavu, pro­tože dovolí přímo pro­gra­mo­vat hard­ware. A víte jak Intel ne­dávno koupil Alteru? To zna­mená jediné: do­čkáme se pro­ce­sorů s in­te­gro­va­nými FPGA.


Teď když jsem tu napsal přes 1000 slov o tom, že hra­nice mezi hard­warem a soft­warem je ml­ha­vější, než se na první pohled může zdát, nabízí se jedna zřejmá otázka: Ne­e­xis­tují nějaké prin­cipy psaní pro­gramů, které ně­ja­kým zá­sad­ním způ­so­bem be­ne­fi­tují hard­warusoft­waru?

Zcela ne­pře­kva­pivě: Ano.

Jedna vlast­nost, ze které pro­fi­tují všichni, je před­ví­da­tel­nost. Pokud se stro­jový kód chová před­ví­da­telně, může hard­ware roz­po­znat vzory jeho cho­vání a pomoci. Sázka na před­ví­da­tel­nost vedla k obo­ha­cení pro­ce­sorů o branch pre­diction jed­notky, které se snaží uhod­nout zdali pro­gram skočí nebo pro­padne7 , a branch target bu­f­fery, který před­vídá cíle skoků na re­gistr (ty­pické při im­ple­men­taci vir­tu­ál­ních metod), cachepre­fet­ching.

Před­ví­da­tel­nost pomáhá soft­waru v tom, že dy­na­mická pro­středí, jako je JIT kom­pi­lá­tor v JVM, může spe­ci­a­li­zo­vat kód pro běžné pří­pady a ty, které na­sta­nou jen zřídka nebo vůbec, ig­no­ro­vat. Takto může de­vir­tu­a­li­zo­vat a in­li­no­vat vir­tu­ální metody, což otevře dveře celé plejádě dal­ších op­ti­ma­li­zací. Pro dy­na­mické jazyky je před­ví­da­tel­nost ještě dů­le­ži­tější, pro­tože pokud má pro­gram ro­zumně sta­tic­kou struk­turu, vir­tu­ální stroj může ob­je­vit skryté třídy a typy ar­gu­mentů funkcí a spe­ci­a­li­zo­vat pro ně kód8 . Před­ví­da­tel­nost je také be­ne­fi­tem pro tra­cing JIT, které na­hrá­vají (tra­sují) li­ne­ární prů­chod kódem, který je často pro­vá­děn, a čím méně od­skoků a od­bo­ček v něm je, tím jed­no­dušší má práci13 . Stejně tak práce Maxime Che­va­lier-Bo­isvertBasic Block Ver­si­o­ning, ocení před­ví­da­tel­nost tím, že bude po­tře­bo­vat vy­ge­ne­ro­vat menší množ­ství verzí zá­klad­ních bloků. Z před­ví­da­tel­nosti také těží pří­stup za­lo­žený na spe­ci­a­li­zaci AST (jako je Tru­f­fle+Graal bac­kend pro Jruby), pro­tože (oči­vidně) není třeba pro­vá­dět takové množ­ství spe­ci­a­li­zací, což vede k menším a rych­lej­ším ně­ko­li­ka­úrov­ňo­vým po­ly­morf­ním inline cache.

Další dobrou vlast­ností pro všechny zú­čast­něné je malý a kom­paktní kód. Na úrovni hard­waru je to proto, že se kód vejde do cache. Nejde jen o ty hlavní úrovně jako L3/L3/L1I, ale také L0, která na ně­kte­rých stro­jích ob­sa­huje de­kó­do­vané mikro ope­race. To pomůže v pří­pa­dech, kdy hlav­ním úzkým hrdlem je de­ko­dér in­strukcí. Pokud je však smyčka velice těsná (něco jako pár de­sí­tek μops na Haswell/Broadwell/Sky­lake x86) a celá se vejde do loop bu­f­feru, hard­ware roz­po­zná, že si vy­stačí s tím, co je v loop bu­f­feru a vůbec nebude ko­mu­ni­ko­vat s cache a de­ko­dé­rem. To může vést ke zrych­lení pro­gramu a úspo­rám ener­gie. Navíc ne­před­ví­da­tel­nému a ne­ro­zumně roz­vět­ve­nému kódu hrozí, že skočí na místo, které ještě není v cache a bude muset čekat.11

Vir­tu­ální stroje kom­pi­lu­jící kód po me­to­dách (jako ty­pické JVM) pre­fe­rují malé metody, pro­tože jim to dává vol­nost v roz­ho­do­vání, zdali danou metodu in­li­no­vat nebo ne. In­li­no­vání zvět­šuje vý­sledný kód a proto, kdyby to JIT začal dělat příliš vel­ko­ryse, kód by na­ky­nul a ne­mu­sel by se vejít do cache, což by vedlo ke zna­tel­nému zpo­ma­lení. In­li­no­vání je dů­le­žité, ale jen v ro­zumné míře. Když se to pře­žene, může to uško­dit. Z toho důvodu JIT ty­picky vybírá kan­di­dáty pro in­li­no­vání heu­ris­ticky a jedna z nich je ve­li­kost metody s tím, že velké metody mají jen malou šanci být in­li­no­vány. Na­pří­klad JVM miluje malé metody a když se roz­jede, začne je spe­ku­la­tivně in­li­no­vat ně­ko­lik úrovní hlu­boko. Malé metody zá­ro­veň vedou k or­ga­ni­zaci kódu s malými funkč­ními celky, které mají jasně de­fi­no­va­nou roli, kdy každá funkce dělá jednu věc, což je obecně dobrá věc.


Na­ko­nec to vypadá, že všechno jsou to jen vir­tu­ální stroje sto­jící na ra­me­nou jiných vir­tu­ál­ních strojů. Do­konce i sa­motné Céčko, kte­rému se někdy říká pře­no­si­telný as­sem­bler de­fi­nuje cho­vání vir­tu­ál­ního stroje, který není nikde im­ple­men­to­vaný v hard­ware, ale shodou náhod se na sku­tečný hard­ware dá docela pěkně na­pa­so­vat. Všechny vir­tu­ální stroje se na­ko­nec od sebe liší jen tloušť­kou abs­trakce, kterou je třeba pře­ko­nat, aby pro­gram do­ká­zal roz­po­hy­bo­vat reálné elek­trony na re­ál­ném kře­míku.


Dále k tématu


Do­datky:

  1. Na­pří­klad po­slední Intelí x86 kusy pře­klá­dají sek­vence ně­kte­rých in­strukcí, jako cmp nebo arit­me­tické ope­race, ná­sle­do­va­ných skokem na jeden μop. Je tedy možné, že všechny in­strukce, které řídí smyčku (inc, cmp, jXX) skončí jako jediný μop přímo im­ple­men­to­vaný v hard­ware. Tohle je podle mě dobrý způsob jak utra­tit do­stupný křemík, pro­tože těsné smyčky jsou časté a pro­gram v nich stráví hodně času.
  2. I když ně­které jed­no­du­ché in­strukce jsou přímo im­ple­men­to­vané v hard­ware. Jak je vidět z ně­kte­rých mik­ro­ar­chi­tek­to­tic­kých sché­mat, x86 CPU mají ně­ko­lik de­ko­dérů z nichž vět­šina dokáže de­kó­do­vat jen jed­no­du­ché in­strukce, které jsou pře­lo­ženy na jeden μop a jeden, který pře­kládá kom­pli­ko­va­nější ope­race nebo pra­cuje s mi­k­ro­kó­dem. De­kó­do­vání může pro kom­pli­ko­vané CISC ISA před­sta­vo­vat úzké hrdlo.
  3. Na­pří­klad arit­me­tické in­strukce, které mají cíl nebe zdroj v paměti jsou pře­lo­ženy na jeden μop, který pro­vede load/store a je ne­plá­no­vaný na ně­kte­rou z do­stup­ných load/store jed­no­tek a další μop sa­motné arit­me­tické ope­race. Pro pro­gra­má­tora vi­di­telná ar­chi­tek­tura tak může být re­gis­ter-memory, ale mik­ro­ar­chi­tek­tura je typu load-store.
  4. CMS naběhl ještě před star­tem ope­rač­ního sys­tému a byl to jediný kus soft­waru na­psaný přímo pro in­terní VLIW ar­chi­tek­turu, všechno ostatní byl tra­diční x86 od ope­rač­ního sys­tému až po uži­va­tel­ské apli­kace.
  5. Jenom s tím roz­dí­lem, že VLIW přesně pasuje na do­stupné funkční jed­notky a celá dlouhá in­strukce je vy­ko­nána pa­ra­lelně, za­tímco každý μop je na out-of-order stro­jích plá­no­ván a pro­vá­děn dy­na­micky. VLIW za­chy­cuje sta­tický in­strukční pa­ra­le­lis­mus, μop na OOO dy­na­mický.
  6. Mill se v mnohém podobá Itaniu, které čás­tečně zapadá do rodiny VLIW strojů – každá in­strukce je „dlouhá“ a ob­sa­huje ně­ko­lik ope­rací (v tomto pří­padě se sku­pině ope­rací říká bundle) a ex­pli­citní ozna­čení da­to­vých zá­vis­lostí mezi ope­ra­cemi. Pokud je mik­ro­ar­chi­tek­tura dané im­ple­men­tace Itania do­sta­tečně široká, stroj může vy­ko­nat pár bundlů pa­ra­lelně a nemusí sám dy­na­micky zjiš­ťo­vat zá­vis­losti mezi ope­ra­cemi. Zá­mě­rem bylo do­sáh­nout vět­šího ILP na no­věj­ších stro­jích bez nut­nosti out-of-order hard­waru a se za­cho­vá­ním bi­nární kom­pa­ti­bi­lity.
  7. V sou­čas­nosti branch pre­dic­tor do­sa­huje úcty­hodné přes­nosti. Z paperu Pre­diction and the Per­for­mance of In­ter­pre­ters je vidět, že pro­ce­sor dokáže před­po­ví­dat skoky ve smyčce in­ter­pre­tru a svým způ­so­bem pra­cuje na meta úrovni – ne­před­vídá skoky v kódu, ale v kódu, který in­ter­pre­tuje kód.
  8. Spe­ci­a­li­zace se dá do­táh­nout dál než skryté třídy/spe­ci­a­li­zace kódu. Paper Adap­tive Just-in-time Value Class Op­ti­mi­zation se zabývá spe­ci­a­li­zací kom­po­zit­ních da­to­vých struk­tur.
  9. I ně­které ne-VLIW ISA od­ha­lují in­terní de­taily mik­ro­ar­chi­tek­tury. Jde na­pří­klad o delay-slot.
  10. Mezi mě mimo jiné patřil Cliff Click, který měl o pro­ce­so­rech Vega skvě­lou před­nášku, která kdysi, spolu s Per­for­mance Anxi­ety od Joshe Blocha, na­smě­ro­vala můj zájem směrem k hard­waru a pro­ce­so­rům.
  11. Uka­zuje se, že ně­kte­rým ser­ve­ro­vým úlohám ne­stačí in­strukčí cache.
  12. Ale ani toto není nový nápad. Sám Ivan Godard říká, že Mill je rodina ar­chi­tek­tur ve stej­ném smyslu jako IBM System/360.
  13. Tady stojí za zmínku trace cache Pentia 4, která pra­cuje v duchu tra­cing JITu a ukládá li­ne­ární sek­venci de­kó­do­va­ných mikro-ope­rací.
  14. Podle knihy The Soul of a New Ma­chine Tracy Ki­d­dera stroje v se­dm­de­sá­tých letech pře­chá­zely od přímé im­ple­men­tace in­strukcí v hard­ware na mi­k­ro­kód.
@kaja47, kaja47@k47.cz, deadbeef.k47.cz, starší články