Vlákno názorů k článku Programujeme v jazyce Assembler v Linuxu: Úvod od Ivona Prenosilova - tento clanek je dosti mystifikacni a nicnerikajici blabol. jenom...

tento clanek je dosti mystifikacni a nicnerikajici blabol.

jenom malickost
pokud chcete pouzivat intervalove oznaceni tak je to takto:

env[x] x = <0; n-1> ne x = (0; n). zacinate od 0 vcetne. tedy alespon pokud pod linuxem nejni jina konvence env[].

pane ludwiku, jelikoz je autor viditelne nekompetentni, rada bych se zeptala Vas, pokud dovolite :-)

jak vypada adresovy prostor pod linuxem? kolik pameti je vyhrazeno jadru, kolik zustava programu? napriklad ve srovnani s NTckama:

dve minus neco giga pro program (pokud /3GB tak 3 minus neco), zbytek je jadro. dve (nebo tri) giga zacinaji od nuly, cili 0 - 0x80000000 patri procesu. (pripadne vic pro /3GB). dale se tam nachazi peb, kde jsou informace o nahranych modulech a podobne. take kazdy thread ma v process address space teb, kam se treba ukladaji per thread promenne. je tam jeste jedna stranka mapovana do jadra (pouze pro cteni) obsahujici treba aktualni timestamp - aby ku prikladu kvuli cteni casu nebylo potreba volat jadro (existuje neco takoveho na linuxu?). navic je treba mit minimalne ntdll.dll v adresovem prostoru (pro nativni programy) takze to bude o neco mene nez dve ci tri giga. mohl byste mi, prosim, osvetlit, jak to vypada na linuxu?

dekuji
ip

No prima - vy se me na neco chcete zeptat a pritom neuveritelnym zpusobem zkomolite moje jmeno, i kdyz se na teto strance vyskytuje minimalne 8x spravne :-((

Jmenuju se Michal Ludvig, ne Ludwik !!!

Nemam ted cas hledat presne udaje, ale pro x86 je to zhruba takhle (vezmu to od nejnizsich adres):

1) od cca 0x08000000 nahoru je mapovan vlastni kod programu
2) pak nasleduji globalni promenne
3) potom misto pro alokace skrz malloc & spol.
4) od 0x40000000 nahoru jsou mapovany sdilene knihovny
5) od 0xBFFFFFFF dolu je alokovan zasobnik (stack)
6) nejvyssich 512 MB (?) okupuje kernel

Celkem to mame 4 GB virtualniho prostoru.

Zde je to rozkresleno trochu nazorneji:
http://linuxassembly.org/articles/startup.html
(mimochodem napadna podobnost s castmi dnesniho clankem je jiste ciste nahodna :-)

6) Nejvyssi 1GB, respektive 1GB - 128MB. Nejsem si jisty co zabira uplny konec pameti, ale je to oznaceno jako __VMALLOC_RESERVE.

Ovsem pozor: existuji volby prekladu kernelu, ktere prepinaji na 2GB/2GB nebo dokonce na 4GB/4GB (zpomaluje !).

" tento clanek je dosti mystifikacni a nicnerikajici blabol. ","pane ludwiku, jelikoz je autor viditelne nekompetentni, rada bych se zeptala Vas, pokud dovolite :-) "
----------
Ne ze bych se chtel autora nejak zastavat, ale on napsal alespon neco - narozdil od Vas (teda pokud neberu v potaz hordu dotazu, urazek a nepresnosti, kterych jste se ve sve kratke odpovedi dopustila). A zbytek informaci, resp. jejich opravy - jak vidno - se da vyzjistit v diskuzi na jejimz zaklade se da clanek poopravit, aby do budoucna nikoho nematl. A ackoliv je mozna pan Ludvig kompetentnejsi nez autor clanku, jeho znalosti a zkusenosti by nam byly uplne naprd, protoze bez zde pritomneho clanku by se o sve informace pravdepodobne s nikym nepodelil.
---
Takze:
-- autorovi preji hodne kuraze do dalsiho pokracovani
-- Ivone Prenosilove studenou sprchu

Je dobře, že lidé tady doplňují a opravují autora, ale
nešlo by to bez těch urážek? Jestli jste někdy psali technicky článek, víte sami, jak je těžké to napsat tak, aby se žádný odborník neozval a nenapadl nějakou jeho část, neobvinil vás z nepřesnosti, špatného názvosloví apod.

Assembler je pro fajnšmekry, je to skutečně vysoká škola programování. A je těžké o tom psát vyčerpávajícím způsobem na malém prostoru zde vyhrazeném.

assembler ze je vysoka skola programovani??????? jezismarja! to je stejna pitomost jako kdyz se lide "trumfuji" v piti piva, plivani do dalky apod.
assembler je relikt minulosti a prestoze se dodnes na nektere veci pouziva (a nekteri lide v tom i vidi smysl) tak neni nic vic. a co se tyce programovani v nem tak to dokaze kazde pako... zkuste se na programovani zeptat napr. nekoho ze sceny kolem funkcionalniho progromovani - system typu, ruzne morfismy, kalkuly atd. tomu rikam "vysoka skola progamovani" a ne blbemu prepisovani pameti (coz assembler v podstate je, protoze vic abstrakce tam proste neni)

moc rad bych videl, jak by se Vam libilo mit napsany driver pro Vasi videokartu v nejakem vyssim jazyce. Zkuste se podivat po nejakem develop foru pro vysokorychlostni drivery...

No, kdyby kazdy dnesni programator zacinal na Assembleru (jako napr. ja :-), tak by dnesni systemy trhaly dlazbu svou rychlosti. Bohuzel tomu tak neni a vetsina dnesnich programatoru pojmy 'rychlost', "setreni mistem", 'elegantnost reseni', atd. ve svem slovniku nemaji. Pro dukaz si spustte $ top. :-)

Co se tyka GCC optimalizace (jiny thread). GCC je na poli x86 kompilatoru docela dost lama, vetsina komercnich ho tezce prevalcuje. A pokud vam nekdo tvrdi, ze clovek nezvladne napsat lepsi kod nez kompilator, neverte mu. Dvoj a vicenasobna rychlost neni vyjimkou. A desetinasobna uspora mista uz vubec ne.

Jde o pohled na vec, vy zastavate nazor, ze program musi byt "umelecke dilo" a jini (treba ja), ze musi byt maximalne efektivni a "setrny" k HW. Dodnes pisu v Assembleru hodne (i kdyz s rozmyslem), protoze je podstatny rozdil, jestli operace bezi 20 hodin, nebo 11, ci jestli aplikace bezici 24/7 ma zatez 80%, nebo 20%. S tim, ze programovani v asmu je "blbe prepisovani pameti" samozrejme nesouhlasim, blbe je v pripade, ze je blby programator, nebo prekladac.

Jedno Vám povím:

možná se Vám assembler nelíbí, ale mně se třeba nelíbí Java a všechny ty C-křížky a interpretovaný hovadiny. Jsem nucen pracovat na databázi, která má napsaný engine v Javě a přál bych Vám na tom pracovat! Jepice se svym jednodenním životem a nulovou inteligencí by ty dotazy zvládla daleko rychleji.

Teď se neuražte, ale programátor v Javě, C#, VB, VB-sketch, JavaSketch a tomu podobný --- to neni programátor, ale lama, která se naučila klikat v programech se zkratkou IDE (např. Borland*, VisualStudio, ...). Klikat umí bába v kanclu! Tak se vzpamatujte! Já si programátorů píšících v asm velice cením, protože o tom počítači aspoň něco vědí!

PS.: Doufám, že jsem nikoho moc neurazil a pokud ano, tak přijměte mou omluvu.

Jeste lepsi je strojovy kod.
Napr. na Z80 se dala udelat instrukce "nastav n-ty bit bajtu na jednicku", i kdyz procesor umel jen instrukce typu "nastav 4. bit bajtu na jednicku".

Protoze cislo bitu bylo jako bitove pole v opkodu instrukce, clovek si ho spocital, pouknul na adresu do kodu (SamoModifikujiciSe Kod (TM) ) a nechal probehnout. A vyhnul se tak zdlouhave a pokazde jinak trvajici smycce.

Kdyz clovek pouziva asm a abstrahuje od strojoveho zapisu instrukci, nevsimne si takoveto vyhodne vlastnosti strojoveho kodu.

Strojovy kod ma take tu vyhodu, ze se vyvojar nemusi rozmyslet, zda pouzije GAS nebo NASM. Zapis je zde jen jeden - ten uvedeny v datasheetu od procesoru :)

Kdybys ten samomodifikujici kod udelal na pentiu 4, trpel bys delayem v radu stovek cyklu, nez se vyprazdni pool mikroinstrukci a nez se data prelijou z datove do instrukcni cache.

Quake to pouziva, ale je to trba delat jen tehdy, kdyz se to vyplati --- tnz. usetri se tim vic nez stovka ztracenych cyklu.

a jeje, stara klasika Z80-tka :o)), spomenie si este niekto na ladislava zajicka a jeho "bity do bytu?"

Nevím, v čem je problém v nastavování/sha­zování bitů v Bajtu v assembleru? Pomocí logického OR nastavím, pomocí AND shodím

Uprimne Vam DEKUJI za podporu!

Navrhuji psat tento serial dvoupruchodove - autor vzdy nadhodi clanek, my (Michal Ludvig, ja a jiste se najdou i dalsi) opravime vetsinu chyb a autor to pak muze opravit a poslat jako dalsi clanek.

<nevim-zda-vazne>
A co zavest na Rootu wiki stranky, jejichz prvni obsah by byl plnen clanky?
</nevim-zda-vazne>

>Ne ze bych se chtel autora nejak zastavat, ale on >napsal alespon neco - narozdil od Vas
:-) vzdycky kdyz se rozhoduji, jestli napsat hromadu nesmyslu nebo radeji nenapsat nic ...

>(teda pokud neberu v potaz hordu
>dotazu
dotazy byly spise pro ty, kteri se o linux zajimaji. ja radeji zustanu u winnt, preci jenom se mi tento system libi daleko vice ;-)

>urazek
spise bych rekla realistickych zhodnoceni

>nepresnosti
>kterych jste se ve sve kratke
>odpovedi dopustila)
jakych nepresnosti jsem se dopustila?

add pan ludvig > omlouvam se za zkomoleni Vaseho jmena a dekuji za informace

add neologism > s timto si jdi otravovat na blackhole. coze? ze uz te tam nikdo nechce poslouchat? achich ouvej :-)

OT upozorneni: Nepise se 'add bod 1' ale 'ad bod 1'.

:-) vzdycky kdyz se rozhoduji, jestli napsat hromadu nesmyslu nebo radeji nenapsat nic ...
-------------------------------
---> implikaci tohoto vyroku dochazim k nazoru, ze s nejvetsi pravdepodobnosti pisete vzdy hromady nesmyslu, tudiz je dalsi debata irelevantni.

( Abychom si rozumeli: neurazim, pouze se snazim 'realisticky' interpretovat co jste prave napsala. Jestlize jsem od Vas zadne clanky na rootu necetl [ctu roota pravidelne a navic jsem se take snazil hledat], znamena to ze bud jste se nepokusila zadny napsat - pak plati ma predchozi odpoved a Vase kritika neni v zadnem pripade na miste. Jestlize jste se pokusila neco napsat a <nebylo to zverejneno>/<rozhodla jste se to nezverejnit>, pak plati to co jste odpovedela => Vasimi slovy: byla to hromada nesmyslu). Nicmene - jestli jsem se dopustil chybne interpretace Vaseho vyroku, milerad si to necham vysvetlit.

ano, samozrejme, ze pisi hromady nesmyslu - proto nikdy neuvidite muj clanek na rootu. nicmene ve foru pod clanky se to mezi ostatnimi prispevky ( treba i Vasemi) s prehledem ztrati :-)

>Jestlize jsem od Vas zadne clanky na rootu necetl[ctu roota pravidelne a navic jsem se take snazil hledat], znamena to ze bud jste se nepokusila zadny napsat - pak plati ma predchozi odpoved a Vase >kritika neni v zadnem pripade na miste.
jestli berete clanek na rootu jako bernou minci schopnosti kritizovat, tak to se nad sebou zamyslete :-)

jak tak nad tim premyslim, dosti to souvisi s mymi predeslymi nekompetentnimi blaboly do fora pod clanky. pokud chce byt root profesionalni a odborny, nemuze strpet clanky jako je tento, ktery viditelne psal nejaky zacatecnik. a mrzi me to jeste z toho duvodu, ze takto spatne napsany clanek uz tu dlouho nevysel ...

btw jeste jste neodpovedel, kde jsem se dopustila onech "nepresnosti".

Pravda je, že některé nepřesnosti v článku obsažené jsou do nebe volající a ukazují na autorovy elementární neznalosti. Neztotožňuju se s Vaším názorem, že napsat článek s četnými a zásadními chybami a spolehnout, že ho někdo opraví, je legitimní způsob odborného publikování.
Souhlasím s tím, že Ivona Přenosilová by si mohla nalézt duchaplnější způsob, jak si obhájit svoje místečko na slunci; možná by jí v hledání mohla pomoci i ta studená sprcha.
Autorovi taktéž přeju kuráž, dále aby mu vydrželo jeho nesporné nadšení pro assembler, a také aby našel odvahu a skromnost požádat někoho o přečtení a korekci článku ještě před jeho uveřejněním.

Je to jak Ludvig popsal, ale ten kernel má 900MB (ty jsou lineárně pomocí velkých stránek namapovány na prvních 900MB paměti), nikoli 512MB. Zbytek se používá v kernelu na virtuální alokaci (alokace více nesouvislých stránek mapována do souvislého adresního prostoru) a cache mapování, když jádro potřebuje přistupovat k vyšším adresám.

Stránku s timestampem Linux nemá, při zjištění času se vždy volá kernel. Novější jádra namapují procesu stránku, na které se nachází vstup a výstup ze syscallu (tzn. to o int 0x80 z článku taky moc neplatí) --- tam se podle typu procesoru zapíše intrukce sysenter (Intel) nebo int 0x80, pokud je procesor starý, že to neumí (AMD syscall to asi neumí, ale nevim --- každopádně by tam šel jednoduše dopsat).

Thready jsou implementovány tak, že pro každý thread je jeden deskriptor v LDT a na něj ukazuje GS. Pomocí čtení paměti přes GS je možno zjistit, který thread se právě vykonává nebo přistupovat na thread-specific datové položky (dělají se tak, že se před deklaraci globální proměnné napíše __thread).

nt na novejsich procesorech pouzivaji sysenter/sysleave tez misto int 2eh. mapovana stranka nejni jen pro timestamp, ale jsem moc lina divat se pro co jeste ...

per thread zalezitosti se pod winnt resi pomoci selectoru v gdt (fs registr). pri context swapu se meni na adresu TEBu noveho threadu. pokud se pro kazdy thread pouziva polozka v LDT neomezuje to maximalni pocet threadu?

to same co pisete pro gs registr plati na nt pro fs registr - je tam datova struktura obsahujici TLS

NT maji odlisne FS na kazdem procesoru a z neho urci o jaky thread se jedna?

LDT mnozstvi threadu v procesu na Linuxu omezuje. Mozna kdysi ve starych libc se thread urcoval pomoci ESP. To GS kazdopadne uz zmenit nejde --- je to zakompilovane do vsech programu, co pouzivaji thread-local promenne.

>NT maji odlisne FS na kazdem procesoru a z neho urci o jaky thread se jedna?
ano, ale je to trochu slozitejsi. nejprve je dulezite rozlisit kernel a user mode.
fs je rozdilne na kazdem procesoru i v kazdem user mode threadu. ted prichazeji
v potaz dva gdt selectory:

selector 0x30 - ten ukazuje na PCR (PCRB), process control region, ktery je samozrejme
na kazdem procesoru jiny, ale nemeni se.
selector 0x3b - ten ukazuje na UTEB (user mode thread environment block). ten
se meni (base) pri kazdem context switchi.
DPL=3, Base=0x7FFDE00 (1st thread), Lim=0x00000FFF
pro kernel mode thready je base = 0
jak vidite, tento selektor ukazuje do address space procesu, do
ktereho nalezi.

kdyz se zavola syscall, v syscall handler prologu se nastavi fs == 0x30 - cili
ukazuje na PCR daneho procesoru, na kterem zrovna bezi. tam je ulozen odkaz treba
na aktualni thread object, etc. kdyz se zase prepina zpet z kernel modu do user
modu, nastavi se zpet fs registr na 0x3b. jelikoz tento selector ma pro kazdy
user mode thread jinou bazi (a ukazuje na jinou datovou strukturu), umoznuje
pouzivat thread local variables.


>LDT mnozstvi threadu v procesu na Linuxu omezuje. Mozna kdysi ve starych
>libc se thread urcoval pomoci ESP. To GS kazdopadne uz zmenit nejde ---
>je to zakompilovane do vsech programu, co pouzivaji thread-local promenne.
fs take menit nejde. kvuli optimalizaci se pouziva inline kod.

Mno, kdysi ve starych libc - ja bych tak neprehanel - rekl bych, ze takhle zmena (thread-identifikace via %gs) je az od kernelu 2.5.x. Navic tu zustavaji architektury, ktere specialni registr pro thready nemaji, tam se to stale provadi via %esp (tzn. se zaokrouhli na 2MB nahoru, kde je struktura __pthread_desc, ci neco takoveho, tam jsou vsechny thread-local veci, ala pointer na lokalni promenne, thread errno, id, atd.).

Myslis jako ze procesor utahne vic jak 16000 threadu ? (maximalni velikost LDT je 64KB).

maximalni velikost ldt (i gdt) je sice 64 kilo, nicmene deskriptor ma 8 bajtu, ne 4. cili neni to 16k threadu, ale 8k threadu. je to velke cislo i tak. neprela jsem se, jestli je mozne to naplnit (ano je), nebo ze je to realne. navic pod linuxem, kde je to s threadama trochu slozitejsi (podporuje linux vubec prave kernel mode thready? shedulable entita je proces, nebo thread pod linuxem?), takze se spise pouziji procesy. byla to jen otazka, nic ofenzivniho :-)

> Novější jádra namapují procesu stránku, na které se nachází vstup a výstup ze syscallu.

Jenže KAM ji mapují? Hledal jsem v hlavičkách pro glibc a nic jsem nenašel. Je to pevná virtuální adresa, která nezávisí na verzi kernelu? Jaká?

Jak se taková stránka volá, když i386 neumí pro "call" a "jmp" jiný operand než pc-relativní? To každé místo, kde v kódu volám kernel generuje relokaci? Pro programy to sice nevadí, ale co volání kernelu z -f PIC kódu? To tam bude navíc další jump instrukce s indirekcí přes GOT? Každý nepřímý skok na AMD i Intelu flushuje pipelie. Nebylo by lepší mít vsyscall stránku namapovanou na začátku každé knihovny?