Názory k článku Čtyřicet let existence architektury 386: revoluce přinesla Doom a Linux

Super článek, díky za něj. Ale nedávno jsem dočetl knihu The Game Engine Black Book https://fabiensanglard.net/gebbdoom/index.html a tam jsem nabyl dojmu, že na 386 Doom asi sice běžel, ale že cílený byl hlavně až na 486.

Na 386 to moc dobře nejelo. Hratelné to bylo až na 486.

Na 386 jsme hráli spíš Stuns, nebo "Olympiáda" (Summer/Winter Challenge).

Stunts jel i na 286, to byla klasicka 16bitova hra (dlouho neprekonana btw)

V Stunts ma bavilo jazdiť s formulou a robiť s ňou glitche, lebo tá fyzika tam nebola úplne dobrá :)

Taky se dala udělat dlouhá rovinka, na konci skokánek a za tím byl takovej ten hard limit (plot), o kterej se auto zaseklo a spadlo kolmo dolů.

Já jsem udělal jednou trať tak přeplácanou, že projet ji trvalo víc jak 10 minut. Takže stačilo objet start-cíl, dostali jste penalizaci 10 minut a i tak vyhráli.

Upřímně nevím, co si s takovou informací počít. Měl jsem 386DX se 4MB RAM a Doom I i Doom II běžely naprosto bez problémů.

Bez problémů ? Na 386DX33 dá Doom v plném okně celých 6.1 FPS.
https://www.youtube.com/watch?v=9zAI8K7OzDQ
U nás bylo běžné AMD 386DX40, takže tam to dalo o něco více. I tak ale na 386 bylo nutné zmenšit okno a případě snížit kvalitu grafiky.

Běželo to a to stačí, nějaké detaily už se tolik neřešily ;-) Ale Wolfenstein 3D na tom běžel dobře :-)

Hele, měl jsem tam i matematický koprocesor (80387), mělo to vliv? To nevím. Ale fakt si nevzpomínám, že by byl problém.

V té době jsem byl dítě, tak nevím. Co jsem četl v knize, tak 487 koprocesor sice zrychlil FP na třetinu oproti 387, ale pořád to bylo žalostně pomalé, tak stále používali celočíselné operace.

Zdrojáky Dooma jsou k dipozici a IMHO tam žádné floaty a doubly nejsou. Však to taky dneska rozběhají na každém silnějším MCU, kde taky FPU nebývá.

Bezelo to celkem obstojne, na tu dobu https://www.youtube.com/watch?v=L6U8fyEgRH4

Tehdy kazde FPS nad 10 bylo dobrych, dale se mohlo okno zmensit a jeste tam byla moznost vykresleni dvou (nebo i ctyr???) pixelu vedle sebe stejnou barvou - vyuzival se ModeX, tak to byla vlastne operace zadarmo.

PS ty zaseky ve videu: dotahovani dalsich dat z disku - na zacatku je videt, ze ma 4MB RAM (coz byvalo maximum pro tehdejsi desky)

7. 10. 2025, 12:17 editováno autorem komentáře

Není pravda, běžné byly 0.256 MB moduly a 1MB moduly a to použité typicky v sadách po čtyřech.

DX stroje měly prakticky vždy 8 slotů, ale více než 4MB bylo neobvyklých.

Doom na 386SX moc svižně něběžel, důvod je jasný. Na 386 DX Doom mohl mít hratelné FPS, ale...

Maximum asi ne, viz. např. https://www.youtube.com/watch?v=NJb-DgLcwX4

Tak to mám pro vás špatnou zprávu, prostě si to buď nepamatujete, nebo lžete.

Tak asi by 386 nebyla v minimálních požadavcích. Ano, bylo to s doublepixelováním a ve zmenšeném okně. Asi jak hráli lidi Wolfenstein-like hry na Amigách.

Já Doom hrál na 386DX-40 s 8MB paměti a poté, co jsem si místo původní grafické karty pořídil trochu lepší, běhal naprosto v pohodě. Ale i předtím se to hrát dalo.

U počítačů IQ 151 tvůrci nepředpokládali škodolibost spolužáků. Pokud po levé straně seděl nějaký gauner, bylo třeba tlačítko Reset chránit.

Reset jsem sice nemačkal, ale pamatuju si, jak se IQ přehřálo a zatuhlo. Nebylo to ojedinělé.

IQ151 žhavilo tak, že na těch žebrech nahoře se daly dělat topinky. A když někdo hodil dovnitř zápalku, vzplála - a na funkci počítače to nutně nemuselo mít vliv!

Osmibitový SP na 8080, to je asi chyba v tabulce.

opraveno, chyba copy+paste ;/

Podle mě dnes už nemá cenu mluvit o CISC vs RISC. Celé je to jen "frontend" a CPU si stejně všechno rozloží na uops. Co se týče rozšíření a různých extensions CPU jsou dnes prostě super komplexní - stačí porovnat instrukce x86 a třeba aarch64, když tomu přidáme SVE a SME tak se dostáváme na celkem srovnatelnou komplexitu. X86 má prostě nevýhodu v tom, že dekodér musí číst jednotlivé bajty - já bych to dnes označil za špatný design, ale v době vzniku nikdo nevěděl, že to bude problém za dalších 20 let nebo že ta architektura přežije 4 dekády.

jj dneska už se to v mainstreamu slévá (a ARM nikdy nebyl čistý ARM).

To kódování mělo význam v době, kdy byly krátké skoky, každý přechod přes hranici segmentu byl obecně problematický a lidi měli pár MB RAM. Zmenšovalo to velikost kódových sekcí (nechci teď psát segmentů, ať se to neplete). Někde se válí porovnání velikostí binárek pro různé platformy, zkusím to dohledat (z hlavy nedám, jestli to byla procenta nebo desítky procent, ale spíš to budou ty nižší desítky procent).

Mikrokodovana bola uz 8088 a dokonca aj nejake o dekadu starsie CISCove procesory. RISC vs CISC ani tak nie je o tom, ci je procesor mikrokodovany alebo nie. Skor ide o to, ako komplexny "frontend" ma.

Z toho sa potom odvodzuje, ako zlozity musi byt engine, ktory mikrokod interpretuje a vsetko sa stava nasobne zlozitejsie.

Tradicnym problemom je napr. podpora komplexnych adresovacich rezimov, ktore zvacsuju dlzku zvonku viditelnej pipeline a predlzuju latenciu instrukcie. RISCy spravidla inklinuju k load-store architekture, kde tento problem odpada. Vsetka komplexnost adresovacich rezimov sa sustredi na instrukcie load a store a zvysok instrukcnej sady pracuje cisto s registrami.

Takze, presnejsie rozdelenie by asi bolo nie CISC vs. RISC ale architektury s lubovolnym pristupom do pamate vs. LOAD/STORE architektury.

Rozlišovat to na load/store je sice zajímavé, ale taky to nemá moc smysl.

V případě x86 se jedná v podstatě jen o "kompresi" - store s nějakou operací jsou jen legacy instrukce (ADD, SUB, atd...), které se používají s lock prefixem pro atomické operace, a ostatní instrukce jsou operace + volicelný load - v případě x86 je to nutnost kvůli tomu, že počet registrů byl historicky hodně omezený, i v případě x86_64.

Atomické operace jsou v tomto kontextu zajímavé, protože rozbíjí ten koncept "load/store" architektury - jedná se vždicky o load, op, a store, a pokud architektura umožňuje implementaci lock/free algoritmů, tak potřebuje i pair operace popř něco jako cmpxchg16b, což tu architekturu dál komplikuje.

No a teď pojďme třeba na aarch64 a MOPS rozšíření, které v podstatě implementuje něco podobného jako REP MOVSB v x86 - prostě primitiva pro memcpy a memset, atd...

Takže, můj názor zůstává - toto rozdělování architektur dnes už nedává smysl. Moderní architektury konvergujou k nějakému designu a to jak jsou věci zakódované je hlavně problém frontendu. AArch64 je třeba značně omezený, ale jen proto, protože ty instrukce mají omezenou velikost. Ale taky umí třeba komplexní adresování [base + index * N] kvůli tomu, aby to byla praktická ISA.

Jo, tento pohlad dava zmysel.

Ten frontend má ale vliv na složitost dekodéru instrukcí. Aby uměl dekódovat více instrukcí za cykl, tak u RISC roste počet tranzistorů lineárně a u CISC exponenciálně. Proto Apple Silicon a Qualcomm Snapdragon X Elite dekódují 8 instrukcí za cykl a Intel a AMD se zasekly na 4 instrukcích (v inner loop je cachování napodobující 6 instr. / cykl).

Taky to v důsledku znamená, že se (při instrukcích s RISCovou strukturou) nemusí řešit výpadky stránky uprostřed instrukce (při jejím načítání), adresy skoků jsou o 1-2 bity kratší atd. Ty kratší adresy sice vypadají jako maličkost, ale v omezeném prostoru (32 bitů) pro instrukce to znamená, že skoky nemusí zabrat tolik prostoru (polovinu nebo čtvrtinu).

Ano, všechny tyhle věci zjednodušují omáčku okolo samotných výpočetních jednotek. Pro zajímavost, Qualcomm Snapdragon X Elite má poloviční plochu co odpovídající Intel pro laptopy (nicméně je na o trošku novější generaci u TSMC). A přitom i v emulaci x86 má o něco větší výkon jak tehdejší Intel (emulace je cca na 2/3 nativního výkonu; Intelu dost škodí/lo, že se v tenkém laptopu přehřívá a omezuje "turbo frekvenci"). Apple a AMD byly už tehdy výkonnější procesory (tj. stále existoval nějaký x86, který byl lepší než ARM) a Intel od té doby taky pokročil, nicméně Qualcomm nelení ("Qualcomm pro X2 Elite slibuje výkon 75 % nad konkurencí").

Intel bych za referenci, pokud jde o plochu čipu / jádra u AMD64 asi nebral. Už Jim Keller opatrně mluvil o tom, že mají problém se SW nástroji na design rozložení čipu + si Core nejspíš táhne balast z minulosti. Zen od AMD je v tomhle designovaný líp a ostatně i Atom mikroarchitektura od Intelu je efektivnější, pokud jde o vyžití plochy křemíku.

Jinak nejde jen o tenké laptopy. Nízká efektivita Core je problém i při implementaci AVX-512, kdy když kód chce provádět dané operace, zvedne se odběr a klesne frekvence. Člověk tak musí sakra benchmarkovat, jestli se mu AVX-512 v daném případě vyplatí. Zen má v tomhle bezproblémovější implementaci.

Ten prvy predpoklad nie je automaticky. Su RISCove instrukcne sady, ktore maju variablnu dlzku instrukcii, alebo na to aspon maju podporu. Namatkovo to tusim vie Power a RISC-V, aj ked u druheho sa to vacsisnou nevyuziva.

Mas pravdu, neni to automaticky. Zajimavosti je, ze Apple se podlilel na navrhu Aarch64 (ARM64), dekadu predtim, nez to vyuzil v Apple Silicon. Jinymi slovy hral "long game". Tezi z toho samozrejme vsichni vyrobci ARM.

7. 10. 2025, 20:47 editováno autorem komentáře

jj to se vracíme zpátky k pojmu RISC. Protože kdysi to označovalo CPU se stejně dlouhými instrukcemi, LOAD-STORE architekturu a velkým počtem pracovních registrů - tedy vlastně přesný opak 386ky :-). Už ani Thumb (16) do této kategorie nespadá, ale všechny první a druhé generace RISCů jsou v tomto ohledu prakticky totožné.

Takže kolega cc má pravdu, dneska je to takové fuzzy rozdělení.

Intel sa na styroch instrukciach za cyklus zasekol nie kvoli tomu, ze su tie instrukcie zlozite. Dekoder instrukcii je v idealnom pripade blba kombinacna logika. Problem Intelackeho formatu instrukcii je, ze je - kulantne a strucne povedane - strasne debilny. Je totiz variable length a dlzka instrukcie sa da zistit az po jej uplnom dekodovani. Ona totiz instrukcna sada 8086 nikdy nebola stavana na tak masivnu rozsiritelnost, aku zazila.

Napr. mozu mat instrukcie prefixy a skoro kazda instrukcia ma ako zdroj alebo ciel moznost zadat tzv. EA - effective address. To je vyraz variabilnej dlzky, ktory urcuje nepriame adresovanie operandu v pamati.

To sposobuje, ze moze mat instrukcia skrz ten operand roznu dlzku a zaroven este ma aj roznu latenciu pri vykonani. Typicky u Intelu je latencia instrukcii zapisovana ako X + LEA, kde X je konstantny pocet taktov procesora a LEA je vzorec, ktory urcuje dodatocne takty CPU podla toho, co je v operande pre pristup do pamate.

Ano, je to kombinace vice problemu. Jen doplnim, ze v SIMD operacich, zvlaste pak AVX-512, se protlaci "vice prace" skrz dekoder. Ale ne vsechno je vektorove/maticove. Napr. vykonani skriptu ve webove strance je obri balast skalarnich operaci. Dale v multithread (MT) je v AMD hyperthreading (HT), tedy 2 dekodery vedle sebe pro jedno jadro.

A zase tu máme RISC a CISC. ARM měl být RISC, ale co třeba ARM vs Thumb? 2 ISA v jedné architektuře? Jedna dokonce variable length? Je to RISC nebo CISC? A nebo to nemá cenu rozlišovat?

Třeba takový RISC-V, který to RISC má přímo v názvu může mít 16-bit i 32-bit instrukce, což opět komplikuje decoder, který bude asi složitější než takový decoder aarch64, který prostě vezme 32-bitů a může dekódovat. Je to RISC a nebo CISC?

Frontend je prostě frontend a pokud si CPU chce zachovat kompatibilitu (což většina chce), tak i ten frontend do budoucna nabobtná. X86 má prostě smůlu v tom, že to je byte-by-byte, což je úplně naprd. Ale to přece nemá nic společného s CISC vs RISC, je to jen debilně navržené kódování.

Kdyby teď někdo přišel s tím, že by navrhnul lepší kódování pro x86, co by mělo fixní instrukce třeba 32 bitů (nebo 32 a 64 bitů), tak by to pořád byla ta stejná architektura, jen by se vyměnil dekodér.

Pro zajímavost, ARM měl vedle Thumb ještě Javovou instrukční sadu. Používalo se to v tlačítkových mobilech, když byly aktuální. Ta mobilní Java pak běžela asi na 70 % nativního výkonu procesoru, což v dřevních dobách, kdy nebyl JIT a výkon na něj, bylo skvělý. Nicméně si za to ARM nechal platit tučnou licenci a mezitím vzniklo JIT, takže pak už to výrobci telefonů nelicencovali a ARM tu ISA vyhodil. Nějakou dobu licencoval ještě softwarovou emulaci té ISA, aby systémy využívající ji fungovaly na nových SoC bez ní. S JIT to běželo na 60 % nativního výkonu, takže skoro stejně a mezitím vzrostl i hrubý výkon CPU. Podobně Apple Silicon nemá Thumb, tedy má všechny instrukce stejně dlouhé.

Thumb je jen pro 32-bit ARM, takže Apple Silicon ho mít ani nemůže (neexistuje pro aarch64).

Ona taka nejaka aktivita od Intelu relativne nedavno prisla. Volali to x86s alebo ako.

Malo to riesit ti najviac strasne legacy veci v x86tke, ako boot do realneho 16bitoveho rezimu a vyhadzanie niektorych velmi zriedkavo pouzivanych instrukcii (kto ste kedy pouzili AAA?).

Udajne za to z trhu dostali strasneho sprda.

Jj AAA a spol. zbytečně zasekaly poměrně velkou část prostoru pro kódy instrukcí a v praxi se to asi vůbec nepoužívalo (a ani si neuvědomuju, jak to napsat třeba v C, aby to překladač použil).

Boot v 16bitovém režimu (a asi i s A20 GATE - to je taky pěkná historičnost) s námi je až nechutně dlouho.

AAA, AAD, AAM, AAS, ARPL, DAA, DAS, INTO, POPA, POPAD, PUSHA, PUSHAD - tyto instrukce neexistují v 64-bit režimu. Ono je ale nikdo nepoužívá ani v 32-bit režimu.

Rád bych jen upřesnil informace k počítači IQ151. Kryt nebyl plechový, ale z jakéhosi reaktoplastu podobného bakelitu, ale jemnozrnnějšího a pevnějšího. Když se íkvéčko přehřívalo (což se stávalo běžně, když na něm stál "Merkur" bez dřevěného podstavce), bylo to cítit typickým zápachem spáleného bakelitu. Ty podstavce jsme pak vyráběli ve školních dílnách jako Baťa cvičky.

7. 10. 2025, 09:37 editováno autorem komentáře

IIRC existovalo víc verzí a dokonce i méně známý předchůdce IQ150. Jestli si dobře vzpomínám, IQ150 i první IQ151 měly ještě kovový kryt, až později se přešlo na plast.

Je fakt, že se to později změnilo, ale u nás na SPŠE to byly fakt plechy. A s tím přehříváním to bylo stejné jako u plastů, taky jsme měli Merkury (asi pro ně někdo v dílně udělal stojánky, byly takový dost vachrlatý :-)

Mám ještě dva IQ151. Jsou to verze G, mají plastový kryt. Co se týká přehřívání tak všechny legendy to hodně nadsazují, pokud se nepletu tak příkon je nějak kolem 100W což je mnohem méně než současná PC. Pravda zdroj nebyl dobře navržen, a tak se mohl přehříval ale o nějakém vaření čaje nemůže být řeč. Pokud zavzpomínám jak jsme na ně chodily ve 2. ročníku SPŠ Chomutov v roce 1987/88 chodil, nepamatuju se nějaký problém, ale možná jako žák jsem to neviděl.
Co se týká chlazení, tak k IQ 151 se dodávaly originální stoly kde byly poličky pro monitor (TV merkur/pluto), v zadní části byla polička otevřená pro větrání. Mám ještě 4 stoly v původním provedení v laboratoři elektrotechniky (na poličku krásně pasuje postavit osciloskop). K tomu pak byly takové menší stolečky "přídavný stolek k IQ". Desky na nich byly z hodně kvalitního umakartu, po 40 letech je skoro netknutý. Několik stolů jsem pak při rekonstrukci učebny využil tak, že na dva pevné kovové rámy jsem nechal udělat novou 2,5m dlouhou pracovní desku desku, tak aby to ladilo se zbytkem nábytku.
Někdy v dubnu jsem byl nucen kvůli "malování" Iqečka přenést do té laboratoře i s merkurama, tak mi to nedalo a musel jsem je naaranžovat tak jak to bylo v době jejich slávy (bohužel jsem si to nevyfotil).

Co se týká přehřívání tak všechny legendy to hodně nadsazují, pokud se nepletu tak příkon je nějak kolem 100W což je mnohem méně než současná PC.

Mnohem méně je to leda tak u nějakých výkonných herních PC se silnými grafickými kartami. Jinak není problém se při běžné práci pod 100W udržet. A můj server na housingu, což je normální ATX minitower (sice už poněkud starší, ale pořád třicet let po tom IQ151), překračuje 40W jen ve špičkách. U osmibitového počítače z 80. let není 100W rohodně něco, čím by se dalo chlubit.

Ono ještě v dobách Pentium 4 byl problém, že na tehdejší dobu topily 120 W. Ne protože by elektřina byla drahá, ale nebyly ještě vynalezeny moderní větráky, které to dokáží tiše uchladit.

Některá PC možná topí víc, ale mají větráčky, takže se to docela ochlazuje. Kdežto IQčko mělo jen ta žebra (navíc pro jistotu stříbrná nebo šedá), takže to fakt topilo.

Predstavuji si jak by tehdy implementovali levny maly vetracek tak jak ho zname dnes - BLDC motor kde jsou sekvencne spinane civky aby se to vrtelo. Bylo by to asi mozne (pri penalizaci velikosti) ale cenove odhaduju na tisicovku tehdy pro maloseriovou vyrobu.
Pamatuji si jak byly i obycejne male tranzistory drahe.

Podle toho, co jsem slyšel, byl kryt z materiálu typu polyuretan a byl stříkaný do formy. Myslím, že byl i pěněný kvůli váze a vyplnění formy. Jednalo se levnější nízkotlakovou formu. Vysokotlaké vstřikování a forma o těchto rozměrech jsou drahé. V paměti mi název materiálu zní jako IPUR nebo I-PUR, ale nalézt to nemohu, PUR je běžná zkratka pro polyuretan.

Co se přehřívání týče, tak jsme měli jak moduly BASIC, Grafik a i Pascal (tak rok 1987 na Gymnáziu u Libeňského zámku). Tak mě napadlo vyndat BASIC, vložit Grafik a Pascal a opravdu se mi povedlo implementovat interpolované čáry. Ten Grafik měl paměť nějak nepřímo adresovanou, pokud si pamatuji, možná adresa a barva přes 8255 nebo nějak jinak vytvořené IO obvody. Ale po krátké chvíli s začal stroj přehřívat (pěněný polyuretan sice není tak dobrý izolant jako polystyrén, ale na odvod tepla z elektroniky to dobrý nápad není) a celá horní část krytu se začala vydouvat. Rychle jsem počítač vypnul, vrátil původní moduly a dokud byl kryt rozehřátý, tak vzdutí stlačil dolů a pak již podobné pokusy nezkoušel. Chlazení dozadu žebry měly jen zdroje.

PMD-85 na tom bylo s konstrukcí o něco lépe a videopaměť byla mapovaná do posledních 16 kB adresního prostoru. Text se ale musel vypisovat vždy po bodech a řádka grafické paměti byla rozdělená na 48 byte pro 288 bodů (v byte dva bity na barvu a šest na jednotlivé pixely) a pak zbylých 16 byte na návrat paprsku. Těch 256 x 16 byte jsem často pro nějký stav programu v assembleru používal, aby mi zbylo více ve spodních 32 kB kontinuální RAM.

IPUR je ciastocne gumova forma PUR, ktora sa pouzivala na makcene vyplne v automobilovom priemysle. Boli z toho napriklad madla, volanty a niektore casti vnutorneho polstrovania v Skodovkach.

Matně si vzpomínám, že snad přímo návod k IQ-151 měl nějaká doporučení týkající se osazování modulů do určitých pozic s ohledem na odvod tepla - tuším, že se to týkalo např. modulu Pascal.

Akurat vcera som docital Oral History of 386, koho by to zaujimalo, prepis je dostupny tu:

https://www.computerhistory.org/collections/catalog/102702019/

Kazdopadne, v clanku su nejake nepresnosti. 4004 a 8080 su uplne nezavisle procesory vyvinute ako nezavisle externe zakazky. 8080 nie je evolucia 4004, ale konverzia cipovej sady spomenuteho terminalu Datapoint do jedneho kusu kremika vo forme mikroprocesora. 4004 vnikol ako externa zakazka na procesor snad pre kalkulacky.

Intel sa k 8080 dostal tak, ze dostal zakazku na vyrobu tychto cipov. Cipy 8080 implementovali instrukcnu sadu cipovej sady terminualu Datapoint (ktoru navrhli v IBM este o nejaky ten piatok skor). Kym bol vyvoj dokonceny, trh sa posunul a zakaznik uz o cip nemal zaujem. Aby nemusel Intelu za vyvoj zaplatit plnu sumu, cast platby vyriesili tym, ze Intelu predali prava na cip.

Intel v tej dobe fakt neveril, ze procesory su buducnost, doslova padlo: "Preco by som do pocitaca predal jeden procesor, ked mozem predat X pamati?". Intel bol este do zaciatku 80. rokov vyznamnym vyrobcom pamati.

Ostatne procesory v 80-tkovej rade su potom s 8080 viac alebo menej spatne kompatibilne. 8085 je kompatibilna snad aj na binarnej urovni a pre 8088 slo spravit transliteraciu kodu, kedy sa instrukcie 8080/8085 prelozili do instrukcii 8088. 8086 jakbysmet.

Tiez by som povedal, ze ta situacia 8086 vs. ostatne pokusy Intelu o procesor boli tak trocha naopak. 8086 je jedna z mala veci, co im na tomto poli vysla. Samotne 8086 bol projekt, ktory mal preklenut obdobie, kym intel dokonci micromainframe - Intel 432. To bol extremne komplexny projekt, ktory mal - celkom neprekvapivo - tie iste problemy ako Itanium o dve dekady neskor a do znacnej miery podobne problemy ako Intel 860 o dekadu neskor. Bol pomaly, drahy a neefektivny.

Preto Intel vobec 8086 nasadil ako docasne riesenie. Potom nanho nalepili 286tku, ktoru ako produkt aj v Inteli povazovali za nutne zlo a neskor spustili aj vyvoj 386tky z rovnakych dovodov.

Projekt Intel 432 sa dostal do tak mizerneho stavu, ze ho v Intelu interne restartovali ako projekt P6 (?). Spociatku mala byt 386tka s P6 kompatibilna, co znamenalo, ze by bola porusena spatna kompatibilita s 286tkou a IBM PC.

Preco si nieco take v Inteli dovolili? V dobe, ked sa 386tka zacala vyvijat (1981-1982) vlastne este nikto nevedel, co s IBM PC bude. Predaje sa este len spustali a nikto si neuvedomoval hodnotu existujuceho kodu. Spatna kompatibilita nebola temou. Zaroven si ale uvedomovali, ze dizajn 8086tky s iba 8mimi pracovnymi registrami (do znacnej miery podedeny od 8080) a segmentovymi registrami je gula na nohe. Intel strasil Zilog MMU.

Az feedback z trhu sposobil, ze sa vyvojovy tim priklonil ku kompatibilite s 8086. Marketaci Intelu 8086tky a 286tky predavali so slovami: "napiste vas software pre 286tku dnes a zajtra pobezi bez zmeny na 386tke". Az toto sposobilo, ze boli zahodene vylepsenia, ktore by zvysili pocet pracovnych registrov a bola dodrzana binarna kompatibilita s 8086/286. Co dnes vyzera ako samozrejmost vtedy samozrejmostou vobec nebolo.

Dalsim pomocnym faktorom bolo to, ze aj projekt P6 sa dostal do sklzu a obvody pre zbernicu v 386tke nebolo mozne navrhnut, pretoze neexistoval stabilny navrh samotnej zbernice.

To, ze Intel nebol ziadny expert v navrhu procesorov ilustrovala aj interna situacia vyvojovych timov. Samotni clenovia vyvojoveho timu 386 priznali ze v dobe, ked do Intelu nastupovali bol Intel na tom po stranke vyvoja tragicky. V inych firmach zaoberajucich sa vyvojom cipov (vtedy dost dominovali ASIC pred programovatelnymi obvodmi) fungovala riadna dokumentacia, formalne specifikacie, automatizovane nastroje na vyvoj a testovanie cipov.

V Inteli nic z toho nemali. K 8086 ani neexistovala formalna specifikacia, 286tka na tom bola iba o trocha lepsie, stale bola cela navrhnuta a testovana manualne. 386tka bola vlastne prvy procesor, ktory bol v Inteli vyvinuty state of the art procesom za pouzitia automatizacie. Do znacnej miery bez vedomia a ciastocne aj proti voli vedenia Intelu: "ak by vedeli co tu robime (a akymi nastrojmi to robime), urcite by nam to nedovolili".

To, ze v tej dobe bola pre Intel priorita v procesore 432 a P6 znamenalo, ze 386tka bola outsider s minimalnym financovanim a podporou. Takze niektore nastroje, ktore sa pri vyvoji 386tky pouzivali boli pokutneho povodu. Napr. autorouter na procesory bol napisany a spravovany studentom. To sa zmenilo az ked si Intel uvedomil, ze ako 432 tak P6 nemaju na trhu sancu uspiet a sustredili sa na 386tku. To nastalo az takmer ku koncu jej vyvoja.

Ani 386tka nebola schopna ukoncit nastup RISCov. Az zhruba pri 486tke sa podarilo dosiahnut paritu 486 s RISCovymi procesormi vo vykone a dosiahnut aspon ciastocne toho, ze procesor dokazal vykonat jednu instrukciu v jednom takte. Ani to ale nepomohlo a s Pentium Pro sa z Intelu vlastne stal frontend k RISCovemu procesoru. Tym padom CISCy prezili iba v mikrokontrolleroch a to este zhruba tri dalsie dekady. Dnes sice existuju, ale su to vsetko vybehove produkty s minimom dalsieho vyvoja a ustupuju RISCovym rieseniam.

7. 10. 2025, 11:09 editováno autorem komentáře

jj 4004 vzniklo pro kalkulacky, chtel to puvodne Busicom (dneska uz neexistuji).

Nicmene je to prvni generace CPU od Intelu, do historie to patri, i kdyz to neni mikroprocesor pro pocitace.

(jinak pozor na to, ze to Oral history jsou skutecne vzpominky jednotlivych akteru, oni schvalne moc nekomentuji rozhodnuti na nejvyssi urovni - treba dohody s AMD- , protoze tam treba jako inzenyri nebyli pritomni)

Oral history of 386 existuje ako tri separatne nahravky, jedna z nich riesi aj multi-source, resp. rozhodnutie od multi-source u 386tky upustit. Tu som ale zatial nedocital.

A je tam este tretia, ktora riesi marketing. Tu som ani citat nezacal.

4004 do genezy patri, akurat clanok (ak som ho spravne sparsoval) uvadza ze 4004 bola uvazovana do terminalov Datapoint, co nie je pravda.

ajo to opravim, jestli to tak vyznelo. Datapoint prisel az s 8008 (ja to zminoval asi hlavne proto, ze syntaxe Inteliho assembleru z toho vychazi, vlastne az dodnes ;)

Jinak ten dil o multi-source je zajimavej. Sice jsou tam nektere veci, ktere jinych zdroju probehly jinak, ale jako celek je to pekny.

hele to casove nevychazi. 432 zarizli uz v roce 1981 ne? A prace na 386 zacaly pozdeji AFAIK, takze se to vubec neprekryvalo. Jako jestli to myslis tak, ze predtim se do x86 neinvestovalo, mozny to je, ale v 1985 uz urcite na 432 nikdo nedelal ani nemyslel.

Oni prace na 432 nezarezali uplne, oni ten projekt rebootli do projektu P6, ci ako to volali. Nakoniec sa to tusim zhmotnilo ako i860.

Kazdopadne vtedy si este v Inteli mysleli, ze 432 bolo izolovane zlyhanie a ze koncept komplexneho "objektoveho" procesora ako taky je zivotaschopny. Takze cela linia procesorov 80x86 bola brana ako gap filler az cca do 1984, kedy jednak IBM PC nabral trakciu a druhak sa ukazalo, ze micromainframe nie je konkurencieschopny koncept.

tam je zajímavý i to, jak dlouho to Intelu trvalo navrhnout a dodat. V porovnání s MIPSem nebo i ARMem (což byla v podstatě one man show). Prostě původní jednoduché RISCy byly fakt jednoduché, žádný složitý řadič nebo dekodér instrukcí... (další generace s prediktory skoků, registrovými okny atd. už byly horší).

Niektore z prvych RISCov boli dost drsne masiny. Chybajuce nasobicky, alebo implementovana instrukcia iba na "jeden krok z operacie nasobenia" a nutnost vkladat delay sloty pri skokoch su famozne.

Cast z toho sa ale zachovala do dnesnej doby, napr. este POWER 4 (a mozno aj novsie) ma v specke napisane, ze data s ktorymi pracuje vektorova jednotka musia byt zarovnane. Ak zarovnane nie su, procesor bude ignorovat dolnych 5 bitov adresy a bude pracovat s datami ako keby zarovnane boli. Takze bude pracovat s inymi datami nez programator uvazuje.

Nevygeneruje to chybu, interrupt, trap ani nic. Proste procesor urobi nejaku uplne neocakavanu operaciu :) Je zodpovednostou programatora aby pracoval so zarovnanymi datami.

Na druhej strane sa veci ako prediktory skoku, register renaming a spekulativne vykonavanie implementovali podstatne lahsie ako na zlozitych architekturach. To bude zrejme aj dovod toho, ze vela z tychto technik sa prvy krat objavilo v mikroprocesoroch prave na RISCoch.

Zaujímavé, že doma sme nemali 386 ani jednu. Mali sme 286, nepociťovali sme nutnosť upgrade, až potom na pentium ... (a pre seba som si zohnal lacnú 486 na písanie v tex-u a programovanie až dlho potom)

U mna bola naopak 386SX prve PC s ktorym som musel vydrzat az do konca milenia.

Z referencnej prirucky 80386 mam dodnes PTSD a to, akym sposobom sklbili spatnu kompatibilitu s 32-bitovou podporou povazujem za chybu. Aj ked po precitani toho dokumentu berem 386tku na milost a uz by som vyvojovy tym uz za to co spachali nevydal popravcej cate :)

No viděno zpětně, těžko říct, jestli 386 byla z pohledu zpětné kompatibility tragédie nebo ne. Kdyby 386 neposunuli směrem k 32 bitům, tak by to také celé mohlo umřít, nebo by na tom začali "bastlit" v AMD nebo v IBM, možná v Harrisu a Intel by byl z kola ven. Jako 386 je bastl (a ještě víc to, co vzniklo potom), ale byla buď možnost nekompatibilní skok nebo kompatibilní smíšení původních 16 a nových 32 bitů.

(Linux ani OS/2 to vlastně netrápí, tam jedou 32bitovej režim se stránkováním od začátku a nějaké zpětné DOSoviny tam neřeší :-)

32bit v tej dobe uz mala minimalne Motorola s 68k a prave v 1985 prisiel aj MIPS, ktory bol tiez 32bitovy a zaroven vznikol aj ARM a este o rok neskor SPARC. O par rokov neskor sa objavil Power.

Ono to PC vlastne nemalo vyhrane az niekedy do druhej polovice 90. rokov, kedy Wintel vsetky ostatne platformy vyvrazdil. Ak by neprisli Windows 95ky, lebo x86 nebolo 32-bitove, Wintel by sa nekonal a situacia by dnes asi vyzerala uplne inac.

Niekto iny mohol nad x86 bastlit 32-bit. Avsak tiez by asi cakal na to, kym PC ziska trhovy podiel. A cast motivacie k trhovemu podielu PC AT bola, ze bude mat spatne kompatibilneho nastupcu, ktory bude 32-bitovy. Bez oznameneho nastupcu PC nemuselo ziskat trakciu a bez trakcie sa ina firma nemusela do vyvoja 32-bitoveho nastupcu pustit.

Zaroven, ak by boli obmedzeni spatnou kompatibilitou, asi by nic lepsie nevymysleli. Vacsina toho, co je na 386tke humus je podedena z 286tky, alebo vznikla kvoli zachovaniu spatnej kompatibility.

386SX to nebola taká tá 286-ka lenže s 386 procesorom? S benefitmi/nevý­hodami oboch?

(Aby sme nevyzerali ako takí buržuji, boli to pracovné počítače, mama bola freelancerka, tak na tom pracovala. Tá 486-ka mi slúžila ešte do roku 2004 a bola na to, aby som nemusel tráviť čas v školskom labáku, fakt veľmi lacno som ju kúpil.)

7. 10. 2025, 17:47 editováno autorem komentáře

Ne, nebyla, bylo to 386, akorát na rozdíl od 386 měla jen 24bit adresní sběrnici, tak uměla adresovat jen 16MB (v té době to bylo víceméně jedno, protože paměti byly za ranec, nejvíc jsem v tom viděl jen 8MB tehdy), na rozdíl od 386, která měla plnou 32bitovou adresní sběrnici a uměla tedy 4GB - na což ale stejně nebyly paměťové moduly. Navíc chvilku na to, aspoň tady u nás, přišly 486, nejdřív z VLBus a pak PCI sběrnicemi a to bylo už úplně jiný kafe...

Ja som bol v tom, že 386SX malo 16 bit zbernicu kvôli kompatibilite s PC/AT tak nič, asi si to zle pamätám.

Nemôžem už upravovať, ale dobre som to napísal, rovnaké parametre mala platforma PC/AT práve založená na procesore 286. 386SX slúžilo ako náhrada 286 procesora v PC/AT. Tj sa využila stará architektúra s novým procesorom. PC/AT malo tiež 16 bit ISA a 24 bit adresnú.

Ale nebolo to také jednoduché, že len swapnúť procesor, pätica bola iná. Bolo treba novú dosku s patričnou päticou. Aj keď boli na to nejaké hacky/adaptéry, ako pozerám.

Samozrejme, že sa to nepropagovalo ako PC/AT, kde zmenili 286 za 386 kvôli marketingu.

9. 10. 2025, 01:09 editováno autorem komentáře

V 16bit programech totiž 386 nebyla rychlejší než 286. A první 386 byly pro 32bit programy zabugované.

Ještě upřesním: První 386 byly zabugované pro 32bit OS. Ale když běží jen jedna aplikace (a DOS), tak ta může mít workaroundy. Gates původně chtěl, aby na nich běžel Windows 95, takže část workaroundů v jejich kódu je. Nakonec to ale vzdali. Nicméně Doom a další hry vesele využívaly např DOS4GW Protected Mode.

Mas k tomu bugu vic info? Ja jen, ze jsem videl bezet Linux (nejakou 1.x a potom i 2.x) na 386DX a zdalo se to byt mega stabilni. Padala jen Xka kvuli driverum, ale jadro samotne drzelo (4MB RAM jestli si pamatuju dobre, mozna i 8MB, ted nevim).

Těch bugů bylo víc, ale ten nejznámější, podle kterého se i vypálilo označení na Intelem otestovaných kusech, je tento:
https://retrocomputing.stackexchange.com/questions/17803/intel-386-multiply-bug

EDIT: Ty samozřejmě můžeš do kódu dát workaroundy. Např. jak aplikace měly workaround pro Pentium FDIV bug posunutím operandů mimo pásmo, kde se použila ručně vložená tabulka výsledků.

EDIT2:
"If you buy an 80386 machine, card, or chip, make sure you get the B1 revision of the chip or something newer (B2, B3, and so on). There are far too many bugs in the A1 and A2 versions of the chip to be acceptable."
https://www.pcjs.org/blog/2015/02/23/

EDIT 3:
K nám do Česka se dostaly novější modely procesorů se zpožděním, takže cenově dostupné 386 byly už o mnoho let novější a bez chyb.

8. 10. 2025, 16:28 editováno autorem komentáře

Např. já jsem provozoval Slackware na 386DX@40 MHz se 4 MB RAM, jádro 1.2.x a na tom X s TWM - obojí bez problémů. Oproti tomu Windows 95 se na tom samém počítači kously aspoň 2x denně.

Chápem, že tie 32 bit programy sa samé nenapísali a za ich existenciu vďačíme 386 (teda aj). Ale z používateľského hladiska to bola väčšinou taká trochu lepšia 286-ka :)

8-bit guy na youtube má taký seriál, kde si nalepí bradu a trošku si pustí fantáziu na špacír, že aká by mohla byť nejaká platforma, kebyže sa naplno využije ... 386-ka by asi dokázala zaujímavé veci so 4GB RAM a tak ďalej...

Jinak aby to nevyznělo jako nekritická chvála na Intel. Já vlastně moc Inteláckých CPU neměl. Pokud si vzpomínám (když vynechám SoC a MCU):

- MOS 6502 (Atari)
- 80286 od AMD
- 80486 tentokrát od IBM (Blue Lightning, dneska asi docela rarita)
- Celeron od Intelu - jedinej CPU, co mi kdy shořel (když odešel větráček)
- Darovanej Duron (ten dostal hodně zabrat přetaktováním a úpravou napájení, ale asi jede dodnes)
- Intel Atom (tak tento CPU se úplně nepovedl)
- Pentium D co dlouhá léta běželo jako server :)

Potom už jen firemní notebooky, tam jsou to i3-i7. A ostatní mají doma AMD (všechno Epycy)

Co se týká těch Atomů, první generace nebyly úplně dotažené. Ale dnes z nich Intel poměrně těží. Dnešní levná Pentia a Celerony i všechna E-jádra vycházejí právě z nich.

tak se schálně naivně zeptám - a to se ještě někam montuje? Všude okolo sebe vidím Intel Core (nebo něco serverového).

To jsou ty procesory Intel N95, N100, N150, kterých je plný Alík?

Atomy jsou označovány jako x72...E a x74....E. N-ka dneska Intel označuje jako "Intel Processor", takže to znamená ... nic. Jako ano, je to levné, ale má to jen několik E jader (žádná P jádra), takže to neutáhne ani video :)

Vždyť to píši: E-jádra od Intelu jsou technologickými následníky těch Atomů. Takže ano, máte je ve většině strojů, která mají nějaká E-jádra a kromě toho navíc v kdečem, kde je nějaký levný současný "Celeron" nebo "Pentium" nebo jak Intel low-end označuje dnes. Nevím, jestli jsou aktuálně v prodeji ale ještě nedávno byly. Čili jestli všude okolo sebe vidíte na desktopech alespoň trochu aktuální Intel Core, vidíte v každém dost pravděpodobně i několik (kdysi) Atomů. Pochopitelně v podstatně modernější a výkonnější podobě.

A co se výkonu týká, minimálně v mém stroji je jedno E-jádro výkonné zhruba stejně, jako jedno jádro deset let staré i7. Což tedy video utáhne naprosto v pohodě. Minimálně natolik, aby to s bohatou rezervou stačilo na to, co pouštíme my.

7. 10. 2025, 18:59 editováno autorem komentáře

Duron byl od AMD, ne od intelu...

však jo - píšu, že jsem tolik Inteláckých CPU neměl. Zatím je většina v sekci "non x86" nebo second sourcing od AMD nebo IBM.

Což mi po mnoha a mnoha letech připomnělo, že jsem měl kdysi Cyrix 6x86. Díky za promakaný a čtivý článek, nostalgie z něj úplně teče. Ty doby, kdy jsem na Z80 zkoušel disassemblovat hry a poprvé se mi povedlo přepsáním toho správného DECu udělat nesmrtelnost :-)

Ten IBM 486 byl jen přeznačený Cyrix, ne?

Pro zájemce na doplnění (jestli dobře koukám, ještě to nezaznělo) jedno dobové video mj. s Patem Gelsingerem: https://www.youtube.com/watch?v=LQcLhBZY12g ...

Super, daval som hore odkaz na textovy prepis, ale pozret si video moze byt rychlejsie.

(zaujimave je, ze Gelsingera som v prepise nezachytil)

Blbec som, toto je uplne ine video.

Trošku OT: Pat Gelsinger je podepsanej na každé originální 386: https://www.tomshardware.com/pc-components/cpus/pat-gelsingers-initials-are-etched-into-every-386-processor-ever-made-intel-ceo-literally-made-his-mark-as-a-key-cpu-designer

` Doom a Linux ` Jak moc je ten luxusni nazev dvoj..tri .. N-smyslny?-)

Jen doplním, že existoval Windows/386. Což byla verze systému Windows 2.1. Tedy již před verzí 3.0 a NT.

On Windows 2.x a 3.x byly odděleně kernel a userspace, takže třeba Windows 3.1 spouštěl 32bit aplikace, ale API OS bylo 16bit. Díky tomu např. mohl spouštět programy v RAM nad 1 MB a Win32s programy nebyly alokací omezené na 64kB bloky paměti.

7. 10. 2025, 15:45 editováno autorem komentáře

IQ 151 měl jsem ten skvost doma. Nebyla skříň bakelitová a ne plechová? Ano ty žebrované chladiče topily hodně slušně. Tlačítko Reset mě mnohokrát přivedlo na pokraj šílenství, když zničilo moji několikahodinovou práci, jednou jsem vypěnil, stroj rozebral, a tlačítko ve svěráku uřízl a zkrátil, že nevystupovalo nad úroveň klávesnice, prostě se muselo zamáčknout malíčkem a byl klid.

A pritom stale existuji, mozna trosku exoticke protoze jsou site na miru sitovemu bootu, udrzovane linuxove distribuce pro toto CPU.

Napriklad:
https://github.com/marmolak/gray386linux