• úvod
  • témata
  • události
  • tržiště
  • diskuze
  • nástěnka
  • přihlásit
    registrace
    ztracené heslo?
    LITTLELIAssembler
    there are 10 types of people in the world. those who understand binary, and those who don't.
    windows bring the power of yesterday computers in nowadays
    sexy nastenka
    rozbalit záhlaví
    KOMPAS
    KOMPAS --- ---
    <ot>
    KYOSUKE: to mi pripomnelo linuxove lp0 on fire ^_^
    kdo neveri, at tam bezi, ac se to nezda, tato chybova hlaska mela sve opodstatneni
    </ot>
    KYOSUKE
    KYOSUKE --- ---
    http://en.wikipedia.org/wiki/Halt_and_Catch_Fire

    Halt and Catch Fire, known by the mnemonic HCF, was originally a fictitious computer machine code instruction claimed to be under development at IBM for use in their System/360 computers, along with many other amusing instructions such as "Execute Operator".

    :-D

    Nebo taky: http://www.csd.uwo.ca/~magi/personal/humour/Computer_Audience/Assembler%20as%20it%20REALLY%20is.html :-D
    SHALDAN
    SHALDAN --- ---
    _K5_: jasně .. podívej se na masmforum v sekci IDE a uvidíš ... já mám rád WinAsm: http://www.winasm.net/ ... má i resource editor a podobné vychytávky .. zvykl jsem si na něj tak, že v něm i koduju webové stránky :))
    _K5_
    _K5_ --- ---
    Existuje něco jako visual assembler? Tedy IDE prostředí pro assembler podobné třebas Borlandím Delfám či Builderu? Protože takové IDE ušetří až 50% práce....
    _BENNY
    _BENNY --- ---
    a taky hadam ze je v samotne korporaci Intel poraadnej bordel. napisu na helpdesk ze mi 64bit kompajler nejde nainstalovat na x64 server edition ptz ma ten jejich instalator chybu. za mesic se mi ozve nejakej indican Popokatepetl s tim, ze si mam prece nainstalovat tu jejich 64bit verzi ktera prece funguje. odepisu, ze ne, ze nefunguje, prilozim screenshoty installeru a odpoved uz zadna. za mesic napisu znovu, odpoved opet zadna. za tri mesice mi poslou mail, ze si muzu konecne stahnout funujici 64bit verzi pro x32 edici. k nasrani.
    LITTLELI
    LITTLELI --- ---
    hmm coz bezpecne bori trebas mplayer :)
    ale tam jsou kusy kodu v asm .)
    _BENNY
    _BENNY --- ---
    LITTLELI: mno widlacky ICC ma byt plne kompatibilni s MSVC a linuxacky ICC ma byt plne kompatibilni s GCC. prvni je splneno na jednicku s hvezdickou, to druhy je mizerie. dle meho ciste osobniho nazoru je to dano linuxovou systemovou infrastrukturou, je v tom proste hroznej bordel :) a mozna bych mel byt vubec rad, ze gcc na x86 funguje tak jak funguje (tedy na 70%) :)
    s deploymentem bych si hlavu nedelal, je spousta aplikaci ktere sazeji na vykon (multimedia, system-level appz atp), v cemz je ICC bezkonkurencne nejlepsi.
    LITTLELI
    LITTLELI --- ---
    _BENNY: hm a neni to tim, ze jaksi ten deployment je daleko slozitejsi, zatimco to gcc je tam "alespon" vsude?
    SHALDAN
    SHALDAN --- ---
    jinak jsem právě přeložil 28. tutoriál týkající ho se Win 32 Debug API ... hmm .. docela šťavnaté téma :))
    http://shaldan.xf.cz/
    _BENNY
    _BENNY --- ---
    LITTLELI: bohuzel - Intel pro Linux stoji uplne za hovno, samej internal error a nonimplemented stuff. je mi lito ze to musim tak rict, ale ICC pro Linux pro x86 je jeste horsi nez GCC ;)
    LITTLELI
    LITTLELI --- ---
    no on ten Intel Compiler je nejlepsi i v Unixovych prostredich :)
    jenze to bych i cekal, gcc neni jenom pro Intel zeano.
    _BENNY
    _BENNY --- ---
    SHALDAN: prechod na 64bity planuju uz dlouho, brzdi me akorat neschopnost Intelu dodat funkcni 64bit verzi produkujici 64bit kod integrovany do MSVC... jsou to liny mrchy, ale kompajler na Widle maji nejlepsi :)
    SHALDAN
    SHALDAN --- ---
    LITTLELI: :)))) ... ono je to stejně asi pro většinu z nás taková srdeční záležitost .... bojovníci, jak psáno někde v úvodu stránek, kde se dá stahnout masm balík :))).
    V době JAVY, Delphi a podobných skládaček bude asi čím dál tím méně příležitostí se čistě assemblerem živit nebo spíše přiživit, ačkoliv opravdu si myslím, že pro zkušeného assembleristu není problém s pomocí assembler IDE udělat v pohodě a rychle pěknou Win32 aplikačku, která běží jako hodinky a má pár kb :)). A vo tom to je. Všichni víme, že o nepoužitelnosti assembleru kolují mýty, které platily tak před 10 lety. Samozřejmě mluvím o assembleru pro x86, osobně přímo o MASM.

    Jsou ale jistě mezi vámi borci, co kódují na tak hlubokém levelu, že by se mi zatočila hlava :))
    LITTLELI
    LITTLELI --- ---
    hmm, moje tam ani nesahaji. proste sem si precetl docku.
    k poradnym toolum sem se stejne nedostal.
    SHALDAN
    SHALDAN --- ---
    LITTLELI: :)) ... ty seš na mě moc velikej profík a znalec ..... moje obzory končí v běžných Win32 aplikacích, případně zbožné přání ve hrách :)
    LITTLELI
    LITTLELI --- ---
    no pokud potrebujes brutalni silou zpracovat velke mnozstvi dat, tak je dobry premyslet o SIMD, nekde to moc nejde.

    zkoumal nekdo tu autovectorization v gcc?
    SHALDAN
    SHALDAN --- ---
    jinak si myslím, že dnešní kompilátory C++, třeba Visual mají mnoho možností optimalizace, pokud se do nich trochu člověk ponoří, věřím, že ve většině případů ani assembler není potřeba a kámen úrazu je především vlastní uspořádání dat, nikoliv samotný kod. Alespoň to tvrdí Randall Hyde ve Write Great Code II :))


    _BENNY: Však už můžeš psát pro 64-bity .. tam to je už s registrama lepší, pokud se nepletu :))
    _K5_
    _K5_ --- ---
    no, ono je samozřejmě optimalizovat (na rychlost) a optimalizovat (na velikost kódu)

    je mi jasné, že tam, kde bude program čekat na uživatele, nemá cenu honit rychlost

    ale tohle je pro nás assemblerové začátečníky zatím moc složitá věda ;-)
    LITTLELI
    LITTLELI --- ---
    co se tyka optimalizace kodu tak si dovolim odkazat na nastenku kde jsou linky na dokumenty o optimalizaci, dobre techniky pro optimalizaci jsou (alespon) parovani resp. razeni instrukci tak, aby do pipe pritekaly pokud mozno plynule na jejich execution cycle, pak neni dobry kombinovat mov eax, 0 a lodsb (al) tj plneni velkeho a maleho registru v toku za sebou. dochazi pak k false dependency.

    ale tyhle veci jsou markantni spis kdyz je nejaka kriticka cast kodu se spoustou iteraci a skoku. btw trebas se doporucuje temer vzdy skakat s branch instrukcemi dopredu a dozadu skakat s jmp. protoze se na to chyti static prediktor, na prvni jmp je tam docela pravdepodobnost, ze udela cache miss, ale v dalsich iteracich uz je to v pohode. static prediktor na opusteni toho cyklu pak je levnejsi a s nizsi pravdepodobnosti cache miss, protoze je tam zase (ruzne dlouha) prefetch queue.

    dobra optimalizace je pouzivat neprenositelny cmov :) 686+ only :)
    ty dokumenty jsou opravdu spickove, hlavne ty od AMD :) dokonce tam jsou i pomucky na to jak kodit v C aby clovek kompileru pomohl k lepsimu kodu.
    _BENNY
    _BENNY --- ---
    no jasne, registry jsou nejrychlejsi pamet, HLL programy je nepouzivaji ptz je pouzivat neumi (vzdycky si je necim zaserou) a x86 jich ma krapet malo :)
    SHALDAN
    SHALDAN --- ---
    _K5_: no to bude těžké poradit .... za prvé nejsem zkušený :)) a za druhé je to případ od případu ... ale troufám si říct, že asi lehce nebude možné (pro začátečníka určite ne) vymyslet optimalizovanější kod přímo v assembleru oproti třeba .if apod... a i ti největší guru to používají, takže můžeš pak klidně lehce spát :))

    Ale jinak obecně platí, že čím častější užití registrů, tím to běží rychleji :))

    Nejlepší informace jsou jednoznačně na www.masmforum.com .. ale tam už asi seš předpokládám :)
    Kliknutím sem můžete změnit nastavení reklam