Pekny.
Ale je vhodne doplnit, ze dnesni X86_64 jsou sice HW kompatibilni az kdesi k 8086, ale pokud je budete chtit v tomto modu pouzivat, dostanete neco s vykonem 386DX.
Zkracene, nekde v rohu dole na cipu sedi stary 386, v realu se jede na uplne novych a nekompatibilnich strevech, co s tim puvodnim 40 let starym navrhem nema moc spolecnyho.
"dnesni X86_64 jsou sice HW kompatibilni az kdesi k 8086, ale pokud je budete chtit v tomto modu pouzivat, dostanete neco s vykonem 386DX."
Z ceho vychazite ? Mel jsem za to, moderni procesory umi naprostou vetsinu tech 16bit veci bez jakekoliv penalizace*, jako kdybych pouzil prislusne prefixy pro "ekvivalentni" instrukci v 64bit modu.
"nekde v rohu dole na cipu sedi stary 386" - to same, vzdyt ty 32bit instrukce jedou uplne stejnou cestou jako 64bit, stejne jako kdyz oprefixuju neco v longmode.
nebo ... ?
--
* nepocitam segmentaci realmodu
Ta adresace 1MB je IMHO jediné omezení. Výkonově to může být i lepší než protected režim, protože odpadne kontrola v tabulce deskriptorů. jinak real mode je fakt o adresaci (a defaultní velikosti operandu), protože například je stále možné používat plné 32bitové registry atd.
* adresaci řeší unreal mode
Jasne, takhle to chapu taky, ale pak neplati "nekde v rohu dole na cipu sedi stary 386"
Spis to je ze se realne pouziva treba 1/50 plochy CPU, zbytek logiky je nevyuzit.
Celkem se divim, ze x64 procesory nenavrhli tak, aby tam v budoucnu byla moznost odriznout ty backward compatible veci (a resit je softwarove, treba neco na zpusob SMM, nebo jak ma MIPS handler pro unaligned load/store).