Ahoj. Super článek. Na mě hodně složitý, protože jsem chyběl u základů programování a assembler, fortran - či jiné jim podobné - jazyky jsem úplně přeskočil.
Tento příspěvek do diskuze se ale netýká úplně tohoto konkrétního článku. Tak jako já jsem nebyl u assembleru, spousta z nás i mnohem dříve narozených než já (77 - můj první počítač byl 286 kterou jsem pořizoval v době, kdy ostatní už pomalu přecházeli na pentia a zbavovali se 486), nebyla u zrodu počítačů, u děrných pásek a elektronkových sálových počítačů.
A vůbec nikdo z nás asi nebyl s Turringem, když louskal enigmu a sestrojoval jeden z prvních počítačů.
Chtěl jsem se zeptat, zda by jste byl schopný a ochotný někdy napsat článek o tom, jak vlastně funguje počítač. Protože "ovládat" jej umíme všichni. Někteří umí vytvořít neuvěřitelně komplikovaný word, jiní excel, někteří vyrobí fantastickou hru (klidně i low level programováním mimo frameworky) a jiní složí fantastickou hudbu nebo sestříhají skvělý film. A nebo samozřejmě naprogramuje fantastický kus SW.
Téměř nikdo už dnes ale podle mě netuší / nechápe jak fungje nitro počítače, Jaké jsou jeho naprosto základní komponenty bez kterých by to nešlo a jaký mají konkrétní účel.
Zajímalo by mě zda by byl někdo schopný nějak elegantně a relativně srozumitelně převést Turringův myšlenkový koncept na základě kterého pak vznikaly samostné první počítače do prezentace.
Je jasné že počítač vychází z instrukcí, čtecí hlavy, vstupů a výstupů. Co se ale v dnešních počítačích opravdu děje, jak moc jsou si podobné nebo naopak zcela rozdílné oproti původnímu konceptu? To já osobně nemám naprosto žádné tušení.
Tak pocitace opravdu nefunguji jako Turinguv stroj.
Zacnete u von Neumann-a, to je zaklad vetsiny velkych pocitacu, zatimco Harvardska architektura je videt v nekterych mikrokontrolerech.
https://cs.wikipedia.org/wiki/Von_Neumannova_architektura
https://cs.wikipedia.org/wiki/Harvardsk%C3%A1_architektura
Ale pokud nejste schopen si najit a dostudovat pak zbytek - co je mezi odkazem a tim co mate na stole .. sebelepsi clanek vam to nevysvetli bohuzel. Informaci na tohle tema je vice nez dost.
Dobrý den,
kdysi mi tady vyšel seriál https://www.root.cz/clanky/jak-pracuje-pocitac/ . Možná by prvních pár dílů mohlo pomoci. Je tam vysvětlen mikrořadič, ALU, jak zhruba pracují strojové instrukce, ale zase ne moc do hloubky. Kdyžtak mi prosím dejte zpětnou vazbu, můžu to rozšířit.
Základní principy, na kterých je založená činnost elektronických počítačů, jsou popsané na mnoha místech. Sám jsem v osmdesátých letech začínal s knihou Od logických obvodů k mikroprocesorům, Jean-Michel Bernard , Jean Hugon.
Série článků Co se děje v počítači https://www.root.cz/serialy/co-se-deje-v-pocitaci/ od pana Tišnovského také přináší nabízí základy a pak jde dále. Ale nemá smysl chtít nějaký jeden krátký článek s instantní předvařenou znalostí. Takto to nechodí a pokud je dotaz míněný takto, tak spíš nemá smysl ani dopovídat.
Jinak Architektury počítačů (Computer Architectures nebo Computational Structures) jsou základem, který by každý programátor měl znát, pokud jeho výsledky mají alespoň trochu rozumně využít potenciál dané platformy nebo je jsou nějaké požadavky na na spotřebu a čas. A na všech světově relevantních univerzitách se pro obory computer science a electrical engineering učí.
Pro obor Otevřená Informatika na ČVUT FEL jsme pak připravili základní kurz takto
https://cw.fel.cvut.cz/wiki/courses/b35apo/start
Jsou zde jak záznamy přednášek, tak i možnost si vše procvičit a to i online, pokud nechcete simulátor instalovat pro Linux, Win nebo MAC
a je možné mít i ke cvičení zpětnou vazbu
https://comparch.edu.cvut.cz/online-tools/webeval/
Kurz končí tak znalostmi odpovídajícími state of the art v CS z roku 1985 (vznik RISC->SPARC, MIPS na světových univerzitách). Pokud pak chcete pokročit v technikách dále, tak základy využijete i při studiu našeho předmětu Pokročilých (pokročilejších) architektur počítačů
https://cw.fel.cvut.cz/wiki/courses/b4m35pap/start
V rámci něho si každý student navrhuje i vlastní procesor. Předávané znalosti odpovídají tak tomu, kde byl vývoj špičky v oblasti CPU tak v půli devadesátých let.
Pak ty základy, bez kterých to nejde, můžete využít při čtení aktuálních recenzí a popisů, pro x86 třeba na
I když tento server se zdá mít zrovna problém. Pro trochu profi programování na x86 pak mohu doporučit
https://www.agner.org/optimize/
Ale pokud nebudete ochotný investovat do těch základů, tak je to čtení ztráta času.
Skvělé knihy v češtině, jdoucí od úplných základů až ke stavbě vlastních osmibitových počítačů, jsou od pana Malého v edici knihy NIC.CZ:
- M. Malý: Hradla, volty, jednočipy
- M. Malý: Porty, bajty, osmibity
A v případě zájmu pak lze pokračovat různými směry dál: konstrukce s ESP32, vlastní procesory na programovatelném poli atp.
Mimochodem, co jsem tak zběžně kouknul, tak ty úplně základní principy jsou podobné těm ukazovaným ve videích Bena Eatera (ono to asi nejde jinak). Ale v knize je "mnohem víc času" to pochopit než ve videu, včetně příkladů, obrázků, provokativních otázek apod. :) Tak by to mohla být pro mnohé také dobrá alternativa.
8. 1. 2025, 22:17 editováno autorem komentáře
Tak zrovna tenhle dil me pripomina prednasky na FIT VUT z pred 20+ let, kdy jsem to hltal, byt to bylo uz tenkrat trocha retro - diky za milou vzpominku na tyhle hezci veci z vejsky! :)
Ohledne te drasticke rozdilnosti 86 / 286 / 386 - to se mohlo udelat jen tenkrat - kdy vyrobce jeste mel primy feedback z trhu na sve produkty a dokazali tedy udelat VM86 rezim. Dnes se bohuzel superskalarne chrli jeden nedodelek za druhym a k nejake relevantni korekci uz nedoslo od doby netburst/core zlomu. Je paradoxni, ze az dnes mame reseni (napr. OSS a cele systemy jako Gentoo), kterym by vubec nevadila zmena ktera nezachovava zpetnou kompatibilitu.. ale vsichni tu kompatibilitu bohuzel drzi na hw urovni :D
Super článek!
Ten i80376 mohl být super nástupce (bootuje rovnou do chráněnýho módu). Bohužel podle wikipedie to vypadá, že zároveň s eliminací reálnýho módu odstranili i stránkování *facepalm* (a člověk si pak říká zda to nebyly jenom přeznačený zmetky z výroby :-D ).
BTW CPUID začlo už na 486 i když technicky to byl asi backport z pentia na další generaci 486 (on i writeback se do 486 přidával až okolo pentia). Jinak mód SMM se podle wikipedie objevil už na 386 (nějaká laptopová verze). I když je fakt, že to je vlastnost spíš pro BIOS.
Tak v x86_64 režimu, tedy v tom pročištění architektury a rozšířením na 64-bitů, se kterým přišlo AMD, když tušili že licenci na Itanium nedostanou , tak jsou režimy jen dva a žádné nesmysly se selektory/segmenty. Vše se řeší přes stránkování, user a system mode a pár specializovaných registrů. Segmenty FS GS se zachovaly jako ofsetová adresace pro thread local storage. Ale jinak je to vyčištěné.
Na rozumných architekturách, jako m68k, nikdy taková zvěrstva nebyla a vývojáři v IBM museli hodně brečet, když měli PC naplánované na m68k a pak jim vedení přikázalo kvůli dohodě o licencích s Intelem jít do pravěku na 8088. Pak všechny podtrhl Microsoft s tím, že neudělal DOS pro 386 a tak se tisíckrát více něž bys tálo přepsání té FAT FS knihovny (nazývané DOS) v mnoha firmách nainvestovalo do DPMI a pak i Microsoft, když uznal 386 musel řešit na stále 16-bit Windows 3.x systém VxD aby těch několik paralelně spuštěných DOS, vlastně spíš bare metal, aplikací mohl přepínat.
Když ty články čtu, tak se mi z toho promrhání potenciálu a prostředků mnoha o řád technicky schopnějších firem než byl Microsoft zase dělá špatně.
Je pro info, v roce 1987 a 88 jsem pracoval s malým Unixem s m68k a stránkováním, byl to embargovaný vývojový systém Philips PMDS-85 na vývoj a HW ladění od 8080 až po m68k vlastní návrhy...
Zpět k x86, i v těch 64-bitech zůstává hrůza SMM a tak často BIOS dělá motheboardy nepoužitelné pro RT nasazení. Později pak přibyl Virtual monitor, často značený ring -1 pro HW virtualizaci.
Ale doufám, že ta x86 hrůza již postupně přestane strašit.
Když třeba na Alze u notebooků nastavím procesor na Apple Silicon (733), MediaTek (5), Qualcomm (114) tak nabídka již začíná být zajímavá a za pár let to třeba dožene i RISC-V a na x86 si již nikdo kromě sběratelů nevzpomene. Intelu bych přál ať přežije, ale doporučuji, ať sám architekturu již nikdy nevymýšlí. I když před lety nějakým omylem vymysleli 8x196 to snad nezkazili a létá v letadlech bezpečně dodnes. 8008 a 8080 by se také daly vzhledem k době odpustit. Sami věděli, jaká je x86 katastrofa, ale i432, 860 i Itanium vedené snahou to změnit byly ještě horší. A opět se hromada lidí kvůli šílené architektuře x86 učí jak s ní žít. Advanced Performance Extensions s REX2 je další berle místo vymetení smetí.
Na druhou stranu obdivuji, jak dobré měají v Intelu a AMD implmentátory, kteří s tou hrůzou dokázali být desetiletí výkonově kokurenceschopní a někdy i na špici, po tom co většina lepších alternativ obchodně nevyšla. Ale teď je spotřeba na laptopech vyřazuje, na mobilech byl poslední záchvěv před u Intelu tak 10 lety.
U intelu me spis vadi, ze tlaci nesmysly proti vuli uzivatelum a co nezapada do jejich linek, tak vas poslou do haje.
Projekty ktere jsme nerealizovali, protoze to Intel nechtel dat:
- software defined camera - uplne nas vyghostovali Broadwell CPU ktere meli eDRAM L4 cache .. vznikli 2 modely a cache nebyla riditelna - asi ukojeni investoru jako s prvnima 10nm o dekadu pozdeji. Navic OpenCL nikdy intel nedodelal do pouzitelneho a free stavu u svych iGPU.
- thunderbolt 2,3,4 - ne, nemuzete udelat reusable modul, muzeme vam schvalit pouze end user produkt a musite jich prodat miliony... asi ne jako, kdyz je ten produkt high end jako zlaceny opticky kabel
- movidius DSP - sice to je genericky DSP a lze to volne programovat, tak Intelova predstava byla to bundlovat s firmwarem ktery je "hw akcelerator pro AI", tj je to omezeno na inferenci (data vuci modelu), ktery dodate ovladaci mezivrstve. Ale kdyz ja chci delat kompresni kodeky, tak jako ne. Vemte milion na AI a pak vam mozna dame SDK.. wtf. Blbci.
- intel quark x1000 - je to x86 pentium soc, obdoba dnesniho RPico MCU. Ale koupit to slo jen jako demo devkit s cilem konkurovat Ardiumu ... a pak to taky zarizli kdyz to nenaplnilo ocekavani. Ale dovolit jinym udelat neco lepsiho - ani nahodou.
V podstate je dnes temer nemozne udelat revolucni produkt, protoze si vyrobci vsech soucastek narokuji se drzet strikne jejich vytvorenych koleji.. se nas asi boji, mekkousi :D
A tyka se to i obyc komponent.. treba vicefazove VRM jako mate na kazde druhe grafice pro stovky amper.. neni sance sehnat. Vsichni cekaj ze to pujde do spotrebky nebo superpocitaci v milionovem mnozstvi. Meh.
Souhlas. Zase na druhou stranu, Intel se snažil prosazovat další architektury. Intel 432 (no to nebyla sláva), Intel 860, 960, Xscale (ok, to bylo v rámci license s ARMem AFAIK).
Ale svět chtěl Wintel platformu :(, tak prostě investovali do tohoto segmentu. On i Microsoft se chytil do stejné pasti, a těžko říct, jak z ní vycouvá (ale je v lepší pozici než Intel).
No a potom Intel začal jednat z pozice síly - tlačení nových slotů/socketů ne kvůli tomu, že by to bylo technicky lepší, atd. V té době se ukázala síla trhu, kde je rozumná konkurence (Athlon a vlastně i Duron).
8. 1. 2025, 10:00 editováno autorem komentáře
Microsoft teď hodně maká na ARMu, aby měl záložní architekturu a s těmi zkušenostmi pak mohl přidat i další, podle potřeby. Servery už standardizoval, jako předtím zvládl PC, např. UEFI BIOS a inicializační kód PCIe karet bajtkód vykonávaný tím UEFI BIOSem, takže stejná karta funguje v obou typech serverů (není potřeba flashovat BIOS jako na PowerPC Macách nebo emulovat x86 jako na Amize). Naportoval na ARM jádro Chromu (tak vznikl Edge Chromium, když se Google na portaci neměl), naportoval starý .NET (Framework) i nový (založený na Core), naportoval i Javu...
Ty ROM s inicializací na PCIe kartách by měly být vyřešené již od příchodu ACPI, od kdy karty měly mít inicializaci v bytekódu pro interpreter. S tím a formátem ELF přišel Intel, když chtěl utéct z x86 na Itanium.
I když když nyní koukám na 14.4.2 PCI Option ROMs
v Unified Extensible Firmware Interface (UEFI) Specification,
tak to zase vypadá pěkně divoce
Ten EFI Byte Code (EBC) Virtual Machine je asi jediný přenositelný, ale ten tam, podle mě měl být již od ACPI a Itania a přitom tenkrát se tomu , myslím UEFI neříkalo...
Specifikace formátu zde
https://uefi.org/specs/UEFI/2.11/22_EFI_Byte_Code_Virtual_Machine.html
Na druhou stranu obdivuji, jak dobré měají v Intelu a AMD implmentátory, kteří s tou hrůzou dokázali být desetiletí výkonově kokurenceschopní a někdy i na špici, po tom co většina lepších alternativ obchodně nevyšla.
O tomhle bych si rád přečetl něco víc do hloubky, protože kritiku x86 architektury čtu roky, ale nikdy né nějak uceleně a vlastně všechny ty informace dohromady si trochu odporují / nepodporují se.
Co mám na mysli. Třeba i od vás jsem tu četl kritiku, že maximální počet dekódovaných instrukcí (x86) za takt je cca 6 a že arm umí víc. No ok. Potom vidím přednášku (C/C++) třeba od Fedora Pikuse (Siemens), kde říká, že stejně ani v benchmarku není možné využít všechny jednotky (cca 7).
Tak fajn, vezmu si kalkulačku, vezmu konzervativní jádro s počtem integer jednotek v jádře, tedy 4 (tohle je tak rok 2002, jestli si správně pamatuju kolegu studenta na univerzitě) a počítám: 4GHz*8B*4*2 = 238GB/s per jádro. (4GHz je takt mého cpu (Ryzen 7 5800), 8B je 64b, 4 integer jednotky a dvě hodnoty na operaci). DDR4 3200MT/s dává cca 25.6GB/s. Dva kanály to máme cca 50GB/s. Takže jedno jádro moderního x86 CPU je limitováno pamětí. Těch jader máme fyzických 8, takže cca 2TB/s. Na to bychom nepotřebovali ani DDR5 ale rovnou HBM a to ještě budoucí verze. (A to ještě navíc nikam neukládám ty spočítané hodnoty.) A ano, zjednodušil jsem to na 1T operace. Kdybychom chtěli třeba dělit, tak nám i ta rychlost paměti zatím trochu stačí.
Tak zatím to x86 nahání frekvencí (na úkor spotřeby). Frekvence ale už skončila, takže je jen otázka času, kdy se rozdíl prohloubí.
Frekvence je limit pro všechny architektury stejný. Jestli mám x86_64 nebo aarch64 na 4GHz je jedno. Jestli jeden procesor někde vyloženě neplýtvá časem (a na to se vlastně ptám), tak oba budou jednak stejně rychlí ve stejných výpočtech a potom stejně narazí na rychlost pamětí / sběrnic. A zatím to vypadá tak, že tam kde naráží 8jádrový x86, tak tam je potřeba 128jádrový arm. Kde je navíc potřeba, aby se progs naučili programovat multithreading (čemuž fandím cca od roku 2006 :-D - ve skutečnosti tak 2000, protože kámoš měl dvou cpu desktop (Abit BP6)).
Ano, limit frekvence je nezávislý na CPU architektuře. Ale RISCový dekodér může dekódovat, kolik instrukcí za cykl chce (jednoduché paralelizovat, když instrukce mají stejnou délku), podobně je jednodušší zvětšovat out-of-order buffer, cache a v případě vlastních procesorů si můžete taky udělat, kolik linek RAM budete chtít. Vyšší modely Apple Silicon mají brutálně širokou sběrnici do RAM a přenosovou rychlost. Podobný princip jako SGI workstation z 90tek, co mám doma. To jen na x86 PC je málo linek do RAM.
jednoduché paralelizovat, když instrukce mají stejnou délku
Tohle přece univerzálně neplatí, ne? Už jsem viděl i přednášky (ARM), kde sice někdo napřed chválil stejnou délku instrukcí, ale ve druhé hodině si na to zase stěžoval, protože paměť má jen nějakou rychlost a ty instrukce by mohly být kratší (THUMB). Proto bych rád diskusi nechal na úrovni porovnání architektury a nikoliv toho, kdo co má jak velké, protože:
To jen na x86 PC je málo linek do RAM.
Což se dá snadno navýšit a proto třeba EPYC má 12 kanálů. Ostatně každý serverový procesor jich má tak nějak víc.
Tak sám vím, že znalosti mám také celkem omezené. Když si ale představím, jak je komplikované jen najít konce instrukcí a správně je napasovat na na dekodéry a kolik vrstev multiplexerů je k tomu potřeba, tak tam vidím hromadu zbytečných taktů v pipeline, aby se to stihlo rychle. Pokud vím, tak již dlouho si x86 udržují v instrukční cache hinty k tomu, aby opakovaně šlo nalezení hranic rychleji. Další problém jsou skoky, proto pak platí různá pravidla, že víc jak dva skoky myslím že na 16 byte vedou k úplné ztrátě predikcí. Aby to alespoň trochu šlo s granularitou na byte, tak je to udělané tak, že se do branch prediktorů indexuje bity od 4. výše. Dříve to bylo jen nějak do 12-tého bez plhodnotného tagu a pak byly ty specre a meltdown útoky. Ale aby mohly být ty dva skoky v 16-tici, tak jsou tam nějak 2x a drží ze k nim ty offsety... Dekódovat to musí být peklo. Ale již se nějak na 6 a možná i 7 dostanou. Aplí ARM v pohodě 8 a těď již u M4 snad i 9. Ale ta logika na x86 je nepoměr. Aby to mělo šanci, tak se používá branch trace cache, pokus vlastně přeložit vše u NetBurstu (Pentium 4) nevyšel, ono tam asi vzhledem k těm problémům s mapováním 1 byte až 14 byte instrukce na jednu nebo nějakou kombinaci přeložených nemohl indexováním vyjít. Trace cache má výhodu, že se přeložené cílové instrukce ukládají jako řetízek indexovaný adresu skokové instrukce. Chytá to lag v překladu po skoku, ale nejlépe to bude chodit pro krátké cykly, kdy se tam vejde vše a již se na původní instrukce nesahá vůbec.
Obecně si myslím, že ARM Aarch64 (32-bit conditional nejde) a RISC-V v té vlastní výkonné části na tom jsou mnohem lépe. Ale Intel vždy uměl float a implementace operací (f0 bug byla smůla, ale jinak je opravdu dobrý) a asi i u SSE a tak nabízí dobré věci, například shuffle s automatickým doplněním nul na záporné indexy atd...
Ale stále si smyslím, že je ten celek špatně a Alpha, PowerPC, Aarch, RISC-V by ho měly na úrovni vlastního core válcovat. jenže pak je to uncore a napojení na paměťové ringy, home directory, memory controlery atd, a tam asi opravdu Intelu a AMD umí něco navíc. Jinak když si představíme ty výpočty na propustnost, tak kontinuální protahování dat větších než je cache zahubí vše. Wikipedia uvádí DDR5 32.0–70.4 GB/s pro 64 bits šířku. Lze to navýšit 2x nebo i 3x více nezávislými kanály/řadiči, když jedou prokládaně. Jenže to je teorie, realita je, že latence je 14 ns, jsou tam možnosti otvárat různé skupiny bank naráz (třeba tažení dat do dvou vláken/jader operujících v jiné části adresního prostoru). Ale stále je to o tom dostat data do cache a udržet výpočet v ní. AMD Infinity Fabric má má bandwidth až 512 GB/s, tedy jádra, nebo spíš L2 a L1 cache ukrmí, když jsou data v někré části L3, třeba i na jiném socketu.
Na druhou stranu Nvidia NV Link má až 1.8TB/s a HBM 4 až 1.6TB/s. Ale stále to ty 4 ALU nebo třeba i SVE s šířkou 512 bitů (64 byte) na 3 GHz neukrmí... Takže je opravdu potřeba dostat výpočty do L1 cache, která často umí v jednom taktu třeba i šest přístupů. Ale ono se tan objeví lagy/bubliny na skocích a pak ty obrovské, když se musí do vnější paměti... To se pak částečně kryje hyperhreadingem když již i ten data flow limit (out of order limit) okolo 600 instrukcí nenajde nic, co by mohl řešit když se nějaká instrukce blokuje...
h diskutovat s
Určitě by bylo zajímavé o těchto věcech diskutovat s těmi, co to přímo pro Intel, AMD a další navrhují, ale asi tam bude dost NDA.
V rámci předmětu B4M35PAP nyní jeden student podle mnou odpřednášených a přežvýkanách principů třeba z knihy Shen, J.P., and Lipasti, M.H.: Modern Processor Design : Fundamentals of Superscalar Processors, First Edition, New York, McGraw-Hill Inc., 2004 , zkouší navrhnou 4 wide out of order se dvěma ALU, jednou jednotkou skoků a jednou na paměť. Tak nad tím debatujeme a již toto vede na hromadu komplikací. V zásadě je potřeba řídicí část rezervačních stanic a další věci jet minimálně o cyklus dříve, než vlastní přepínání a forwarding dat. A v reálu se to jede asi spíš o dva takty dříve, aby pipelining v rozhodovacích cestách umožnil na plné frekvenci naplánovat dopředu pipelining, reorder, register rename a forwarding v datových cestách. I když ty muliplexery v datových cestách jsou také děsivé, několikrát třeba i stovka bitů třeba z osmi zdrojů... Ale ta řídicí část potřebuje zatřiďovací prioritní fronty atd... Když se to udělá jednoduše, tak se pak předběhne s instrukcí, která není potřeba a naopak tak, která blokuje další se dostane pozdě a tím se zahltí dispatch a decode a je to pomalejší než in order jednoduchá pipeline...
Je to celkem zajímavé a v zásadě asi i ta nejlepší reálná řešení jsou jen aproximace a kompromis, aby se ta řídící část nakonec nebyla tak složitá, že poběží na 1 MHz nebo bude desítky cyklů prohledávat, co dělat dále.
Tak to jsou nějaké z rukávu sypané úvahy. V jednodušší formě bez toho obrazu ve velkém, jen po částech a základních principech to pak máme v těch odkazovaných přednáškách z B4M35PAP.
Nedávno jsem celkem zajímavě zpracované úvahy o těch reorder bufferech a jak na architectural state a rename a dalších našel v kurzu Australian National Univerzity
https://comp.anu.edu.au/courses/comp3710-uarch/
https://comp.anu.edu.au/courses/comp3710-uarch/lectures/
Jsou tam zajímavé úvahy.
Ono to tak v principu funguje. OS jenom rozlišuje, na kterém ring běží (0 - OS, 3 - userspace). Segment registry jsou prakticky jenom dva - CS a DS, bo CS může být pouze read|exec, zatímco DS může být read|write, pokud mě paměť neklame. Ale oba dva mají stejné mapování na lineární paměť, která je poté mapovaná na fyzickou paměť. Nejsem si teď jistý, zda OS a userspace mají jiný pár CS a DS. DS == ES == SS. FS se používá na některých OS k implementaci thread-local variables, ale ty se dají alternativně spočítat i ze ESP (zarovnat nahoru, kde je uložena struktura informací o threadu, obsahující i tabulku thread-local variables).
Takže ty segmenty OS využívá jenom proto, že musí z hlediska architektury. Kdyby je Intel v době 386 zcela zahodil a použil jenom MSW a CR0, fungovalo by to úplně stejně.
Ono to dnes vzásadě tak je
Nicméně stránkovací jednotka v real režimu moc dobře nefungovala. Ono označení "protected" je prostě označení pro zpětně nekompatibilní režim z původním x86.
Celá ta šaškárna je dána i tím, jak fungoval trh tehdy. Portace aplikací v zásadě nebyla běžná, a byla drahá (viz portace her). Dnes se často neřeší, co je tam za procesor, když už to není naprogramované ve vyšším jazyce tak i C se dá dobře portovat a nová verze CPU tak nemusí být zpětně kompatibilní.
Už je to dlouho, ale pokud si dobře vzpomínám, je tam i nějaký "present" flag a při pokusu o čtení ze segmentu, který není "present" se vyvolá výjimka. IIRC v takové té knížce od Grady byla zmínka, že to mělo sloužit právě k tomuto účelu. Těch technických problémů je samozřejmě víc, segmenty mohou být různě velké, mohou se překrývat atd. Právě proto se to v praxi implementovalo až na 386 přes stránkování - a proto si asi většina myslí, že to bez stránkování ani nejde.
Present flag se právě používal na demand-load, kdy se segment načetl z disku, až se na něj poprvé sáhlo.
Běžně se používal discardable segment na kód, který se použil jen jednou při inicializaci a pak už nebyl nikdy potřeba, nebo na read-only data na jedno použití jako jsou relokace.
Segmenty měly jen accessed flag, ale neměly dirty flag, swapování zapisovatelných segmentů bylo neefektivní.
Když budu hnidopich, tak informace v článku "Není ostatně bez zajímavosti, že následník čipu 80386, tedy mikroprocesory 80486, sice byly rychlejší a měly integrovanou cache (popř. i matematický koprocesor, pokud se jednalo o variantu DX)" není úplně pravdivá. O CPU sx 487 tady asi málo kdo slyšel :-)...
Jinak dík za článek.
IMHO Intel mohl vybruslit že zajetí kompatibility novou čistou architekturou x64 CPU, případně i nějakou lepší architekturou a s přídavnou kartou "PC on chip" a případná emulace starých programů by probíhala na přídavné kartě se sdílenou pamětí.
No, nejsmutnější bylo to, že 486SX byly vlastně taky plnohodnotné 486DX, jen s uměle odstaveným koprocesorem. Ale to bychom mohli jít zpátky až k panu Sinclairovi a jeho "32Kb" pamětem (a možná ještě dál).
Dneska by se to nejspíš řešilo nějakým updatem firmware, který by po zaplacení povolil tu původně vypnutou část. Ostatně to takhle prý dělá i IBM u S/390.
A byl to Intel? Mám zažito, že 386DX ve 40 MHZ to bylo vlastně am386DX-40, protože Intel měl jen 33?
Nebyl, Intel opravdu u 386 skončil na 33 Mhz, ten můj byl od AMD. Vlastně jediný procesor od Intelu, který jsem kdy měl ve svém počítači, byl mnohem později nějaký Atom v netbooku. Teď je ještě Intel ve služebním notebooku, ale tam byl výběr dost omezený.
Měl jsem vždycky za to, že když se na čipu při výrobě nepovedla koprocesorová část, tak se zablokovala a čip se prodal jako 486SX. A podobným způsobem se to upravilo na koprocesor, když byla chyba v "základním" procesoru. (Ale nepamatuji se, že bych někdy viděl desku pro 486 která by měla druhý slot pro koprocesor.)
Nebo jak to tedy bylo?
Ta zakladovka vypada treba nejak takto http://www.amoretro.de/wp-content/uploads/2011/12/unknown_ASI_486_ISA_motherboard.jpg nebo takto https://www.retropcstore.com/wp-content/uploads/2020/04/181633101846_4-1536x1020.jpg
Ale nektere desky mely socket pro koprocesory Weitek, to je neco jineho (i kdyz taky FPU).
A Overdrive je taky neco jineho, k tomu se jeste dostanu.
V tom případě mi to nedává moc smysl. Proč osazovat koprocesor 487, když můžu osadit rovnou plnohodnotnou 486DX (a původní 486SX prodat)? Ale koukám na to dnešním pohledem. Otázka je jak to bylo v roce 1990. Možná, že i autoři od Intelu to všechno zamýšleli původně jinak.
Co se týká těch desek, tak budou asi z nějaké první generace desek pro 486. Soudím dle pamění SIMM30, pozdější pak už měly SIMM72. VL-BUS vznikl o něco později než 486 (dle wikipedie: 486 1989, VLBUS-1992) . Takže možná to mohlo být naopak, a ty desky byly v roce 1992 "nadupané" verze. O rok později je převálcovaly desky s VL-BUS. No a v roce 195 se už nabízely desky pro 486 (ale spíš DX4) se zběrnicí PCI. Tenkrát jsem dal kvůli ceně přednost ještě VL-BUS.
hmm asi cenova politika, kdy si nekdo koupil jen 486SX bez FPU a pozdeji bylo levnejsi jen dokoupit 487SX (kdovi kolik by dostal za jetou 486SX). Ale popravde to moc nepamauju, ja jel 486DX.
A bylo to s VL-Busem, protoze ten dokazal byt teoreticky rychlejsi, nez PCI, ale dulezitejsi bylo, ze tady byly starsi karty pro VL Bus, kdezto PCI karty byly o dost drazsi.
Ono je otázka komu by jste chtěl tu 486SX prodat. Většina SX byla 25 nebo 33 MHz verze, tedy reálně ty nejpomalejší 486ky. Takže prodat to jako upgrade někomu nedávalo smysl. Dotyčný by si musel koupit i základní desku, takže by si k tomu koupil i aktuální procesor. Navíc tu 487 by jste si nekoupovali asi hned po koupi SX (to by jste si koupili rovnou DX), takže o ten rok, dva, tři později byla ta SX verze relativně ještě pomalejší.
Z dnešního pohledu to jako by jste chtěl někomu prodat v roce 2018-2020 Ryzen
3 1200 - tedy nejpomalejší model co se vyráběl. Asi by jste kupce také hledal obtížně.