Vlákno názorů k článku Když céčko nestačí: GAS od Zdenek Kabelac - LZAP-ovi Bohuzel z Vase clanku vyzaruje odpor k syntaxi...

LZAP-ovi

Bohuzel z Vase clanku vyzaruje odpor k syntaxi AT&T a neustale jej 'shazujete' v porovnani se syntaxi Intel (proste je nepredstavuje ani prinejmensim rovnocene, ale jak jakousi odpudivou prekazku, kterou musi pisatel asm obtizne prekonavat). (dle meho jste napr. zapomel uvest ze mate u Intel syntaxe asi 20 ruznych typu mov-u podle toho, jake registry chcete zrovna pouzit)

Sam pisete, ze vkladani je nemotorne - no, bodejt by bylo, kdyz jste jej ne zcela nepochopil.

V komentari rikate, ze by se rychlost nejak nezvetsila - no jiste, Vas kod by zrejme i gcc lepe zoptimalizvalo, nez jste jej vy napsal (minimalne loop unrolingem), ale jde o to, ze vy zbytecne pouzivate registry na to, aby jste operandy prenesl do tech registru, ktere potrebujete. Jenze presne tohle vsechno se da zaridit temi modifikatory - cimz usetrite minimalne ty instrukce, kterymi je nacitate.
Dalsi velmi podstatnym rozdilem je, ze muzete rici, ktere veci nemuseji byt az tak nutne v registrech, ale muzete nechat na kompilatoru zvazit jestli by mohl pouzit misto registru nejakou 'pametovou' promennou - to je velka vyhoda oproti normalnimu psani assembleru - kdy muzete psat castecne 'abstraktni' assembler a v pripade nedostatku volnych registru se nezabyvat vzdy tim, jak nejaky counter vnejsi smycky pocitat. (Dulezite napr. pokud delate kod, ktery je
-fPIC komplivatelny, kdy pro statickou verzi prekladu mate jeste jeden registr volny - coz u x86 platformy s temi nekolika registry je velmi uzitecne)

Ano je to hodne mocny nastroj - mozna, ze mu casem prijdete na chut - ale jak rikam z Vaseho clanku cisela znacna nevrazivost k nemu a v podstate jste ani nepochopil zakladni principy prace s nim, coz si myslim, ze by autor, pisici takovyto 'zasvecene'
se tvarici clanek, mel znat - Kdyby jste zvolil
jinou formu - napr. Moje boje s GAS - tak bych asi nemel nic proti, ale kdyz pri popisu GAS ztravite polovinu clanku tim, ze ukazujete jak by to bylo dle Vas krasne s Intelovskou syntaxi, tak je tu neco spatne...

PS: V zadne pripade Vas nechci zrazovat od dalsiho psani clanku, ale proste nez se pustite do pole, ktere uz spousta lidi oralo pred Vami, je dobre se zeptat na jejich nazor.

----

Vety pana M.P.
* GAS - nechtene dite,...
* GAS - pouzival syntaxi AT&T -
GNU tvurci se rozhodli, ze vyrobi nekompatibilni
syntaxy pro Intel asm Linux
* ASM nema smysl kontrolovat
* nejlepe by bylo GAS odhodit
* ASM neni nikdy prenositelny
* Linux zavedl hokej

Na tyto argumenty/vety bylo nekolikrat panu M.P. odpovezeno - nicmene nekdo tu ma asi velmi dlouhe vedeni.

Takze GAS neni nechteny - do techto instrukci se preklada kod z Cecka, Paskalu, Forthranu atd. -proste je to neco jako bytecode pro Javu. Proc by meli vymyslet pro Intely neco extra ???

GNU GAS pro Linux nevymyslel - ten preci vznikl az nekdy v roce '92 - pred nim tu ale byla spousta ruznych BSD, SunOS aj - syntaxe AT&T tedy byla prirozenym vyberem.

Kdyz napisete pro GCC kod, ktery bude generovat ASM do Intelovoske syntaxe a prislusne vse opravite v cele jeho architekture - pak si muzete vyhazovat, co uznate za vhodne.

Ja osobne - aniz bych videl nativni asm treba od PPC, nebo od MIPS nemam zadny zasadni problem porozumet intrukcim v AT&T provedeni - vy se radeji naucite 20 ruznych syntaxi asembleru - no holt ja jsem asi pohodlnejsi...


ASM neni prenositelny - no jisteze asi jen tak nevezmete kod pro Motorolu a nevrazite jej do Intelu - ale napr. muzete prenaset kod mezi platformami na stejnych CPU - a diky tomu, ze vsude maji GCC s GAS tak to neni problem. To ale neznamena, ze se kvuli tomu, ze si intel mysli ze nektere registry jsou neco extra budu ucit 'x' ruznych mov-u, add-u, atp... Proste chci prenest registr A do registru B. Proc bych mel potrebovat neco jineho nez 'mov' (l,w,b pak slouzi jako specifikator prenasene delky.)



Linux zavedl hokej - no sam pisete, ze si chteli zjednodusit zivot - ale samozrejme, ze chteli - nebo Vy si ho snad komplikujete ???

Tedy jeste jednou a polopate - LINUX nema s GAS a jeho syntaxi nic spolecneho, To ze se pro implementaci zvolila AT&T syntaxe, kterou v dobe vzniku pouzivali snad vsichni krome Intelu, byla podle Vas neuveritelne spatna volba - tento Vas nazor bohuzel nesdilim.

Navic nevim nad cim se zrovna Vy rozciluje - zvladnul jste jiz nejakych XY assembleru - takze pridat si tam jeden dalsi s AT&T syntaxi by prece nemel byt zadny problem (a jesti si predstavte, ze kdyz jej zvladnete a budete pouzivat, budete moci zapomenout na tech zbylych xy :))

Přiznám se, že teď už chápu, že gas jako backend pro gcc je O.K.. Pokud gas nebyl určen na přímé programování v asm, pak je to v pořádku.

Jinak dokážu si představit, že kod bude prenositelny mezi ruznymi platformami na stejnem procesoru i tehdy, kdyby vsude vladla Intelovska syntaxe.

AT&T syntaxe urcite neni spatna volba, naopak neuveritelne dobra, pokud mela slouzit pouze jako vnitrni format pro gcc.

To je vas vyklad, ja se nesnazil nic shazovat, samotny system Linux je dukazem toho, co s GASem lze udelat. Clanek jsem napsal z pohledu programatora, ktery ma jiz nejake zkusenosti s programovanim na platforme Microsoft. Jeste jednou opakuji ze zadnou nenavist ke GAS nemam, ani k AT&T, je jasne, ze GAS nebyl sestrojen pro intel. Nad nenavisti (k ms-intel) byste se mel mozna zamyslet vy!

V porovnani s vkladanym masm assemblerem JE podle meho nazoru vlkadani v GASu nemotorne, nikde jsem ale nepsal ze je na nic nebo ze neni efektivnejsi nebo ja nevim co. Nalejme si cisteho vina, je proste jen jine.

Co se tyce optimalizaci, asi jste si toho porad nevsiml, ale tenhle clanek NEBYL o zadne optimalizaci. Co se tyce prikladu, tezko by zde optimalizator neco zmohl, a prosim nepiste mi tady o tom, ze by to mohlo byt rychlejsi o dve-tri instrukce, to je k smichu. Pokud rozumite GASu, pak jiste chapete, ze veci tykajici se optimalizaci NEMOHLY byt zahrnuty v jednom clanku. Opravdu se na me nezlobte, timhle jsem se ve clanku nezabyval. Kdyz si koupite ucebnici anglickeho jazyka, v prvni kapitole asi nebudete resit nepravidelna slovesa.

Kdybyste zapatral do archivu roota, nenasel byste o GAS zadne vetsi povidani a ja si zkratka rekl, ze by zde melo neco byt. Take proto, ze informace o GASu se tezko hledaji (alespon me to moc neslo -- ne, nebojte, info ovladat umim ;-). Chtel jsem zkratka dat navedomi, ano je zde najaky GCC a je tam neco jako GAS, da se vkladat, jde to takhle (AT&T nebo INTEL) a lze s tim psat i externe. TECKA.

Co se tyka nazvu clanku, tak se musite smirit s nazvem, ktery jsem clanku dal. Clanek si nekladl za cil byt jak vy rikate ``zasveceny'', podava zakladni informace, coz porad nemuzete stravit. Nelibi se vam, ze nekdo, kdo ma mensi znalosti problematiky nez vy, pise nekde clanky. Prominte, ale to bysme se asi nikam nedostali ;-P

Opravdu me mrzi, ze diskuzi pod clankem chapete jako moznost navazet se do autoru, moznost presentovat sve znalosti, ale vezte, ze diskuze to jsou proto, aby jsme mohli upresnit a doplnit podavane informace. Nediskutujme tedy o zasvecenosti ci nezasvecenosti, ale o GASu. Timto vam chci podekovat za velmi podnetne doplneni co se tyce optimalizace a zaroven dekuji za *SKVELY* tip na ffmpeg.

Jeste pred vydanim clanku jsem se rozhodl zadny dalsi dil nepsat (basm, nasm), a to diky jednomu cloveku ze skoly, ktery me od toho odradil. Jenom abyste se netrapil, ze uz o assembleru nebudu psat. Neni to kvuli vam ;-)

ps - howk. uz se k tomu nebudu nejak vyjadrovat, pokud mate nejake vyhrady, ktere se netykaji GASu, pouzijte prosim muj email, dekuji

Asembler je naprosto nutny pri programovani 3D her - muzete si myslet o prekaldacich C++ cokoliv (ja ja zcela bezne pouzivam), ale jakykoliv kod napsany clovekem optimalizovany na rychlost a ne na krasu(tedy pouzivani vsech existujich moznosti instrukci) bude jste dlouho rychlejsi nez stejny kod vytvoreny prekladacem. A prenositelnost znamena ze ho muzu prelozit na stejnem stroji bez upravovani sytaxe pod ms-windows jako na linuxu. A Instel standart je proste puzivany stnadart pro procesory INTEL.
To znamena, ze GAS je pouze pro mezipreklad z C++.
A ktomu by mel byt i kvalitni ASEEMBLER s Intelovskou syntaxi pouzitelny i pro vkladani do C++ kodu.
Bez toho se 3D hry nebudou bezne portovat na linux(na Windows jsou podstane lepsi prodeje a tak se primarne budou vyvyjit tam). Proste rozhoduje cena za portaci - a cim to jde jednoudusec tak je to levnejsi a rychlejsi.
A pokud neboudou pod Linuxem hry tak se bezne pouzivat v domacnostech LINUX nebude - nebot dite(pro ktere je PC hlavne porizovano) rekne tatinkovy, pokud tam nejdou me hry o kterych se bavim se vsemi kamarady ve skole, tak ten linux zahod a dej mi tam WINDOWS, jinak takovej pocitac ani nechci!!!
A to si uvedomte - snadnost vyvoje aplikaci znamena hodne aplikaci a tim praktickou pouzitelnost LINUXU pro jine veci nez jsou servery!!!