Názory k článku Od reálného režimu k režimu chráněnému na procesorech 80286 a 80386 (2.část)

jenom technicka otazka - ty zdrojaky jsou v nasm a cross-buildovatelne na linuxu, nebo je to nejaky DOS-ovskej assembler? Si matne vybavuji ze to melo nekompatibilni / prohozenou syntaxi..

Je to psané v NASM a překládat je to možné jak v DOSu, tak i - jak píšeš - v Linuxu. Stačí použít přepínač -bin, takže výsledkem jsou "flat" soubory. A COM soubory jsou "flat", pouze kód začíná na 0x100 (to zařizuje direktiva ORG).

GNU assembler používal AT&T syntaxi, zdroj a cíl prohozen.
Cross-build byl jen výběr výstupního formátu binárky u linkeru.

jen dodám, že moderní GNU assembler (GAS) už umí i Intel syntaxi; někdy se to může hodit:


.intel_syntax noprefix


To je otázka, co je "správně" a co "prohozené". Když jsem se s intelí syntaxí setkal poprvé (ještě na 8080), připadalo mi to pořadí divné a nechápal jsem, proč to udělali "obráceně". Když jsem se pak později začal (už spíš u disassembleru než assembleru) setkávat s AT&T zápisem, připadal mi "obráceně" ten, protože už jsem byl zvyklý na Intel. No a dnes už mi zase "obráceně" připadá Intel.

Na druhou stranu, adresace typu 0x1(%rbp,%rsi,8) působí podivně pořád, i když už s jejich čtením většinou problém nemám. :-)

clovek si precte tento clanek a pak se jen divi, ze intel zariznul snahu na zjednoduseni procesoru a rezimu x64.

Zjednodusovat se nebude - je to prece x86. Pokud neco, tak by mohli pridat dalsi bit ci rovnou dva, k executable strankam, ktere budou napovidat, ze tam ulozeny kod neni ci je zarovnan na hranici 4 / 8 / 16 bajtu (a vypadovan treba NOPy, pro zpetnou kompatibilitu). Pak si muze ID vzit tento hint a dekodovat paralelne kolik instrukci chce, protoze budou "fixni" velikosti a nemusi hledet na vocasni bajty - ty jsou ignorovany (maj byt nop).

koukam ze zarovnani dost hraje roli uz ted, kvuli uop cache

https://www.bazhenov.me/posts/2024-02-performance-roulette/
https://www.youtube.com/watch?v=IX16gcX4vDQ

Můj první PC procesor naštěstí byla až 386, takže když jsem se pak začal učit assembler, působila na mne 286 spíš jako taková slepá ulička, kde si Intel vyzkoušel všechny chyby, aby to pak na 386 udělal už pořádně. :-)

Jj, já měl stejný pocit. Měl jsem to lepší (nebo naopak horší?) tím, že jsem napřed měl 286 a potom až 486. A 386 představovala IMHO asi největší skok ve vývoji celé platformy, potom to byl až nástup SSE a následně x86-64.

Mozna jsi chtel rict "... kde si intel vyzkousel vsechny chyby, aby JE pak na 386 udelal poradne" :-)

Když přepnu do unreal režimu (real režim s nastavenými segment-limity na max), zůstanou tam i po tom, co změním hodnotu segmentového registru, nebo se to vrátí do 8086 módu adresace?

Tedy v unreal režimu, změna segmentu znamená pouze změnu báze, nebo přepsání všech skrytých částí podle realného režimu?

IIRC by se mělo aktualizovat všechno, právě proto se jako jeden z kroků po přechodu do/z real modu nastaví všechny segmentové registry, aby fungovaly správně podle toho nového režimu. Ten termín unreal mode je tak trochu zavádějící, ve skutečnosti to není samostatný mód, je to normální real mode, jen se vynechá tenhle jeden krok "čištění". A myšlenka je právě ta, že když jsou všechny segmenty přes celý adresní prostor, můžu na segmentaci zapomenout a se segmentovými registry není potřeba vůbec hýbat.

No v ofiko postupu pro přepínání do reálného režimu se naplnění segmentů muselo udělat ještě v PE, včetně dlouhého skoku pro nastavení CS. Pak se teprve nuloval PE

Změna segment registru v reálném režimu nemá vliv na limity segmentu. Jinak by ten unreal režim vydržel jen do prvního interruptu.
Výhoda unrealu byla právě kompatibilita s realem.
Normálně šlo používat služby DOSu i BIOSu bez konverze adres.

limity zůstanou. ono takto (asi) fungovaly některé ovladače paměti, že vlastně přepnuly do nereálného režimu, ale v ostatních věcech se to tváří jako běžnej reálnej režim pro aplikace psané pro reálnej režim. Tedy dokud někdo ten limit nepřekročí, protože to najednou "půjde". Už si to nepamatuju přesně, ale emm386 nebo himem.sys (prostě něco z DOSu) to takto dělával.

Já svého času měl QEMM a ten jakékoliv nestandardní programování trestal klasickou Black Screen of Death

Takhle nějak vypadal

https://user-images.githubusercontent.com/122238513/231559595-13e961a5-2500-47fe-a369-874041e46b04.png

QEMM jel celou dobu ve vm86, takže všechny výjimky odchytával on.

takova obrazovka byval muj nightmare. Diky za pripomenuti :-)

HIMEM.SYS aktivoval unreal režim a segmenty bez limitu. EMM386 zapínal VM86 + stránkování a segment limity na 64kB.