hmm, moje tam ani nesahaji. proste sem si precetl docku.
k poradnym toolum sem se stejne nedostal.

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 :)

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?

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 :))

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 ;-)

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.

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 :)

_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 :)

to ja si pred par dny (pracovne) musel vymyslet svuj vlastni p-kod assembler... v jednoduchosti je kraasa :-)

SHALDAN: no, jsem teprve u první kapitoly ;-) a assembler x86 vlastně vůbec neumím

CERBERUS: jo jo, tak to jsem tam zapomněl, jinde xory mám. Určitě by se dalo optimalizovat i to, že jsou tam konstatny 32 a 63 (což je "skoro" 64 a tedy rotace o jeden bit ;-)

Mě v tuto chvíli jde spíš o obecné principy, například jestli není lepší psát míň "assemblerově" a víc "preprocesorově" (tedy místo CMP+JMP psát .IF .ENDIF), nebo bych chtěl pochytit nějaké moudro, jestli víc využívat registry procesoru nebo naopak každý prd cpát do RAMky jako je běžné ve vyšších jazycích atd

_K5_: Hezke :) Ale pri zbeznem pohledu jsem narazil na 'mov eax,0'.Radsi bych dal 'xor eax,eax', je to mensi a rychlejsi :)

_K5_: šikovné :)) ... jsem rád, že ty překlady kromě mně přineslo něco užitečného i někomu jinému :). Graficky lepší a příjemnější forma tutoriálů se připravuje na stránkách winasm komunity, takže až to tam dají, dám vědět :))

V rámci samouky assembleru (díky za SHALDAN ) jsem sesmolil takovou malou pitominu, uvítám konstruktivní kritiku, co se má nebo dá udělat jinak/lépe. Zkompilované s návodem a příkladem je to tady, celý zdroják se mi sem nedaří pastnout :-(, asi vadí mix uvozovek, apostrofů a vran v definicích, ale bez těch se obejdete ;-)

.code
start:
invoke GetCommandLine
mov CommandLine, eax

invoke PathGetArgs,CommandLine
mov ParamsText, eax
mov esi, eax
lodsb
or al,al
jz ZobrazNapovedu
cmp al, 63
je ZobrazLepsiNapovedu
lodsb
cmp al, 32
jl ZobrazNapovedu
lodsb
cmp al, 32
jl ZobrazNapovedu
mov esi, ParamsText
add ParamsText, 2
mov eax,0
lodsb
sub al, 48
cmp al, 7
jl CislaOK
sub eax, 7h
cmp al, 7
jl @F
xor al, al
@@:
add eax, MB_ICONERROR
jmp NaplnPromenne
CislaOK:
or al,al
jz UkazMessageBox
add eax, MB_ICONQUESTION
mov ParamsCaption, offset MsgBoxCaption3
NaplnPromenne:
mov Vzhled, eax
jmp UkazMessageBox
ZobrazLepsiNapovedu:
mov ParamsText, offset MsgBoxCaption4
mov ParamsCaption, offset MsgBoxCaption0
jmp UkazMessageBox
ZobrazNapovedu:
mov ParamsText, offset MsgBoxCaption1
mov ParamsCaption, offset MsgBoxCaption0
UkazMessageBox:
invoke MessageBox, NULL, ParamsText, ParamsCaption, Vzhled
invoke ExitProcess, eax ;errorlevel = kód stisknutého tlačítka
end start

//OT

Velmi se omlouvam za SPAM, ale rad bych Vas pozval do nove zrizeneho klubu :

[ Software testing - Quality Assurance aneb testuji, testuješ, testujeme software ]

//OT

KYOSUKE: co jsem v rychlosti našel u Agner's Fog Pentium Optimazition :

BT, BTC, BTR, and BTS change the carry flag but leave the other flags unchanged. This causes a false dependence on the previous value of the flags and costs an extra uop. Use TEST, AND, OR or XOR instead of these instructions.
------------------
18.5 Bit test (all processors)
BT, BTC, BTR, and BTS instructions should preferably be replaced by instructions like TEST, AND, OR, XOR, or shifts on P1, PMMX and P4. On PPro, P2 and P3, bit tests with a memory operand should be avoided.

Jinak teda na http://developer.amd.com/documentation.aspx se objevily nový zajímavý věci, K8 a podobně by stálo za to hodit na nástěnku. Zkusím se tím trošku probrat. ;-)

Hele, lidi, jak je to s tím BTčkem? Fakt je pomalejší, než TEST? Teda z toho AMDího tlustopisu mi to vůbec nepřišlo. Budu si ty guidy muset asi vytisknout, zjistil jsem, že ty AMDí jsou fakt pěkný. ;-)

hehe .. tam je dobrej flame ohledne optimalizace přes bitová pole hned v prvním vláknu :)))

http://www.root.cz/clanky/fixed-point-arithmetic/ :-)

Ale to zas bude flejmů... :-D

ARCHDRONE: jukni do nejakyho demokodu :) to je casto velmi cryptic ;)